DOKK / manpages / debian 12 / debspawn / debspawn-build.1.en

debspawn-build - Build Debian packages in a container

debspawn build [-h|--help] [--variant] [-a|--arch] [--suite] [--sign] [--only] [--include-orig] [--buildflags] [--results-dir] [--maintainer] [--clean-source] [--lintian] [--no-buildlog] [-i|--interact] [-e|--setenv] {SUITE} [DIR|DSC_FILE]

Build a Debian package from a directory or source package *.dsc file. debspawn will create a new container for the respective build using the base image specified, build the package and return build artifacts in the default output directory /var/lib/debspawn/results/ unless a different location was specified via the --results-dir flag.

Downloaded packages that are build dependencies are cached and will be reused on subsequent builds if possible.

You can inject packages into the build environment that are not available in the preconfigured APT repositories by placing them in /var/lib/debspawn/injected-pkgs/${container-name}, or in /var/lib/debspawn/injected-pkgs/ to make a package available in all environments. Internally, debspawn will build a transient package repository with the respective packages and add it as a package source for APT.

If you want to debug the package build process, you can pass the --interact flag to debspawn. This will open an interactive root shell in the build environment post-build, no matter whether the build failed or succeeded. After investigating the issue / building the package manually, the shell can be exited and the user is asked whether debspawn should copy back the changes made in the packages' debian/ directory to the host to make them permanent. Please keep in mind that while interactive mode is enabled, no build log can be created.

You can build a package from its source directory, or just by passing a plain .dsc file to debspawn build. If the result should be automatically signed, the --sign flag needs to be passed too:

			$ cd ~/packages/hello
			$ debspawn build sid --sign
			$ debspawn build --arch=i386 cosmic ./hello_2.10-1.dsc

You can also build packages using git-buildpackage and debspawn. In this case the --lintian flag is also used to perform a Lintian static analysis check in the container after build:

			$ gbp buildpackage --git-builder='debspawn b sid --lintian --sign'

To debug a build issue interactively, the --interact flag can be used:

			$ debspawn build sid --interact


Print brief help information about available commands.


Set the variant of the selected image, that was used for bootstrapping.


The architecture of the base image that should be selected.


Explicitly set a suite name (instead of having it derived from the container name).


Sign the resulting package.


Select only a specific set of packages to be built. Choices are: binary: Build only binary packages, no source files are to be built and/or distributed. arch: Build only architecture-specific binary packages. indep: Build only architecture-independent (arch:all) binary packages. source: Do a source-only build, no binary packages are made.


Forces the inclusion of the original source.


Set flags passed through to dpkg-buildpackage as semicolon-separated list.


Override the configured results directory and return artifacts at a custom location.


Set the name and email address of the maintainer for this package and upload, rather than using the information from the source tree's control file or changelog.


Run the d/rules clean target outside of the container. This means the package build dependencies need to be installed on the host system when building from a source directory.


Run the Lintian static analysis tool for Debian packages after the package is built.


Do not write a build log.


Run an interactive shell in the build environment after build. This implies `--no-buildlog` and disables the log.


Set an environment variable for the build process. Takes a `key=value` pair any may be defined multiple times to set different environment variables.

On Debian, sbuild is the primary tool used for package building, which uses different technology. So naturally, the question is whether the sbuild build environments and the debspawn build environments are be identical or at least compatible.

Due to the different technology used, there may be subtle differences between sbuild chroots and debspawn containers. The differences should not have any impact on package builds, and any such occurrence is highly likely a bug in the package's build process. If you think it is not, please file a bug against Debspawn. We try to be as close to sbuild's default environment as possible, but unfortunately can not make any guarantees.

One way the build environment of debspawn differs from Debian's default sbuild setup intentionally is in its consistent use of unicode. By default, debspawn will ensure that unicode is always available and enabled. If you do not want this behavior, you can pass the --no-unicode flag to debspawn build to disable unicode in the tool itself and in the build environment.

debspawn-update(1), debspawn-create(1), dpkg-buildpackage(1).

This manual page was written by Matthias Klumpp <>.

Copyright © 2018-2022 Matthias Klumpp