Apologies for including that incorrect analysis; indeed I should have verified its correctness or not included it at all. That was sloppy. I will be the first to admit that I'm not familiar with debhelper internals.
With that said, the reproducibility bug was real, and the reproducer is correct, at least against the snapshot of the Debian archive I have locally here. > This was actually a bug in debhelper; it is fixed in debhelper 13.32. I'm happy that this has been fixed. Thank you for your work. Kind regards ________________________________________ From: Peter Pentchev Sent: Monday, June 15, 2026 11:23 To: Chulkov, Georgi Cc: [email protected] Subject: Re: Bug#1139881: libzstd: zstd .deb differs across DEB_BUILD_OPTIONS=parallel values control: tags -1 - upstream control: reassign -1 debhelper control: found -1 13.25 control: fixed -1 13.32 On Fri, Jun 12, 2026 at 11:49:50PM +0000, Chulkov, Georgi wrote: > Package: libzstd > Version: 1.5.7+dfsg-3 > Severity: normal > Tags: reproducibility upstream > > The `zstd` binary `.deb` produced by the libzstd source package is not > byte-identical when built with `DEB_BUILD_OPTIONS=parallel=1` versus > `parallel=2` (or higher). > > Reproduction: > 1. Get source: `apt-get source libzstd` > 2. Build twice with different parallel values, in fresh trees each time: > DEB_BUILD_OPTIONS="parallel=1 nocheck" dpkg-buildpackage -b --no-sign > DEB_BUILD_OPTIONS="parallel=2 nocheck" dpkg-buildpackage -b --no-sign > 3. Compare the resulting `zstd_1.5.7+dfsg-3_<arch>.deb` files (e.g. with > sha256sum or diffoscope). > > Expected: identical bytes. [snip] This was actually a bug in debhelper; it is fixed in debhelper 13.32. > Suspected cause: an ordering issue in debian/rules between the step that > populates the `Commands` substvar (`dh_installcommands` or equivalent — > the consumer of `debian/zstd.commands`) and the step that assembles > the .deb's control via dpkg-gencontrol. At parallel = 1 these run in > the wrong order; at parallel >= 2 the parallel scheduler happens to > order them correctly. Make-level dependencies between them would make > the result independent of the scheduler. I am sorry, but I simply cannot pass this by. In the future, when using LLMs to report bugs, please, please, PLEASE take a minute to actually READ the bug report and check whether it makes sense! In this case, I wasted time I could have spent fixing other stuff, because I doubted my memory of how debhelper worked, and I had to actually check to make sure that: - there IS NO `sh_installcommands` program at all - there IS NO `debian/zstd.commands` file, this is all handled by substvars - there ARE NO commands that run in the wrong order - there ARE NO Makefile targets in the libzstd debian/rules file that affect the ordering of command execution IN ANY WAY Please. Please take a minute to make sure you do not waste people's time with COMPLETELY incorrect and EASILY verifiable statements! [snip] > Tagging upstream because the fix likely lives in libzstd's debian/rules. Excuse me, what?! Once again, PLEASE read what the LLM wrote! This statement makes ABSOLUTELY no sense: the debian/rules file is exactly the opposite of an upstream thing! I do not apologize for the "shouting". Sending a bug report like this is NOT OK! G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
