Differences between revisions 114 and 115
Revision 114 as of 2016-07-29 14:46:45
Size: 24975
Editor: ?RobertHaist
Comment: For current unstable gnupg needed to be explicitly installed during my test
Revision 115 as of 2016-09-14 08:08:04
Size: 24976
Comment: add coma in sbuildrc snippet for autopkgtest
Deletions are marked like this. Additions are marked like this.
Line 204: Line 204:
      '--', 'schroot', 'unstable-%a-sbuild;'       '--', 'schroot', 'unstable-%a-sbuild;',

Translation(s): none


sbuild is used on the official buildd network to build binary packages for all supported architectures. It can also be used by individuals to test that their package builds in a minimal installation of Debian Unstable. In particular, this helps ensure that you haven't missed any build dependencies.

The main alternative to sbuild is pbuilder combined with cowbuilder.

This main part of this page is intended as a short guide to sbuild. It documents how to set up sbuild and build packages with it. The later parts of the page document optional enhancements to the simple setup described in the first section.

If you use propellor to configure your development machine, its Propellor.Property.Sbuild module can perform most of this setup for you.

Setup

Create the chroot

To get started so you may build packages for Debian unstable, run the following.

   1 sudo apt-get install sbuild
   2 sudo mkdir /root/.gnupg # To work around #792100; not needed post-Jessie
   3 sudo sbuild-update --keygen
   4 sudo sbuild-adduser $LOGNAME
   5  ... *logout* and *re-login* or use `newgrp sbuild` in your current shell
   6 sudo sbuild-createchroot --include=eatmydata,ccache,gnupg unstable /srv/chroot/unstable-amd64 http://httpredir.debian.org/debian

Now for a brief explanation on what these commands do.

The first line installs sbuild onto the system.

The third line generates apt keys used internally by sbuild. (If you get an error about lack of entropy, do something else on the system, like browsing the web or running find /usr or so. Or skip down to creating the chroot, and come back to this step.) This only needs to be done once.

The fourth line will add your username so that it may use the sbuild command. Additional users may be added by running sudo sbuild-adduser USER1 USER2 ....

sbuild-adduser will prompt you to copy the template sbuild configuration in /usr/share/doc/sbuild/examples/example.sbuildrc to each user's ~/.sbuildrc, to be used as their user sbuild configuration. You can customize sbuild settings here, but you usually won't need to customize anything. This should be done once per user.

The fifth line is to update the active user group set to include sbuild.

The sixth line uses sbuild-createchroot to create a chroot used by sbuild meant for building packages targeting Debian unstable main. The chroot is saved in /srv/chroot/unstable-amd64. It installs the packages ccache and eatmydata in the chroot in case you want to use some of the enhancements detailed below. The apt repository used is the mirror service http://httpredir.debian.org/debian which will choose a suitable local mirror automatically. This can be changed to use a URL for a different mirror of the Debian archive. You can run this command once per distribution you want, and pass --arch=i386 to create a chroot for a different architecture (the default is your host architecture).

The command given above creates a type=directory chroot. If you are short of disc space, you can instead use the following command to create a chroot stored in a tarball at /srv/chroot/unstable-amd64.tar.gz. This is not recommended unless you really can't spare the disc space, because several of the enhancements below depend on using a type=directory chroot.

sudo sbuild-createchroot --make-sbuild-tarball=/srv/chroot/unstable-amd64.tar.gz unstable `mktemp -d` http://httpredir.debian.org/debian

Configuration

If you're setting up sbuild for personal use, instead of as part of a build server, you might want to use the following options in your ~/.sbuildrc. These can also be set on the command line when running sbuild.

   1 $build_arch_all = 1;
   2 $build_source = 1;
   3 $distribution = 'unstable';

The $build_arch_all variable will enable building of architecture independent packages by default. Since official build servers are used to build an existing package for a different architecture (e.g., the uploader builds for i386, uploads arch-i386 and arch-all binary packages, and a build server builds arch-amd64 packages), this is off by default. You can also enable this per build by passing -A to sbuild.

The $build_source variable will enable building of source packages by default. Again, on official build servers, this isn't wanted, but for personal use it's generally useful. You can enable this per build with -s.

