Adrian Knoth wrote: > This might be a dup of #658890, but I'm not exactly sure whether it is > still open or not (shown as closed on the web, but appears in the list > of already reported bugs)
The bug reports are unrelated. > While trying to build jackd2: > > xdelta: > /tmp/pristine-tar.hvfFLpNHxB/jackd2_1.9.8~dfsg.1.orig.tar.gz.tmp: > Checksum validation failed, expected: eb84ed4fbaca5b83923ac4e4144b64d8, > received: 6246a3ea1653bfdfd534f276d341368b > xdelta: /tmp/pristine-tar._wxzziRdtQ/recreatetarball: Checksum > validation failed, expected: aa4aded40663ef72f066263ef23b526e, received: > 319f8426d5414188701cfe0d3e1f0b47 This is an unusual failure mode for pristine-tar. It was earlier able to generate a delta file, which worked, and it's committed to the git repo, but now using that same delta is failing. Apparently running tar on what should be the same set of inputs (the source files in git) is prodocing a different output than it did when this tarball was checked in. Indeed, the generated tarball differs between runs on the same system: joey@wren:~/tmp/jackd2>cmp /home/joey/tmp/pristine-tar.QiAWLfEMZI/recreatetarball /home/joey/tmp/pristine-tar.PIDCIh2l52/recreatetarball /home/joey/tmp/pristine-tar.QiAWLfEMZI/recreatetarball /home/joey/tmp/pristine-tar.PIDCIh2l52/recreatetarball differ: byte 145, line 1 Both were generated by the same command, run on the same input files. Looking at the two trees generated by the two pristine-tar runs, they're identical right down to the file sizes and modification times. Aha.. except that the directories the two trees are in have different mtimes! When I touch the two directories to have identical mtimes, I see identical tarballs generated from the two trees, as expected. pristine-tar sets the atime and mtime of the toplevel directory to 0, and then sets the mtime of the files inside in turn. When it gets to setting the mtime of $dir/waf, the mtime of the toplevel directory has been reset to the current time. What's notable about $dir/waf? Well, it starts out a symlink, and pristine-tar replaces it with an empty file. Which is where the bug lies, as it does this in the same loop that's setting times, and this file deletion changes the mtime of the parent directory. So, I've fixed pristine-tar and will be uploading it, but the sad thing is that the delta file checked into jackd2 was created with the old, broken version, and relies on whatever mtime the directory happened to be reset to when you originally checked it in. So while I've fixed the bug from reoccurring, it won't make your delta file work. You'll need to get the original tarball and re-commit it with pristine-tar to fix your delta file. (In an absolute pinch, if the original tarball was not available, we could try to guess the right mtime to use to make the old delta work. It would be around when the delta was committed to git..) -- see shy jo
signature.asc
Description: Digital signature
