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
