Mainline builds

Andy Whitcroft apw at
Tue Apr 6 12:02:21 UTC 2010

On Tue, Apr 06, 2010 at 11:46:18AM +0200, Geir Ove Myhr wrote:
> Thank you for the explanation. I have a few follow-up questions inline.
> On Tue, Apr 6, 2010 at 11:20 AM, Andy Whitcroft <apw at> wrote:
> >> Also, since around March 15 the mainline builds have a release name
> >> associated to it (lucid and karmic). Could somebody explain the
> >> significance of this or document it at
> >> ?
> >
> > These indicate which Ubuntu series the builds were made in, essentially
> > from which series the configuration was taken.  Previously the
> > configurations were very similar and there was little difference which
> > release they were built and no need to differentiate them.  However,
> > from Karmic to Lucid we have a number of very specifici configuration
> > requirements such as DEVTMPFS which mean that a kernel built with a
> > Karmic based configuration and the same kernel built with a Lucid based
> > configuration are considerably different.  Therefore it is sensible to
> > expose the build series in the built directory names.  This will also
> > allow us to build in multiple series where that is appropriate.
> What is the practical implications of which series the configuration
> is taken from? I see that the most recent 2.6.34-rcX, drm-next, and
> drm-intel-next all use Karmic configuration. Would it be fine to ask a
> bug reporter on Lucid to test one of those mainline kernels?

The greater the configuration skew the higher the likelyhood of a kernel
not being compatible with the userspace components.  While we expect
that a newer kernel to work on older userspace (on the previous series)
we do not test it there, and do not expect older kernels to work on
newer series (though they may).

The main time we have an issue is during the middle of a development
release particularly where the release is an LTS where we want to test
the same mainline kernels on different releases.

> >> And while mentioning the wiki page, it would be nice if it could
> >> explain in more detail what "Ubuntu kernel configuration files" means.
> >> My experience is that copying e.g.
> >> /boot/config-2.6.34-020634rc1-generic does not reproduce a mainline
> >> build if I build it myself (e.g. I will have to turn kernel debugging
> >> off in order to produce kernel-image*.deb < 30 MB instead of > 200
> >> MB). The wiki page
> >> suggests one needs to use the --overlay-dir option to make-kpkg with a
> >> current ubuntu-git tree.
> >
> > All Ubuntu builds are built with debugging turned on, and that then
> > stripped at packaging time.  This allows one build to produce .ddeb and
> > .deb packages and saving time.
> Okay. So is the following close to an accurate description?
> * Mainline kernels: Ubuntu specific configuration (.config) + Ubuntu
> specific packaging (taken from/usr/share/kernel-package unless
> specified by --overlay-dir) + unmodified kernel source
> * Stock ubuntu kernels:  Ubuntu specific configuration + Ubuntu
> specific packaging + kernel source from Ubuntu git tree

Both are built using the Ubuntu specific configuration and packaging taken
from the series in which they are built, taken directly from the tip of
the git tree for that series.  In the case of the mainline releases the
Ubuntu source tree is then substituted for an unmodified upstream version
at the specified tag.

> >> I understand you guys are busy preparing for the Lucid release, but
> >> the missing mainline builds and difficult compile instructions make
> >> triaging and upstreaming Ubuntu bugs and testing patches from upstream
> >> much harder. For example, drm/i915 developers need more testing of the
> >> patch at (LP:
> >> 541511) and I would have liked to prepare an Ubuntu package with that
> >> so that some of the Ubuntu users who have reported this problem could
> >> provide their test results without figuring out how to patch and build
> >> a kernel.
> >
> > Entirely why we spend time producing these builds.  I hope to have these
> > fixed and building again correctly today.
> Thank you! I will try again to build a kernel-package with 2.6.34-rc3
> + patch once I have some spare time.

That one is building at the moment and should pop out shortly, it will
be the first built 'in' lucid.


More information about the kernel-team mailing list