Man page - sbuild-qemu(1)

Packages contains this manual

Package: sbuild-qemu
apt-get install sbuild-qemu

Manuals in package:

Documentations in package:

sbuild-qemu

Manual

SBUILD-QEMU

NAME
SYNOPSIS
OPTIONS
CONSIDERATIONS
LIMITATIONS
VM ACCESS
EXAMPLES
ENVIRONMENT
COPYRIGHT
SEE ALSO

NAME

sbuild-qemu - sbuild using QEMU images

SYNOPSIS

sbuild-qemu [ -h ] [ --image=IMAGE ] [ --ram-size=MiB ] [ --cpus=CPUs ] [ --overlay-dir=OVERLAY_DIR ] [ --noexec ] [ --autopkgtest-debug ] [ <sbuild-options> ]

Build Debian packages with sbuild using QEMU images, by using sbuild’s --chroot-mode=autopkgtest .

All options other than the ones described below are passed on through to sbuild (1), though the options --dist , --arch and --build are peeked at when looking for images. The image will be started in -snapshot mode, so the image is never modified. Multiple processes can use the same image concurrently.

OPTIONS

-h , --help

Show this help message and exit.

--image =IMAGE

QEMU image file to use for building. If not specified, sbuild-qemu will look for an image with the name DIST-autopkgtest-ARCH.img , where DIST is taken from --dist if present, and ARCH is taken from --arch or --build if present. Otherwise, DIST defaults to ’unstable’, and ARCH to the host architecture. sbuild-qemu will first look in the current directory for such an image, and then in the directory $IMAGEDIR . A suitable image can be created with sbuild-qemu-create(1).

--ram-size =MiB

VM memory size in MB. Default: 2048

--cpus =CPUs

VM CPU count. Default: 2

--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.

--autopkgtest-debug

Enable debug output for the autopkgtest-virt-qemu(1) driver.

--boot =auto,bios,efi,ieee1275,none

How to boot the image. Default is BIOS on amd64 and i386, EFI on arm64 and armhf, and IEEE1275 on ppc64el.

CONSIDERATIONS

Using a fast temporary image overlay is key to faster build times. An overlay created on a tmpfs would be 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 filesystems 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 sbuild-qemu-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 further consequence of this chroot mode, what is stated in autopkgtest-virt-qemu(1) generally also holds here.

EXAMPLES

$ sbuild-qemu -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, an image with the name unstable-autopkgtest-amd64.img will be looked for first in the current directory, and then in $IMAGEDIR .

The -s and --arch-all aren’t known to sbuild-qemu, and are therefore will be passed on through to sbuild for it to use.

ENVIRONMENT

$IMAGEDIR defaults to ˜/.cache/sbuild .