Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)
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- 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 signature.asc Description: signature
Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)
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- 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 ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)
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
Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)
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 signature.asc Description: signature
Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)
Package: sbuild Version: 0.80.0 Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org 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/ -- 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 perl5.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 ii e2fsprogs 1.45.6-1 ii kmod 27+20200310-2 ii wget 1.20.3-1+b3 -- no debconf information