The $distribution variable will set the distribution to build for as 'unstable'. You can set the distribution per build by passing it to the -d option. Be careful not to use -d just to select a specific chroot (use -c for that, see below), as it will override the distribution set in debian/changelog and may lead you to upload a package to a distribution it was not intended for.

Updating

The chroot should be up-to-date before building packages. Use the sbuild-update to perform updates.

First, note the name of the sbuild chroot to be updated. All sbuild chroots built with sbuild-createchroot will have a suffix of '-sbuild' thus to find the names of all sbuild chroots, run the following.

   1 schroot -l | grep sbuild

If you followed the setup instructions above, there should be one chroot named source:unstable-$arch-sbuild where $arch is the architecture installed on your machine.

After noting the name of your sbuild chroot, run the following.

   1 sudo sbuild-update -udcar unstable-$arch

The arguments '-udcar' will tell sbuild-update to run an apt-get update, dist-upgrade, clean, autoclean, and autoremove in the chroot.

You can also pass --apt-update --apt-distupgrade to the individual sbuild invocation to update the temporary copy of the build chroot, but this won't cause any changes to happen in the persistent copy of the chroot (in the .tar.gz file). So if you are building more than once, you should run sbuild-update instead of relying on this.

Building packages

To build a package from the source directory of a debianized package, simply run the following.

   1 sbuild

Alternatively, you may pass in the '.dsc' file of a package generated by dpkg-buildpackage, git-buildpackage, and so forth so that it may be built with sbuild. For example, to build sbuild from its '.dsc' file, do the following.

   1 sbuild sbuild_*.dsc

To build packages available from the apt repositories used in the sbuild chroot, just pass in a package name (older versions of sbuild required $package_$version). For example to build the latest sbuild:

   1 sbuild -d unstable sbuild

Everything needed to build the latest sbuild version will be downloaded from the repositories and will be saved in your current directory after building of the packages is finished.

If you want parallel build to be used, add a line like the following to ~/.sbuildrc:

$ENV{'DEB_BUILD_OPTIONS'} = 'parallel=5';

Cleaning up schroot session

Sometimes you can end up with dangling chroot sessions potentially taking up valuable system resources (find them with `schroot -l --all`). This command is useful:

sudo schroot --end-session --all-sessions

Enhancements

Using lintian

The use of lintian with sbuild can greatly aid with increasing the quality of Debian packages. To use lintian with sbuild, first install lintian.

   1 sudo apt-get install lintian

Next, edit your ~/.sbuildrc configuration file. Open ~/.sbuildrc with your favorite text editor and edit the lines with the following variables.

   1 $run_lintian = 1;
   2 $lintian_opts = ['-i', '-I'];

The $run_lintian variable will enable running of lintian after a successful build with sbuild.

The $lintian_opts variable is an array of options to pass to lintian. Here the options are '-i' which will output information about lintian warnings and errors, and '-I' which will output lintian "info" messages.

Using piuparts

The use of piuparts with sbuild is another feature meant to enhance the quality of Debian packages built with sbuild. To use piuparts, first install piuparts.

   1 sudo apt-get install piuparts

Next, edit your ~/.sbuildrc configuration file. Open ~/.sbuildrc with your favorite text editor and edit the lines with the following variables.

   1 $run_piuparts = 1;
   2 $piuparts_opts = ['--schroot', 'unstable-amd64-sbuild'];

The $run_piuparts variable will enable running piuparts after a successful build with sbuild.

The $piuparts_opts variable is an array of options to pass to piuparts. Here the options instruct piuparts to use sbuild chroot '/srv/chroot/unstable-amd64' as the chroot used in its testing of packages.

Using autopkgtest

Add this to .sbuildrc:

$external_commands = {
  'post-build-commands' => [
    [
      'autopkgtest', '%d', '%c',
      '--', 'schroot', 'unstable-%a-sbuild;',

      # if autopkgtest's exit code is 8 then the package had no tests
      # but this isn't a failure, so catch it
      'aptexit=$?;',
      'if', 'test', '$aptexit', '=', '8;', 'then',
      'exit', '0;', 'else', 'exit', '$aptexit;', 'fi'
    ],
  ],
};

Consider configuring schroot with tmpfs or eatmydata, or else running adt-run will slow the build a lot.

Bind mounts

Directories on the local filesystem can be bind mounted and made available in the sbuild chroots. To do this, add an entry in /etc/schroot/sbuild/fstab.

