Repository navigation
[Bug]: flatpak and fontconfig cache update #6738
Description
Activity
just FYI: after a few analysis, I confirmed that there was no real incompatible changes in the cache format between 9 and 12 at least. I band-aid it by creating symlinks at the host side for a short term workaround: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/366787e49c69c1fdd66b70b4a48f8c6bae6ab036
The problem is quite simple. there are no cache files that can be read from fontconfig version in flatpak runtime and the runtime cache update in fontconfig also fails because of no writable cache directory in flatpak runtime by its design. Thus, flatpak app can't use a font from the host system.
Flatpak apps should write and read cache from
$XDG_CACHE_HOME/fontconfigthat points to~/.var/app/<appid>/cache/fontconfigon host which should be writable and readable by app. Are you saying it doesn't work?just FYI: after a few analysis, I confirmed that there was no real incompatible changes in the cache format between 9 and 12 at least. I band-aid it by creating symlinks at the host side for a short term workaround: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/366787e49c69c1fdd66b70b4a48f8c6bae6ab036
This may be causing widespread
SIGSEGVcrashes across Plasma 6, KWallet, Kate, KCalc on Kubuntu 26.04 after today's update. When Flatpaks withfilesystem=homewrite cache-12 with cache-9 symlinks to~/.cache/fontconfig, host libfontconfig format 9 failsFcPatternGetCharSet, leading to dereferencing0xfefefefefefefefein Qt 6.Flatpak shouldn't write any fc cache in
~/.cache/fontconfigeven when it hasfilesystem=homepermission unless you forced it some way. It doesn't in my testing.I finally tracked this down how it happens
You didn't really say what "it" is... if users are reporting problems and Flatpak is thought to be part of the cause, we're not going to be able to say much without knowing what symptoms the users reported and how they reproduced those symptoms.
Flatpak shouldn't write any fc cache in
~/.cache/fontconfigIs the problem here (at least partially) that a non-Flatpak app on the host writes something unwanted to that directory, and then Flatpak apps read from it and get user-visible symptoms that aren't their fault?
After I upgraded com.vivaldi.Vivaldi (a Chromium based browser) to use the
org.freedesktop.Platform-26.08runtime (it was previously onorg.freedesktop.Platform-25.08) I started to get user reports of font issues (see the link above).In addition I have since noticed that Vivaldi prints the following on each startup using the newer runtime:
Fontconfig warning: We will not regenerate the cache because some cache files were generated by a newer version (0x2012003) of Fontconfig. Please regenerate the cache with the latest version of Fontconfig to avoid any unexpected behavior. (current version: 0x2012001)I can likely mitigate this for the time being by reverting to the older runtime but it is not a solution going forward.
@ruario this may be caused by using binaries build against older fontconfig versions while 26.08 runtime has latest fontconfig. It seem to happen outside flatpak as well so perhaps something to discuss in fc upstream.
Reacted by ruarioNonetheless, changing the internal build architecture for for all of Vivaldi (the flatpak is a repack) is not something I can realistically do right now. So for now (until I work out something better), I will downgrade the runtime.
Checklist
Flatpak version
1.18.0
What Linux distribution are you using?
Fedora Linux
Linux distribution version
Fedora Rawhide
What architecture are you using?
x86_64
How to reproduce
Well, I wanted to have a channel to discuss with flatpak team as a fontconfig maintainer about the issues being often reported against fontconfig cache update and unexpected rendering in flatpak app, and take measures for that.
I finally tracked this down how it happens. The problem is quite simple. there are no cache files that can be read from fontconfig version in flatpak runtime and the runtime cache update in fontconfig also fails because of no writable cache directory in flatpak runtime by its design. Thus, flatpak app can't use a font from the host system.
For the short term workaround in distribution level:
They could provide a compat package of fontconfig (2.17.x at this point) and build old version of cache files at host which is compatible with flatpak runtime. but this won't be a workaround/solution from the flatpak upstream perspective.
I may need to think about another cache model perhaps, I want to hear some opinion from flatpak team, how this can be addressed from the POV of flatpak.
Expected Behavior
Same rendering result
Actual Behavior
Different rendering result
Additional Information
No response