sbuild with local, newer, dependencies
Written by Barry Warsaw in technology on Thu 01 September 2011. Tags: canonical, debian, packaging, ubuntu,
Update 2016-11-28: I've updated this article with new instructions!
sbuild is an excellent tool for locally building Ubuntu and Debian packages. It fits into roughly the same problem space as the more popular pbuilder, but for many reasons, I prefer sbuild. It's based on schroot to create chroot environments for any distribution and version you might want. For example, I have chroots for Ubuntu Oneiric, Natty, Maverick, and Lucid, Debian Sid, Wheezy, and Squeeze, for both i386 and amd64. It uses an overlay filesystem so you can easily set up the primary snapshot with whatever packages or prerequisites you want, and the individual builds will create a new session with an overlaid temporary filesystem on top of that, so the build results will not affect your primary snapshot. sbuild can also be configured to save the session depending on the success or failure of your build, which is fantastic for debugging build failures. I've been told that Launchpad's build farm uses a customized version of sbuild, and in my experience, if you can get a package to build locally with sbuild, it will build fine in the main archive or a PPA.
Right out of the box, sbuild will work great for individual package builds, with very little configuration or setup. The Ubuntu Security Team's wiki page has some excellent instructions for getting started (you can stop reading when you get to UMT :).
One thing that sbuild doesn't do very well though, is help you build a stack of packages. By that I mean, when you have a new package that itself has new dependencies, you need to build those dependencies first, and then build your new package based on those dependencies. Here's an example.
I'm working on bug 832864 and I wanted to see if I could build the newer Debian Sid version of the PySide package. However, this requires newer apiextractor, generatorrunner, and shiboken packages (and technically speaking, debhelper too, but I'm working around that), so you have to arrange for the chroot to have those newer packages when it builds PySide, rather than the ones in the Oneiric archive. This is something that PPAs do very nicely, because when you build a package in your PPA, it will use the other packages in that PPA as dependencies before it uses the standard archive. The problem with PPAs though is that when the Launchpad build farm is overloaded, you might have to wait several hours for your build. Those long turnarounds don't help productivity much. ;)
What I wanted was something like the PPA dependencies, but with the speed and responsiveness of a local build. After reading the sbuild manpage, and "suffering" through a scan of its source code (sbuild is written in Perl :), I found that this wasn't really supported by sbuild. However, sbuild does have hooks that can run at various times during the build, which seemed promising. My colleague Kees Cook was a contributor to sbuild, so a quick IRC chat indicated that most people create a local repository, populating it with the dependencies as you build them. Of course, I want to automate that as much as possible. The requisite googling found a few hints here and there, but nothing to pull it all together. With some willful hackery, I managed to get it working.
Rather than post some code that will almost immediately go out of date, let me point you to the bzr repository where you can find the code. There are two scripts: prep.sh and scan.sh, along with a snippet for your ~/.sbuildrc file to make it even easier. sbuild will call scan.sh first, but here's the important part: it calls that outside the chroot, as you (not root). You'll probably want to change $where though; this is where you drop the .deb and .dsc files for the dependencies. Note too, that you'll need to add an entry to your /etc/schroot/default/fstab file so that your outside-the-chroot repo directory gets mapped to /repo inside the chroot. For example:
# Expose local apt repository to the chroot
/home/barry/ubuntu/repo /repo none rw,bind 0 0
An apt repository needs a Packages and Packages.gz file for binary packages, and a Sources and Sources.gz file for the source packages. Secure APT also requires a Release and Release.gpg file signed with a known key. The scan.sh file sets all this up, using the apt-ftparchive command. The first apt-ftparchive call creates the Sources and Sources.gz file. It scans all your .dsc files and generates the proper entries, then creates a compressed copy, which is what apt actually "downloads". The tricky thing here is that without changing directories before calling apt-ftparchive, your outside-the-chroot paths will leak into this file, in the form of Directory: headers in Sources.gz. Because that path won't generally be available inside the chroot, we have to get rid of those headers. I'm sure there's an apt-ftparchive option to do this, but I couldn't find it. I accidentally discovered that cd'ing to the directory with the .dsc files was enough to trick the command into omitting the Directory: headers.
The second call to apt-ftparchive creates the Packages and Packages.gz files. As with the source files, we get some outside-the-chroot paths leaking in, this time as path prefixes to the Filename: header value. Again, we have to get rid of these prefixes, but cd'ing to the directory with the .deb files doesn't do the trick. No doubt there's some apt-ftparchive magical option for this too, but sed'ing out the paths works well enough.
The third apt-ftparchive file creates the Release file. I shameless stole this from the security team's update_repo script. The tricky part here is getting Release signed with a GPG key that will be available to apt inside the chroot. sbuild comes with its own signing key, so all you have to do is specify its public and private keys when signing the file. However, because the public file from:
/var/lib/sbuild/apt-keys/sbuild-key.pub
won't be available inside the chroot, the script copies it to what will be /repo inside the chroot. You'll see later how this comes into play.
Okay, so now we have the repository set up well enough for sbuild to carry on. Later, before the build commences, sbuild will call prep.sh, but this script gets called inside the chroot, as the root user. Of course, at this point /repo is mounted in the chroot too. All prep.sh needs to do is add a sources.list.d entry so apt can find your local repository, and it needs to add the public key of the sbuild signing key pair to apt's keyring. After it does this, it needs to do one more apt-get update. It's useful to know that at the point when sbuild calls prep.sh, it's already done one apt-get update, so this does add a duplicate step, but at least we're fortunate enough that prep.sh gets called before sbuild installs all the build dependencies. Once prep.sh is run, the chroot will have your overriding dependent packages, and will proceed with a normal build.
Simple, huh?
Besides getting rid of the hackery mentioned above, there are a few things that could be done better:
- Different /repo mounts for each different chroot
- A command line switch to disable the /repo
- Automatically placing .debs into the outside-the-chroot repo directory
Anyway, it all seems to hang together. Please let me know what you think, and if you find better workarounds for the icky hacks.