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.
Observed: 8-byte size difference. The metadata difference visible in dpkg-scanpackages output: at parallel >= 2 the package declares `Commands: zstd` (auto-populated substvar listing CLI commands provided); at parallel = 1 the field is absent from the produced .deb's control. The other 4 binaries this source produces (libzstd1, libzstd1t64, libzstd-dev, libzstd-tools) are byte-identical across the same matrix; only the `zstd` binary drifts.
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.
Impact: breaks Debian Reproducible Builds for `zstd` specifically. Distribution rebuilders and downstream users can't get bit-identical `zstd` .debs without standardizing on a specific parallel=N value.
Tagging upstream because the fix likely lives in libzstd's debian/rules.
control: tags -1 - upstream control: reassign -1 debhelper control: found -1 13.25 control: fixed -1 13.32 [snip] This was actually a bug in debhelper; it is fixed in debhelper 13.32. 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] 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
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. I'm happy that this has been fixed. Thank you for your work. Kind regards [snip] This was actually a bug in debhelper; it is fixed in debhelper 13.32. 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] 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