While running Lintian's testsuite on a much faster system compared to my Sid amd64 running development workstation, I noticed the following test suite failure when running "private/runtests" or trying to build the package on a more modern and more performant box with Bookworm amd64. (Use "private/runtests -o test:ancient-source" to just run the affected test.) # Hints do not match # # --- debian/test-out/eval/checks/unpack/ancient-source/hints.specified.calibrated # +++ debian/test-out/eval/checks/unpack/ancient-source/hints.actual.parsed # -ancient-source (source): unpack-message-for-source tar: ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59 # +ancient-source (source): unpack-message-for-source tar: ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59 # debian/test-out/eval/checks/unpack/ancient-source/generic.t .. 1/1 # Failed test 'Lintian passes for ancient-source' # at /home/abe/debian/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. But I neither get that failure on my Sid amd64 development workstation nor on SalsaCI (https://salsa.debian.org/lintian/lintian/-/pipelines) nor in pbuilder nor on the buildd (https://buildd.debian.org/status/package.php?p=lintian). So I tried to find differences. $ als debian/test-out/packages/checks/unpack/ancient-source/ancient-source_1.0.orig.tar.gz ancient-source-1.0/README -rw-r--r-- root/root 21 1970-01-01 00:59 ancient-source-1.0/README $ env TZ=GMT als debian/test-out/packages/checks/unpack/ancient-source/ancient-source_1.0.orig.tar.gz ancient-source-1.0/README -rw-r--r-- root/root 21 1969-12-31 23:59 ancient-source-1.0/README But these two outputs are identical on both hosts, the one where the test fails and one of those where it doesn't fail. So the timestamp actually seems to be the same and it's just Lintian's parsing of it seems to differ. The only potentially relevant package version difference I found was tar, which is at 1.34+dfsg-1.1 in Sid and 1.34+dfsg-1 in Bookworm due to a recent FTBFS on 32-bit architectures. But the sole change was in debian/copyright and also downgrading the tar version in Sid to the one from Bookworm didn't make the test failing on Sid. Also running the test suite with "env TZ=GMT" prepended didn't make a difference. Additionally, build 2.116.2 did work on that very same box where 2.116.3 now FTBFS. So it seems to have caused been a recent change (since 2023-01-29) in Bookworm. Or maybe such a change just uncovered an older bug. The locales of two systems where it builds and where it no more builds: Builds fine: LANG=C.UTF-8 LANGUAGE= LC_CTYPE="C.UTF-8" LC_NUMERIC="C.UTF-8" LC_TIME="C.UTF-8" LC_COLLATE="C.UTF-8" LC_MONETARY="C.UTF-8" LC_MESSAGES="C.UTF-8" LC_PAPER="C.UTF-8" LC_NAME="C.UTF-8" LC_ADDRESS="C.UTF-8" LC_TELEPHONE="C.UTF-8" LC_MEASUREMENT="C.UTF-8" LC_IDENTIFICATION="C.UTF-8" LC_ALL= No more builds fine (but hasn't change since when it still built fine): LANG=C LANGUAGE= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL= Also both systems have "Europe/Zurich" in their /etc/timezone. So I currently have no idea where the difference comes from or which environmental change (variables or package versions) triggers it. Cc'ing the Reproducible Builds project in the hope that they have an idea what could have caused the 1h offset in the testsuite on that one box. Bug report written on the system where the test failed.
Axel Beckert <abe@debian.org> writes: The exactly one hour difference makes me suspicious something is going on with time zone conversions. That's also consistent with the one hour time difference between UTC and Europe/Zurich at New Years. Looking at the source of tar, the output timestamp for this error seems to be in local time by default, which would certainly explain the problem but not why we're not seeing it everywhere. I would be curious if it went away if you added --utc to the flags to tar in Lintian::IO::Select::unpack_and_index_piped_tar or (bigger hammer) just set TZ=UTC when running Lintian. Lintian should probably force all output it controls to UTC for reproducibility, including tar's, but I'm still mystified as to why it works on the other system. This part of tar doesn't seem to have changed, and as you mentioned replacing tar didn't change anything.
Wild guess would be timezone differences between the build environments? live well, vagrant
Hi Vagrant, Vagrant Cascadian wrote: Yeah, that's what I looked for first, but both boxes have "Europe/Zurich" as timezone and prepending "env TZ=GMT" didn't make a difference on either side. Thanks for caring nevertheless! Regards, Axel
Hi Russ, Russ Allbery wrote: Nice idea! Will definitely try. I tried with TZ=GMT. I also tried TZ=UTC, but that had no effect. I think you need to use TZ=Etc/UTC there instead. Exactly. All of that. :-) Regards, Axel
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran, Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun. Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie für weitere Details.