Can't use gdk-pixbuf from ubuntu-app-platform

[jhenstridge]

When putting together a snap that relied on the gdk-pixbuf libraries from the ubuntu-app-platform snap, I got the following error when running the program:

(process:13511): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/home/james/snap/thumbnailer/x1/.cache/gdk-pixbuf-loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /home/james/snap/thumbnailer/x1/.cache/gdk-pixbuf-loaders.cache
to make things work again for the time being.

Looking at the desktop-launch script, the pixbuf loader cache file is only generated if gdk-pixbuf is distributed as part of the snap:

# Gdk-pixbuf loaders
export GDK_PIXBUF_MODULE_FILE=$XDG_CACHE_HOME/gdk-pixbuf-loaders.cache
export GDK_PIXBUF_MODULEDIR=$SNAP/usr/lib/$ARCH/gdk-pixbuf-2.0/2.10.0/loaders

if [ $needs_update = true ]; then
  rm -f $GDK_PIXBUF_MODULE_FILE
  if [ -f $SNAP/usr/lib/$ARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders ]; then
    $SNAP/usr/lib/$ARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders > $GDK_PIXBUF_MODULE_FILE
  fi
fi

In addition to searching for modules under $SNAP/usr/lib/..., it should also search under $SNAP/ubuntu-app-platform/usr/lib/..., and do similar when looking for the gdk-pixbuf-query-loaders script.

[didrocks]

Hey @jhenstridge! I did some recent refactoring that I just merged in master. It was before I took some days off, but I'm pretty sure I did fix this along the way. Do you mind giving it a shot?

[jhenstridge]

Just cleaned the desktop-ubuntu-app-platform part and rebuilt, and I see the same loader error.

Looking in the new script, it looks like you set the RUNTIMEDIR environment variable to the ubuntu-app-platform directory, but use RUNTIME everywhere else.

After I fixed that typo, the pixbuf loader cache and mime database (the other thing needed for gdk-pixbuf to work) seem to be generated correctly.

I did run into one other problem though when running the app:

$ thumbnailer.thumbnailer-service 
/snap/thumbnailer/x1/lib/thumbnailer/thumbnailer-service: /snap/thumbnailer/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.7' not found (required by /snap/thumbnailer/x1/lib/thumbnailer/thumbnailer-service)

The simple solution here might be "don't build on Zesty", but it wasn't a problem with the old version of the part. Snapcraft had included a copy of the newer Qt5Core in my snap, but desktop-launch is now selecting libraries from ubuntu-app-platform/ in preference to ones found in the snap itself. I'm not sure whether to class this as a bug, or simply as something that is unsupported.

[didrocks]

oupss, you are corrct, the gtk side was correct, not the Qt one. At least this bug is now fixed (and I'll close it then, but we can continue the conversation)

For the second one, yeah,"don't build on Zesty", as it's not supported, BUT, I think you can get away with that:
If you don't use the platform runtime, like including new Qt libraries versions, you can just use desktop-qt5 parts, which doesn't depend on the runtime. It will include (and the same launcher should work) what's needed for your standalone snap.

[jhenstridge]

Well, I guess my main point was that if I have a library in $SNAP/usr/lib, I would expect it to be used in preference to one in $SNAP/ubuntu-app-platform/usr/lib.

I realise that the circumstances of how I built this particular snap might be unsupported, but I wouldn't be surprised if there are other legitimate uses for this kind of thing.

[didrocks]

It should be the case for most of the things (it's the case for GNOME), and that was one of the main goal of the refactoring I merged this morning.
I maybe did a typo when handling the Qt side or missing one of the magic Qt env variable, but LD_LIBRARY_PATH definitively prefers $SNAP/usr/lib over $RUNTIME/usr/lib. If you beat me to it (can't really look at it right now), I'm happy to merge a fix.

[jhenstridge]

I added a simple echo statement to desktop-launch to dump LD_LIBRARY_PATH, and this is what I got (line breaks added for easier reading):

/snap/thumbnailer/x1/usr/lib/x86_64-linux-gnu/qt4:
/var/lib/snapd/lib/gl:
/snap/thumbnailer/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/dri:
/snap/thumbnailer/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/mesa-egl:
/snap/thumbnailer/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/mesa:
/snap/thumbnailer/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu:
/var/lib/snapd/lib/gl::
/snap/thumbnailer/x1/lib/x86_64-linux-gnu:
/snap/thumbnailer/x1/usr/lib/x86_64-linux-gnu::
/snap/thumbnailer/x1/lib:
/snap/thumbnailer/x1/usr/lib:
/snap/thumbnailer/x1/lib/x86_64-linux-gnu:
/snap/thumbnailer/x1/usr/lib/x86_64-linux-gnu

So it is definitely favouring ubuntu-app-platform libraries over ones from the snap. There are also two places where double colons appear, which could be problematic: an empty entry in the list asks to search the current working directory.

[jhenstridge]

So the "qt4" entry above is because I hadn't run "snapcraft update", so the flavor-select file still read "USE_qt5appplatform". And the double colons seem to be from library paths added by snappy.

I do wonder whether it'd make more sense for this part to append to LD_LIBRARY_PATH instead of prepending though: that would ensure that it doesn't override libraries distributed as part of the snap.

[didrocks]

Indeed, it's quite simple and should be appended instead of prepending. Now I remember that I rely on snapcraft for doing the "$SNAP" based LD_LIBRARY_PATH.

Ok, so, this should be fix in 7a9d26b.

I don't really know yet how the double colon is ending up here (can be runtime specifc or even snapcraft. I'll have to check this.

[jhenstridge]

Okay, just rebuilt my snap with the new part and everything is working.

I think you're right about the doubled colons coming from snapcraft (in the "command-foo" files it generates). I'll follow that up there.

Thanks for all your help.