On Thu, 27 Jun 2024 at 17:26:20 +0200, Johannes Schauer Marin Rodrigues wrote:
> But, if everybody is so excited about this, where are the sbuild contributors
> implementing this?
I'm sorry, consider it added it to my list. As usual, there's no guarantee
that I will get there within my lifetime, but I'll make sure to feel
suitably guilty about my failure to achieve it.
But, having said that:
> The excitement can probably also
> be seen by there existing 13 independent software packages that do "debian
> package building in docker"
The reason we don't have 14, one of them from me[1], is the same reason
I would be reluctant to develop a new sbuild backend without knowing that
it's what the maintainers of our production infrastructure want to use:
Packages are de facto unreleasable (which is effectively a higher severity
than any RC bug) if they don't compile successfully and pass tests in the
project's official build environment. Until recently, this meant stable's
sbuild and schroot (or sometimes oldstable's sbuild and schroot) entering
an unstable chroot; more recently, some official buildds switched to the
unshare backend, resulting in build failures in that backend becoming
worse-than-RC too.
If I do my test-builds in sbuild + schroot in an (old?)stable VM[3], and
they succeed, then I can be somewhat confident that when I do the upload,
the build on the official buildds will succeed too (at least on x86).
If I do my test-builds in some other way, for example directly in a VM,
or in podman, docker, lxc, pbuilder, deb-build-snapshot or whatever other
thing I might personally prefer or find more convenient, then I run the
risk of having my upload fail to build on the official buildds for a
schroot-specific reason, which of course is an unacceptable situation for
which I would rightly be held responsible; and step 1 of resolving that
situation would be to try to replicate the official build environment,
so I might as well save some time by *already* attempting to replicate
the official build environment. A lot of my Debian contributions are
already guilt-based ("if I don't get this uploaded then $bug is in
some way my fault"), and I'm sorry but I am reluctant to add to that
by creating new and avoidable opportunities to fail to live up to the
project's expectations.
Ideally of course I should do my test-builds in *both* sbuild + schroot
and whatever container technology I'm (hypothetically) proposing as
the new production infrastructure, but then each package I release will
take twice as long per attempt to release, and "smcv takes too long to
release important fixes" is a failure mode that cannot be fixed by any
number of additional QA checks.
Until recently, my understanding is that DSA's policy was to lock
down all official machines by preventing unprivileged creation of user
namespaces system-wide, which rules out podman, making it a poor time
investment. This is clearly not entirely true any more, because if
it was, buildds would not be able to use sbuild's unshare backend -
so perhaps now is the time to be proposing a sbuild podman backend,
and I should probably be writing one instead of replying to this message.
Arguably there is already a sbuild podman backend, albeit indirectly:
tell sbuild to use an autopkgtest virt server, and then specify the
podman virt server as the one to use. (This has the limitation that it
can't use the network to install build-dependencies and then disable
networking for the actual build, which is a limitation that it shares
with the current schroot backend.) As I mentioned in another thread,
unfortunately I have spent considerably less time on podman in autopkgtest
than it deserves: I have not tested it recently, so it's entirely possible
that it doesn't work. If that's the case, then I apologise.
I'm sorry that I have failed to provide a concrete solution to this
problem, and I will try to do better in future.
smcv
[1] Arguably we *do* have 14, one of them from me, because
deb-build-snapshot[2] has an "in Docker"/"in Podman" mode - although
deb-build-snapshot primarily exists to automate generation of labelled
snapshot test-builds for manual testing, and the fact that it has a
"build over there" mode is only a side-effect. It isn't intended
for production use (for example it always builds both arch-dep and
arch-indep binary packages, which of course is an unacceptably lazy
shortcut for production or QA use) and I don't maintain it with a
production-quality level of service, which is why there is no ITP
and also no wishlist bug against devscripts. I am sorry that this
tool does not yet meet the project's quality standards.
[2] https://salsa.debian.org/smcv/deb-build-snapshot
[3] ... and replicate all the other behaviours that the buildds
have, such as setting an unreachable home directory, building
:any and :all separately, and choosing the same undocumented apt
resolver for experimental and backports that the real buildds do
