Rebasing patches for fedora kernels

[Sandro Mani]

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?

Thanks,
Sandro

[1] https://bugs.freedesktop.org/show_bug.cgi?id=55112

[Josh Boyer]

On Tue, Oct 2, 2012 at 4:37 PM, Sandro Mani <manisandro(a)gmail.com&gt; 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

[Sandro Mani]

On 02.10.2012 22:55, Josh Boyer wrote:
>  On Tue, Oct 2, 2012 at 4:37 PM, Sandro Mani
> <manisandro(a)gmail.com&gt; 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

[Ian Pilcher]

On 10/02/2012 03:37 PM, Sandro Mani wrote:
>  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? 
Another option is to simply not bother with RPM for this:

1)  Grab the source from kernel.org (git clone)
2)  Copy the most recent kernel config-* file from /boot to .config in
    your kernel source tree.
3.) Apply patches
4)  Run 'make oldconfig' and hit enter until it completes.
5)  make -j<?> bzImage
6)  make -j<?> modules
7)  sudo make modules_install
8)  sudo make install

When the time comes to clean up, simply remove the unwanted files and
directories from /boot and /lib/modules.

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
"Sometimes there's nothing left to do but crash and burn, or die trying"
========================================================================