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

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

-- 
Jarod Wilson
jarod at redhat.com