In fontconfig’s 60-generic.conf, order of preference is estabilished for emoji
font family. Because fontconfig parses the config files in lexicographic order,
appending each <prefer> from <alias> element to the family’s prefer list
(to be prepended before the family) [1], our font family defaults stored
in 52-nixos-default-fonts.conf will take precedence. That is, of course, unless
the default „weak“ binding [2] is used. Emoji family binds strongly [3],
so we need to set binding to “same” for our <alias>es to be considered before
the ones from 60-generic.conf.
By default, we will set the option to all emoji fonts supported by fontconfig,
so that emoji works for user if they have at least one emoji font installed.
If they have multiple emoji fonts installed, we will use the fontconfig’s
order of preference [4].
[1]: https://github.com/bohoomil/fontconfig-ultimate/issues/51#issuecomment-64678322
[2]: https://www.freedesktop.org/software/fontconfig/fontconfig-user.html#AEN25
[3]: cc8442dec8
[4]: c41c922018
It currently lacks an emoji font-family which means it has to be
disabled for them to function [0]. Additionally it's fallen out of
necessity to ship custom font rendering settings (as far as I'm aware
of).
[0]: https://github.com/NixOS/nixpkgs/pull/67215
We don’t want any trailing whitespace, otherwise we mess up the
formating of the shadow file. Some things like readFile may have the
trailing new line.
Fixes#66745
This module correctly includes the vte.sh script
required for vte terminals like gnome-terminal to show the
CWD in the window title and preserved across instances.
This is achieved with the options:
* programs.bash.vteIntegration
* programs.zsh.vteIntegration
as it's best to keep this configuration unguarded by gnome3.enable
to support other vte terminals (such as elementary-terminal).
Note the distinction between Zsh and Bash doesn't include
a different script, as this script only supports those two shells.
systemd provides two sysctl snippets, 50-coredump.conf and
50-default.conf.
These enable:
- Loose reverse path filtering
- Source route filtering
- `fq_codel` as a packet scheduler (this helps to fight bufferbloat)
This also configures the kernel to pass coredumps to `systemd-coredump`.
These sysctl snippets can be found in `/etc/sysctl.d/50-*.conf`,
and overridden via `boot.kernel.sysctl`
(which will place the parameters in `/etc/sysctl.d/60-nixos.conf`.
Let's start using these, like other distros already do for quite some
time, and remove those duplicate `boot.kernel.sysctl` options we
previously did set.
In the case of rp_filter (which systemd would set to 2 (loose)), make
our overrides to "1" more explicit.
sysctl.d(5) recommends prefixing all filenames in /etc/sysctl.d with a
two-digit number and a dash, to simplify the ordering of the files.
Some packages provide custom files, often with "50-" prefix.
To ensure user-supplied configuration takes precedence over the one
specified via `boot.kernel.sysctl`, prefix the file generated there with
"60-".
This change is needed because the order of profiles correlate to the
order in PATH, therefore "/etc/profiles/per-user/$USER" always appeared
after the system packages directories.
If lib.optional is given a false value it will return an empty list.
Thusly the set-environment script can have
```
export GTK_USE_PORTAL=
```
This can rub certain bugs the wrong way #65679
so lets make sure this isn't set in the environment
at all.
Prior to this change GTK_USE_PORTAL was unconditionally
set to "1". For this to not break things you have to have some
sort of portal implementation in extraPortals.
Setting GTK_USE_PORTAL in this manner is actually only useful
when using portals for applications outside flatpak. For example
people using non-flatpak Firefox who want native filechoosers.
It's also WIP for electron applications to support this.
Left to do: re-enable as needed in the usual situations.
This added ~286MiB to the base system closure, which is enough to bring
the sd images over the limit allowed on Hydra.
This is a refactor of how resolvconf is managed on NixOS. We split it
into a separate service which is enabled internally depending on whether
we want /etc/resolv.conf to be managed by it. Various services now take
advantage of those configuration options.
We also now use systemd instead of activation scripts to update
resolv.conf.
NetworkManager now uses the right option for rc-manager DNS
automatically, so the configuration option shouldn't be exposed.
This is more robust than setting via environment variable, though it does come
later in the load sequence. An added benefit is affecting the current
session.
Add an option to set the rc-manager parameter in NetworkManager.conf,
which controls how NetworkManager handles resolv.conf. This sets the
default rc-manager to "resolvconf", which solves #61490. It
additionally allows the user to change rc-manager without interference
from configuration activations.
Back in 2013, update-mime-database started using fdatasync() to write out
its changes after processing each file in /share/mime, with the reasoning
that a corrupted database from an interruption midway would be
problematic for applications[1]. Unfortunately, this caused a
significant regression in the time required to run update-mime-database:
commonly from under a second to half a minute or more.
This delay affects the time required to build system-path on NixOS, when
xdg.mime.enable is true (the default). For example, on one of my systems
system-path builds in ~48 seconds, 45 of which are update-mime-database.
This makes rapidly building new system configurations not fun.
This commit disables the calls to fdatasync(). update-mime-database
checks an environment variable, PKGSYSTEM_ENABLE_FSYNC, to determine
whether it should sync, and we can set this to false. system-path
already only has whatever filesystem commit guarantees that the Nix
builder provides. Furthermore, there is no risk of a failed MIME
database update messing up existing packages, because this is Nix.
(This issue was also reported at and discussed by Debian, Red Hat, and
Gentoo at least.)
[1] https://bugs.freedesktop.org/show_bug.cgi?id=70366
