On Mon, Feb 10, 2014 at 10:01:32AM +0000, Paul Eggleton wrote: > On Monday 10 February 2014 09:59:49 Laurentiu Palcu wrote: > > On Mon, Feb 10, 2014 at 07:37:12AM +0200, Laurentiu Palcu wrote: > > > On Sun, Feb 09, 2014 at 11:25:11PM +0000, Richard Purdie wrote: > > > > On Thu, 2014-02-06 at 13:39 +0000, Paul Eggleton wrote: > > > > > The original patch added in OE-Core commit > > > > > bdf07b1698d228dc7ff555199a269b1ff8ceca19 was supposed to ignore > > > > > conflicts, but it was unable to do so because it wasn't raising errors > > > > > in the right place. When the --attempt option is used (as is done in > > > > > complementary package installation for RPM), raise errors immediately > > > > > on conflicts, catch errors at the right point so that requested > > > > > packages > > > > > and their dependencies can be ignored, and print appropriate warnings > > > > > when doing so. > > > > > > > > > > Fixes [YOCTO #5313]. > > > > > > > > > > Signed-off-by: Paul Eggleton <[email protected]> > > > > > --- > > > > > > > > > > .../python/python-smartpm/smart-attempt.patch | 134 > > > > > +++++++++++++++++++-- 1 file changed, 121 insertions(+), 13 > > > > > deletions(-) > > > > > > > > Could you take a look at: > > > > > > > > http://autobuilder.yoctoproject.org/main/builders/nightly-multilib/build > > > > s/22 > > > > > > > > please? > > > > > > > > I've not 100% confirmed it was this change, it could be something else > > > > (e.g. Laurentiu's rootfs changes) but something in master-next broke > > > > multilib :/ > > > > > > I'll do a build locally with your master-next changes and see what > > > happens. At first sight, it looks like an issue with the rootfs > > > changes. However, 'smart channel --add' is not the command I was > > > expecting to fail... > > > > I pushed a fix on poky-contrib:lpalcu/rootfs_refactoring_ship_oecore > > > > lib/oe/package_manager.py: RpmPM: fix issue with multilib builds > > The lack of detail in the error message is a little bit concerning - we're > not > getting the output from smart in the log, so other than the return value it's > hard to determine what might have gone wrong. Is this something that could be > fixed as well? Sure, I'll prepare another patch that will print all the errors in the log.
laurentiu > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
