Building packages with sbdmock

Note: this page is work in progress documenting my experiments with sbdmock --gcobb 18:17, 12 July 2009 (UTC)

Before submitting packages to the autobuilder, it is important to test that it will build. The first step of that is to use dpkg-buildpackage in the scratchbox environment to create the packages (or a tool like MUD can be used, which automatically calls dpkg-buildpackage).

However, just because a package builds in your normal scratchbox development environment is no guarantee that it will build in the autobuilder. The main reason is that the autobuilder starts with no packages installed and only installs the packages defined in your package control file (using the BuildDepends: line).

sbdmock is a tool which provides a clean scratchbox environment, allowing you to test that your package can build in that environment before submitting it to the autobuilder. It can either be used manually, or it can be used as part of an automatic script (for example, I intend to use it as part of my nightly builds of GPE).

Of course, if the build in sbdmock fails you will need to debug it. sbdmock can be used for that as well.

The sbdmock home page is: http://bifh.org/wiki/sbdmock

The sbdmock git source tree can be accessed at: http://github.com/kad/sbdmock/tree/master

= Getting sbdmock =

This is the procedure I used, using Debian squeeze. Packages for sbdmock may be available for your platform, however I wanted to use the latest development version and, as I expected to make changes to it, I did not want to install it into system directories.

1. Install Debian packages for git-core, python-pip, python-setuptools and python-virtualenv using:

sudo aptitude install git-core python-pip python-setuptools python-virtualenv

2. Create the python virtual environment:

virtualenv sbdmock

3. Install minideblib, which is a prerequisite for using sbdmock:

pip install -E sbdmock minideblib

4. Install sbdmock from the git repository:

pip install -E sbdmock -e git://github.com/kad/sbdmock.git#egg=sbdmock

5. Copy the config files to your sbdmock config directory:

mkdir ~/.sbdmock/ cp sbdmock/src/sbdmock/etc/*.cfg ~/.sbdmock/

6. Test the sbdmock installation:

sbdmock/bin/sbdmock --help

= sbdmock documentation =

There is no documentation. sbdmock --help gives:

Usage: usage: sbdmock [options] /path/to/dsc optional commands: clean - clean out the specified chroot init - initialize the chroot, do not build anything

Options: -h, --help           show this help message and exit -r TARGET            compilation target name/config file name default: default --no-clean           do not clean chroot before building --debug              Output copious debugging information --resultdir=RESULTDIR path for resulting files to be put --statedir=STATEDIR  path for state dirresulting files to be put --sbtarget=SBTARGET  Overrides scratchbox target name from configuration file --addrepo=ADDREPO    Additional repository to sources.list --insertrepo=INSERTREPO Additional repository to sources.list. Will be added on first place --uniqueext=UNIQUEEXT Arbitrary, unique extension to append to target name -u                   Generate unique extension (based on package name) -b                   indicates that no source files are to be built -B                   same as '-b', but no architecture-independent binary package files are to be build either -S                   only the source should be build and no binary packages need to be made --dbo=DBO            Modifiers for DEB_BUILD_OPTIONS (e.g. '+debug,-parallel') --define=DEFINE      Define variables which might be used in other variables. Format: name=value

= sbdmock configuration =

The most important part of the configuration is to put the rootstraps where sbdmock can find them.

The rootstrap file names are specified in the configuration files (for example the standard chinook configuration file specifies maemo-sdk-rootstrap_4.0_armel.tgz as the rootstrap file name). Be aware that the rootstrap file names are relative to your scratchbox home directory. So, you have three options:

1) Put the rootstrap files in your scratchbox home directory. This is easiest and means no changes to the configuration files.  However, depending on how you installed the SDK, they are almost certainly not in that directory at the moment.

2) Put a softlink in the scratchbox home directory by logging in to scratchbox'' and using something like:

ln -s /some/directory/maemo-sdk-rootstrap_4.0_armel.tgz

Note that this directory has be be accessible from within the scratchbox environment, of course.

3) Edit the configuration file to change the location. The configuration file is in the ~/.sbdmock directory and the line to change is the one which defines  config_opts['rootstrap'] .  Again, the file has to be accessible from within the scratchbox environment.

Currently the following config files are shipped with sbdmock, although others may be added soon:

= Test build =

To test the package defined in something.dsc will build using the chinook autobuilder use the following command:

sbdmock/bin/sbdmock -r maemo-chinook-armel-extras-devel -u something.dsc

This command must be issued from outside the scratchbox environment.

sbdmock displays a message at the end of the build saying where the results (including logs) can be found. That filespec is designed to be used from outside the scratchbox environment. From inside the scratchbox environment the results are in  ~/maemo-chinook-armel-extras-devel/results .

Once the -armel-extras-devel build is working, it is worth testing the other configurations: -i386-extras-devel (which the autobuilder will build automatically unless your package defines that it is only for armel), -armel-extras (so that you know the build will work if/when the package is promoted to extras) and -i386-extras.

= Debugging build problems =

The test builds described above use the sbdmock -u option. This option causes sbdmock to create a completely new scratchbox target, with a unique name, run the build and delete the target again. This is ideal for automatic builds and test builds but it is not useful when you want to debug a failing build. In that case, you would like the scratchbox target to remain around so that you can select it and do debugging to see why your build failed, and fix it.

To do this, use the sbdmock --sbtarget command to specify a target to use. This should be a target which already exists but one which you do not mind sbdmock cleaning. Cleaning involves re-initialising the target so things like changes to /etc/apt/sources.list and packages you have installed will be lost. But don't worry, no files in your home directory will be modified.

For example:

sbdmock/bin/sbdmock -r maemo-chinook-armel-extras-devel --sbtarget TEST_40_ARMEL something.dsc

Note: currently sbdmock does not actually recreate the target completely, so it is important that you specify a target which has the correct compiler, devkit and CPU transparency settings for the configuration you are using. In other words, use a target which was set up for the correct version of the SDK and the correct architecture.

If the build fails you can go into scratchbox, select the target (if necessary) and debug the problem. You can then use dpkg-buildpackage to recreate the package files and re-try the build in sbdmock.