I reproduced this on a fresh bookworm install.
Steps to reproduce:
1. configure backports repo
2. install git-buildpackage: apt-get install git-buildpackage
3. install sbuild: apt-get install -t bookworm-backports sbuild
4. create an appropriate sbuild environment:
mkdir -p ~/.cache/sbuild
mmdebstrap --verbose --mode=unshare --architecture="$(dpkg --print-architecture)" --variant=apt --hook-dir=/usr/share/mmdebstrap/hooks/maybe-merged-usr bookworm ~/.cache/sbuild/bookworm-$(dpkg --print-architecture).tar.zst /etc/apt/sources.list
/bin/echo -e '$chroot_mode="unshare";\n$clean_source=0;\n1;' > ~/.sbuildrc 4. clone an arbitrary package from Salsa: git clone https://salsa.debian.org/debian/krb5
5. Execute the build:
cd krb5
git branch upstream origin/upstream
git branch pristine-tar origin/pristine-tar
git checkout -b bookworm origin/bookworm
gbp buildpackage --git-builder='sbuild -d bookworm --no-run-lintian --source-only-changes' --git-debian-branch=bookworm
6. Observe the presence of the buildinfo in the resulting source.changes:
grep buildinfo ../*_source.changes
6. Observe the presence of the buildinfo in the resulting source.changes:
grep buildinfo ../*_source.changes
With the .buildinfo support introduction, one current requirement is
that any .changes file includes at least one .buildinfo file (so
there's currently no filtering based on build type, nor any counting
to not break on potentially old tooling).
Control: reassign -1 dpkg-dev
Control: found -1 1.21.22
On Sat, 10 May 2025, Johannes Schauer Marin Rodrigues wrote:
6. Observe the presence of the buildinfo in the resulting source.changes:
grep buildinfo ../*_source.changes
This is something that dpkg-genchanges does. Sbuild runs this:
dpkg-genchanges --build=source
And that will include a reference to the buildinfo if before running this command, the package was already built. If you run "debian/rules clean" before
running above command, then the resulting .changes file will *not* contain a
reference to the buildinfo.
If you think that this is a bug, you should re-assign this to dpkg.
Thanks, doing so as I ran your reproducer and I confirm that the binary buildinfo is there.
$ grep buildinfo hello_2.10-3_source.changes
807907dc2f97b2a089e6b05e697eaf157f57767b 5813 hello_2.10-3_amd64.buildinfo
15285c44b8509fb01454f419171170f9e6468c866df5e59e65036bc9cd35062c 5813 hello_2.10-3_amd64.buildinfo
7fd5124a2508e44589040f769a152da1 5813 devel optional hello_2.10-3_amd64.buildinfo
Guillem, the issue reported here is that running "dpkg-genchanges --build=source" in a freshly built tree will include the _<arch>.buildinfo from the source+binary build run just before, whereas a source-only build will properly generate a .changes that references a _source.buildinfo.
This introduces a difference in what's generated between users of "sbuild --source-only-changes" and "sbuild --source --no-arch-any --no-arch-all" (or plain dpkg-buildpackage -S).
On Tue, May 13, 2025 at 02:28:57AM +0200, Guillem Jover wrote:
With the .buildinfo support introduction, one current requirement is
that any .changes file includes at least one .buildinfo file (so
there's currently no filtering based on build type, nor any counting
to not break on potentially old tooling).
can't we change this requirement? .buildinfo files for _source.changes
don't make sense, so we shouldn't create nor distribute them.
can't we change this requirement? .buildinfo files for _source.changes don't make sense, so we shouldn't create nor distribute them.(I think we have discussed this in the past. :)
If someone uses dpkg-buildpackage, then build dependencies need to be satisfied (even for source-only builds), where code gets executed from
the package itself (clean targets etc), so this is also a build that generates an upload represented in a .changes file.
Those can also
affect source package generation, so I still think it does make sense
that they generate a .buildinfo file. I also think reproducible source packages are an important thing that we already have (at least tooling
wise), which I'd rather not regress support on.
On Tue, May 13, 2025 at 12:02:54PM +0200, Guillem Jover wrote:
Those can also
affect source package generation, so I still think it does make sense
that they generate a .buildinfo file. I also think reproducible source packages are an important thing that we already have (at least tooling wise), which I'd rather not regress support on.
actually we don't have reproducible source packages and last time we looked (which argueingly is 10 years ago) it didnt seem feasible *and* we didn't
see a compelling reason to have them either.
why do you think they are important?
We have had reproducible source packages (barring OpenPGP signatures in
the .dsc files) since pretty much the same time dpkg-deb gained support
why do you think they are important?For QA alone this seems important (test suites for example), but in a security context, to me this seems like a rather important part TBH,
the foundation on which binary package reproducibility is sitting. More
so in scenarios such as the xz attack for example. Reviewing diffoscope differences is very helpful, but in the end we need to review and modify
the sources, from which the binaries get derived. :)
On Tue, May 13, 2025 at 02:24:38PM +0200, Guillem Jover wrote:
We have had reproducible source packages (barring OpenPGP signatures in
the .dsc files) since pretty much the same time dpkg-deb gained support
have you actually tried that?
why do you think they are important?
For QA alone this seems important (test suites for example), but in a security context, to me this seems like a rather important part TBH,
the foundation on which binary package reproducibility is sitting. More
so in scenarios such as the xz attack for example. Reviewing diffoscope differences is very helpful, but in the end we need to review and modify the sources, from which the binaries get derived. :)
obviously I agree that being able to reproduce the content would be nice, however in our tests years ago, not even that was possible, yet alone
bit by bit (thus including timestamps).
I guess someone would need to actually investigate some hundred packages today, to see how things are really today.
Sure, I'd like to assume at the time this got implemented :), and also
as part of every dpkg release:
https://git.dpkg.org/cgit/dpkg/dpkg.git/tree/build-aux/gen-release#n147
I guess someone would need to actually investigate some hundred packages today, to see how things are really today.Perhaps my statements were sloppy though. When I said reproducible, I
meant that the toolchain can produce them, assuming the source package
itself does not get in the way via «debian/rules clean». I didn't mean
we have 100% coverage on the Debian archive for example, where as you
point out we (well someone :) would need to practically check whether
that's the case. My assumption is that most would do, but I think it's realistic to expect that we might find a number of packages were «debian/rules clean» affects the source generation.
I think whether we can reproduce the same source after a full build
(so the equivalent of a twice in a row build) might perhaps be more challenging (and I'd expect less reproducibility there),
but for a
single d
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 480 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 249:35:04 |
| Calls: | 9,532 |
| Files: | 13,650 |
| Messages: | 6,137,933 |