Tracking Rawhide's (released) kernel rpms through kernel.git

[Paul Bolle]

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

[Kyle McMartin]

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

[Paul Bolle]

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

[Kyle McMartin]

On Thu, Feb 24, 2011 at 09:53:19PM +0100, Paul Bolle wrote:
> > 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?

Rawhide is about the only thing I care about bugs /on/. ;-)

--Kyle

[Don Zickus]

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

[Jarod Wilson]

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>'.

[Chuck Ebbert]

On Thu, 24 Feb 2011 16:20:41 -0500
Don Zickus  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.