On Wed, Jul 15, 2015 at 12:40 AM, Richard Purdie <[email protected]> wrote: > On Thu, 2015-07-09 at 13:49 +0300, Tanu Kaskinen wrote: >> On Thu, 2015-07-09 at 11:11 +0300, Tanu Kaskinen wrote: >> > On Thu, 2015-07-09 at 08:58 +0100, Richard Purdie wrote: >> > > I included these patches on the autobuilder in master-next and saw: >> > > >> > > https://autobuilder.yoctoproject.org/main/builders/nightly-x86-lsb/builds/385/steps/BuildImages_1/logs/stdio >> > > >> >> The libspeexdsp-dev problem is more difficult, and I don't really know >> how to debug it further. The error message was: >> >> error: Can't install pulseaudio-dev-6.0-r0@core2_32: no package provides >> libspeexdsp-dev >> >> However, "bitbake speexdsp" seems to generate the libspeexdsp-dev >> package just fine (libspeexdsp-dev_1.2rc3-r0_core2-64.ipk appears in the >> deploy directory). > > This one is a little crazy to debug. What you need to do is build > something i586 (like qemux86), then build something core2_32 (like > genericx86), then "bitbake core-image-lsb core-image-lsb-sdk -c rootfs" > and hope the -lsb image builds before -lsb-sdk (I hacked runqueue to > ensure that). Then you see this error. > > genericx86 is seeing two copies of libspeexdsp-dev, one from the i586 > feed and one from the core2_32 feed and somehow they confuse it, perhaps > due to the RCONFLICTS or something. > > Obviously this isn't really a bug in the libspeexdsp recipe, its a bug > in smart combined with a second bug where genericx86 shouldn't be seeing > the i586 packages.
Not sure if it's related, but tune-core2.inc deliberately includes PACKAGE_EXTRA_ARCHS_tune-i586 when defining PACKAGE_EXTRA_ARCHS_tune-core2-32, which seems to be correct according to conf/machine/include/README: "PACKAGE_EXTRA_ARCHS_tune-<tune> - List all of the package architectures that are compatible with this specific tune. The package arch of this tune must be in the list." > I'll continue to try and narrow it down and produce a test case which is > more easily replicable. I'll not block your upgrades on this though, > this needs fixing elsewhere. > > Cheers, > > Richard > (going quietly insane with the number of AB 'random' failures) > > > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
