My Waterfox snap won’t launch anymore because of GLIBC_2.30 doesn’t seem to exist. Any idea how I can fix it?
XPCOMGlueLoad error for file /snap/waterfox-snap/32/libnspr4.so:
/snap/waterfox-snap/32/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found (required by /snap/waterfox-snap/32/libnspr4.so)
Couldn't load XPCOM.
You’re including in your snap a libc from 2016 (2.23), are you building on Xenial? Despite this, your binary for waterfox is linked against libc 2.30. You may need to build with core18, not core as was suggested by @ogra. However, core18 does not include libc 2.30, either, which was released in 2019. It only includes 2.27, so you may need to recompile waterfox to link correctly to a less-recent libc or wait for core20 to land.
I think I figured out how to compile directly from source with snaps, and now I’m getting this error:
Failed to generate snap metadata: The specified command '/usr/local/bin/waterfox' defined in the app 'waterfox' does not match the pattern expected by snapd.
The command must consist only of alphanumeric characters, spaces, and the following special characters: / . _ # : $ -
You’re anchoring your executable command path with a leading / character. This is incorrect, because paths should be relative to $SNAP. So if your executable will live at $SNAP/usr/local/bin/waterfox then you want the command to be usr/local/bin/waterfox.
That worked, now I’m facing this problem: I can’t get the files to open up external applications. Thought the desktop helpers would solve that, but either I’m doing something wrong, or totally missing something.
It failed review since it was using the dbus interface. A little while ago I issued a snap declaration allowing use of the name and it now passes automated review.
With the next version of snapd, that dialog should be replaced with a prettier one from xdg-desktop-portal (assuming you have that service installed). It will also let the user confirm that they are fine for the snap to continue opening files of that type without being prompted in future.
It’s using a bit of an ugly hack by including a mimeapps.list file that maps a large number of mime types to xdg-open.desktop, which in turn tells it to execute snapd’s /usr/bin/xdg-open proxy.
Note that we want to get rid of this hack, and instead have Firefox talk directly to xdg-desktop-portal:
I’ve got no idea how much of the portal support code has made it’s way to Waterfox, but you could try running your snap with GTK_USE_PORTAL=1 set in the environment and see what happens.