building fonts: fontcache must be updated regulary

OpenSubmitted by ng0.
Details
5 participants
  • John Soo
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mark H Weaver
  • ng0
Owner
unassigned
Severity
normal
N
(address . bug-guix@gnu.org)
20170511083658.fuc54qhzo7ismnha@abyayala
The problem: Right now after just installing fonts, they do
not become available. This can lead to some applications
appearing "broken", etc. Other operating systems solve this
by having a post-install hook which roughly does just this.

A possible solution:
Our fictional, not yet existing, font-build-system should
run "fc-cache --force --really-force", or we should have
a service which does the same for the fonts installed in
the user profile.
At this point a font-build-system would be good anyway,
as the number of fonts keeps growing, and most fonts are
using similar patterns to be installed.
--
M
M
Mark H Weaver wrote on 11 May 2017 19:46
(name . ng0)(address . ng0@pragmatique.xyz)(address . 26877@debbugs.gnu.org)
8760h7guba.fsf@netris.org
ng0 <ng0@pragmatique.xyz> writes:

Toggle quote (9 lines)
> The problem: Right now after just installing fonts, they do
> not become available. This can lead to some applications
> appearing "broken", etc. Other operating systems solve this
> by having a post-install hook which roughly does just this.
>
> A possible solution:
> Our fictional, not yet existing, font-build-system should
> run "fc-cache --force --really-force",

This cannot work, because the build system code is run within the build
container, where it won't have access to anything in your home
directory. Furthermore, for most users, the packages are built on
another machine, namely one of our build farm slaves.

Even the build system did somehow have access to your home directory,
building the package is not the right time to run "fc-cache". On a
multiuser system, if two users request the same derivation, it is only
built for the first user, and the second user simply uses the one that
the first user built. The relevant time to run "fc-cache" is when the
font is _installed_ in your user profile.

The usual Guix way to handle things like this is to arrange for the font
cache to be part of the profile, and to create a profile hook that
creates the cache from all of the built packages included within.

Mark
N
(name . Mark H Weaver)(address . mhw@netris.org)
20170511194758.etpgtrboftdmptp4@abyayala
Mark H Weaver transcribed 1.2K bytes:
Toggle quote (30 lines)
> ng0 <ng0@pragmatique.xyz> writes:
>
> > The problem: Right now after just installing fonts, they do
> > not become available. This can lead to some applications
> > appearing "broken", etc. Other operating systems solve this
> > by having a post-install hook which roughly does just this.
> >
> > A possible solution:
> > Our fictional, not yet existing, font-build-system should
> > run "fc-cache --force --really-force",
>
> This cannot work, because the build system code is run within the build
> container, where it won't have access to anything in your home
> directory. Furthermore, for most users, the packages are built on
> another machine, namely one of our build farm slaves.
>
> Even the build system did somehow have access to your home directory,
> building the package is not the right time to run "fc-cache". On a
> multiuser system, if two users request the same derivation, it is only
> built for the first user, and the second user simply uses the one that
> the first user built. The relevant time to run "fc-cache" is when the
> font is _installed_ in your user profile.
>
> The usual Guix way to handle things like this is to arrange for the font
> cache to be part of the profile, and to create a profile hook that
> creates the cache from all of the built packages included within.
>
> Mark
>

Okay, you are right about the build system. Your approach reads
better, I was just looking for a way to start a discussion on
this. Right now it is not-obviously broken, and we need to fix
it at some point.
--
L
L
Ludovic Courtès wrote on 11 May 2017 22:55
(name . Mark H Weaver)(address . mhw@netris.org)
8760h7nmec.fsf@gnu.org
Hi,

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (4 lines)
> The usual Guix way to handle things like this is to arrange for the font
> cache to be part of the profile, and to create a profile hook that
> creates the cache from all of the built packages included within.

The problem is that the cache should be mutable so that one can run
“fc-cache -f” after having dropped files in ~/.local/share/fonts, for
instance.

That said, quite surprisingly, I think I never had to run ‘fc-cache’
except in the situation above.

Ludo’.
J
J
John Soo wrote on 7 Jul 2019 12:49
Fontcache in system profile not updated
(address . 26877@debbugs.gnu.org)
00F87CE4-6B21-4E34-927B-173D1B9AE8F5@asu.edu
Hi!

I reported #36013 to add support for kmscon’s fonts and keybinding configuration. I have a mostly working solution. The one problem I have when testing it is that kmscon cannot find a font even though it is installed in the system profile. I think it is caused by the system profile not having the updated font cache when starting the kmscon service. Does that sound like a reasonable explanation, given #26877?

Thank you!

John
M
M
Maxim Cournoyer wrote on 10 Jul 06:27 +0200
Re: bug#26877: building fonts: fontcache must be updated regulary
(name . Ludovic Courtès)(address . ludo@gnu.org)
871quth9rw.fsf@gmail.com
Hello,

ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (15 lines)
> Hi,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> The usual Guix way to handle things like this is to arrange for the font
>> cache to be part of the profile, and to create a profile hook that
>> creates the cache from all of the built packages included within.
>
> The problem is that the cache should be mutable so that one can run
> “fc-cache -f” after having dropped files in ~/.local/share/fonts, for
> instance.
>
> That said, quite surprisingly, I think I never had to run ‘fc-cache’
> except in the situation above.

I've never had to do this in years, although I don't use "loose" fonts
manually installed under ~/.local/share/fonts.

Should we close the issue? Our fontconfig package now honors fonts
found under XDG_DATA_DIRS, and it seems to just work.

Thanks,

Maxim
?