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-create creates VM images
qemu-sbuild-update is to VM images what
sbuild-update is to chroots
sbuild, adding all necessary (and some useful)
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
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.
will pass on every option it does not consume itself to
, 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
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
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
, but had troubles getting it to work. In any case,
chroot mode of
seemed far more powerful and
useful to me.
looks incredibly promising,
but I had already written
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
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
type provide minimal VMs with almost no boot overhead. Firecracker, for
example, claims less than 125ms from launch to /sbin/init
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