[OE-core] qemu rebuild contamination

[Richard Purdie]

On Sun, 2019-10-27 at 07:56 -0700, akuster808 wrote:
> 
> On 10/27/19 2:57 AM, Richard Purdie wrote:
> > I've been trying to figure out why we get a weird build failure
> > with
> > hash equivalence enabled. Armin has also been searching for an odd
> > issue with warrior and the qemu tests. I may have a lead.
> > 
> > If you build a standard qemu:
> > 
> > "bitbake qemu-system-native"
> > 
> > and save off the resulting qemu-system-XXX binaries, then add:
> > 
> > PACKAGECONFIG_append_pn-qemu-system-native = " gtk+"
> > PACKAGECONFIG_append_pn-qemu-system-native = " virglrenderer"
> > PACKAGECONFIG_append_pn-qemu-system-native = " glx"
> > 
> > to local.conf, then:
> > 
> > "bitbake qemu-system-native"
> > 
> > it rebuilds as expected, save off the qemu-system-XXX binaries,
> > 
> > then remove the local.conf entries and:
> > 
> > "bitbake qemu-system-native -c configure -f"
> > "bitbake qemu-system-native"
> > 
> > then save off the resulting qemu-system-XXX binaries, you'll find
> > that
> > whilst these first and last sets should match, they don't. Its
> > obvious
> > with "ldd qemu-system-x86_64" that the linked libraries persist
> > from
> > the second to third set when they should not.
> > 
> > The reason is that when configuration changes, autotools.bbclass
> > will
> > wipe out ${B} however qemu doesn't use the autotools class and
> > hence B
> > is not cleaned for changes in configuration.
> > 
> > We could abstract the pieces of autotools.bbclass which do this
> > into a
> > separate class, or, easier, have qemu's do_configure wipe ${B}.
> > 
> > Armin: This may be the issue you're searching for with warrior?
> You mean the virgl failure? I did set the native packconfig to make
> the
> selftest and that had no affect. In facted, Zeus has the same
> mismatch.
> Alex's patches I believe align them to match.
> 
> The virgl failure is fixed using an updated version of libdrm. I
> thought I sent an email about that.

I'm travelling so a little out of sync, I see the email now. I think I
managed to hit the rebuild issue when I tried to debug it which is why
it seemed related to me.

For the libdrm issue in warrior, we could:

a) Break policy and upgrade libdrm
b) Just upgrade libdrm-native and nativesdk
c) Mark f30 as broken in warrior for qemugl and not expected to work.

Any thougts?

I'm tempted by c).

Cheers,

Richard