Bug#731914: lintian: arch-specific behavior for timestamps far in the future
Jakub Wilk <jwilk@debian.org> writes:
> If a package contains files with timestamps far in the future, then
> lintian will emit different set of tags depending on whether it's run on
> 32- or 64-bit machine.
> (i386) $ lintian --no-cfg
> libghc-quickcheck-instances-dev_0.3.4-1_amd64.deb E:
> libghc-quickcheck-instances-dev: tar-errors-from-data Archive octal value
> 33415462123 is out of time_t range; assuming two's complement
> E: libghc-quickcheck-instances-dev: tar-errors-from-data Archive octal value 33415462123 is out of time_t range; assuming two's complement
> E: libghc-quickcheck-instances-dev: package-contains-ancient-file usr/share/doc/libghc-quickcheck-instances-dev/changelog.gz 1950-12-22
> (amd64) $ lintian --no-cfg libghc-quickcheck-instances-dev_0.3.4-1_amd64.deb
> E: libghc-quickcheck-instances-dev: tar-errors-from-data ./usr/share/doc/libghc-quickcheck-instances-dev/changelog.gz: time stamp 2087-01-28 00:29:07 is 2307798691.20417264 s in the future
Just to be sure I understand, the problem that you're reporting is not so
much that the tags are different (I don't think we can avoid that; tar
either produces one error or a different error, depending on
architecture), but that we diagnose package-contains-ancient-file on i386
systems, which isn't correct? Or that the package wasn't auto-rejected?
The problem from Lintian's perspective on i386 is that by the time we see
the package, tar has already reinterpreted time_t as a signed value. So
I'm not quite sure what to do about this.
I'm wondering if tar-errors-from-data should be an autoreject tag for
ftp-master. Is there ever a case where we would want to accept Debian
packages that produce tar errors when unpacked?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: