[OE-core] [PATCH 2/2] librsvg: Add missing pixbufcache dependencies

[Kyle Russell]

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 <bkylerussell at 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.burton at intel.com>
> wrote:
>
>>
>> On 11 October 2016 at 17:44, Kyle Russell <bkylerussell at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161110/14304ebc/attachment-0002.html>