Snapped app not loading fonts on Fedora (and Arch)

I am also having this problem with Manjaro ARM. None of the solutions above have worked.

Any thoughts here? This is a big issue for my app as it makes my Snap unusable on Fedora and Manjaro for anyone who needs to open the file open dialog.

2 Likes

Although that above did not get the app to work, this, slightly different set of commands, DID work to allow me to run the app. **I am on Manjaro

$ sudo rm -f /var/cache/fontconfig/*
$ rm -f ~/.cache/fontconfig/*

That came from philm of Manjaro: https://forum.manjaro.org/u/philm
**I could not find the post where he offered it.

the DASH EFF seems to do the trick. (-f)

2 Likes

These commands worked for me except I got the ā€˜Argument list too longā€™ error on the second command so I deleted the fontconfig dir and added an empty one. I am using Manjaro KDE. Thanks for this solution. :clap:

FWIW ā€“ Saw this problem with stock Ubuntu 20.04 with a custom gnome theme installed (have no idea if that makes a difference ā€“ just saying).

Again, this fixes it:

The snap that displays this problem for me is ā€œnamegenā€ ā€“ a GTK3-based random name generator. I have since taken it private until I have time to work this more carefully or until the solution is found.

I think Iā€™m running into this on Ubuntu 20.04 when testing a 18.04-based rst2pdf snap before publishing (pull request here https://github.com/rst2pdf/rst2pdf/pull/928). The tool produces PDFs, so it does need to access the fonts on the userā€™s system, and we know our user base has a mix of geekiness, so we canā€™t recommend people run command to clear their font caches as a general thing :confused: Is there a way to manage the font config/cache from within the snap so we can publish a new version? At the moment trying to do anything with fonts is producing FileNotFoundError: [Errno 2] No such file or directory: 'fc-match': 'fc-match' and no output. Advice gratefully received ā€¦

If thereā€™s a better way (or something integrated in the extensions) it would be very niceā€¦
In a snap I maintain (the swi-prolog snap: https://snapcraft.io/swi-prolog) this issue appears from time to time, and while it can be solved by removing the fontconfig cache it is not convenient.
In my case the snap is using the kde-neon extension, if that makes any difference

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 :rainbow: :unicorn: 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