Hi,

I fixed the problem and add a 4 patch and sign-off your first tree
patches also i tested your changes building images in machines: x86-64
(sato, minimal, multilib), x86(minimal), arm(minimal) and mips(minimal).
Details below...

Can you send the 4 patches again?

	alimon

On 01/05/2016 11:00 AM, Matt Madison wrote:
> On Mon, Jan 4, 2016 at 12:56 PM, Aníbal Limón
> <anibal.limon@linux.intel.com> wrote:
>> Hi Matt,
>>
>> Sorry for the delay in the response, i'll test again your patches with
>> the new one and the same error appears when build
>> core-image-full-cmdline or core-image-sato.
> 
> No problem, I figured things would be slow around the holidays.
> 
> I think the problem with this specific configuration has to do with
> trying to add lib32-connman to an image build that already had a
> dependency on connman (from packagegroup-core-x11-sato-base, for
> example).  I modified the DpkgPM class in package-manager.py to run an
> 'apt-get -f install' to fix the dependencies that APT thinks are
> broken if the initial installation attempt fails.  That appears to
> work around the issue adequately, and I see APT reporting


I figured out the issue is related to addition of log check feature into
rootfs image (that's good) but i didn't take into account DpkgPM because
it assumes that can be missing dependencies and executes apt-get -f
install, see the final patch attached.

I'll make the changes to the AB multilib buildset for add package_deb to
the CI cycle.


> 
>    ignore old unsatisfied important dependency on connman-conf:amd64
> 
> which is there because it cannot install both connman-conf and
> lib32-connman-conf, since PACKAGE_ARCH is ${MACHINE_ARCH} in the
> connman-conf recipe.
> 
> For my particular application, I didn't have any conflicts between
> 32-bit and 64-bit packages, so the patches I submitted were enough.
> 
> I'm not sure what the right answer for this should be; hacking in the
> additional 'apt-get -f install' works around the problem here, but I'm
> not sure it solves the general problem correctly.   APT implements the
> Debian policy, and it's complicated - to do it "right" , we'd have to
> ensure that all of the packages get tagged with the right combination
> of Architecture and Multi-Arch headers, and I think we'd have to
> change how we write dependencies in the control files to use the
> '<pkg>:any' notation when that's appropriate.  I'm not even sure if
> that could be computed automatically; it could require a significant
> amount of manual review.

I agree, there are work here to do to make consistent with debian way
but for now is a good start.

> 
> Thanks,
> -Matt
> 
>>
>>         MACHINE ??= "qemux86-64"
>>
>>         IMAGE_INSTALL_append = " lib32-connman"
>>         require conf/multilib.conf
>>         MULTILIBS = "multilib:lib32"
>>         DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
>>
>>
>> I'm reviewing if this an error in the meta data (because
>> core-image-minimal builds) or in the class.
>>
>> Best regards,
>>         alimon
>>
>> On 12/18/2015 08:34 AM, Matt Madison wrote:
>>> This adds a third patch that fixes the problem where APT couldn't
>>> resolve dependencies between when two packages of different architectures
>>> both depended on an allarch package.
>>>
>>> Matt Madison (3):
>>>   package_deb.bbclass, cross-canadian.bbclass: DPKG_ARCH mapping
>>>     function
>>>   package_manager.py: fixes for multilib deb packaging builds
>>>   package_deb.bbclass: add 'Multi-Arch: foreign' tag to allarch packages
>>>
>>>  meta/classes/cross-canadian.bbclass |  2 +-
>>>  meta/classes/package_deb.bbclass    | 37 +++++++++++++++++++++++++++----------
>>>  meta/lib/oe/package_manager.py      | 17 +++++++++++------
>>>  3 files changed, 39 insertions(+), 17 deletions(-)
>>>