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

[Richard Purdie]

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

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