Mainline builds

Geir Ove Myhr gomyhr at gmail.com
Tue Apr 6 09:46:18 UTC 2010


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 canonical.com> 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
>> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds ?
>
> 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?

>> 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 https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
>> 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

>> 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 http://bugs.freedesktop.org/show_bug.cgi?id=27187#c64 (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.

Geir Ove




More information about the kernel-team mailing list