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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2015-07-15 at 01:25 -0700, Andre McCurdy wrote:
> On Wed, Jul 15, 2015 at 12:40 AM, Richard Purdie
> <richard.purdie@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@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."

As we define things today, its certainly correct. I do continue to
wonder if there shouldn't be two different fields, the list of arches to
use at build time and the complete list of compatible arches which would
be separate.

How we'd go about such an invasive change is the real issue.

Cheers,

Richard