On Thu, 2008-05-08 at 10:06 +1200, Martin Langhoff wrote:
> Dennis, David,
>
> There is right now something that I am having trouble understanding
> how it's done - related to kernel packaging. Is there any
> documentation on how the RH team manages kernels with additional
> patches?
>
> All I can find is tips to manage the patches as patches, but that is
> so oldstyle. I want a git-integrated workflow... or quilt or whatever.
> What I would like to do is to track the appropriate git branch that RH
> has for F7 kernels, and merge in the Libertas patches. Right now we
> are doing a pretty hackish thing ;-)
>
> Is there anything like this? I'm sure the RH kernel team is using _some_ dscm...
Actually, we don't. It really is just patches -- and we try to have as
few of those as possible.
We don't normally do development directly on the packaged kernel. The
real development happens in rawhide, which tracks upstream -- so we work
on the upstream kernel's git tree. Then we can just create patches and
add them to the RPM.
I believe there is a way to make quilt use RPM specfiles. I've never
really bothered looking it up, though -- others may know more, if you
ask in the right places (like fedora-kernel-list, which I've added to
Cc).
If I really have to hack on the RPM-built kernel directly for some
reason, I'll do something like this -- starting from the _very_
beginning just in case...
Obviously, start by checking the kernel in question out from Fedora CVS,
just as you would for any other package. I'll use anoncvs here, but
presumably any OLPC developer would have a proper account of their own
and be a real part of the Fedora community.
$ cd ~/working/fedora-pkgs
$ cvs -d :pserver:anonymous@xxxxxxxxxxxxxxxxxxxxx:/cvs/pkgs co common
$ cvs -d :pserver:anonymous@xxxxxxxxxxxxxxxxxxxxx:/cvs/pkgs co kernel/F-7
$ cd kernel/F-7
Then, I find it useful to disable a bunch of the builds I'm not
interested in, to speed things up and to make sure that the tree I'm
left with in my build directory is actually the one I want to frob with:
$ cat > GNUmakefile <<EOF
ppc: DIST_DEFINES += --with baseonly
ppc64: DIST_DEFINES += --with baseonly
i686: DIST_DEFINES += --with baseonly
include Makefile
EOF
Finally, you can build a kernel by running 'make i686'. Or just run
through and apply the patches by running 'make prep'.
If I want to play, I'll usually build a kernel package, and install it
on the unit under test. Then I can go and edit the source files in the
build tree in ~/working/fedora-pkgs/kernel/F-7/kernel-2.6.23/linux-2.6.23.i686
and I can rebuild both kernel and modules and replace them individually
for testing.
When I'm done, generating a patch is as simple as:
$ cd kernel-2.6.23
$ for a in `find linux-2.6.23 -name \*~` ; do diff -up ${a%%\~} $a ; done | tee linux-2.6-foo.patch
Then I can add that patch to the specfile, do a final build (make i686)
to test, and commit it.
If your editor doesn't leave backup files around or you've done it in so
many sessions that your backup files aren't the originals, you can run
'make prep' and then do a recursive diff between the clean
linux-2.6.23.noarch and your edited linux-2.6.23.i686 directories.
For libertas, we really ought to fix up the private ioctl crap so that
it's acceptable upstream, and then we could merge it into the Fedora
kernel. Hell, if you ask John nicely, maybe he'd let us do it anyway --
I've just been assuming he'd say 'no'. We try not to put things into
Fedora which aren't going upstream, in general.
--
dwmw2
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
