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

[Bruce Ashfield]

On Thu, Jul 23, 2015 at 10:14 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Thu, 2015-07-23 at 09:10 -0400, Bruce Ashfield wrote:
>> 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.
>
> That could explain d). I believe c) is from the ongoing selftest issues
> we're having and I we've work in progress for that. That leaves a) and
> b) to look into and fix.
>
>> 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.
>
> a) should be straightfoward to fix, its just updating the message
> whitelists (again).

I'm building a fresh qemux86-64 now, I'm going to see if the warnings
are something
I should fix, versus the whitelist. I should know tomorrow on this one.

>
> b) I'm less sure about. Are there any race fixes in mainline for perf?
> Hard to believe others don't see that one.

I'm searching as well. I'll share any findings ASAP.

Bruce

>
> Cheers,
>
> Richard
>



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