I know that multiple developers started using podman and buildah to manage
containers where they build their Debian packages. With user namespace
supports, this allows rootless building (like the "unshare" chroot
mode)... you don't even need root to setup the "build chroot" since those
are containers that you can download (or rebuild if you prefer).

Thus it would be nice if sbuild had a "podman" chroot mode where it could
use podman containers to build the packages.

A "sbuild-create-oci" command would also be helpful to build the various
container images, either from scratch (so that you don't have to trust
images that you download) or on top of pre-existing OCI images (to
save time and effort). That command should not be hard to build on top
of buildah.

Some links:
http://tauware.blogspot.com/2020/04/building-packages-with-buildah-in-debian.html
https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/

Hi,

Quoting Raphaël Hertzog (2020-11-29 11:42:16)

already today you don't need to be root to setup the build chroot, by using
mmdebstrap as a debootstrap drop-in-replacement in sbuild-createchroot like so:

    $ sbuild-createchroot --debootstrap=mmdebstrap --make-sbuild-tarball ~/.cache/sbuild/unstable-amd64.tar.gz unstable $(mktemp -d)

The resulting tarball can then be used with the sbuild unshare backend. The
only time you need be root is to execute

    $ sudo sysctl -w kernel.unprivileged_userns_clone=1

But I guess you also need this for podman and buildah?

I'm absolutely for it! If somebody wants to implement and maintain it, please
send patches for me to review. The person can then keep maintaining the podman
chroot mode easily because sbuild is in the Debian group on salsa.

What I would like even more, would be to add a podman backend to autopkgtest.
This has the following advantages:

 - it would already work with sbuild today (no changes in sbuild required)
 - no duplicated work to have podman support in both sbuild and autopkgtest

Thanks!

cheers, josch

There's a merge request for a Docker backend for autopkgtest, which I
suspect can easily be turned into a Podman backend since they're broadly
command-line compatible. Getting that into a mergeable state is on my
(long) to-do list. If it works for both, I think ideally we'd have an
autopkgtest-virt-podman that just runs
`exec autopkgtest-virt-docker --podman "$@"`, for better discoverability.

One major blocker for merging a Docker backend is defining exactly what
the isolation-container restriction means, because at the moment some
packages assume that it means a "full-system" container with a
fully-featured init system (like lxc or lxd, where the container usually
"boots" with systemd, Upstart or sysvinit), and Docker is not usually
used in that way.

    smcv

Hi,

Yes.

Even better indeed, but some official way to build the container would
also be welcome... would that also be best done in autopkgtest with
a new autopkgtest-build-podman command?

Is the expectation that sbuild will use whatever "image/container/chroot"
is created by the respective autopkgtest-build-<backend> command? Or has
sbuild special requirements at this level?

Bonus point: adding this to autopkgtest means contributing Python code
instead of Perl. ;-)

Cheers,

Hi,

Quoting Raphael Hertzog (2020-11-29 15:24:01)

it seems though there is progress:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446

In general, sbuild should be fine with any chroot containing Essential:yes and
apt. Starting from this, it will install all the stuff it needs like
build-essential and so on. Admittedly this features is not tested much, so if
you find a minimal chroot sbuild is not able to copy with, please file a bug,
so that sbuild adds a few more bits of setup.

Thanks!

cheers, josch