Thanks for testing, Alex.
On Mon, Apr 1, 2019 at 11:35 PM Alexander Larsson
<alexander.larsson@xxxxxxxxx> 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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
