The keyd package already exists, but without a systemd service.
Keyd requires write access to /var/run to create its socket. Currently
the directory it uses can be changed with an environment variable, but
the keyd repo state suggests that this may turn into a compile-time
option. with that set, and some supplementary groups added, we can run
the service under DynamicUser.
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
The single option tries to do too much work, which just ends up confusing people.
So:
- don't force the console font, the kernel can figure this out as of #210205
- don't force the systemd-boot mode, it's an awkward mode that's not supported
on most things and will break flicker-free boot
- add a separate option for the xorg cursor scaling trick and move it under the xorg namespace
- add a general `fonts.optimizeForVeryHighDPI` option that explicitly says what it does
- alias the old option to that
- don't set any of those automatically in nixos-generate-config
the conversion to the markdown-based workflow missed that generating the
manual as docbook also generates the option docs with nixos-specific
wrapper elements that require postprocessing before the document is
real, valid docbook. restore this processing to the full manual.
it's not the prettiest thing, done like this, but we only need it for
one release so it doesn't have to be.
This patch fixes two issues:
1. The file in which environment variables are set is inconsistent.
- This file sets them in zprofile when programs.zsh.enable is not
set.
- Zsh module sets them in zshenv when programs.zsh.enable is set.
2. Setting environment variables in zprofile overrides what users set
in .zshenv. See these[1] home-manager[2] issues[3].
/etc/profile is also changed to /etc/set-environment. Here is a
comparison:
Using /etc/profile:
- Pros
- config.environment.shellInit is sourced in all zsh
- Cons
- config.environment.loginShellInit is also sourced in non-login zsh
- config.programs.bash.shellInit is also sourced in all zsh
- config.programs.bash.loginShellInit is also sourced in all zsh
Using /etc/set-environment:
- Pros
- config.programs.bash.shellInit is not sourced in any zsh
- config.programs.bash.loginShellInit is not sourced in any zsh
- Cons
- config.environment.shellInit is not sourced in any zsh
- config.environment.loginShellInit is not sourced in any zsh
[1]: https://github.com/nix-community/home-manager/issues/2751#issuecomment-1048682643
[2]: https://github.com/nix-community/home-manager/issues/2991
[3]: https://github.com/nix-community/home-manager/issues/3681#issuecomment-1436054233
- Christmas is over!
- Upstream has changed the name of the target triplet used for the JS
backend from js-unknown-ghcjs to javascript-unknown-ghcjs, since Cabal
calls the architecture "javascript":
6636b67023
Since the triplet is made up anyways, i.e. autoconf does not support
it and Rust uses different triplets for its emscripten backends, we'll
just change it as well.
- Upstream fixed the problem with ar(1) being invoked incorrectly by stage0:
e987e345c8
This makes the following work
disabledModules = [ foo.nixosModules.bar ];
even if `bar` is not a path, but rather a module such as
{ key = "/path/to/foo#nixosModules.bar"; config = ...; }
By supporting this, the user will often be able to use the same syntax
for both importing and disabling a module. This is becoming more relevant
because flakes promote the use of attributes to reference modules. Not
all of these modules in flake attributes will be identifiable, but with
the help of a framework such as flake-parts, these attributes can be
guaranteed to be identifiable (by outPath + attribute path).
