[Fontconfig] Next steps for a reproducible Fontconfig?

[Akira TAGOH]

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 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



-- 
Akira TAGOH