RE: making custom kernels easier to build

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Since this topic is here.  There is an error in Makefile when you do a make modules_install.  It attempts to delete a directory with a delete file command.  This occurs in two places.  If you are fixing fix this problem.  

-----Original Message-----
From: devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Josh Boyer
Sent: Monday, August 11, 2014 8:19 PM
To: Development discussions related to Fedora
Subject: Re: making custom kernels easier to build

On Mon, Aug 11, 2014 at 5:28 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx/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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux