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 it. On Tue, Apr 2, 2019 at 9:35 PM Akira TAGOH <akira@xxxxxxxxx> wrote: > > 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 -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
