Lots of bugs have been filed about "Fails to build source after
successful build" (referring to Debian policy 4.9 (clean target)",
with the information:

This package fails to build a source package after a successful build
(dpkg-buildpackage ; dpkg-buildpackage -S).

It would be great if there were a possiblity to test this with sbuild:
the current option --post-build-commands runs outside the chroot, so
cannot be used for this purpose.  If there were an equivalent option
that ran the commands inside the chroot, it could be used for this
purpose, something like:

Hi,

Quoting Julian Gilbey (2025-08-22 10:58:20)

I agree that it would be nice if there was more flexibility in what build
command sbuild is running. For example as of right now, sbuild hard-codes
dpkg-buildpackage as the build command and Jochen recently hacked this by
injecting another binary called dpkg-buildcommand into PATH which is actually a
script in /usr/local/bin executing a custom set of commands. Doing that should
not be necessary and it should be easier to customize the build step with
arbitrary code execution.

That being said, there is a ton of QA tasks which sbuild could theoretically be
hacked to do. For example you could abuse sbuild as a rebuilder checking
whether your source package is actually bit-by-bit reproducible. Many others
come to mind but one could also argue that it is *not* the responsibility of
the maintainer to test all the things before uploading and sbuild is maybe the
wrong tool to test them. For example, you could also test things like this
using pbuilder, mmdebstrap or by submitting a new test to the salsa CI
pipeline. But then I'd argue: is a check like this really worth the additional
CPU cycles? Is this not something you might only want to check every once in a
while like once per release cycle? And is it then not sufficient to have one
person or team to the mass-rebuild and file the bug instead of every single
maintainer having to be aware of all the possible QA tasks they could perform?

Lastly, the check that you say should be possible with sbuild is possible with
sbuild as Lucas has even so kindly explained in his initial email about his MBF
here:

https://lists.debian.org/debian-devel/2023/08/msg00031.html

sbuild -n -A -s --force-orig-source --apt-update -d unstable -v --no-run-lintian \
--starting-build-commands="cd %SBUILD_PKGBUILD_DIR && runuser -u $(id -un) -- dpkg-buildpackage --sanitize-env -us -uc -rfakeroot" \
--finished-build-commands="cd %SBUILD_PKGBUILD_DIR && runuser -u $(id -un) -- dpkg-buildpackage --sanitize-env -us -uc -rfakeroot -S" \
ruby-highline

Thanks!

cheers, josch

Hi Johannes,

Oh, that sounds quite hacky, as you say; one would like the sbuild
invocation to be clear and repeatable, and if it depends on the
contents of random scripts on the system, anything might happen.
QA tasks are better performed by one person or team, and for them to
file the bug reports.  But as a package maintainer, once I receive
such a bug report, I want to be able to test locally whether I have
fixed the issue before marking it as done.

Ah, awesome!  I'll try that.

Best wishes,

   Julian

Hi,

Quoting Julian Gilbey (2025-08-22 20:07:10)

it depends on the contents of a random scripts *in the chroot*. So the person
performing the hack is at full control of what is going on.

Absolutely. It is the duty of the person reporting the bug to also show you a
method of how to reproduce it. Lucas did exactly that.

I agree that this could be made simpler in the future.

Would you like this bug to be about the dpkg-buildpackage program becoming
configurable and thus avoid having to do PATH hacks? If yes, please adjust the
subject of this bug.

Thanks!

cheers, josch