[Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

Ok, this seems to work well with the latest version of the branch and
my test case:
 https://gist.github.com/alexlarsson/8912637dd6173591a8dec7c043cfa01d

However, I had to fix an issue in flatpak-builder:
  https://github.com/flatpak/flatpak-builder/pull/277
Because fc-cache was picking up the SOURCE_DATE_EPOCH of the build and
injecting it into the cache builds, thus causing it to create invalid
caches (were not matching the on-disk dir mtime so was never used). My
fix of this is is to reset the directory mtimes to 0 during the build
(as they will be when deploying), as this makes fc-cache ignore the
SOURCE_DATE_EPOCH.

So, if we get a new fontconfig with this landed, we could update the
existing runtimes to that version, and then we will be prepared for
when distros update to fontconfig without the uuid support.

There are still some issues though:
 * Only flatpak 1.2.0 and later generates the dir-remapping fontconfig
file, so earlier versions of flatpak will regenerate caches for
/run/host/fonts.
 * On current distros, with the uuid file generated the host fc-cache
will only generate the uuid style cache files, and these will not be
used by the fontconfig in the sandbox.

The first I think is fine, just update your flatpak to the latest
stable release and it will be fast.

However, the second is a problem. It means that the second we update
the flatpak runtime to the latest fontconfig all flatpak apps will get
a slow first startup on all current distros.

Is it possible that we could make the new fontconfig not generate uuid
cache files, but look for them as fallback? I.e. if the (possibly
salted) regular path checksum doesn't exist, look for a .uuid file in
that dir and use that for lookup?

On Thu, Apr 4, 2019 at 8:50 AM Akira TAGOH <akira at tagoh.org> wrote:
>
> Ah, thank you for catching this up. I fixed similar case before but
> missed the case for sub directories. fixed.
>
> On Wed, Apr 3, 2019 at 10:01 PM Alexander Larsson
> <alexander.larsson at gmail.com> wrote:
> >
> > On Tue, Apr 2, 2019 at 2:35 PM Akira TAGOH <akira at tagoh.org> wrote:
> > >
> > > Thanks for testing, Alex.
> >
> > Doing some more testing, and I think I have found an issue.
> >
> > On the host i regenerate caches with your branch, getting FC_DEBUG=16
> > output (among other output):
> >
> >   cache: /6ba42ae0000f58711b5caaf10d690066-le64.cache-7 (dir:
> > /usr/share/fonts/cantarell, salt: (null))
> >   cache: /6ba42ae0000f58711b5caaf10d690066-le64.cache-7 (dir:
> > /usr/share/fonts/cantarell, salt: (null))
> >   charsets 5 -> 1 leaves 75 -> 15
> >   cache: /6ba42ae0000f58711b5caaf10d690066-le64.cache-7 (dir:
> > /usr/share/fonts/cantarell, salt: (null))
> >
> > In the flatpak-generated config in the sandbox have:
> >     <remap-dir as-path="/usr/share/fonts">/run/host/fonts</remap-dir>
> >     <dir>/run/host/fonts</dir>
> >
> > Then, running fc-list in the sandbox prints:
> >
> >   cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir:
> > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell),
> > salt: (null))
> >   cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir:
> > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell),
> > salt: (null))
> >   charsets 5 -> 1 leaves 75 -> 15
> >   cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir:
> > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell),
> > salt: (null))
> >   FcDirCacheWriteDir dir "/run/host/fonts/cantarell" file
> > "/home/alex/.var/app/org.gnome.eog/cache/fontconfig//85bba0c73358da0b93a259c9d2b16b14-le64.cache-7"
> >
> > Note how these get different checksums, meaning that the host cache is
> > not used. I think this is due to the double-slash in "mapped to
> > /usr/share/fonts//cantarell".
>
>
>
> --
> Akira TAGOH