Will this ever get fixed? None of the workarounds work anymore, on some snaps…
on which snaps ?
alfacast for example
Spotify here, currently.
Less than ideal removing my font configs. Can a package maintainer take some responsibility for this please.
well, it is not your configs but only the cached data (the cache gets automatically re-generated).
there have been fixes in various areas (snaps that use snapcraft extensions (i.e. the qt one or the gnome ones) should already behave fine, snaps that use the older desktop launchers and have not been re-built in a while might still be stuck on old behaviour though (thus my quetion above about “which snaps”))
Thanks @ogra. Looking at your github looks like you have made quite a few contributions to snap.
This fix has worked for me. Just to better uunderstand and to move towards a full resolution to this issue. Could you descibe the actual fault to me. I am sure that there is something we can suggest or build for snap to deal with this in a better way.
Thanks for the tip. Looks like there were changes in snapcraft 4.4+ that introduced proper per-snap font cache handling in the configure hook. I see that the snap-store snap from edge (rev 492) has been rebuilt using snapcraft 4.4.1 (according to snap/manifest.yaml). I can confirm that the snap-store works for me now, while previously it would segfault during startup.
It does look like we have a fix. How can we get the snap publishers to actually rebuild their snaps now?
1 Like
we have the feature to send out mails to packagers about security issues in their snaps, i wonder if it is possible to use that system to mail all packagers of snaps plugging the desktop interface perhaps ?
i guess the store team would know if such a feature exists (or is easy/hard to implement) …
boxy-svg (file dialog), shapezio (file dialog) all have the issue and no workaround works currently.
1 Like
AFAIK, this is only for snaps, like snap-store, that use the gnome extension edit: it turns out both the gnome extension and the kde extension do this. The fix in 4.4+ does not apply generically to all snaps, just those that use the gnome extension. So either snaps that continue to not work need to switch to using the gnome-extensions (which is not possible in all cases), or snapcraft needs some more work to enable perhaps just a “fonts” extension which DTRT regardless of whether the snap is using the gnome extensions or not and then push people who can’t switch to using the gnome extension to use just the fonts extension.
Both of these snaps use gnome platform snaps, so perhaps all that’s necessary are rebuilds with newer versions of snapcraft, I think @popey can just trigger a rebuild with a newer version of snapcraft and shapezio will be fixed like 
while I don’t know if the boxy-svg maintainer is here, but there is a contact set for the snap so you could try reaching out that way.
I just triggered and uploaded a new build of shapezio. Let me know if that helps?
1 Like
The update didn’t fix the issue, but I noticed I did the workaround wrong.
The correct workaround is:
rm -r ~/snap/snapname/common/.cache/fontconfig
touch ~/snap/snapname/common/.cache/fontconfig
instead of the ~/snapname/current/.config/fontconfig which I did by accident. That works atleast for now.
1 Like
However, that workaround is not ideal as it causes the dialog boxes to take a long time to open up every time you launch the program.
I have a similar issue on Ubuntu Core 18 with squares instead of fonts and not working icons in my gtkmm application using gnome-3-28. My application is built with the core 18 image. Snap works fine on Ubuntu16.04 and ubuntu18.04 but it fails on Ubuntu core 18 with mir-kiosk and wayland. Non of the workarounds above works for me in this case. Also when I run application I got warnings:
gtk-update-icon-cache: The generated cache was invalid.
WARNING: icon cache generation failed for /root/snap/gsapples/x1/.local/share/icons/Humanity-Dark
gtk-update-icon-cache: Could not rename /root/snap/gsapples/x1/.local/share/icons/Humanity/.icon-theme.cache to /root/snap/gsapples/x1/.local/share/icons/Humanity/icon-theme.cache: No such file or directory
WARNING: icon cache generation failed for /root/snap/gsapples/x1/.local/share/icons/Humanity
note that the gnome extension only ships the dejavu font, if your kiosk app uses or expects anything else you should ship the expected fonts in your app snap … (and make sure the fonts can be found in the font path).
also recent snapcraft generates a configure hook for you that calls fc-cache i think, not sure how that works in case of kiosk snaps … (the only one i have that is using the gnome extension atm doesnt need any fonts (https://github.com/ogra1/picviewer-kiosk))
Right now I’m using sans font, which counts as dejavu I think - so it is not non default font problem.
For the similar test to the one that was done earlier in this thread I installed Inkscape in ubuntu core 18 and effect is simillar - no fonts. No one really needs Inkscape in Ubuntu Core so it is not a problem in itself - but it shows that “build once and install anywhere” does not work in Ubuntu Core for Gtk applications.
I use snapcraft 4.4.2, so I think that this is up to date version. This configure hook, is it something that I have to specify in my snapcraft.yaml file explicitly or is it something that suppose to just work in newer snapcraft version?
as i understood it should just work (though my own desktop related snaps simply already use that config hook and their own font cache (i.e. see the zoom-snap) similar to what inkscape does) … if inkscape does not work this indicates that the fix wont work on core either …
OTOH i dont think anyone ever stated anything about “build once and install everywhere” in regards to Ubuntu Core which is completely focused on embedded, IoT and industrial currently. Graphical apps o Core are expected to be standalone, separately packaged kiosk apps that ship everything necessary along in their package.
Ubuntu Core does not even have a user concept ATM and is lacking any pieces to spawn a user session beyond providing an ssh login for developers (the typical use-case is completely user-less, managed through an agent snap that is hooked up to a central fleet management service or as an appliance with a minimal initial configuration tool)