Re: [OE-core] [PATCH 2/2] librsvg: Add missing pixbufcache dependencies
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 Russellwrote: > 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//? 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 > wrote: > >> >> On 11 October 2016 at 17:44, Kyle Russell 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
Re: [OE-core] [PATCH 2/2] librsvg: Add missing pixbufcache dependencies
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//? If I can get it, how would you prefer me send that to you? On Thu, Oct 13, 2016 at 9:09 AM, Burton, Rosswrote: > > On 11 October 2016 at 17:44, Kyle Russell 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
Re: [OE-core] [PATCH 2/2] librsvg: Add missing pixbufcache dependencies
On 11 October 2016 at 17:44, Kyle Russellwrote: > 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
Re: [OE-core] [PATCH 2/2] librsvg: Add missing pixbufcache dependencies
No, I haven't been able to reproduce it on demand, so there appears to be some race scenario. I have only seen the failure about libXdmcp a couple of times. It does look like libpixbufloader-svg.so depends on libxcb.so as well, so if libxcb-native would be more appropriate here I can use that instead (or in addition to libxdmcp?). 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. If PIXBUFCACHE_SYSROOT_DEPS is supposed to be satisfied another way, I'll be glad to reevaluate. On Tue, Oct 11, 2016 at 10:57 AM, Burton, Rosswrote: > > On 11 October 2016 at 15:17, Kyle Russell wrote: > >> g_module_open() failed for libpixbufloader-svg.so: libXdmcp.so.6: >> cannot open shared object file: No such file or directory >> > > Can you replicate this failure on demand? I can't see why eg xdmcp needs > to be in this list but say libxcb doesn't, which is presumably there that > linkage is coming from. > > One solution for xdmcp would be to remove it entirely... > > Ross > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] librsvg: Add missing pixbufcache dependencies
On 11 October 2016 at 15:17, Kyle Russellwrote: > g_module_open() failed for libpixbufloader-svg.so: libXdmcp.so.6: > cannot open shared object file: No such file or directory > Can you replicate this failure on demand? I can't see why eg xdmcp needs to be in this list but say libxcb doesn't, which is presumably there that linkage is coming from. One solution for xdmcp would be to remove it entirely... Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core