On Tue, Jan 5, 2016 at 3:04 PM, Aníbal Limón
<anibal.li...@linux.intel.com> wrote:
> 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?
Thanks, will send out V3 shortly.
-Matt
>
> 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.li...@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.
Great, that will help.
>
>
>>
>> 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(-)
>>>>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
