[OE-core] [PATCH 0/4] linux-yocto: build changes, 4.1 and libc-headers

[Bruce Ashfield]

On Thu, Jul 23, 2015 at 3:56 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2015-07-22 at 15:48 -0400, Bruce Ashfield wrote:
>> On Wed, Jul 22, 2015 at 10:03 AM, Bruce Ashfield
>> <bruce.ashfield at gmail.com> wrote:
>> > On Tue, Jul 21, 2015 at 11:21 AM, Bruce Ashfield
>> > <bruce.ashfield at windriver.com> wrote:
>> >> Hi all,
>> >>
>> >> This series absolutely needs some more testing and runs through the
>> >> autobuilder, but I've done pretty much all I can do with it here.
>> >>
>> >> I have more changes to the build process that will follow this, but
>> >> these changes need to show that they are stable, so here's the first
>> >> blast.
>> >>
>> >> With this series:
>> >>
>> >>   - I create the 4.1, and 4.1-rt linux-yocto content. This will be
>> >>     the new LTSI kernel. Deletion of 3.14 and 3.19 will follow once
>> >>     all machines have been moved forward.
>> >>
>> >>   - libc-headers updated to match the 4.1 kernel version.
>> >>
>> >> And the one that could cause some issues/compatibility issues is the
>> >> split of the kernel configuration data from the kernel tree itself.
>> >>
>> >> From the commit log:
>> >>
>> >>   The linux-yocto tree has always been a combined set of kernel changes
>> >>   and configuration (meta) data carried in a single tree. While this
>> >>   format is effective at keeping kernel configuration and source
>> >>   modifications synchronized, it isn't always obvious to developers on
>> >>   how to manipulate the meta data versus the source.
>> >>
>> >>   With this change, we remove the meta data processing from the
>> >>   kernel-yocto class and use the external meta-data repository that
>> >>   has always been used to seed the linux-yocto meta branch.
>> >>
>> >>   After this change, linux-yocto can no longer process combined trees,
>> >>   and is simplified as a result.
>> >>
>> >> I'm interested to find out if we get any breakages or severe compability
>> >> issues with the change. I don't want to support both variants of the
>> >> meta data (in and out of tree), since the goal is to reduce complexity
>> >> in the code. Once this change lands, I'll further streamline things.
>> >>
>> >> I've built core-image-kernel-dev and boot tested the qemu* machines.
>> >> qemuppc continues to show a boot failure with systemd, but we have a
>> >> bugzilla to track that.
>> >>
>> >> I'm now doing graphical testing, but wanted to get this out and soaking
>> >> for other images types while I wait for builds to churn.
>> >
>> > As a follow up, my qemuarm boots that worked on Friday, are now hanging.
>> > I'm bisecting to find out what happened.
>>
>> And a final follow up.
>>
>> qemuarm (console and graphics) works fine .. but only if you use gcc
>> 4.9.x, gcc 5.1
>> is doing something evil.
>>
>> We've looked into this in the past, so it is a known issue, but I need
>> to handle these
>> separately.
>
> We got the results of a run of those changes through the autobuilder
> without the noise of other failures. The error reporting system shows:
>
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=d687cdfd04f3d97923c93239ea902bb38e2ea336
>
> and I believe we have the following issues:
>
> a) qemux86/qemux86-64 are throwing warnings about errors in logs
> b) perf has some weird make race
> c) the qemuarm build looks like qemu either segfaulted or was killed
> d) we're occasionally seeing 3.19 and 3.14 fetch failures:
> https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
> https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio

I explained to Ross that dependent layers need to be updated if they set
their own SRCREV_meta, since the repository is completely different. I
sent a patch for meta-intel to deal with it. Obviously, I only built with the
core BSPs during testing.

>

I'll definitely need help on these, since I wasn't seeing any of these issues
during my testing. Otherwise, this won't be done until September (vacation
and other issues to deal with).

But I'll see what I can do.

I unfortunately can't merge anything but critical kernel patches until
these go in as well
since the meta branch is gone in the new scripts, which means SRCREV_meta is
a constant conflict.

Cheers,

Bruce

> To try and promote more sstate cache reuse whilst we sort the remaining
> issues, I merged the linux-libc-header part, we need to get the above
> fixed before the other pieces can merge.
>
> Cheers,
>
> Richard
>
>
>



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