Hi Johannes, On Fri, Aug 22, 2025 at 11:52:31AM +0200, Johannes Schauer Marin Rodrigues wrote: > Control: tag -1 + moreinfo > > Hi, > > Quoting Julian Gilbey (2025-08-22 10:58:20) > > 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: > > > > --post-build-chroot-commands="dpkg-buildpackage -S" > > 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.
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. > 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? There are two different things here: I totally agree that many of the 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. > 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 Ah, awesome! I'll try that. Best wishes, Julian
