reproducible builds: timezone(?) leaks into build artifacts
while trying to verify the reproducibility of the 1.0.1-RC2 artifacts, I ran into a difference: the jar files' entries (for example for pekko-parsing_2.13-1.0.1-RC2.jar) have an extra field of type 0x000a (https://commons.apache.org/proper/commons-compress/apidocs/org/apache/commons/compress/archivers/zip/X000A_NTFS.html) containing file timestamps.
These timestamps are set to Sat Jan 01 00:00:00 CET 2000 on the staged release, while they are Sat Jan 01 01:00:00 CET 2000 on my local build - only the hour is different. It almost seems as if the intent was to have a fixed value here, but the timezone of the build machine is leaking into the artifact.
Changing the TZ environment variable during the build did not affect the timestamps, but building in a different build environment did produce the same timestamps - I still have to figure out what the relevant difference is.
Last time I looked into these kinds of things, I think it was a combination of osgi, sbt-assembly, and sbt-reproducible-builds which created weird fields, but I cannot remember exactly. I remember weird code trying to synthesize these fields regarding the time stamps...
Since these fields seems to use an epoch style encoding of instants, is, what you are observing actually different timestamp longs in the files?
This has affected us for a while. My usual timezone is Dublin but I'm currently in CET. It would be great to sort out where this diff comes from.
I think this is caused by https://github.com/apache/commons-compress/pull/472
Is still still an issue after https://github.com/apache/pekko-http/pull/488 ?
Checked the 1.1.0-M1 artifacts, those are now reproducible for 2.13, so indeed the fix seems to have the intended effect.
I used:
sbt "set ThisBuild / net.bzzt.reproduciblebuilds.ReproducibleBuildsPlugin.reproducibleBuildsCheckResolver := DefaultMavenRepository; shell"
> reproducibleBuildsCheck
Filed https://github.com/raboof/sbt-reproducible-builds/issues/323 to make this a little easier
I also tried to reproduce for Scala 3, which showed two further problems:
- #565
- #566