[Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH akira at tagoh.org
Tue Apr 2 13:08:27 UTC 2019

There are another problem that salt can't be overwritten by another
dir elements coming later. which looks intuitive to me. so I'll fix

On Tue, Apr 2, 2019 at 9:35 PM Akira TAGOH <akira at tagoh.org> wrote:
> Thanks for testing, Alex.
> On Mon, Apr 1, 2019 at 11:35 PM Alexander Larsson
> <alexander.larsson at gmail.com> wrote:
> > I don't understand why its generating cache files with the same
> > filenames, even though the salt for /usr/share/fonts is different.
> I've added some debugging output (try FC_DEBUG=16 if you want to see
> more) to see how fontconfig determines cache filename with given
> config. and I found etc/fonts/conf.d/50-flatpak.conf has:
>         <reset-dirs/>
>         <dir salt="unique-per-runtime">/usr/share/fonts</dir>
> and reading config files in ASCII order. so when comparing the name of
> "50-flatpak-salted.conf" and "50-flatpak.conf", 50-flatpak-salted.conf
> is read first. then it was reset and overwritten (newly added in fact)
> by the non unique string in 50-flatpak.conf.
> That's the reason why you got same cache names in two runs.
> So if you don't need to keep the above two lines in 50-flatpak.conf,
> you can drop them from there and add <reset-dirs/> to
> 50-flatpak-salted.conf.
> > And why does it think they are invalid after having just generated
> > them? (The script that generates the 50-flatpak-salted.conf removes
> > all caches, so the claimed to be invalid files are definitely created
> > by fc-cache...)
> From the debugging message for consideration:
> /usr/cache/fontconfig: cleaning cache directory
> FcCacheTimeValid dir "/usr/share/fonts/liberation-fonts" cache
> checksum 1554199639.0 dir checksum 155420102
> 3.810342069
> /usr/cache/fontconfig: invalid cache file:
> e9b75eee6795385ae3f53a200406b963-le64.cache-7
> Those sum is coming from mtime of cache and dir. fontconfig detects
> that dir has been updated but cache wasn't. so considered it is
> outdated...
> > Also, i worry about the fact that it seems to list all the fonts in
> > /usr/share/fonts twice, the second time complaining about looping.
> > Maybe the reset-dirs is not working in fc-cache, so its picking up the
> > first instance of /usr/share/fonts?
> No. that is because scanning paths recursively twice when parsing dir
> element in config and generating caches. so that is irrelevant to this
> though.
> Hmm, maybe good to shutting that message up or stop scanning recursively either.
> > Also, why is it warning about
> > "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf"? Why is
> > it even trying to parse this file? It should not be used?
> This isn't actually new. when path can't be converted with
> prefix="xdg" (for instance, unable to determine relevant XDG env vars
> and even hone dir) and so on, that makes a path empty. but that
> message seems accidentally shown. I've reverted this behavior to the
> past one.
> --
> Akira TAGOH


More information about the Fontconfig mailing list