Currently translated at 100.0% (32 of 32 strings)
Add translation using Weblate (Danish)
Co-authored-by: cafkafk <christina@cafkafk.com>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/da/
Translation: Home Manager/Home Manager CLI
In #587, kalbasit introduce the `-i` flag so the sudo invocation would
run in an environment with `HOME` set to the correct value for the
target user. This was necessary to be able to set up multiple users
without interfering with the invoking user's `HOME`.
In #807, I switched to `-s` instead because I managed to get an
invalid shell set for my user by switching `useUserPackages` from
`true` to `false` which changes the location where packages are
installed and `~/.nix-profile/bin/<my-shell>` was no longer valid.
This was based on the assumption that `SHELL` would be set to some
sensible value by Home Manager at this point. This turned out to be
false as reported in #2900.
In 0ced6d6d (this commit's parent at this time), I explicitly set
`SHELL` to `${pkgs.bash}` so it is definitely set to a good shell when
invoking the activation script.
However, #807 broke activation for multiple users, the original
motivation for `-i`, as reported in #2856. I fixed this in #2857 by
additionally passing `--set-home`.
Further discussion with rycee in #3040 made me realize that the
activation script already has a good Nix store bash shebang. So all
the problems have been caused, not by the shell used for the
activation script but by sudo trying to use a different shell at all.
`-i` uses the shell set in the `passwd` file for the target user, but
this can become invalid as happened to me. `-s` uses either `SHELL` if
it's defined or the invoking user's shell as set in the `passwd` file.
By explicitly setting this to a shell provided by Nix we make sure
we're not trying to launch a non-existent shell. However, we're
clearly already running in an existing shell and because of
`--set-home` we can activate other users properly so there's not
actually any need to try to have sudo start a different shell first,
it just adds an extra process that then goes on to run the activation
script with a good bash because of the shebang.
Dropping `-s` altogether and keeping `--set-home` should avoid all of
these issues.
In #807 I changed the flag passed to `sudo` from `-i` to `-s` so
`sudo` wouldn't use a non-existent shell defined in the `passwd` file.
kalbasit also reported in that PR that `-i` didn't work for them
anymore on an M1 Mac, presumably because Apple changed something in
newer versions of macOS.
Some users reported that this broke the behavior for them because
`SHELL` was set to a path that didn't even exist on their system. It's
unclear how this came to be but it shows that my assumption that
`SHELL` would be set to a reasonable shell by Home Manager at this
point in the activation is false.
As a way around this problem we can explicitly set `SHELL` when
running the activation script to a value that we know will be good,
like `${pkgs.bash}`.
One change in behavior this causes is that the activation script will
always be run by bash, not the user's shell. If the script is
generated by Home Manager this is fine since it can be generated
taking into account the supported set of functions and behaviors. If
the intent is for the activation script to possibly be run by non-bash
and even non-POSIX shells, like tcsh, ksh or Xonsh, then this fix will
not suffice. Turns out this is indeed an assumption made by Home
Manager, so this is the proper behavior.
Fixes#2900
If the user has enabled the XDG user directories module then we can
use the XDG music directory in the MPD module. Otherwise we'll leave
the option undefined so that the user is forced to define the
directory to use.
This applies to state version 22.11 and above.
Fixes#3225
Instead of referencing the `HOME` environment variable, use the
`home.homeDirectory` option. This allows other modules to reference an
XDG user directory without having to support shell syntax.
Units with
Install.RequiredBy = [ target ]
set will now be linked in the
${target}.requires
directory. Similar to how `Install.WantedBy` already causes a link in
the
${target}.wants
directory.
The `tag.gpgSign` config option was added in Git 2.23.0 and seems like
it should be set in addition to `commit.gpgSign` when
`programs.git.signing.signByDefault` is enabled
The GNU Privacy Guard 2.3 man page for `gpg-agent` describes the
`--grab` and `--no-grab` options as follows:
> Tell the pinentry to grab the keyboard and mouse. This option should
> be used on X-Servers to avoid X-sniffing attacks. Any use of the
> option --grab overrides an used option --no-grab. The default is
> --no-grab.
Therefore Home Manager should explicitly output `grab` when
`cfg.grabKeyboardAndMouse` is true. Previously Home Manager emitted
`no-grab` when `cfg.grabKeyboardAndMouse` was false.
PR #3192
everything is now covered by other settings that are more user friendly
than this big opaque attrset.
Also 'configure' wont do anything with nixpkgs-unstable the way HM
configures neovim. so no need to keep it, the deprecation warning is > 1
year old.
