XPost: linux.debian.bugs.dist
From:
[email protected]
Hi!
On Mon, 2025-05-12 at 10:38:08 +0200, Raphael Hertzog wrote:
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).
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).
From the grep above, I'm assuming there's no reference to a
*_source.buildinfo file in debian/files, so that means one will not
get included in the generated .changes file (as I think would be
expected if one performs a source-only or source+binary build?).
I guess what I see here is potentially a problem with how the build is
being driven by sbuild or whatever else is driving it, where there's
at least a missing source build phase (dpkg-buildpackage --build=source),
or parts of it (dpkg-genbuildinfo --build=source).
But then it could be argued that there's potentially a problem with dpkg-genchanges where it should track how many .buildinfo files are being distributed, and probably warn (or error out?) if none are, and then if
it has seen a .buildinfo matching the current --build mode, then ignore
other .buildinfo files not matching it. Although this would break
source-only uploads performed as full builds, which was added explicitly
to support that use case when source-only uploads support got added in
Debian. For example I routinely prepare all my uploads with:
$ dpkg-buildpackage --changes-option=-S
Because I want the artifacts I built to be recorded as part of the
.buildinfo. But if what you really want is a pure source-only upload,
then I think that's what you should be asking your build driver, the
equivalent of:
$ dpkg-buildpackage --build=full
$ dpkg-buildpackage --build=source
So adding such filtering would break that use case above. I'd need to
think how to support such filtering, but right now I'm not seeing it.
(Unless I've completely misunderstood the bug report, as I don't think
I've ever really used sbuild, where my main interactions with it are
via code reading and to support it as part of dpkg. :)
Thanks,
Guillem
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)