[OE-core] [PATCH 4/9] linux-yocto/3.14: cleanups and gcc5 ARM build fixes

[Bruce Ashfield]

On Sun, Aug 30, 2015 at 11:49 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Sun, 2015-08-30 at 10:34 -0400, Bruce Ashfield wrote:
>> On Sun, Aug 30, 2015 at 10:30 AM, Bruce Ashfield
>> <bruce.ashfield at gmail.com> wrote:
>> > On Sun, Aug 30, 2015 at 9:57 AM, Richard Purdie
>> > <richard.purdie at linuxfoundation.org> wrote:
>> >> On Wed, 2015-08-26 at 22:31 -0400, Bruce Ashfield wrote:
>> >>> Updating the 3.14 SRCREVs to match the latest kernel meta data updates
>> >>> and also to merge four patches Richard Purdie located that fix the
>> >>> gcc 5.x ARM build (we still have boot issues, but building is the
>> >>> first step).
>> >>>
>> >>> Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com>
>> >>> ---
>> >>>  meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb   |  6 +++---
>> >>>  meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |  4 ++--
>> >>>  meta/recipes-kernel/linux/linux-yocto_3.14.bb      | 18 +++++++++---------
>> >>>  3 files changed, 14 insertions(+), 14 deletions(-)
>> >>>
>> >>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
>> >>> index 0bd94f0c600d..d59f06b81c04 100644
>> >>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
>> >>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
>> >>> @@ -3,9 +3,9 @@ KBRANCH_qemuppc ?= "standard/preempt-rt/qemuppc"
>> >>>
>> >>>  require recipes-kernel/linux/linux-yocto.inc
>> >>>
>> >>> -SRCREV_machine ?= "863ba0912f559ba9d64ab94bf04f0226fdf0cb49"
>> >>> -SRCREV_machine_qemuppc ?= "9d464d6696a0fc755c65a2cf75ad7a4656ac6e1e"
>> >>> -SRCREV_meta ?= "b55cfc0308bf7158843db4b8f69f866487a0919e"
>> >>> +SRCREV_machine ?= "302ca233332fd364ecd028a0cf21b4cdc045e056"
>> >>> +SRCREV_machine_qemuppc ?= "e4847afbb42583fa05e6a94c8d0c8f8e37ed5622"
>> >>> +SRCREV_meta ?= "3a09b38a9f5015c56d99d17aa7c2f200c566249b"
>> >>>
>> >>
>> >> I can't find e4847afbb42583fa05e6a94c8d0c8f8e37ed5622 on the
>> >> standard/qemuppc branch? Did you miss a push?
>> >>
>> >> I merged this to master not realising this issue and the autobuilder is
>> >> now unhappy so need to get this resolved one way or another ASAP :/.
>> >
>> > I'm out until tomorrow morning. So a revert is the only way to fix it quickly.
>> >
>> > As I mentioned in my pull request, I had to update all my scripts that do the
>> > SRCREV updates for the meta branch split out .. so I warned that something
>> > unexpected may have happened (with three kernel versions, and 3 types of
>> > kernels across 8 boards ..).
>>
>> That being said, I did sneak in and check:
>>
>> > git push origin standard/preempt-rt/qemuppc
>> Everything up-to-date
>> > git branch --contains e4847afbb42583fa05e6a94c8d0c8f8e37ed5622
>>   standard/preempt-rt/qemuppc
>>
>> That's a merge commit on the top of the branch.
>>
>> If I get back early enough tonight, I'll look more.
>
> If I have to guess, your scripts have taken the qemuppc -rt revision and
> applied it to the qemuppc standard kernel (the non -rt version).
>

The revs still look right to me.

Do you have a link to the autobuilder failure for this one ?

You said that e4847afbb42583fa05e6a94c8d0c8f8e37ed5622 wasn't being found
for qemuppc on standard/base, in the -rt recipe (at least that's what the first
email in the thread seems to indicate).

But KBRANCH_qemuppc ?= "standard/preempt-rt/qemuppc" is set, which matches
the SRCREV that I pushed.

So if you point me in the direction of a log, I'll figure out what
part I'm missing.


> I'll try changing it to the standard/qemuppc revision instead (patch
> pushed for that).
>
> We also have an issue with 3.14 qemumips failing in do_patch:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/464/steps/BuildImages/logs/stdio
>

I'll have a look at this on in the morning, I've launched a build.

Bruce

> I've not looked into that one.
>
> Cheers,
>
> Richard
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"