I had no problem and building and running the rust app.
But once published for snapcraft, build is fine, but running it would have this error.
(process:20418): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Gtk-Message: Failed to load module "unity-gtk-module"
(svgbob-desktop:20418): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
** (svgbob-desktop:20418): ERROR **: Unable to fork a new child process: Failed to execute child process "/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess" (No such file or directory)
Trace/breakpoint trap
I understand that webkit is linked dynamically, but it seems snapcraft wasn’t able to successfully link it at launch.
You’re not using the desktop helpers, so you’ll need to either do so or implement the functionality yourself. The desktop-launch scripts do a lot of environment variable overrides to help get things like gdk-pixbuf to work.
Thanks for your help, that did removed the gdk-pixbuf issues.
I added to have $SNAP/bin as a correction.
command: desktop-launch $SNAP/bin/svgbob-desktop
I still have the webkit errors though.
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
** (svgbob-desktop:29481): ERROR **: Unable to fork a new child process: Failed to execute child process "/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess" (No such file or directory)
It looks like I may have to create some .desktop file these in order to successfully launch the app from snap.
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
** (svgbob-desktop:23912): ERROR **: Unable to fork a new child process: Failed to execute child process "/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess" (No such file or directory)
Trace/breakpoint trap
But if i run the installed snap directly like this:
Launching like that will run the application without confinement likely causing it to use your system libraries, which may not exist. This is not how snaps are meant to run, and will fail in weird and wonderful ways on anything other than an Ubuntu 16.04 system. The reason it is “working” when you launch directly like that is because you have all the libraries your application depends upon installed on your host system.
The problem you’re really encountering is that libwebgit2gtk includes a path referencing where it thinks it is installed which, when we install into a snap package, is incorrect. This can be fixed in the future using the layouts feature, but that’s not ready yet.
well, i think the original “environment:” entry for LD_LIBRARY_PATH should have actually covered it … perhaps it makes sense to add that back in …
No, because it’s a subprocess. an executable. LD_LIBRARY_PATH doesn’t change an executable command. libwebkitgtk tries to start a new process to which it defines a fully-qualified path - i.e. it does not rely on $PATH expansion.
I based my snapcraft.yaml file from this https://github.com/babluboy/bookworm/blob/master/snapcraft.yaml which has a webkit2 dependency as well, I tried installing the snap package but it has a different error.
sudo snap install bookworm
bookworm
[INFO 23:22:10.349752] Application.vala:154: Bookworm version: (null)
[INFO 23:22:10.349779] Application.vala:156: Kernel version: 4.15.0-30-generic
[WARNING 23:22:10.366247] [Gtk] Locale not supported by C library. Using the fallback 'C' locale.
Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.87" is not allowed to own the service "com.github.babluboy.bookworm" due to AppArmor policy
I wonder if that project, at some point its snap package runs without problems.
I’ve tried several attempts of configuration changes, but there was no luck eliminating the error when launching my snap package.
I think this has to do with how rust links the webkit library and it is not the same way snapcraft expecting it to be. The build configuration for the webkit dependency is defined here it is using pkg-config to probe the webkit version.
(you can actually make use of it already via the passthrough directive in snapcraft.yaml (note though that it will fail store review until the feature is out of experimental state))
you should be able to use something like (untested):
I was trying the passthrough under app, but the snap build was rejected in the publishing step.
What version of snapcraft should I be using this? Maybe I should try this on 2.43
you dont want it under app: passthrough needs to be its own toplevel item in snapcraft.yaml …
see:
but yeah, as i said, any passthrough entry will automatically get your snap into manual review until layouts are official … you then need to wait for a reviewer to pick up the blocked snap.
Hey, I’ve just spent many hours debugging my build until over 5am in the morning, and one of the last issues I’ve had was the same as the one here.
Fortunately, I’ve found https://bugs.launchpad.net/snappy/+bug/1648988/comments/2 which mentions snapcraft-preload - this solved the problem for me without layouts! I’ve just patched it a bit at https://github.com/jkozera/snapcraft-preload to be compatible with current glibc. (Also I’ve removed lots of wrappers which we don’t need for WebKit, so the fork is unlikely to be upstreamed in this state.)
Though if you’re not using 18.04 ("base: core18"), you may be fine with the old version at upstream (But I haven’t checked it.) See “forked from” on GitHub - I cannot paste more than 2 links as a new user, sadly.
Note you will likely also need the libstdc++-dev and libc-dev-i386 packages, even if building on amd64. (Unless using my fork for 18.04, which disables the 32 bit version - then libstdc++-dev should be enough)
You can see the full snapcraft.yaml which I’m using at my zevdocs repo on GitHub (again, can’t post more than 2 links as a new user) - hope it helps!
Anyway after solving the WebKitWebProcess path problem, I’ve had two more issues:
Some “Failed to create sharedmemoryfile /WK2SharedMemory” errors - I’ve tried to fix them by adding the "browser-support" plug, but it didn’t work. So I’ve amended my fork of snapcraft-preload to also wrap open(...) calls, which has helped. This means I’m not sure if browser-support is necessary anymore, but it’s way past too late in the morning to check it now for me.
“Error loading the injected bundle (/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/injected-bundle/libwebkit2gtkinjectedbundle.so)” - amended my fork to also include dlopen(...) and now it works.
without shame