were recently accepted into unstable, are a collection of scripts that wrap
standard features of
provide a trivial interface for creating and using QEMU-based environments for
qemu-sbuild-createcreates VM images
qemu-sbuild-updateis to VM images what
sbuild-updateis to chroots
sbuild, adding all necessary (and some useful) options for
Here's a simple two-line example for creating an image, and then using it to build a package:
$ sudo qemu-sbuild-create -o simple.img unstable http://deb.debian.org/debian $ qemu-sbuild --image simple.img -d unstable [sbuild-options] FOO.dsc
qemu-sbuild automate certain things, but
also accept a number of options. For example,
install additional packages either from one of the APT sources, or
packages from the local filesystem.
qemu-sbuild will pass on every option it does not consume itself to
sbuild, so it should mostly work as a drop-in replacement for it (see the
Limitations section below for where it doesn't).
The created images can also be used for running
autopkgtest itself, of
Excellent isolation. One can go nuts in an environment, change or even break things, and the VM can always simply be reset, or rolled back to an earlier state. Snapshots are just terrific for so many reasons.
With KVM acceleration and a fast local APT cache, builds are really fast. There's an overhead of a few seconds for booting the VM on my end, but that overhead is negligible in comparison to the overall build time. On the upside, with everything being memory-backed, even massive dependency installations are lightning fast.
With the parameters of the target environment being configurable, it's possible to test builds in various settings (for example: single-core vs. multi-core, or with memory constraints).
Technically, it should be possible to emulate, on one host, any other guest
architecture (even if emulation might be slow because of missing hardware
acceleration). This would present an attractive alternative to (possibly
distant and/or slow) porter boxes. However, support for that in
qemu-sbuild-utils is not quite there yet.
The utilities are currently only available on the
amd64 architecture, for
building packages in
i386 VMs. There are plans to support
arm64 in the near future.
qemu-sbuild-create needs root, for the debootstrap stage. I'm looking into
ways around this (by extending
vmdb2). In any case, image updating and
package building do not need privileges.
autopkgtest mode does not yet support interactivity, so one cannot drop
into a shell with
--build-failed-commands, for example. The easy workaround
is to connect to the VM with SSH. For this, the image must contain the
I looked at
qemubuilder, but had troubles getting it to work. In any case,
autopkgtest chroot mode of
sbuild seemed far more powerful and
useful to me.
vectis looks incredibly promising,
but I had already written
qemu-sbuild-utils by the time I stumbled over it,
and as my current setup works well for me for now and is simple enough to
maintain, I decided to polish and publish it.
I'm also looking into Docker- and other namespace-based isolation solutions (of which there are many), which I think are the way forward for the majority of packages (those that aren't too close to the kernel and/or hardware).
Rather than relying on the kernel for isolation, KVM-based solutions like Amazon's Firecracker and QEMU's microvm machine type provide minimal VMs with almost no boot overhead. Firecracker, for example, claims less than 125ms from launch to /sbin/init. Investigating these is a medium-term project for me.
Why not schroot?
I have a strong aversion towards chroot-based build environments. The concept is archaic. Far superior software- and/or hardware-based technologies for process isolation have emerged in the past two decades, and I think it is high time to leave chroot-based solutions behind.
These utilities are just high-level abstractions. All the heavy lifting is done