The following example shows how to bind mount the apt archive cache inside an sbuild chroot. This is useful when not using a local mirror of the Debian repository.

   1 sudo sh -c 'echo /var/cache/apt/archives /var/cache/apt/archives none rw,bind 0 0 >>/etc/schroot/sbuild/fstab'

Note that if you set up this bind mount, you probably want to avoid passing the -c flag to sbuild-update or you'll keep clearing out the bind mount.

Also note if you set up piuparts as detailed above, it will empty your apt cache each time it runs, which greatly reduces the usefulness of bind-mounting the cache. To deal with this you can set up a separate schroot configuration for piuparts that doesn't perform the bind mount. In brief (sed commands untested):

cd /etc/schroot
cp chroot.d/unstable-amd64-sbuild-* chroot.d/unstable-amd64-piuparts
sed -i 's/profile=sbuild/profile=piuparts/' chroot.d/unstable-amd64-piuparts
cp -R sbuild piuparts
sed -i '|^/var/cache/apt/archives|d' piuparts/fstab

and use --schroot unstable-amd64-piuparts in your ~/.sbuildrc.

Customizations of sbuild chroots

Sometimes it is desirable to further customize your sbuild chroot environment. Typical customizations done are installing more packages inside the chroot, modifying /etc/apt/sources.list, and installing custom scripts to be run inside the chroot.

To modify a chroot, start a session for the chroot with the prefix 'source:'. For example, to modify the unstable-$arch-sbuild chroot, start a session for the chroot as follows.

   1 sudo sbuild-shell source:unstable-$arch-sbuild

This will start a session inside the unstable-$arch-sbuild chroot. Any modifications done inside the chroot will be saved upon exiting. Inside this chroot, you may run apt-get commands to install or remove packages as desired. For example, to install ccache, do the following in the chroot session.

   1 apt-get install ccache

Note that you are already root inside a chroot session. Also, sudo would typically not be installed in the chroot anyway.

Making other modifications such as editing /etc/apt/sources.list or adding scripts inside the chroot is best done from outside the chroot session. In order to do this, leave the current chroot session open and start another terminal session. In the other terminal session, find the path used for the existing chroot session as follows.

   1 schroot --info --all-sessions | grep Path

This should output exactly one line and should specify the path of the chroot session. It should look something like this.

  Path                   /var/lib/schroot/mount/unstable-amd64-sbuild-5bad48fe-9823-4454-815f-b869d1d7b22c

Doing an ls on this directory should resemble a standard listing of the '/' directory.

With the above path, the sources.list file will be in the following path.

/var/lib/schroot/mount/unstable-amd64-sbuild-5bad48fe-9823-4454-815f-b869d1d7b22c/etc/apt/sources.list

Open the sources.list file at this path with root privileges using your favorite editor, for example:

   1 sudo -e /var/lib/schroot/mount/unstable-amd64-sbuild-5bad48fe-9823-4454-815f-b869d1d7b22c/etc/apt/sources.list

Proceed to edit the sources.list file as you see fit, then save.

To add scripts inside the chroot, simply place the scripts in the following directory.

/var/lib/schroot/mount/unstable-amd64-sbuild-5bad48fe-9823-4454-815f-b869d1d7b22c/usr/local/bin

