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