I created a kernal patch package for our local site, linux-patch-web100, that was working fine with hardy. It seems that the "--added-patches" argument to make-kpkg was removed sometime between the release of hardy and lucid. I haven't found any discussion of this online. My question is, what is the current best practice for packaging linux kernel patches? Is it still dh-kpatches? Do I just have to update my README to instruct the users to run /usr/src/kernel-patches/all/apply/web100 before make-kpkg? Or, is there a new framework that is now preferred?
Many Thanks,
Tim Nowaczyk
--
Timothy Nowaczyk
Network Systems Engineer
University of Virginia - ITC
tan7f@virginia.edu
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
08-10-2010, 04:09 PM
Tim Gardner
linux-patch packaging best practice.
On 08/10/2010 08:55 AM, Tim Nowaczyk wrote:
> Hello all,
>
> I created a kernal patch package for our local site,
> linux-patch-web100, that was working fine with hardy. It seems that
> the "--added-patches" argument to make-kpkg was removed sometime
> between the release of hardy and lucid. I haven't found any
> discussion of this online. My question is, what is the current best
> practice for packaging linux kernel patches? Is it still
> dh-kpatches? Do I just have to update my README to instruct the
> users to run /usr/src/kernel-patches/all/apply/web100 before
> make-kpkg? Or, is there a new framework that is now preferred?
>
> Many Thanks, Tim Nowaczyk
>
> -- Timothy Nowaczyk Network Systems Engineer University of Virginia -
> ITC tan7f@virginia.edu
>
>
>
>
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 https://wiki.ubuntu.com/Kernel about how we maintain the
Ubuntu kernel.
rtg
--
Tim Gardner tim.gardner@canonical.com
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
08-10-2010, 06:33 PM
Tim Nowaczyk
linux-patch packaging best practice.
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 https://wiki.ubuntu.com/Kernel 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 (http://www.web100.org/) 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
../kernel-patches/all/apply/web100
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@virginia.edu
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
08-10-2010, 08:06 PM
Pete Graner
linux-patch packaging best practice.
On Tue, 2010-08-10 at 14:33 -0400, Tim Nowaczyk wrote:
> 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 https://wiki.ubuntu.com/Kernel 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 (http://www.web100.org/) 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...
Thats not what Tim G. was saying. You need to apply those patches to the
a local copy of the Ubuntu git tree and build the kernel from source.
The pointers he gave you will tell you how to check out a copy of the
tree, apply the patches and build/package.
>
> apt-get install linux-patch-web100
> cd /usr/src/linux
> ../kernel-patches/all/apply/web100
> make-kpkg ...
>
> The web100 patches don't create modules, so I think that means I can't use dkms, right?
>
Correct, you have to patch the core kernel sources.