On 2025-10-09, Soren Stoutner wrote: > On Thursday, October 9, 2025 12:00:09 AM Mountain Standard Time Guillem Jover > wrote: >> On Wed, 2025-10-08 at 15:10:49 -0700, Soren Stoutner wrote: >> > On Wednesday, October 8, 2025 1:41:17 PM Mountain Standard Time Guillem >> > Jover >> > >> > wrote: >> > > As was mentioned on the list thread, this change would require for > tzdata >> > > to be installed everywhere, otherwise the results are bogus (AFAIUI). >> > >> > There may be some great difficulty caused by making tzdata a dependency of >> > reprotest. If there is I would be interested in know what it is. >> >> Adding tzdata as a dependency to reprotest would not affect what gets >> installed in the chroots where the packages get built. Forcibly >> injecting that in the chroots would be wrong in so many ways, when we >> have made it possible to not need to have it installed in buildds (or >> as part of the build-essential transitive set) by default. >> >> > It should be noted that the reproducible builds project successfully > builds >> > this package. >> > >> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ >> > pyinstaller-hooks-contrib.html >> > >> > My memory is that didn’t used to be the case. So, either my memory is > wrong >> > or reproducible builds recently started using the Continent/City > (zoneinfo) >> > syntax. In either case, I think it would be advantageous for reprotest > (and >> > the Salsa CI test that uses it) to mirror the behavior of reproducible >> > builds. >> Given that tzdata is not installed unless (build-)depended on >> explicitly, using the Continent/City notation seems wrong for the >> reproducible-builds to be setting it like that. >> >> But in any case if that package fails to build when the current >> timezone is set to a valid value that the package does not support, >> then that is definitely a bug in that package that should be fixed. >> Trying to force the build/test (or user) systems to use another format >> is not reasonable. > > As noted earlier, it builds and tests fine in Debian’s official reproducible > builds. I would assume that means that the tzdata package is installed and > that the timezone modifications are done using the Continent/City (zoneinfo) > syntax when reproducible builds are run.
I have seen some packages where reprotest catches timezone related issues that tests.reproducible-builds.org appears to miss. If TZ=GMT+12 and TZ=GMT-14 are valid settings for TZ in any cases (even if some definitions of TZ are more restrictive or require a different format), then I do not see a problem with reprotest setting those, and any package that fails to build with those values set, in my opinion, has a bug. I could see the case for making the timezone values configurable, much like the locales can be configured, perhaps something like: --vary=timezone,timezones.tz=Etc/GMT+12:/usr/share/zoneinfo/Etc/GMT-14 As that allows testing all sorts of permutations, even if the default is unchanged. > I was under the impression that reprotest desired to produce the same results > as the official reproducible builds. Is that not correct? That is not correct. I am not even sure what an "official reproducible build" is, given that the main goal of Reproducible Builds is to make it possible for arbitrary third parties to independently verify the results of builds. I would say reprotest is a bit like reproducibility fuzz testing... it creates an intentionally wacky, weird build environment to actively shake out bugs, and gives you --vary and other options to fine tune which things to, well, vary. While reprotest and tests.reproducible-builds.org test many of the same things, reprotest is probably a bit more aggressive by default, varying build path and perhaps a few other things (ASLR?), as well as just testing a different set of locales by default, and probably a few other things: https://tests.reproducible-builds.org/debian/index_variations.html I think the salsa-ci reprotest jobs do not use the reprotest defaults either, at least normalizing the build path, if I recall correctly. Also, https://reproduce.debian.net, which actually tests against packages in the Debian archive, varies as little as possible, using a predictible build path consistent with the one used by buildd.debian.org and not intentionally varying anything (although obviously the system clock is going to be different, and things like the kernel version are likely to change as security updates happen). So, I can see some frustration that they are not all testing the same things, though they each serve a somewhat different purpose, even though they are all ostensibly tools for testing for reproducibility... live well, vagrant
signature.asc
Description: PGP signature
