On 5 jul 2011, at 15:09, "Richard Purdie" <[email protected]> wrote:
> On Tue, 2011-07-05 at 14:54 +0200, Anders Darander wrote: >> * Phil Blundell Phil Blundell <[email protected]> [07/05/11 02:44 PM]: >>> On Tue, 2011-07-05 at 14:01 +0200, Anders Darander wrote: >>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass >>>> index 943252a..26ee416 100644 >>>> --- a/meta/classes/kernel.bbclass >>>> +++ b/meta/classes/kernel.bbclass >>>> @@ -149,7 +149,6 @@ kernel_do_install() { >>> >>> # >>> # We don't want to leave host-arch binaries in /sysroots, so >>> # we clean the scripts dir while leaving the generated config >>> >>>> # and include files. >>>> # >>>> oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean >>>> >>>> - make -C $kerneldir _mrproper_scripts >>>> >>>> find $kerneldir -path $kerneldir/scripts -prune -o -name "*.[csS]" >>>> -exec rm '{}' \; find $kerneldir/Documentation -name "*.txt" -exec rm >>>> '{}' \; >>> >>> Did you verify that this doesn't introduce any new QA warnings during >>> packaging? Presumably that line was originally added for a reason and >>> it seems a bit surprising that just deleting it without any replacement >>> is the right thing to do. >> >> No, I didn't really verify that. Do I need to run with any specific options >> enabled, or should it be enough to just bitbake my modules recipe? (I can't >> test for the moment, as the latest pull from oe-core forces a rebuild of gcc >> etc). >> >>> Also, if the scripts dir isn't being cleaned anymore, I guess the >>> preceding comment should be adjusted to match the new reality. >> >> That's true. >> >> I'll wait to see if someone else has any comments, or if I find some QA >> warnings before I produce a version 2. > > I'm cc'ing Darren as this is one of his favourite subjects :/. > > Summary is that this works well in some kernel versions and not in > others. We might have to start doing this conditionally based upon > kernel version I guess... Ah, well then it is worse than I thought. ( On the other hand, that would explain why no one has noticed the problem, until I tried using the wrong kernel version). Do we have any idea at what point the kernel breaks? I guess that might be a question for Darren. Cheers, Anders _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
