Can't say I fully understand this yet but filing a bug as one doesn't seem to exist yet. Richard wrote an explanation in email: > With the recent fixes to gdk-pixbuf loaders, we're now seeing a 100% > reproducible problem with the second multilib test on the autobuilder. > The reproducer is: > > require conf/multilib.conf > MULTILIBS = "multilib:lib32" > DEFAULTTUNE_virtclass-multilib-lib32 = "x86" > RPM_PREFER_ELF_ARCH = "1" > IMAGE_INSTALL_append = " lib32-connman-gnome" > MACHINE = "qemux86-64" > > bitbake core-image-sato > > then watch as you see errors trying to run connman-applet due to no > pixbuf loaders. > > The problem is that it installs lib32-gdk-pixbuf and lib32-libgtk+ > however it doesn't install any lib32 gdk-pixbuf loaders. > > Since lib32-libgtk+ RRECOMMENDS several, it probably should, however > this is crazy rpm mutilib so it assumes the non lib32 variant can > actually handle its needs when it clearly can't. ... > FWIW, I did try: > > IMAGE_INSTALL_append = " lib32-connman-gnome lib32-gdk-pixbuf-loader-png lib32-gdk-pixbuf-loader-jpeg" > > however whilst this fixed the connman-applet start errors, the icons on > the desktop disappeared, I worry that the icon cache format is multilib > specific and you can't run two different sized libgtk on the same icon > directory. So there might be two problems here: 1. We need to be able to describe the dependencies correctly -- Robert, you had a possible fix for this, correct? 2. We may need separate loader caches for different lib-versions.
> 2. We may need separate loader caches for different lib-versions. Actually, this seems to work just fine: if I make sure the pixbuf loaders are installed for both lib versions, sato desktop finds the 64 bit ones and the connman applet finds the 32 bit ones. There is a follow-up bug though: the applet mis-renders all text and says Pango-CRITICAL **: no modules found. No builtin or dynamically loaded module were found. PangoFc will not work correctly It seems Pango has the same problem: the 32 bit modules are not installed.
Lets take a step back here. Why are we installing the 32-bit connman and not using the 64-bit? Is this an issue where we are building a very large multilib system for testing purposes, or is this a real world situation like glibc-std-sato or something? I don't believe we have seen this problem very often because multilib is usually used for select implementations of components a user wants to make available for the alternative library format vs building everything for the multilib. (That is not to say there isn't a bug here, I'm sure there is...) I'm just worried we've moved to an artificial test case that is not likely to affect someone in a more real-world situation.
It's for sanity testing: can we build a 64-bit image with a select component being 32-bit. The complication that said component (connman-gnome) uses GTK+, gdk-pixbuf, and Pango, all of which have runtime loadable modules, sure is making this more of a test than you'd expect but it isn't unusual in my opinion.
*** Bug 8580 has been marked as a duplicate of this bug. ***
For those following at home, Roberts python-smartpm patch and related discussion: http://lists.openembedded.org/pipermail/openembedded-core/2015-October/112050.html (In reply to comment #2) > Lets take a step back here. Why are we installing the 32-bit connman and > not using the 64-bit? Is this an issue where we are building a very large > multilib system for testing purposes, or is this a real world situation like > glibc-std-sato or something? I think the choice here is not unreasonable: connman-applet is a pretty basic GUI application (it shouldn't actually install 32bit connman itself since the API is D-Bus). That said, maybe this is too ambitious for 2.0? We could change the test case to something that does not use dynamically loaded modules (in other words, not a GTK+ application), and if multilib is in the releases notes mention that the support does not cover that case yet.
(In reply to comment #5) > That said, maybe this is too ambitious for 2.0? We could change the test > case to something that does not use dynamically loaded modules (in other > words, not a GTK+ application), and if multilib is in the releases notes > mention that the support does not cover that case yet. As a concrete suggestion: IMAGE_INSTALL_append = " lib32-connman-client" This is the command line connman client instead of the GUI client. It results in installing these 32 bit packages and seems to work fine: lib32-connman-client x86 1.30 lib32-glibc-locale-en-gb x86 2.22 lib32-libc6 x86 2.22 lib32-libdbus-1-3 x86 1.8.20 lib32-libffi6 x86 3.2.1 lib32-libglib-2.0-0 x86 2.44.1 lib32-libglib-2.0-locale-en-gb x86 2.44.1 lib32-libreadline6 x86 6.3 lib32-libtinfo5 x86 5.9 lib32-libz1 x86 1.2.8 I haven't really looked if this brings any value on top of the other multilib tests as it is.
Oh, one more workaround option for 2.0.x: Add both 32 and 64 bit versions of module packages to IMAGE_INSTALL_append by hand: lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png lib32-gdk-pixbuf-loader-png pango-module-basic-fc lib32-pango-module-basic-fc This makes connman-applet work fine as a 32 bit app.
Yes, that last workaround is the best for now. Can you send a patch for the autobuilder?
(In reply to comment #8) > Yes, that last workaround is the best for now. Can you send a patch for the > autobuilder? Done, bug 8624 is for the workaround.
I think I might not be the right assignee anymore? Is roberts python-smartpm work still relevant?
Move it to 2.3 M2, we may not use smart any more in 2.3.
Smart it gone.