Re: Kernel config fragments are not applied

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 14-05-01 02:32 AM, Neuer User wrote:
> Hi Bruce
>
> Here is the error messega, I get after a "bitbake linux-cubox-i -c
> cleansstate; bitbake linux-cubox-i" using the recipe you posted:

Aha. This is what I was seeing as well, and there's some issues and 
assumptions
that are built into those kernel recipes that are causing the yocto
tools to attempt a patch (which is already on the branch) and hence
the failure (the recipes should really be tweaked .. but I digress).

I'm prepping a small patch that will have this particular recipe and
use case working out of the box.

Bruce

>
> ERROR: Function failed: do_patch (log file is located at
> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660)
> ERROR: Logfile of failure stored in:
> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660
> Log data follows:
> | DEBUG: Executing shell function do_patch
> | WARNING: no meta data branch found ...
> | ls: cannot access .meta*: No such file or directory
> | Already on 'imx_3.0.35_4.1.0'
> | [INFO] validating against known patches  (cubox-i-standard-meta)
> error: patch failed: arch/arm/lib/memset.S:19#############] (/)(110 %)
> | error: arch/arm/lib/memset.S: patch does not apply
> | ERROR. could not update git tree
> | ERROR. Could not apply patches for cubox-i.
> |        Patch failures can be resolved in the devshell (bitbake -c
> devshell linux-cubox-i)
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_patch (log file is located at
> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660)
> ERROR: Task 3
> (/home/ubuntu/yocto/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-cubox-i_3.0.35.bb,
> do_patch) failed with exit code '1'
>
> Hope, it helps!
>
> Michael
>
> Am 01.05.2014 06:29, schrieb Bruce Ashfield:
>> I'm glad that I looked again, I though there was an error without my
>> clean up series .. but what I was seeing was a legitimate double
>> application of the patch.
>>
>> What error where you seeing when you tried a bbappend like so:
>>ll ticking.. ;-)

If anyone has more suggestions or info, please let me know! I’ll keep 
you posted.

Update: Just reached 4 days of uptime!

Update 2: Today it’s 4 month’s after I wrote this blog. The machine is 
still up & running and has reached 106 days of uptime!

Update 3: After 7 months (222 days of uptime) I finally retired the 
machine since we migrated to our CloudStack cloud. The fix described ab
>> ------------
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>>
>> SRC_URI += "file://videoin.cfg"
>> --------------
>>
>> Your error message will set me straight .. and tell me if it is just
>> the late night hacking fooling my eyes .. or not!
>>
>>
>> Bruce
>
>