* Russ Allbery <r...@debian.org>, 2013-12-13, 13:45:
(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?
That's the main problem.
Or that the package wasn't auto-rejected?
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.
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.
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.
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?
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.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
