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

[Richard Purdie]

On Thu, 2015-07-23 at 11:01 -0400, Bruce Ashfield wrote:
> 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:
> >> > 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.

I believe we have everything except b), the last build was much greener.
For b), what strikes me as odd:

https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/409/steps/BuildImages/logs/stdio

|   CC       /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/util/thread-stack.o
|   CC       /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/util/symbol-elf.o
|   CC       /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/util/probe-event.o
|   CC       /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/qemux86-pokymllib32-linux/lib32-perf/1.0-r9/perf-1.0/builtin-annotate.o
|   CC       /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/util/perf_regs.o
|   MKDIR    /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work//lib32-perf/1.0-r9/perf-1.0/util/scripting-engines/
|   CC       /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/qemux86-pokymllib32-linux/lib32-perf/1.0-r9/perf-1.0/util/scripting-engines/trace-event-perl.o
|   CC       /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/util/zlib.o

Why is it building in two different directories (qemux86-poky-linux and
qemux86-pokymllib32-linux) ?

I'd bet that would explain the errors and that it would only show up in
a multilib case (which is the default on the AB for this part of the
build).

Hopefully this gets us closer to figuring out what its doing...

Cheers,

Richard