[OE-core] [PATCH 0/3] speex, speexdsp: 1.2rc1 -> 1.2rc2/1.2rc3

[Andre McCurdy]

On Wed, Jul 15, 2015 at 12:40 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> 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 at 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
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core