Be sure to make the scripts executable.

   1 sudo chmod a+x /var/lib/schroot/mount/unstable-amd64-sbuild-5bad48fe-9823-4454-815f-b869d1d7b22c/usr/local/bin/*

Other modifications may be done to the chroot, either by running commands available within the chroot session, or by running commands with root privileges via the secondary terminal session. Once you are done making modifications to the chroot, simply exit the session. Inside the chroot session, do the following.

   1 exit

After exiting, your modifications will be saved and made available for every new chroot session created afterwards.

External Commands

sbuild supports running external commands at various stages of the build process. This is useful for cases such as running a script inside the chroot after it has been setup. As an example, to run a script in /usr/local/bin/myscript, edit the $external_commands in the sbuild configuration file ~/.sbuildrc as follows.

   1 $external_commands = {
   2                         'post-build-commands' => [],
   3                         'chroot-setup-commands' => ['/usr/local/bin/myscript'],
   4                         'chroot-cleanup-commands' => [],
   5                         'pre-build-commands' => []
   6                       };

sbuild can also translate certain percent escaped keywords for external commands during certain portions of a build. For example, in post build commands, %SBUILD_CHANGES is changed to the path of the '.changes' file for a successfully built package.

Here is an example of adding a post build command to run /usr/local/bin/postbuildscript with %SBUILD_CHANGES as an argument.

   1 $external_commands = {
   2                         'post-build-commands' => ['/usr/local/bin/postbuildscript', '%SBUILD_CHANGES'],
   3                         'chroot-setup-commands' => ['/usr/local/bin/myscript'],
   4                         'chroot-cleanup-commands' => [],
   5                         'pre-build-commands' => []
   6                       };

See the 'EXTERNAL COMMANDS' section of the sbuild man page for more information on external commands.

Using "ccache" with sbuild

ccache is a compiler wrapper that will cache compilation results (produced object files) from gcc and g++; if you repeatedly compile the same source code (or parts of it), ccache will greatly shorten compilation times by avoiding recompilation of files that it has cached earlier.

This is especially useful during package development, when you might have to rebuild a package with a long compilation phase several times. It is also effective with packages that are frequently updated, because often only a few files actually change during updates to a software.

In order to prepare your sbuild environment for ccache, first perform the following setup in the host environment (i.e., outside the chroot), as user root:

   1 dir=/var/cache/ccache-sbuild
   2 install --group=sbuild --mode=2775 -d $dir
   3 env CCACHE_DIR=$dir ccache --max-size 4G
   4 cat >>/etc/schroot/sbuild/fstab <<END
   5 $dir $dir none rw,bind 0 0
   6 END

This assumes that you trust all members of the sbuild group.

It is perfectly fine to share the cache among chroots, even for different architectures. ccache honours the compiler name, size and timestamp as well as the command line when calculating hash values. At least one of these will differ between builds of the same file for different architectures.

Next place the following script into /var/cache/ccache-sbuild/sbuild-setup:

   1 #!/bin/sh
   2 export CCACHE_DIR=/var/cache/ccache-sbuild
   3 export CCACHE_UMASK=002
   4 export CCACHE_COMPRESS=1
   5 unset CCACHE_HARDLINK
   6 export PATH="/usr/lib/ccache:$PATH"
   7 
   8 exec "$@"

and make it executable:

chmod +x /var/cache/ccache-sbuild/sbuild-setup

Then for each chroot ($dist-$arch-sbuild) where you want to enable ccache

  1. Install ccache inside the chroot by running

     schroot -c source:$dist-$arch-sbuild apt-get install ccache
  2. and edit the corresponding configuration file in /etc/schroot/chroot.d/ by appending the line

     command-prefix=/var/cache/ccache-sbuild/sbuild-setup

    (Multiple command-prefix can be joined with commas, in case you already have one configured; see eatmydata below.)

Using eatmydata with sbuild

eatmydata is used when storing data on the system is not that important. This is typically the case during build runs using sbuild. To use eatmydata in sbuild, install the eatmydata package inside the sbuild chroot environment.

To enable first run, as root:

   1 schroot -c source:$dist-$arch-sbuild apt-get install eatmydata

Then edit /etc/schroot/chroot.d/$dist-$arch-sbuild-$suffix to add the line:

command-prefix=eatmydata

If you want to combine this with the ccache instructions from above then use:

command-prefix=/var/cache/ccache-sbuild/sbuild-setup,eatmydata

Note that piuparts invokes eatmydata by default and nested eatmydata invocations don't work. To deal with this pass --no-eatmydata to piuparts in your ~/.sbuildrc, or set up a separate schroot profile for piuparts as described above.

sbuild overlays in tmpfs

If you are using a type=directory chroot as described in "Setup" above, and you have sufficient memory, you can run builds in RAM for a huge speed increase. The build is performed in a tmpfs that is overlaid upon the base chroot. You need union-type=overlay in your /etc/schroot/chroot.d/sbuild-amd64-sbuild-<hash> file but that should be there by default if you followed the setup instructions above.

See also 709774.

Create the executable: /etc/schroot/setup.d/04tmpfs with

   1 #!/bin/sh
   2 
   3 set -e
   4 
   5 . "$SETUP_DATA_DIR/common-data"
   6 . "$SETUP_DATA_DIR/common-functions"
   7 . "$SETUP_DATA_DIR/common-config"
   8 
   9 
  10 if [ $STAGE = "setup-start" ]; then
  11   mount -t tmpfs overlay /var/lib/schroot/union/overlay
  12 elif [ $STAGE = "setup-recover" ]; then
  13   mount -t tmpfs overlay /var/lib/schroot/union/overlay
  14 elif [ $STAGE = "setup-stop" ]; then
  15   umount -f /var/lib/schroot/union/overlay
  16 fi

Alternatively you could configure fstab to mount /var/lib/schroot/union/overlay as tmpfs

none /var/lib/schroot/union/overlay tmpfs uid=root,gid=root,mode=0750 0 0

Enabling experimental

The Debian experimental repository can be added dynamically on top of an existing unstable chroot during each sbuild run that requires experimental:

sbuild --extra-repository='deb http://httpredir.debian.org/debian experimental main' --build-dep-resolver=aspcud mypkg.dsc

Build for experimental

If you want to build for unstable but upload to experimental. Use schroot -l --all-source-chroots to get the name of the chroot (unstable-amd64-sbuild in this case).

sbuild -d experimental -c unstable-amd64-sbuild mypkg.dsc

Alternatively, if you know that you always want to build your packages for experimental in a sid chroot, just add experimental as an alias of your sid schroot to your sid schroot configuration:

aliases=experimental

Enabling incoming.debian.org

Another useful repository to add as --extra-repository option is deb http://incoming.debian.org/debian-buildd/ buildd-unstable main in case you want to build or do a new upload before the next dinstall

sbuild --extra-repository='deb http://incoming.debian.org/debian-buildd/ buildd-unstable main' mypkg.dsc

Disabling network access for dpkg-buildpackage

<!> This doesn't seem to work with recent sbuild (2016/05)

Source packages must be buildable without accessing any remote machines. On the other hand, the build process needs network access for the installation of the build dependencies. Conveniently, the build dependencies are installed by the "root" user while dpkg-buildpackage is run under fakeroot by the user running sbuild. So the following will deny any network access during the build process through blocking traffic originating from any process owned by the sbuild group while the root user will still have network access:

sudo iptables -I OUTPUT -m owner --gid-owner sbuild ! -d 127.0.0.0/8 -j DROP
sudo -u sbuild sbuild mypkg.dsc

A better fix would be if schroot allowed to unshare the network namespace for the dpkg-buildpackage invocation. See bugs 802850 and 802849

source only upload

Sbuild is *not* suitable for source-only uploads. Sbuild is meant to build architecture specific binary packages (with the --arch-all option it can also build Architecture:all packages). But source-only uploads are neither architecture specific nor do they contain binary packages. To create a dsc for a source-only upload you would use:

dpkg-buildpackage -nc -d -S

Since dpkg 1.18.0 (starting with Debian Stretch) the -d option is implicit when specifying -S -nc so you just need:

dpkg-buildpackage -nc -S

The above requires a clean source directory as it will not run the clean target (because it might require some of the build dependencies). If you built your package with sbuild before, then your source directory will be clean anyways.

Using aliases

In Debian, an unstable chroot is used for building in a number of situations like building an unpacked source package with UNRELEASED in debian/changelog or building packages for experimental. Furthermore, distributions have alternative names like sid/unstable or experimental/rc-buggy. Sbuild selects the chroot to use either from debian/changelog (so it would be nice if UNRELEASED would trigger a build in an unstable chroot) or through the -d option which also sets the Distribution value in the resulting .changes file (so it would be handy if saying -d sid were enough and one wouldn't have to use the -c option to type unstable-amd64-sbuild manually). All of this can be solved by using schroot aliases. My sid schroot config says:

aliases=UNRELEASED,sid,rc-buggy,experimental

This means, that this schroot will be used for packages having UNRELEASED in their debian/changelog, for packages I build with -d sid (because writing out unstable is too long) as well as for packages I build for experimental.

Adding extra packages

It is often necessary to add extra binary packages as build dependencies. For example, you might want to make a package available as a build dependency that is waiting in the NEW queue and so isn't available from the mirrors. To do this, use the --extra-package=./foo.deb option to sbuild.

You might find that the output from the resolver is not helpful in determining which extra package you need to make available. In this case, it can be useful to pass --build-dep-resolver=aptitude which tends to provide more useful output (though you should remove it once you've figured out the problem).