This documents describes how to setup and use the kernel team build scripts. This is meant as a reference for the kernel team.

Basic setup

The scripts are located in a public git repository (on zinc aka They are written so they can be executed from the current working directory or some directory of the PATH environment.

git clone git:// <localdir>
cd <localdir>

The scripts will store and use configuration files located in ~/.ubuild. The base directory can be changed by exporting a shell variable set to the location of the desired location. This might be done by putting the following code into the .bashrc file.


An initial configuration can be created by calling build-init. This will create the base configuration directory, the main config file, the groups, the distros and some default hosts.

Main config file

Path: $UBUILDDIR/config

This contains the global options (shell syntax):




The default distro to use.

Group definitions

Path: $UBUILDDIR/groups/<groupname>

These define groups of hosts to use for builds. The default group will be used if no other group is given. The autobuild group is used when scripts are started with the autobuild argument. The layout is one target per line. Each target can be either a <host> or <host>-<arch>, or <arch>. If using a hostname, this host will be used to build the native architecture of that host on that host. The <host>-<arch> form is used to enforce builds of another supported architecture (e.q. ronne-i386 builds i386 packages on ronne which is amd64). Finally <arch> will look for a host that can build the desired architecture (do not expect this to work too well at the moment).

Distro definitions

Path: $UBUILDDIR/distros/<dist>

For each distro, this sets (shell syntax) the options that are specific for each distro:




Defines the location where the kernel sources (git) for this distro are located (local host).

Host definitions

Path: $UBUILDDIR/hosts/<host>

Defines the environment for each host that can be used with the build scripts. New hosts should be created by (though this can also be done manually):

build-create-host <fq-hostname>

The script will check the target host and create a configuration for that. The name for that host will be the basic hostname (without domain). A suitable target host must satisfy some requirements:

  • The local system/user must be able to ssh to the target host.
  • The target host must have the the following packages installed:
    • git-core (to push the sources)

    • Either dchroot or schroot (builds are always done in a chroot environment)

  • The target host must have chroot environments ready for kernel compilation. The environments must be named <distro> for the environments that use the base architecture of that host. Or <distro>-<arch> for those that are created for different architectures (e.g. hardy-lpia).

The following variables are set in the host config file (shell syntax):




Optional command to set a desired architecture


Supported architectures, separated by blanks.


Base directory used for builds. This path must be valid in the chroot environment!


Either schroot or dchroot


Command used to build as root (default fakeroot)


Fully qualified hostname


The real architecture of the host

Running a build


Before starting the actual build some files have to be sent to the target host. This includes some scripts that will be run during the build as well as the git tree. This also cleans up the source directory on the target host.

The basic command to prepare a target is build-prep which will take the following optional arguments:

--dist <dist>

Specifies a different distribution than the default one specified in $UBUILDDIR/config (hardy,intrepid,...)

--branch <name>

Will send a different branch (default is master)


Does send the LUM sources instead of the kernel sources

build-prep <target>

Start a build

This will start a build on the specified target as a background process. Requires --dist to be specified if not the default. The current state can be monitored by calling build-status or build-monitor.

build-start <target>

Checking the status

Requires --dist if not the default.

build-status [-v] <target> [<target> ...]

Will run a one time check on the target(s). Using the -v option will produce more detail.

build-monitor [-v] <target>] [<target> ...]

Runs a periodically updated status on the target(s) by using the build-status command in the background.

Preparing PPA builds

build-mkppa [--nopkg] [--noinc] [--base <tag>] [--erase]


Do not create the package files


Do not increment the build version number

--base <tag>

Create a branch (ppabuild) based on the given tag


Deletes everything other than the directory .git

This command must be run in the top-level directory of a git tree and will try to automatically apply patches and commits necessary for a PPA build. This will also update the changelog and modify the current tree.

In order to operate a certain directory layout is required:

If <kernel> is the current directory that contains the kernel, build-mkppa will look for a directory named <kernel-ppa> that contains the following files and directories:

  • ppa-version will be created and contains the version number of the last PPA build which will get incremented each time the command is run.

  • patches or patches-<tag> contain the patches that get applied on top of the current git tree for the PPA build. The first one is used for normal builds while the second one is used for builds based on a specific release tag.

  • abi-version is optional and will contain the version number of the build that defines the kABI version for this build. This is usually a link to the ppa-version file of another package (e.g. for LUM this points to the kernel-ppa version.

Kernel/Dev/KernelBuildScripts (last edited 2012-04-25 17:18:57 by sconklin)