This is from https://autobuilder.yocto.io/builders/nightly-x86-64-lsb/builds/87 , a master-next build but I don't think the master-next changes are related -- this could be intermittent: | make[3]: Entering directory '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/build/src/symbolic' | make[3]: Nothing to be done for 'install-exec-am'. | for size in ; do \ | for file in `cd ../../../adwaita-icon-theme-3.20/Adwaita/$size; find . -name "*.png"`; do \ | context="`dirname $file`"; \ | /bin/mkdir -p /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/image/usr/share/icons/Adwaita/$size/$context; \ | /bin/bash /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/adwaita-icon-theme-3.20/install-sh -c -m 644 ../../../adwaita-icon-theme-3.20/Adwaita/$size/$file /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/image/usr/share/icons/Adwaita/$size/$file; \ | done; \ | done | for file in `cd ../../../adwaita-icon-theme-3.20/Adwaita/scalable; find . -name "*.svg"`; do \ | context="`dirname $file`"; \ | /bin/mkdir -p /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/image/usr/share/icons/Adwaita/scalable/$context; \ | /bin/bash /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/adwaita-icon-theme-3.20/install-sh -c -m 644 ../../../adwaita-icon-theme-3.20/Adwaita/scalable/$file /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/image/usr/share/icons/Adwaita/scalable/$file; \ | for size in 16x16 24x24 32x32 48x48 64x64 96x96; do \ | /bin/mkdir -p /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/image/usr/share/icons/Adwaita/$size/$context; \ | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/sysroots/x86_64-linux/usr/bin/gtk-encode-symbolic-svg ../../../adwaita-icon-theme-3.20/Adwaita/scalable/$file $size -o /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64-lsb/build/build/tmp/work/all-poky-linux/adwaita-icon-theme/3.20-r0/image/usr/share/icons/Adwaita/$size/$context; \ | done \ | done | Can't load file: Unrecognized image file format | Can't load file: Unrecognized image file format | Can't load file: Unrecognized image file format | Can't load file: Unrecognized image file format (...this continues for a while) This failure case happens when the native sysroots /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache does not contain the entry for libpixbufloader-svg.so when adwaita do_install runs. I've looked at the recipes and they seem correct to me: * adwaita depends on gtk-icon-utils-native (through gtk-icon-cache.bbclass) * gtk-icon-utils-native depends on librsvg-native (which provides the svg loader) * librsvg inherits pixbufcache I believe the loaders.cache file is generated through a postinst-intercept (update_pixbuf_cache), I wonder if it is possible that it hasn't run by the time adwaita installs?
Looking at the native case, I guess the following bit of pixbufcache class is relevant. Maybe it fails to run when librsvg comes from sstate or something? gdkpixbuf_complete() { GDK_PIXBUF_FATAL_LOADER=1 ${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders --update-cache || exit 1 } # # Add an sstate postinst hook to update the cache for native packages. # An error exit during populate_sysroot_setscene allows bitbake to # try to recover by re-building the package. # DEPENDS_append_class-native = " gdk-pixbuf-native" SSTATEPOSTINSTFUNCS_append_class-native = " pixbufcache_sstate_postinst" # See base.bbclass for the other half of this pixbufcache_sstate_postinst() { if [ "${BB_CURRENTTASK}" = "populate_sysroot" ]; then ${gdkpixbuf_complete} elif [ "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then if [ -x ${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders ]; then echo "${gdkpixbuf_complete}" >> ${STAGING_DIR}/sstatecompletions fi fi }
(In reply to comment #1) > Looking at the native case, I guess the following bit of pixbufcache class > is relevant. Maybe it fails to run when librsvg comes from sstate or > something? sstatecompletions seem to work just fine: even if rsvg comes from sstate and the cache has been modified in between, the loader cache gets updated just fine before adwaita installs.
Ah! So, this happens: librsvg-native restored from sstate gdk-pixbuf-native built from scratch gdk-pixbuf-native's sstate preinst deletes all existing loaders gdk-pixbuf-native's sstate postinst regenerates the loader cache Obviously step 3 seemed like a good idea at the time...
Forgot to say, this is the reproducer: $ wipe-sysroot ; bitbake gdk-pixbuf-native -c cleansstate ; bitbake adwaita-icon-theme -C unpack
All of this complication just disappeared with recipe specific sysroots (oe core 809746f56df4b91af014bf6a3f28997d6698ac78), closing (and cheering).