On Tue, Oct 2, 2012 at 4:37 PM, Sandro Mani <manisandro@xxxxxxxxx> 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
