We were able to capture a full cooker log with the libpixbufloader-jpeg failure, and I only see the populate_lic_setscene tasks being run for jpeg-native. We were running jethro with the two patches I originally provided in this thread.
Is there a specific task dependency chain you'd like for me to look for in the log? On Fri, Oct 14, 2016 at 5:55 AM, Kyle Russell <bkyleruss...@gmail.com> wrote: > Actually, we just hit another failure mode running with these two > patches. Again, we're currently running on the jethro branch. > > g_module_open() failed for /poky/build/tmp/sysroots/x86_ > 64-linux/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so: > libjpeg.so.9: cannot open shared object file: No such file or directory > > Looking at the build output itself, I was reminded of another signature of > this failure. It seems like the do_populate_lice_setscene runs for the > package that should have provided libjpeg.so.9, but no > do_populate_sysroot_setscene. I remember also seeing this on the other > failures I mentioned. > > $ cat build-output.log | grep jpeg-native > NOTE: recipe jpeg-native-9a-r0: task do_populate_lic_setscene: Started > NOTE: recipe jpeg-native-9a-r0: task do_populate_lic_setscene: Succeeded > > I can try to get the full cooker log from the build slave if you want. Do > you mean the file from tmp/log/cooker/<machine>/? If I can get it, how > would you prefer me send that to you? > > On Thu, Oct 13, 2016 at 9:09 AM, Burton, Ross <ross.bur...@intel.com> > wrote: > >> >> On 11 October 2016 at 17:44, Kyle Russell <bkyleruss...@gmail.com> wrote: >> >>> I suspect this list may still not be entirely complete, because ldd >>> shows several dependencies for libpixbufloader-svg.so. However, I'm not >>> really that familiar with all the dependencies going on here; we are >>> definitely seeing sporadic failures for various native libraries during the >>> pixbufcache postinst task though. Best I could tell, it looked like the >>> PIXBUFCACHE_SYSROOT_DEPS functionality was accidentally removed from the >>> pixbufcache.bbclass a while back (hence, my first patch). Adding that hunk >>> back in has seemed to help most of the failures, but we still see lingering >>> failures for pixman and libXdmcp on occasion. >> >> >> This bit of code is particularly tangled, so I'm hoping I can remember >> the details. The AB just hit a related problem earlier in the week so I'm >> trying to remember how all this ties together. >> >> The SYSROOT_DEPS bit wasn't removed accidentally because the way the >> query-loaders script is executed has changed. It used to be ran via >> SSTATEPOSTINSTFUNCS so would execute the moment that gdk-pixbuf-native or >> librsvg-native was unpacked. As sstate installation is top-down instead of >> bottom-up this would generally mean that librsvg-native would be installed >> before even gdk-pixbuf-native was installed, and typically before stuff >> like libpng-native or the rest of the stack. >> >> This was changed so that the SSTATEPOSTINSTFUNC simply writes a >> sstate-completion script that is executed once all of sstate has been >> unpacked, so ordering isn't a problem. The logic to add explicit >> dependencies isn't required anymore. >> >> Of course native dependencies are not as neat as target dependencies >> which is something I'd really like to see fixed, but in general I can't >> understand why this happens for you: if gdk-pixbuf-native can be extracted >> from sstate then all of its dependencies must have been too, and they >> include recipes such as libxdmcp-native. If the dependencies need a >> rebuild then gdk-pixbuf should need a rebuild too... >> >> A full cooker log with the bug would be appreciated, but I know that's >> unlikely to happen! >> >> Ross >> > >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
