This convenience function allows automatic assignment of a package's
associations to `xdg.mimeApps.defaultApplications`.
For example,
xdg.mimeApps.defaultApplications =
config.lib.xdg.mimeAssociations [ pkgs.gnome.evince ];
Co-authored-by: Ryan Trinkle <ryan@trinkle.org>
`modulesPath` is usually used with antiquotation
(`"${modulesPath}/some-module.nix"`). Since antiquoted paths are copied
to the Nix store, one must explicitly do `"${toString
modulesPath}/some-module.nix"` to avoid that. Ideally `modulesPath`
should be a string to avoid this. Note that `modulesPath` is already
defined as a string in <home-manager>/modules/default.nix and
<nixpkgs>/nixos/lib/eval-config.nix.
When processing `publicKeys` entries, handle entries that contain
multiple public keys (i.e. gpg --show-key returns multiple `pub`
lines) properly, setting the trust level for each key.
PR #2897
This makes it a lot easier to access the `pkgs` that would be used to
build the home configuration, e.g.
nix build ./dotfiles#homeConfigurations."user@host".pkgs.vim
This is useful as it allows access to a Nixpkgs that has been
instiantiated with config and overlays.
Removed by upstream since commit:
bcbc410c92
This commit is included since v9 release:
https://github.com/yshui/picom/releases/tag/v9https://github.com/yshui/picom/releases/tag/v9-rc1 (the actual changelog)
While this doesn't break the config per see, it results in the
following warning in the logs:
[ DD/MM/YYYY HH:MM:SS.mmm parse_config_libconfig WARN ] The
refresh-rate option has been deprecated. Please remove it from
your configuration file. If you encounter any problems without
this feature, please feel free to open a bug report
Beside the above change we also remove an old workaround and also
write the configuration file to a well-known location in the user's
home directory.
The code that is being evaled without the `--print-full-init` flag is
this:
```sh
__main() {
local major="${BASH_VERSINFO[0]}"
local minor="${BASH_VERSINFO[1]}"
if ((major > 4)) || { ((major == 4)) && ((minor >= 1)); }; then
source <(/nix/store/...-starship-1.3.0/bin/starship init bash --print-full-init)
else
source /dev/stdin <<<"$(/nix/store/...-starship-1.3.0/bin/starship init bash --print-full-init)"
fi
}
__main
unset -f __main
```
This code checks for bash version >= 4.1 , which has been released in
2009. Since this version is widely unavailable in nixpkgs, we can skip
one program invocation and directly call `starship init bash
--print-full-init`.
This is achieved by generating the Home Manager configuration
file as `~/.config/task/home-manager-taskrc`, and including that
file into ~/.config/task/taskrc.
Fixes#2360
Co-authored-by: mainrs <5113257+mainrs@users.noreply.github.com>
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
* systemd: fix creation of user service unit files
* helix: fix failing test due to file output format change
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
It can happen in some cases that home-manager first runs before gpg
creates its homedir, and it creates it with 755 permissions which the
user then needs to change by hand.
Do this in the module instead: before linking files, make sure the
homedir exists, and if it doesn't, create it with the right permissions.
Changed option types to `either str path` to allow using path values.
The related session variable is defined for the default and the extra
user directories now.
Changing from `sudo -i` to `sudo -s` messes up activation when multiple
users are managed. `--set-home` should have similar behavior to `-i` in
that the activation script is run from the user's home directory.
Fixes#2856
Currently activation is run with `sudo -i` this defaults to the user's
login shell. This can lead to problems if the user's shell isn't set
properly.
By passing `-s` rather than `-i`, `sudo` runs `activate` in `SHELL`
instead. We assume that at this point in the activation `SHELL`
contains the path to a bash in the nix store. This should always be a
valid shell to run the `activate` script with.
From the `sudo` manual it seems like this cannot be fixed if `SHELL`
isn't set at this point or by passing a command to `-s` because that
command is then passed to the user's shell.
This makes definitions like
home.activation.foo = mkIf false "bar"
work, where previously they would complain about
`home.activation.foobar.data` being used but not defined.
The crucial part is that we don't call `convertAllToDags` in
`dagOf.merge`, because we need to process `mkIf`/`mkMerge` properties
first. So we let `attrEquivalent.merge` do its job normally, but give
it a type `dagEntryOf` that does the conversion.
Ideally this shouldn't require so much boilerplate; I'd like to
implement something like
types.changeInto dagContentType elemType dagEntryAnywhere
in Nixpkgs.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Update translation files
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/
Translate-URL: https://hosted.weblate.org/projects/home-manager/modules/
Translation: Home Manager/Home Manager CLI
Translation: Home Manager/Home Manager Modules
Before enabling dconf in Home Manager, dconf must be enabled in system
config.
Otherwise it will fail like this:
```
$ home-manager switch
Starting Home Manager activation
Activating checkFilesChanged
Activating checkLinkTargets
Activating writeBoundary
Activating installPackages
replacing old 'home-manager-path'
installing 'home-manager-path'
Activating dconfSettings
error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit dconf.service not found.
```
