Your message dated Mon, 21 Sep 2026 15:42:26 +0200
with message-id <[email protected]>
and subject line Re: Bug#1139881: libzstd: zstd .deb differs across
DEB_BUILD_OPTIONS=parallel values
has caused the Debian Bug report #1139881,
regarding libzstd: zstd .deb differs across DEB_BUILD_OPTIONS=parallel values
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1139881: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1139881
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
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.
--- End Message ---
--- Begin Message ---
Already marked as fixed, but was not `-done` so the BTS kept it "open".
Fixing that now.
On Mon, 15 Jun 2026 12:23:14 +0300 Peter Pentchev <[email protected]> wrote:
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!
--- End Message ---
