Subject: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)
Date: Sun, 29 Nov 2020 11:42:16 +0100
Package: sbuild
Version: 0.80.0
Severity: wishlist
X-Debbugs-Cc: [email protected]
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.htmlhttps://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sbuild depends on:
ii adduser 3.118
ii libsbuild-perl 0.80.0
ii perl 5.32.0-5
Versions of packages sbuild recommends:
ii autopkgtest 5.15
ii debootstrap 1.0.123
ii schroot 1.6.10-11
Versions of packages sbuild suggests:
pn deborphan <none>
ii e2fsprogs 1.45.6-1
ii kmod 27+20200310-2
ii wget 1.20.3-1+b3
-- no debconf information
Hi,
Quoting Raphaël Hertzog (2020-11-29 11:42:16)
> 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).
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?
> 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/
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
Acknowledgement sent
to Simon McVittie <[email protected]>:
Extra info received and forwarded to list. Copy sent to sbuild maintainers <[email protected]>.
(Sun, 29 Nov 2020 11:54:02 GMT) (full text, mbox, link).
Subject: Re: Bug#976073: sbuild: support "podman" as chroot mode and provide
a sbuild-create-oci command (built on top of buildah)
Date: Sun, 29 Nov 2020 11:50:38 +0000
On Sun, 29 Nov 2020 at 12:33:22 +0100, Johannes Schauer Marin Rodrigues wrote:
> 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
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
Acknowledgement sent
to Raphael Hertzog <[email protected]>:
Extra info received and forwarded to list. Copy sent to sbuild maintainers <[email protected]>.
(Sun, 29 Nov 2020 14:39:05 GMT) (full text, mbox, link).
Subject: Re: Bug#976073: sbuild: support "podman" as chroot mode and provide
a sbuild-create-oci command (built on top of buildah)
Date: Sun, 29 Nov 2020 15:24:01 +0100
Control: clone -1 -2
Control: reassign -2 autopkgtest
Control: retitle -2 "autopkgtest: implement a podman backend"
Control: block -1 by -2
Hi,
On Sun, 29 Nov 2020, Johannes Schauer Marin Rodrigues wrote:
> 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?
Yes.
> 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
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,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <[email protected]>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Hi,
Quoting Raphael Hertzog (2020-11-29 15:24:01)
> On Sun, 29 Nov 2020, Johannes Schauer Marin Rodrigues wrote:
> > 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?
>
> Yes.
it seems though there is progress:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446
> > 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
>
> 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?
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
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.