#731914 lintian: arch-specific behavior for timestamps far in the future

Package:
lintian
Source:
lintian
Submitter:
Jakub Wilk
Date:
2013-12-14 17:30:04 UTC
Severity:
normal
#731914#3
Date:
2013-12-11 09:32:58 UTC
From:
To:
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


Apparently libghc-quickcheck-instances-dev would have been auto-rejected
from the archive if ftp-master.d.o had been running a 32-bit system.
#731914#8
Date:
2013-12-13 21:32:38 UTC
From:
To:
What do you prefer ?

Tag for 31bits overflow  or 64 bits ?

I suppose 31bits is on the safe side ?

Bastien
#731914#13
Date:
2013-12-13 21:45:13 UTC
From:
To:
Jakub Wilk <jwilk@debian.org> writes:

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?
#731914#16
Date:
2013-12-14 17:26:00 UTC
From:
To:
* Russ Allbery <rra@debian.org>, 2013-12-13, 13:45:

That's the main problem.

I think it would be should emit a more specific tag than
"tar-errors-from-data" in such cases (say
"timestamp-does-not-fit-32-bit-time_t"). Then we could talk ftp-masters
to add it to their tag list.

Lintian could refrain from emitting "package-contains-ancient-file" when
it sees "Archive octal value ... is out of time_t range; assuming two's
complement" error from tar, and emit
"timestamp-does-not-fit-32-bit-time_t" only.

If maintainer's clock was slightly off, then tar could transiently warn
about timestamps from future. I don't think we want packages rejected
just because of that.