table of contents
QEMU-SBUILD(1) | User Commands | QEMU-SBUILD(1) |
NAME¶
qemu-sbuild - sbuild using QEMU images
DESCRIPTION¶
usage: qemu-sbuild [-h] [--arch ARCH] [-d DIST] [--image IMAGE]
- [--autopkgtest-debug] [--ram MiB] [--cpus CPUs] [--overlay-dir OVERLAY_DIR] [--noexec]
Build Debian packages using sbuild(1) and QEMU images
optional arguments:¶
- -h, --help
- show this help message and exit
- --arch ARCH
- Architecture to use. Default is the host architecture. Currently supported architectures are: amd64, i386.
- -d DIST, --dist DIST
- Distribution (for the .changes file). Default is 'unstable'.
- --image IMAGE
- VM image to use for building. If not specified, will look in $IMAGEDIR for an image with the name DISTautopkgtest-ARCH.img. A suitable image can be created with qemu-sbuild-create(1).
- --autopkgtest-debug
- Enable debug output for the autopkgtest-virt-qemu(1) driver.
- --ram MiB
- VM memory size in MB. Default: 2048
- --cpus CPUs
- VM CPU count. Default: Number of physical cores on the host.
- --overlay-dir OVERLAY_DIR
- Directory for the temporary image overlay instead of autopkgtest's default of /tmp (or $TMPDIR).
- --noexec
- Don't actually do anything. Just print the sbuild(1) command string that would be executed, and then exit.
All other options are passed on through to sbuild(1). The image will be started in -snapshot mode, so no changes are saved, and multiple processes can use the same image concurrently.
CONSIDERATIONS¶
Using a fast temporary image overlay is key to faster build times. An overlay created on a tmpfs would is ideal, and can speed up I/O by an order of magnitude,compared to a slow HDD. If tmp or $TMPDIR are mountpoints for a tmpfs, then all should be fine by default.
However, tmpfs filesytems are backed by memory and swap on the host, so a build needing substantial disk space in the VM may fail. If this happens, the --overlay-dir option should be used to point to a host directory with more available disk space. Note that the base image itself must have been created with a suitable size, see the --size option to qemu-sbuild-create(1).
LIMITATIONS¶
Due to the nature of sbuild's --chroot-mode=autopkgtest, not all sbuild options are supported yet. In particular, getting an interactive shell, for example using --build-failed-command is NOT possible. However, there are other ways to access the build environment (see below).
VM ACCESS¶
sbuild's --chroot-mode=autopkgtest uses autopkgtest-virt-qemu under the hood, so you will find an SSH shell on port 10022 (or the first free port after that) if, and only if, the openssh-server package is installed in the VM.
As a futher consequence of this chroot mode, what is stated in autopkgtest-virt-qemu(1) generally also holds here.
EXAMPLES¶
$ qemu-sbuild -d unstable -s --arch-all FOO.dsc
This will build the package FOO.dsc using unstable as the Distribution in the generated .changes file.
Because the --image option was not specified, the image $IMAGEDIR/unstable-autopkgtest-amd64.img will be used to build the image (assuming that the host architecture is amd64).
The -s and --arch-all aren't known to qemu-sbuild, and are therefore will be passed on through to sbuild for it to use.
ENVIRONMENT¶
When using default image detection (meaning the --image option was not used, and therefore the image name is generated using the distribution and architecture names), qemu-sbuild looks for images in $IMAGEDIR, or /var/cache/qemu-sbuild if $IMAGEDIR is unset.
COPYRIGHT¶
Copyright © 2020 Christian Kastner <ckk@kvr.at>
SEE ALSO¶
qemu-sbuild-create(1), qemu-sbuild-update(1).
December 2020 | qemu-sbuild 0.1 |