This is a follow-up to an earlier article, Space-efficient reproducible builds using schroot, sbuild and LVM, explaining how I use the setup described there in practice.

sbuild is designed to be used for architecture-specific builds (supplementing the normal builds by the maintainer), on a buildd. As a result, the normal, documented setup will tend to behave like a buildd rather than like a Debian maintainer. However, it's entirely possible to use sbuild for normal uploads (including NMUs and sponsored uploads) too.

The short version is, here's my .sbuildrc:

# Directory for writing build logs to
$log_dir = "$HOME/.cache/sbuild.logs";

# Mail address where logs are sent to (mandatory, no default!)
$mailto = "smcv";

# Don't override the maintainer or uploader name, just the key
# with which to sign the package...
#$maintainer_name='';
#$uploader_name='';
$key_id='0x5530ec76';

# ... but actually, don't sign the package anyway - I'll use
# debsign
$pgp_options = '-us -uc';

# perl requires this file to return a true value
1;

and here's how to build packages for upload:

debuild -us -uc -S
cd ..
sbuild -As foo_1.2-3.dsc
# ... sanity-check, install and test the resulting packages ...
debsign foo_1.2-3_i386.changes
dput foo_1.2-3_i386.changes

My normal procedure for doing a maintainer upload, for example for one of the pkg-telepathy packages, goes like this:

  • Produce an unsigned source package somehow, e.g. with debuild -us -uc. For quick testing before the "real" build, you can build a binary package too (which will be overwiten by the next step). If you're confident that the binary packages produced by sbuild will work first time, you can save time by using the -S option to do a source-only build.

    In practice, I usually use one of these, depending on the VCS the package is in:

    • git-buildpackage -us -uc -S (using git-buildpackage for pkg-telepathy packages that are maintained in git)
    • bzr builddeb --merge -S (using bzr-buildpackage for pkg-telepathy packages that have not been moved to git yet)
    • svn-buildpackage -S (using svn-buildpackage for pkg-python-modules or pkg-utopia packages)

  • Feed the resulting .dsc file to sbuild, using a command like sbuild -As foo_1.2-3.dsc. The -A option tells sbuild to build Architecture: all binary packages (which it usually omits), and the -s option tells it to rebuild the source package (partly just to get the source package into the .changes file, and partly to ensure that the source package was built in a "clean" environment).

  • Wait for the build to complete. Read the tail of the log to check that the .deb files have sane contents.

  • Use lintian -I foo_1.2-3_i386.changes to check the result of the build for sanity, and debdiff foo_1.2-[23]_i386.changes to compare with the previous release. Install the resulting .deb files with sudo debi foo_1.2-3_i386.changes and do some testing.

  • If all is well, sign the new .changes file with debsign foo_1.2-3_i386.changes and upload it with dput ftp-master foo_1.2-3_i386.changes.

The debuild, debsign, debdiff and debi scripts can be found in the devscripts package; dput and lintian have their own packages.

This setup works sensibly for sponsored uploads too: here's a simulated sponsored upload, imagining that I'd been asked to sponsor the hello package and had already checked and approved the maintainer's changes. ::

smcv@carbon% sbuild -As hello_2.2-2.dsc
Automatic build of hello_2.2-2 on carbon by sbuild/i386 0.57.0
Build started at 20080413-1415
...
Finished at 20080413-1416
Build needed 00:00:15, 3168k disk space

# The maintainer, rather than the sponsor, is correctly the one
# credited in the .changes file...
smcv@carbon% sed -ne 's/@/ AT /p' hello_2.2-2_i386.changes
Maintainer: Santiago Vila <sanvila AT debian.org>
Changed-By: Santiago Vila <sanvila AT debian.org>

# and the .changes file is unsigned (so if I was sponsoring it,
# I could sign it with debsign to get a correct sponsored upload)
smcv@carbon% grep PGP hello_2.2-2_i386.changes || echo "not signed"
not signed
smcv@carbon% debsign hello_2.2-2_i386.changes
...