First kernel upload for gutsy...priceless

[Matt Zimmerman]

On Fri, Apr 27, 2007 at 05:00:33PM -0400, Ben Collins wrote:
> The new build system is in effect in linux-source. I've updated the wiki
> to reflect a few things about it, but I still need to do a large bit of
> public documentation. There's lots of comments and a few READMEs in the
> debian/ directory. It has some great features, including a build time test
> suite that we plan to use for module validation, among other things.

If this helps to simplify kernel maintenance and makes it easier to
implement new functionality, I'm all for it.  I have a few questions and
concerns, though.

First, what's the rationale for splitting linux-ubuntu-modules into a
separate source package?  This requires an additional upload for every
kernel ABI change, including some security updates, which is something we
originally tried to minimize by bringing drivers in-tree.  I think we're now
up to four (kernel, ubuntu, restricted, meta).

I'm also concerned about the possiblity for users to end up without
linux-ubuntu-modules, losing functionality.  The ipw2200 firmware, for
example, is in this package, and without it the driver fails in mysterious
(to a desktop user) ways.  The metapackages are convenient, but they have
not been a panacea, and we already have occasional problems of this type
with l-r-m.

> Part of this new build system brings us some new and interesting
> flavours right out of main tree: Xen and Real-Time.
> 
> Previously, large patchsets like this were rejected, and required to be
> built out-of-tree. There's a million reasons we did this, but the main
> one is that we didn't want this patch in our stock source. With the new
> build system, however, we can have flavours which patch the stock source
> at build time to produce a sand boxed build. So while we have Xen and
> Real-Time kernels (-xen and -rt flavours), the main kernels are not
> patched with this code.
> 
> This is a big win for us and the community. It means we can provide
> steady updates during development cycle, and provide things like
> linux-restricted-modules. For post release it means that security
> updates will benefit even these targets.

What happens if the patch fails to apply, or the patched source fails to
build?  How does it affect the build time for kernel uploads?

> Please note that this does not mean we'll be doing a flavour for any old
> patch that someone drops in an email and sends our way. So please, hold
> your suspend2 requests, and similar. Even though this is easier to
> maintain, it still means we have to maintain it. If the patch doesn't
> apply, we gotta do something about it (especially if the team involved,
> like ubuntu-studio and ubuntu-xen, don't keep their end of the
> bargain :)
> 
> This is the last kernel upload you'll see for a few weeks. 3/4 of the
> kernel team will be on the road next week, and the following week is UDS
> where we'll all be drinking the night away in some spanish saloon, maybe
> dodging bulls in our spare time.
> 
> So happy kerneling everyone!
> 
> PS: -rt and -xen did not get nvidia or fglrx builds in lrm. For -rt it
> was because Ingo's patch changes some things so that nvidia and fglrx
> kernel modules link to GPL-only symbols, thus making them unloadable.
> 
> 
> -- 
> Ubuntu:    http://www.ubuntu.com/
> Linux1394: http://www.linux1394.org/
> 
> 
> -- 
> ubuntu-devel-announce mailing list
> ubuntu-devel-announce at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce

-- 
 - mdz