Snapped app not loading fonts on Fedora (and Arch)

snap
30

I’ve bisected libfontconfig versions between 2.12.6 (which we know to work), and current master (2.13.92+). I’ve made sure that there is only one source of fontconfig cache under /var/cache/fontconfig and no other location can be written to inside the snap.

The commit that broke it was correctly identified by @jamesh before:

If we want to get it working, we need to have a way of ensuring that the generated font cache is comptible with whatever the libfontconfig version is used by the snap (be it the core* one, or Gnome runtime one).

2 Likes
31

As I mentioned on IRC, it is quite possible that the breakage is earlier than this commit. The difference is that commits from this one on produce cache files that Bionic’s fontconfig can see (i.e. based on the MD5 of the file name), and the ones just before it don’t (i.e. a UUID matching the $dir/.uuid file).

It would probably be possible to bisect further back by generating a cache and then symlinking the UUID cache file to the equivalent MD5 name and see if the snap is still broken.

1 Like
32

Having worked around the UUID thing, I was able to narrow it down to this single commit.
https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/0f9bbbcf8f6f8264efb0a2ded4d8d05f3b10f7a4

Reverting the commit in full and regenerating the cache, made the fonts works again. In your view, what is the best way to proceed with the upstream?

3 Likes
33

Debugging this further. The fonts work on Focal and Debian 10, both using libfontconfig 2.13.1. I’ve pulled the actual libfontconfig.so.1.12.0 binary from Debian and font files. Also mounted an empty tmpfs over /etc/fonts (and then /etc/fonts/conf.d) to make sure we’re using a vanilla config. Then symlinked the MD5-named cache file expected by gnome-3-28-1804 is symlinked to the right UUID-name file as expected by the Debian version.

In the end fonts were still rendering as boxes, suggesting that perhaps problem is somewhere else in the stack. I need to consult with @jamesh on how to proceed with debugging this.

1 Like
34

Clearing fontconfig cache fixed this problem for me on Arch Linux. I use infinality patched font BTW

35

Once you do fc-cache -f on the host, and then run the snap again, the font should be broken in snaps again. I haven’t been able to do it yet, but the next step is probably dissecting the cache file generated by 2.13.1 and 2.13.92+ to check the differences.

1 Like
36

Hi, had the same issue with CherryTree.
My fix was:

sudo rm /var/cache/fontconfig/*
rm ~/.cache/fontconfig/*
fc-cache -r

Thanks @vgm106

1 Like
37

Thank you for that fix. It makes one wonder why there is still font caching in Linux at all considering it takes about 600ms for fc-cache to run so why does it even exist? Seems like some relic of the Xfree86 days, as in 1986 presumably(?)

39

Could you test mattermost-desktop? Maybe this is an issue with the electron-builder tooling. The mattermost-desktop snap uses electron but not the electron-builder tooling.

41

This is a great test case, which is very difficult to reproduce. Could you please test the inkscape snap? There’s been a proposed fix for fontconfig mismatches in the inkscape snap and we would love to get confirmation that it works in cases like your’s.

Thanks!

43

That’s great info!

It is pretty hard to reproduce, if you aren’t a daily Fedora user. I just did a fresh install of Fedora 32 earlier this week and couldn’t reproduce the font issue. I’ve tried this a number of times with different versions of Fedora in the past and never reproduced it myself. It’s all related to the version of fontconfig that was used to generate cache files on the host. How recent was your fresh install? Was your homedir preserved from a previous install?

Thanks for the info!

@ted ^^ confirmation the snap private font caches seem to fix the issue, thanks for being a guinea pig.

3 Likes
45

Please make sure you remove ~/snap/inkscape/common/.cache/fontconfig directory first. FWIW the inkscape snap from edge works here on Arch too.

The gimp or glimpse-editor snaps segfault and render boxes in the splash screen, but as I understand those do not have the special sauce @kenvandine added.

1 Like
47

@kenvandine Are you planning to upstream your fontconfig magic? This would benefit from being included as a snapcraft extension.

48

Yes, we are planning to add this to the snapcraft extension. We need to work out some details first to make this more generic.

2 Likes
49

I got hit by this with codium https://github.com/VSCodium/vscodium/issues/426

Any hints how to patch https://github.com/snapcrafters/codium/blob/master/snap/snapcraft.yaml to make the fonts great again?

50

Fedora 2.45 package has some cherry-picks that disable system font cache handling. You may need to remove the user’s fonts cache too rm -f ~/.cache/fontconfig/* and one from the snap, usually ~/snap/codium/common/.cache/fontconfig/*. Unfortunately deskop helpers do some weird thing and copy over the user’s fonts cache (which may have been generated with a problematic version of fontconfig), to the snap. Hence, a workaround is needed.

51

I don’t understand why fontconfig doesn’t migrate the cache “database” like any modern app does nowadays?

If the problem with desktop helpers, then maybe they should run the migration function when copying fonts?

52

@mborzecki For me this wasn’t enough, on Fedora 32 KDE. For example, with the boxy-svg snap I had to remove the snap’s fontconfig folder entirely, and replace it with an empty file to prevent it from being created again, or else every time the snap launched it would regenerate the problematic fontconfig cache, and fonts wouldn’t work.

There is one caveat to this, is that every time I use the snap, the first time I do something that requires fontconfig cache, it hangs for a few seconds and then works.

53

That didn’t help. F32, Gnome.

✗ rm -rf ~/.cache/fontconfig 
✗ rm -rf ~/snap/codium/common/.cache
✗ codium

About.

image

54

you were missing one command to re-generate the cache, so you just end up with a generated cache by the snap again, the full sequence should be:

$ rm -rf ~/.cache/fontconfig 
$ rm -rf ~/snap/codium/common/.cache
$ fc-cache -r
$ codium

see if this works any better …