• Intro
• Downloads
• Community
• Development
• News
• TALK

Building packages with sbdmock

Note: this page is work in progress documenting my experiments with sbdmock gcobb 21:59, 15 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-builder 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 Build-Depends: 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:

Note: the extras configurations are not used by the autobuilder: all building is done in extras-devel.

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 -i386-extras-devel, which the autobuilder will build automatically unless your package defines that it is only for armel. Note that the autobuilder never uses the -extras configurations.

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.