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

[Jakub Wilk <jwilk@debian.org>]

* Russ Allbery <rra@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