I have been working on the mainline kernel builds action from UDS.
There are two drivers for this functionality:
1) mainline kernels at the same levels as our Ubuntu kernels. If we have
a kernel which incorporates 188.8.131.52 it is useful to offer a vanilla
184.108.40.206 for comparison against allowing us to eliminate the Ubuntu
delta as the issue, and
2) linus kernels. It is helpful to have mainline kernels to allow testing
of bleeding edge kernels.
For this discussion we are talking about officially tagged kernels,
v220.127.116.11 or v2.6.29-rc2, we are not considering -git kernels at this
Following this email are two patches. The first modifies the configuration
system to simplify the build process. The second carries the build
= Naming =
Our first major problem is how should we name the kernels produced in
this way. There are a large number of conflicting factors, we need:
1) to be able to install one or more of these kernels without affecting
the currently installed kernels;
2) to be able to clearly recognise these kernels when they are installed both
when selecting them on the boot menu and when reporting them in uname -a
(remember we do not have /proc/version_signature in mainline kernels);
3) our current build machinary expects to name the packages based on
the first three components of the kernel version number and the ABI
number, these in combination need to be unique to prevent collisions
in /lib/modules; and
4) valid package version numbers, any naming must fit into the valid
version numbers and so cannot contain '.', '_', or '-' in most parts
of the name that we can change (see 3).
Of these (1) and (3) combine to limit us to modifying the abi number,
and the contents of this must be unique to the kernel. (2) and (4)
combine such that we must encode the full version number in as near to a
human reable form as possible. To this end I am proposing we encode
this as below. Basically that we convert the version number string by
converting the number in it to be two digits, remove the '.' and '-'
symbols. For example the abi number for the following releases is as
Where the commit does not have an official tag for example if we are
taking a kernel between tags say for a -gitN release
we further append the abbreviated sha1 of the actual commit. This would
not be the common case. This would appear as below:
Note that this is the ABI number we are modifying and so we will end up
with kernels with names as below:
installing like this:
and showing up in uname as below (again remember we have no
version_signature on mainline kernels):
Linux pinky 2.6.27-02062712-generic #1
SMP Fri Jan 23 12:34:01 UTC 2009 i686 GNU/Linux
= Build Script =
Following this email (patch 2) is the first version of the build script.
This is designed to be run in a special git repository. Special in the
sense that it is a virgin ubuntu-intrepid (or ubuntu-jaunty) tree with the
required mainline release added as a remote and fetched into it. That is
such that the commit you wish to build and its tags are available within
the repository. You then simply run mainline-build <commit> to generate
the binary debs required:
I see this being used in this manner. We would make a mainline build repo
by cloning say the each ubuntu-* tree which we care about. We could then
add a remote of upstream connected to the stable tree for that release.
This would be fetched on a regular basis from a cronjob. As new mainline
tag appear this would trigger execution of the mainline-build script
as above. The resulting binary .deb's would then be collected in a
web accessible directory for installation.
NOTE: that as things stand we need to modify the config generators to
allow us to run make oldconfig to take the default options as often
the config we are using is not 100% compatible with the new kernel.
The patch to modify this also follows this email (patch 1).
= Requirements =
We would need to find or generate a machine environment where we are
1) access mainline releases (git.kernel.org),
2) access our main ubuntu-* repositories (kernel.ubuntu.com), and
3) access to schroot environments for the supported architectures.
I believe we can split the processing between say zinc and ronne pretty
easily assuming we can transfer data between them. We need to think on
what the least we would need to ask for to make this work actually is.
Andy Whitcroft (2):
UBUNTU: allow us to build default configs for automated builds
UBUNTU: mainline-build -- add build machinary for mainline builds