prefix-dev
Rattler build does not preserve mtime during package installation
I know this is absolutely insane, but here goes.
Bazel sets mtime of installed files 10 years into the future. If the files don't have an mtime long in the future, it claims they are corrupt.
https://github.com/bazelbuild/bazel/issues/14355 https://github.com/conda-forge/ray-packages-feedstock/pull/226
The bazel package on conda-forge contains some files which must have this future mtime crap:
When installed via conda/mamba-build:
File: _build_env/share/bazel/install/ee1819c7c6ef276537e1ca6a5f696249/A-server.jar
Size: 113415341 Blocks: 221520 IO Block: 4096 regular file
Device: fc00h/64512d Inode: 2038632294 Links: 23
Access: (0644/-rw-r--r--) Uid: ( 5061/ conda) Gid: ( 5061/ conda)
Access: 2025-08-29 19:21:39.072630474 +0000
Modify: 2035-10-10 10:10:00.000000000 +0000
Change: 2025-08-29 20:06:59.376634651 +0000
Birth: 2025-08-29 09:49:58.504359503 +0000
When installed via rattler-build:
File: build_env/share/bazel/install/ee1819c7c6ef276537e1ca6a5f696249/A-server.jar
Size: 113415341 Blocks: 221520 IO Block: 4096 regular file
Device: 252,0 Inode: 1964492878 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 5061/ amorton) Gid: ( 5061/ amorton)
Access: 2025-08-29 15:15:52.145597243 -0500
Modify: 2025-08-29 15:15:52.168597195 -0500
Change: 2025-08-29 15:15:52.168597195 -0500
Birth: 2025-08-29 15:15:52.145597243 -0500
To anyone that finds this, the following appears to be a viable workaround in your build script for the time being:
find $CONDA_PREFIX/share/bazel/install | xargs -n 1 touch -mt 203601010101
I will also file an issue with the conda-forge bazel feedstock, since I don't know that these files should be packaged.
Hey @apmorton thanks for the investigation. It looks like a painful one!
This is actually a rattler issue as rattler is the one dealing with the installation of files. I think we would ideally not have to copy over file metadata as that is obviously going to cost some valuable time when installing but I guess if we have to ... we'll do it.
Do you think this will also be an issue when packaging software with rattler-build? Because we do things to make sure that the timestamps are deterministic. I believe we are actually writing the $SOURCE_DATE_EPOCH time as the timestamp for all files in the tarball, and we don't have a way to escape that right now. Would love to hear your thoughts.
If the only place this matters I bazel, then it probably isn't worth fixing - the workaround I posted is ugly, but works.
This would also be an issue in rattler-build if/when the bazel feedstock itself converts to rattler-build.
I think the best thing to do for now is continue pulling on this over at https://github.com/conda-forge/bazel-feedstock/issues/273
Perhaps we can simply not package these files or patch out the future mtime check within bazel itself?
Actually, this only happens when run in an Alma9 container. I don't see it happening in Ubuntu 24.04, there the mtime is set correctly.
I think #1891 might be part of the same issue, related to alma9? I posted some additional possible debugging steps in there. Maybe someone can run them?
Adding CAP_FOWNER doesn't make a difference. I'm also confused why this would do so. conda(-build) can successfully extract these files.