Bug#1117626: reprotest: Use the Continent/City (zoneinfo) syntax for time zone variation

[Vagrant Cascadian]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20251009/27c78d93/attachment.sig>