linux-patch packaging best practice.

Tim Nowaczyk tan7f at
Tue Aug 10 18:33:10 UTC 2010

On Aug 10, 2010, at 12:09 PM, Tim Gardner wrote:

> Tim - we're all pretty much git centric and do development ala the upstream kernel community. As such we (the kernel team) don't apply patches to the source package, rather we commit a patch to a local git repository and rebuild. There is a boat load of information in the wiki beginning at about how we maintain the Ubuntu kernel.
I must not have made myself clear.  I'm not trying to get a patch included in the default ubuntu kernel.  In hardy, there were packages like, linux-patch-evms, linux-patch-lustre, and linux-patch-aufs, that would allow the system administrator to add functionality to the kernel on specific systems by installing one of those packages, then runniing make-kpkg --added-patches evms, for example, to build a kernel with the evms extensions.  I created a package that bundled up the web100 patches this way (  I see that the three previously mentioned packages aren't in lucid.  I installed linux-patch-tomoyo on my lucid machine to see what the new practice is, but it's README says to run "make-kpkg --added-patches", even though "--added-patches" no longer works on lucid (I guess I should file a documentation bug).  So, I think my question still remains unanswered.  Is there a new framework in place in Ubuntu for patching the kernel on an individual machine?  Or is the only solution to update my documentation to say...

apt-get install linux-patch-web100
cd /usr/src/linux
make-kpkg ...

The web100 patches don't create modules, so I think that means I can't use dkms, right?

Many thanks,
Tim Nowaczyk

Timothy Nowaczyk
Network Systems Engineer
University of Virginia - ITC
tan7f at

More information about the kernel-team mailing list