Is it possible to track the (released) kernel rpms for Rawhide through kernel.git (git://pkgs.fedoraproject.org/kernel.git ) and build the (released) kernel rpms locally?
The background is that I'd like to maintain a (small) set of patches on top of those releases and build my ".local" rpms from that repository. Currently I download (every now and then) the kernel SRPM with "yumdownloader --source", edit its specfile, rebuild it, etc., all by hand. That is often more work than I'd like it to be and error prone too.
(Of course this is not Rawhide specific. One might want to do that for non-Rawhide releases too.)
Paul Bolle
On Wed, Feb 23, 2011 at 10:46:02AM +0100, Paul Bolle wrote:
Is it possible to track the (released) kernel rpms for Rawhide through kernel.git (git://pkgs.fedoraproject.org/kernel.git ) and build the (released) kernel rpms locally?
https://fedoraproject.org/wiki/Building_a_non-debugging_kernel
Basically follow these directions, but throw your own patches. I recommend patching your stuff in at the beginning of the list of patches, since they change less. Then you can git diff that, and probably reapply it every time you have to merge.
YMMV, No warranty, guarantee void in Tennessee, etc. Don't complain to us about bugs.
--Kyle
On Wed, 2011-02-23 at 10:41 -0500, Kyle McMartin wrote:
https://fedoraproject.org/wiki/Building_a_non-debugging_kernel
Basically follow these directions, but throw your own patches.
The fedpkg stuff seemed overkill for my needs. This is what I did: - hacked at pyfedpkg until it just did enough to download the files in the sources file; - built an RPM with a command like this: rpmbuild --define '_specdir !#:+' $PWD --define '_sourcedir !#:+' $PWD [...] kernel.spec
I recommend patching your stuff in at the beginning of the list of patches, since they change less.
For my particular workflow it would be nice to have two sections reserved for local patches, wrapped in, say, "%if %{local-patches}", to store the references to the patch files and their ApplyPatch entries. All that so I could build my local kernel flavor with "rpmbuild --with local-patches [...]".
And yes, I'd like a pony too.
YMMV, No warranty, guarantee void in Tennessee, etc. Don't complain to us about bugs.
You do realize we were talking about Fedora Rawhide, don't you?
Thanks!
Paul Bolle
On Thu, Feb 24, 2011 at 09:53:19PM +0100, Paul Bolle wrote:
On Wed, 2011-02-23 at 10:41 -0500, Kyle McMartin wrote:
https://fedoraproject.org/wiki/Building_a_non-debugging_kernel
Basically follow these directions, but throw your own patches.
The fedpkg stuff seemed overkill for my needs. This is what I did:
- hacked at pyfedpkg until it just did enough to download the files in the sources file;
- built an RPM with a command like this: rpmbuild --define '_specdir !#:+' $PWD --define '_sourcedir !#:+' $PWD [...] kernel.spec
I recommend patching your stuff in at the beginning of the list of patches, since they change less.
For my particular workflow it would be nice to have two sections reserved for local patches, wrapped in, say, "%if %{local-patches}", to store the references to the patch files and their ApplyPatch entries. All that so I could build my local kernel flavor with "rpmbuild --with local-patches [...]".
For RHEL we added code like this
# empty final patch file to facilitate testing of kernel patches Patch99999: linux-kernel-test.patch
# conditionally applied test patch for debugging convenience %if %([ -s %{PATCH99999} ] && echo 1 || echo 0) %patch99999 -p1 %endif
for sorta of the same reasons. a quick and easy way to add a patch to the srpm without touching the spec file.
There is just an empty linux-kernel-test.patch lying in the tree. If it is non-empty then it gets applied.
If you want to whip something up like that, I'm sure Jarod would review it. He likes spec file patches. :-)))
Cheers, Don
On Thu, Feb 24, 2011 at 04:20:41PM -0500, Don Zickus wrote:
On Thu, Feb 24, 2011 at 09:53:19PM +0100, Paul Bolle wrote:
On Wed, 2011-02-23 at 10:41 -0500, Kyle McMartin wrote:
https://fedoraproject.org/wiki/Building_a_non-debugging_kernel
Basically follow these directions, but throw your own patches.
The fedpkg stuff seemed overkill for my needs. This is what I did:
- hacked at pyfedpkg until it just did enough to download the files in the sources file;
- built an RPM with a command like this: rpmbuild --define '_specdir !#:+' $PWD --define '_sourcedir !#:+' $PWD [...] kernel.spec
I recommend patching your stuff in at the beginning of the list of patches, since they change less.
For my particular workflow it would be nice to have two sections reserved for local patches, wrapped in, say, "%if %{local-patches}", to store the references to the patch files and their ApplyPatch entries. All that so I could build my local kernel flavor with "rpmbuild --with local-patches [...]".
For RHEL we added code like this
# empty final patch file to facilitate testing of kernel patches Patch99999: linux-kernel-test.patch
# conditionally applied test patch for debugging convenience %if %([ -s %{PATCH99999} ] && echo 1 || echo 0) %patch99999 -p1 %endif
for sorta of the same reasons. a quick and easy way to add a patch to the srpm without touching the spec file.
There is just an empty linux-kernel-test.patch lying in the tree. If it is non-empty then it gets applied.
If you want to whip something up like that, I'm sure Jarod would review it. He likes spec file patches. :-)))
I blame dzickus!
Wait, what are we talking about now? :D
I think we did have that in the Fedora kernel, and it got nuked. I don't object to it coming back, but its not my call. If it did, it would be nice if something were simultaneously set in the build to set buildid to make sure the kernel spit out has a different nvr from a stock kernel.
Personally, I just maintain a git branch with additional patches and spec file changes to apply them, and then routinely rebase it. Then 'fedpkg srpm', then 'rpmbuild --rebuild --with baseonly <that srpm>'.
On Thu, 24 Feb 2011 16:20:41 -0500 Don Zickus dzickus@redhat.com wrote:
For RHEL we added code like this
# empty final patch file to facilitate testing of kernel patches Patch99999: linux-kernel-test.patch
# conditionally applied test patch for debugging convenience %if %([ -s %{PATCH99999} ] && echo 1 || echo 0) %patch99999 -p1 %endif
Fedora has something similar:
Patch02: git-linus.diff
ApplyOptionalPatch git-linus.diff
This gets applied early, before any fedora patches, and since it's really meant for applying an upstream git snapshot it gets applied even when building a vanilla upstream kernel.
I use it all the time for testing -stable updates.
kernel@lists.fedoraproject.org