Re: Next steps for a reproducible Fontconfig?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux