making custom kernels easier to build

[Josh Boyer]

On Mon, Aug 11, 2014 at 5:28 PM, Chris Murphy <lists at colorremedies.com> wrote:
> Since it came up at Flock: if it's possible to incorporate this recent experiencing testing Btrfs patches it'd be nice.

Please send requests for the kernel to the kernel list in the future.
We don't read devel as frequently.

> Two patches listed here, one is based on Btrfs integration branch, the other based on 3.16.0. I didn't realize the original patch was based on integration branch, which is apparently why it kept failing to apply with rpmbuild (and hence patch) on kernel-3.16.0-1.fc21.src.rpm. I'm told in this email that git am would have sorted this out for me. (?)
>
> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg36299.html
>
> Request 1: if there's a more tolerant patch applying method with git that could be incorporated, even if it's just a step that converts the patch so that rpmbuild/patch will eat it, that would be nice. But if it requires a local git clone of upstream's dev branch, then ignore this part because I'm not going to do that. I'd sooner ask for a patch that applies onto something I'm actually going to build.

I'll look this over later.  I'm far too jet lagged to do it now.

> Request 2:  patches to just get picked up by dropping them somewhere, like rpmbuild/SOURCES/*.patch always get picked up and applied, rather than requiring two manually entered entries in kernel.spec per patch.

Patches require ordering.  At a minimum you're going to have to list
them in the order they should apply.  The first line in the spec is to
enumerate them (e.g. Patch25100).  We might be able to do something
about the application, but if we do it's going to make things more
obfuscated, either by keeping the patches in a series file elsewhere
or using something else.  We default to explicit and dumb so you can
see exactly what is applied where.

josh