Rebasing patches for fedora kernels

[Josh Boyer]

On Tue, Oct 2, 2012 at 4:37 PM, Sandro Mani <manisandro at gmail.com> wrote:
> Hello,
>
> I was asked to try the drm-intel-next-queued for an intel drm bug (see [1]).
> While frequently rebuilding packages, I've seldom had to rebuild a kernel,
> especially with such a huge patch. In this case, I was lucky and the diff
> between the drm-intel-next-queued and the vanilla 3.6-rc7 (against which the
> branch is based) applied with some successful hunks to kernel-3.6.0-1.fc18.
> But it would still be great to know, what would be the proper way to
> approach such a case?

If you're comfortable with git, find the git commit in the kernel.org
tree that corresponds to the Fedora kernel you're using.  Then use git
am -i or something similar and work through the conflicts.  That will
get you a series of commits for your patches on top of the vanilla
kernel version, and in most cases it's enough to just apply to Fedora.

If you're still getting conflicts because of patches Fedora is carrying
or if you're not comfortable with git, use the SRPM (or local fedpkg
checkout) of the Fedora kernel you're using and run it through a prep
step.  Then go into the prepped sources and work through applying the
patch you're trying to use.

It's worth mentioning that we're always building Linus' latest tree in
either Branched or rawhide.  If you're willing to use bleeding edge to
test your issues/patches, it will likely be less work to get them to
apply than using a kernel from a stable Fedora release.  You will also
be closer to what upstream is currently working on, so maybe you'll get
better responses (no guarantees).

That's it.  There is no magic for rebasing patches.  We still suffer
through rebasing every release and the kernel developers just have an
elevated pain threshold.

josh