Rebasing patches for fedora kernels

[Sandro Mani]

On 02.10.2012 22:55, Josh Boyer wrote:
> 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

Ok, many thanks.

Sandro