Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: fontconfig via HM doesn't actually work for me (HM installed fonts not seen by applications) #4048

Open
2 tasks done
ppenguin opened this issue Jun 1, 2023 · 7 comments
Assignees
Labels
bug status: stale triage Issues or feature request that have not been triaged yet

Comments

@ppenguin
Copy link

ppenguin commented Jun 1, 2023

Are you following the right branch?

  • My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

  • I have searched the existing issues

Issue description

I just moved the many "extra" fonts for my HM user from the global nixos config into my HM-config.

So I have:

home.packages = with pkgs; [ ... /* many fonts */ ];
fonts.fontconfig.enable = true;

When e.g. running font-manager I can only see the fonts that were installed system wide (via fonts = [ ... ]; in configuration.nix.

Running fc-cache --force --verbose gives me many errors about "looped dirs" (safe to ignore as duplicates?) and non-writable cache dir(s). The latter is to be expected if I understand correctly, since the cache is read-only by design and built to the nix store by the HM module. So fc-cache is ineffectual as well by design for this setup, I guess.

I checked and have ~/.config/fontconfig/conf.d/10-hm-fonts.conf, containing

<?xml version='1.0'?>

<!-- Generated by Home Manager. -->

<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
  <include ignore_missing="yes">/nix/store/8563zkq3iw1k9l3l4a1544xs6nskglzk-home-manager-path/etc/fonts/conf.d</include>
  <include ignore_missing="yes">/nix/store/8563zkq3iw1k9l3l4a1544xs6nskglzk-home-manager-path/etc/fonts/fonts.conf</include>

  <dir>/nix/store/8563zkq3iw1k9l3l4a1544xs6nskglzk-home-manager-path/lib/X11/fonts</dir>
  <dir>/nix/store/8563zkq3iw1k9l3l4a1544xs6nskglzk-home-manager-path/share/fonts</dir>
  <dir>/home/jeroen/.nix-profile/lib/X11/fonts</dir>
  <dir>/home/jeroen/.nix-profile/share/fonts</dir>

  <cachedir>/nix/store/8563zkq3iw1k9l3l4a1544xs6nskglzk-home-manager-path/lib/fontconfig/cache</cachedir>
</fontconfig>

The first <include> appears to be the same one that is pointed to by ~/.nix-profile/etc/fonts/conf.d,
the second doesn't exist (?!), the second and fourth <dir> entries are also the same /nix/store path content and the X11 don't exist (I'm on wayland, probably normal).

I also have ~/.nix-profile/etc/fonts/ which only contains a dir conf.d which contains symlinks (e.g. 30-courier-new.conf) to the nix store realisations of corefonts and vistafonts, which I do have in home.packages, but I have many more fonts as well but these are the only ones that are linked here.

When I run a devShell from a flake that does this:

  ...
  let
       fonts = pkgs.makeFontsConf { fontDirectories = with pkgs; [ freefont_ttf fira fira-mono ubuntu_font_family noto-fonts-cjk gyre-fonts hyperscrypt-font lmodern ]; }; # https://github.com/NixOS/nixpkgs/issues/24485
  in
  pkgs.mkShell { 
   ...
    shellHook = ''
    export FONTCONFIG_FILE=${fonts}
  '';
  }

and in this shell start font-manager, I indeed see the selected fonts.

I.e. that begs the question what HM does differently, or why we can't use makeFontsConf in HM as well?

So I'm a bit lost why HM fonts management doesn't work for me, but also it might be better to use the same fonts = [ ... ]; paradigm in HM instead of just putting fonts in home.packages?

Maintainer CC

@rycee

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.2.16, NixOS, 23.05 (Stoat), 23.05.20230531.3a70dd9`
 - multi-user?: `yes`
 - sandbox: `relaxed`
 - version: `nix-env (Nix) 2.13.3`
 - nixpkgs: `/nix/store/bcwv054bxj0k
@ppenguin ppenguin added bug triage Issues or feature request that have not been triaged yet labels Jun 1, 2023
@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/since-upgrade-to-23-05-nerdfonts-wont-show/28636/5

@rycee
Copy link
Member

rycee commented Jun 17, 2023

Does the generated configuration show up when you run fc-conflist | grep $HOME? Do any of the fonts show up in fc-list?

@exzombie
Copy link
Contributor

For me, it's even stranger: the ~/.nix-profile/etc/fonts/ directory doesn't exist either. fc-conflist does include /.config/fontconfig/conf.d/10-hm-fonts.conf.

The directory ~/.nix-profile/share/fonts/ exists and the fonts are installed there; fc-list includes the fonts installed by HM, and fc-match can match them. However, other programs are hit or miss. font-manager, for example, doesn't list them.

@exzombie
Copy link
Contributor

Ok, so I tracked the "hit or miss" nature of the problem down to "Hack Nerd Font Mono", which seems to be a bit problematic. For example, it couldn't be loaded by emacs. I tried other Nerd fonts, and they work. Also in other programs, like konsole or libreoffice.

font-manager still doesn't see any Nerd fonts installed by HM. Not a problem for me, though it might indicate not everything is peachy. But it just as well be an issue specific to this program.

@stale
Copy link

stale bot commented Oct 28, 2023

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

  • If this is resolved, please consider closing it so that the maintainers know not to focus on this.
  • If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
  • If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

  • If you are also experiencing this issue, please add details of your situation to help with the debugging process.
  • If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

@stale stale bot added the status: stale label Oct 28, 2023
@fedor-ivn
Copy link

Any updates here? Still reproducible

@stale stale bot removed the status: stale label Apr 2, 2024
Copy link

stale bot commented Jul 3, 2024

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

  • If this is resolved, please consider closing it so that the maintainers know not to focus on this.
  • If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
  • If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

  • If you are also experiencing this issue, please add details of your situation to help with the debugging process.
  • If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

@stale stale bot added the status: stale label Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug status: stale triage Issues or feature request that have not been triaged yet
Projects
None yet
Development

No branches or pull requests

7 participants