Jakub Wilk <jw...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
