Christoph Goehre wrote: > here are my files: > > http://www.debiaan.de/~chris/recreatetarball > md5sum is 0875293fba458279e971d6283833b2d7 > > > git archive --format=tar 7f12af07f9b02c17c68afb7304de6774f926aebb > http://www.debiaan.de/~chris/7f12af07f9b02c17c68afb7304de6774f926aebb-tar-tree > md5sum is fa2e3a47e0ab11af5db467e994e0db46 > > and the output of pristine-tar by creation icedove-l10n_3.1.6.orig.tar.gz. > > BTW: I'm running sid on a amd64 machine. The package version which has Guido > reported on his system are here:
The relevant package seems to be tar 1.24. With 1.23, I see the failure; and after upgrading, it works. That's a bit surprising. I had expected tar's output to be somewhat more stable. And from 1.19 to 1.23, it was.. The content inside the two recreatetarballs seems identical, but the one made with the new tar is smaller: -rw-r--r-- 1 joey joey 60856320 Nov 10 17:38 bad/recreatetarball -rw-r--r-- 1 joey joey 60753920 Nov 10 03:03 good/recreatetarball Actually, it's not as simple as tar no longer producing the same file in all cases. If that were the case, using pristine-tar to generate tarballs from old deltas produced with the old tar would fail. But it works ok on eg, stuff from pristine-tar's own git repo. I *do* see such a failure with icedove-l10n_3.1.3.orig.tar.gz when using the new tar. Also with icedove_3.0.orig.tar.gz. Size of the tarball seems the most likely trigger. I will try to bisect the change in tar. -- see shy jo
signature.asc
Description: Digital signature
