On Thu, Jul 23, 2015 at 3:56 AM, Richard Purdie <richard.pur...@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.ashfi...@gmail.com> wrote: >> > On Tue, Jul 21, 2015 at 11:21 AM, Bruce Ashfield >> > <bruce.ashfi...@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" -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
