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.
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>
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.
The conversion from `concatMapStrings` to `concatStringsSep` introduced in https://github.com/nix-community/home-manager/pull/2481
creates an unintended behavior change where the formatted config does not end in a newline.[1]
This is problematic for manipulation at the Nix level. In particular, this cause a regression in
the generation of gtk2 settings due to concatenated of the formatted config and `gtk2.extraConfig`
without a newline in between.
This commit restores `concatMapStrings` to match the previous behavior and adds a newline to
the final string for the generated gtk2 config. The test case for gtk2-basic-config
was also updated to check behavior at concatenation boundaries.
[1] - https://github.com/nix-community/home-manager/pull/2481#discussion_r830648706
If set to true, desktops configured in `monitors` will be reset every time
the config is run.
If set to false, desktops will only be configured the first time the config is run.
This is useful if you want to dynamically add desktops and you don't want them
to be destroyed if you re-run `bspwmrc`.
Nix permits user level configurations through ~/.config/nix/nix.conf that allow
customization of system-wide settings and behavior. This is beneficial in chroot
environments and for per-user configurations. System level Nix configurations in the
form of /etc/nix/nix.conf can be specified declaratively via the NixOS nix module but as
of currently no counter part exists in home-manager.
This PR is a port of the RFC42 implementation for the NixOS nix module[1]
to home-manager. Non-applicable options have been excluded and the config generation
backends have been tweaked to the backends offered by home-manager. A notable change
from the NixOS module is a mandatory option to specify the Nix binary corresponding
to the version "nix.conf" should be generated against. This is necessary because
the validation phase is dependent on the `nix show-config` subcommand on the host platform.
While it is possible to avoid validation entirely, the lack of type checking was deemed too significant.
In NixOs, the version information can be retrieved from the `package` option itself which
declares the Nix binary system-wide. However in home-manager, there is no pure way to
detect the system Nix version and what state version the "nix.conf" should be generated
against. Thus an option is used to overcome this limitation by forcing the user to
specify the Nix package. Note this interaction can still be automated by forwarding
the system-wide Nix package to the home-manager module if needed.
Three unit tests were added to test the module behavior for the empty settings, the example
settings and the example registry configurations respectively.
[1] - NixOS/nixpkgs#139075
* gtk: add cursor theme configuration
- Added the `cursorTheme` under the gtk module.
- Added tests for the gtk3 settings file generation, and renamed
the gtk2 unit test expected file for clarity.
- Added guard against generating a blank `gtk.css` when `cfg.extraCss`
is empty.
- Replaced `concatMapStrings` calls with `concatStringsSep`. The library function
`concatMapStrings` generates an intemediate list which is then passed to
`concatStringsSep`, As we are not performing other transformation except
the addition of newlines, a direct call to `concatStringsSep` is sufficient.
- Updated description of examples to be more general "~/.config" -> "$XDG_CONFIG_HOME".
- Update helper functions `toGtk3Ini` and `formatGtk2Option` to use the library
function `boolToString` and escape the separator in the key name.
* xcursor: delegate GTK cursor settings to gtk.cursorTheme
- Added deprecation warning for GTK settings in the `xsession.cursorTheme` module.
- Modified config section to use `gtk.cursorTheme` for GTK cursor settings.
This has no effect if the user does not have any aliases defined for
any accounts.
This will also only add `--my-address=` to only accounts that are
enabled to be tracked by mu.
Note, the pubs configuration file uses ConfigObj syntax, which is
similar to the INI files syntax but with extra functionalities like
nested sections. This prevents it from using Nix's INI format
generator. Here is an example of pubs configuration that cannot be
generated using Nix's INI format generator:
[plugins]
[[git]]
manual=False
For this reason, we opted for a stringly-typed configuration since the
use of a structured `settings` option would require a custom parser.
Previously, if a process inside a foot client triggered the OOM killer,
systemd would also kill the parent unit, namely the foot server.
This is not ideal if a user has a lot of clients attached, and it's
usually not the terminal emulator's fault that a process inside it has
ended up using all the available memory.
There seems to be some changes on how wrapped binaries are implemented
on nixpkgs. This broke the nnn tests since the tests were coupled with
the old implementation.
This commit fix the tests, and also make it less coupled by just testing
if the bookmarks/plugins/environment variables are available.
This patch moves both home.sessionVariables and
programs.zsh.sessionVariables from .zshrc to .zshenv. Additionally,
these two kinds of session variables will not be sourced more than
once to allow user-customized ones to take effect.
Before, session variables are in .zshrc, which causes non-interactive
shells to not be able to get those variables. For example, running a
command through SSH is in a non-interactive and non-login shell, which
suffers from this. With this patch, all kinds of shells can get
session variables.
The reason why these session variables are not moved to .zprofile is
that programs started by systemd user instances are not able to get
variables defined in that file. For example, GNOME
Terminal (gnome-terminal-server.service) is one of these programs and
doesn't get variables defined in .zprofile. As a result, the shells it
starts, which are interactive and non-login, do not get those
variables.
Fixes#2445
Related NixOS/nixpkgs#33219
Related NixOS/nixpkgs#45784
This file is not formatted before and is excluded by ./format, so I don't format it.
When an hook is defined, a side effect was the creation of the
${notmuchIni.database.path}/.notmuch/ directory by home-manager. If
the Xapian database does not exist yet but this .notmuch directory
exists, Notmuch is confused and throws an error when `notmuch new` is
run (while this should create the database the first time).
This commit changes the hooks paths to $XDG_CONFIG_HOME where Notmuch
expects them (see notmuch-config(1)) instead of inside the maildir
database directory.
It also moves the configuration where Notmuch expects it, but the
$NOTMUCH_CONFIG environment variable is kept for backward
compatibility.
Watson is a CLI for tracking your time.
Two unit tests were added to validate the module behavior for an empty
configuration and the example configuration.
Based on nixpkgs commit c4b3aa62608d592d8a983be685f7e82000f4de30
stringBool is not needed because makeDesktopItem handles converting boolean parameters to string,
and noDisplay and prefersNonDefaultGPU parameters have been added.
Swayidle is an idle management daemon for Wayland. This modules adds support for
running swayidle as a SystemD user unit and makes it configurable through
home-manager.
The empty configuration test for the bottom module introduced as of https://github.com/nix-community/home-manager/pull/2323
is not cross platform. Specifically, it silently fails under a darwin environment due to
the configuration file not being generated at $XDG_CONFIG_HOME. This PR add cross platform support
by specifying the platform-dependent configuration directories to check. The expected unit test data
was also extracted to a separate file to differentiate between test data changes and
changes to the test itself.
Write YubiKey token IDs in the format yubico_pam expects. See
https://developers.yubico.com/yubico-pam/ for details. Also refer to
the NixOS option security.pam.services.<name>.yubicoAuth.
Closes#2502
The `style` option now also accepts a path instead of a text
configuration.
Keeping up with new Waybar options is annoying, so make the module a
freeform module.
The `modules` option will be removed in release 22.05.
The logic to generate warnings for modules and everything was
removed. I don't want to maintain the code that generates these
warnings anymore.
Since Rofi 1.7.1 (specifically davatorium/rofi@0e70d8a), the deprecated
`theme` option in the `configuration` section no longer works. For 1.7.0
and up, `@theme "name"` is supposed to be used *after* the
`configuration` block.
Swaynag is a replacement of i3-nag for sway. Swaynag is embedded in
Sway's build process albeit it is not an integral part of Sway,
therefore it has been added under `wayland.windowManager.sway` instead
of `programs`. It can be moved at a later time if necessary.
Two unit tests were added validate the module behavior for an empty
configuration and the example configuration.
Add an option to set custom `$ZPLUG_HOME`. Changing it with
`home.sessionVariables` doesnt work, since it has to be exported
before Zplug is initialised
Rationale:
As of release 1.1.2[1], the configuration ini file supports
declaration of the `[main]` header as an alternative to global
properties by enumerating all sections and mapping each to the
respective parsing function. Global properties will still be parsed
correctly by fnott however generation adds unnecessary complexity to
the module. This commit removes the need for global properties
generation.
Changes:
- Fixed the FIXME at L118.
- Cleaned up unneeded let bindings.
- Changed the generation method to use the `pkgs.formats.ini` from
pkgs-lib instead of the raw `generators` library. This was done for
consistency and clarity as the `pkgs.formats.ini` is still required
for type declaration and uses `generators` internally.
- Removed `global-properties` testcase.
- Updated `example-settings` testcase.
[1] - https://codeberg.org/dnkl/fnott/releases/tag/1.1.2
nnn is a terminal file manager.
It is configured mostly using environment variables, so the way I
found it to avoid needing to write either shell specific code or
using `home.sessionVariables` (that would need to make the user
relogin at every configuration change) is to wrap the program using
`wrapProgram`.
This commit adds a module for configuring atuin, a replacement shell
history program.
The module adds options for generating atuin's `config.toml` from Nix,
and options to enable atuin's integration for bash and zsh
(which will rebind history keys to open the atuin history).
* screen-locker: Make xautolock optional, reorganize options
xautolock isn't really needed to trigger xss-lock on the basis of time
since the built-in screensaver functionality of X serves as one of the
event sources for xss-lock. Keeping it around and defaulting to
"enabled" to avoid unexpected breakage.
Also shuffled around the options to submodules for xss-lock and
xautolock to get rid of prefixes in option names and to make
enableDetectSleep a bit clearer.
* screen-locker: update maintainership
* tests/screen-locker: Stub i3lock and xss-lock
* screen-locker: add package options for xss-lock and xautolock
kanshi configurations can have more than one exec statement in a
profile. This change allows services.kanshi.profiles.<name>.exec to be
a list of strings rather than a single string.
This option provides a more convenient way to overlay dummy packages.
It also adds a function `config.lib.test.mkStubPackage` that can,
e.g., be used for `package` options.
Currently, when a custom path is set for any of the XDG base
directories (i.e XDG_DATA_HOME, XDG_CONFIG_HOME, ...), the path will
be coerced into a string when consumed by other options such as
xdg.configFile et al. This causes the the given path to be copied to
the nix store which in the case of xdg.configFile et al, translate to
the file being written there as it is a absolute path.
Interestingly, the default base directories all work as intended as
they are encoded as a string.
This commit converts the option to a string regardless of whether it
is a primitive path or a string encoded path. This allows downstream
consumers to use the base directories in arbitrary way without
accidentally copying the content of the directory to the store. It is
implemented in a similar manner as how home.homeDirectory undergoes
string conversion.
The existing file-attr-name test was modified to test also custom xdg
base directories, and the home.file generation test was removed as
there is a dedicated test for this case in the files module. The test
case was renamed to file-gen to better reflect the new scope.
Bottom is a cross-platform graphical process/system monitor with a
customizable interface and a multitude of features.
Two unit tests were added validate the module behavior for an empty
configuration and the example configuration.
- Change generation behavior to always generate a configuration file
and pass it explicitly to fnott, it enforces the module to be
hermetic instead of offloading the configuration selection to
heuristics.
- Various style changes.
- Fix issue where fnott would abort due to an invalid config file when
both the configFile and settings options are unset.
- Remove the empty-settings test as a configuration file is now
already generated.
Suggested-by: Robert Helgesson <robert@rycee.net>
Fnott is a keyboard driven and lightweight Wayland notification daemon
for wlroots-based compositors.
There are four unit test to validate behavior for an empty
configuration, the default configuration, global properties and
systemd service file generation.
At the moment, only the inbox of each mail account is added to neomutt.
This inbox is always called "Inbox", so if you configure multiple
accounts, it is hard to know which one is which.
This change allows the user to specify a display name per account that
uses `named-mailboxes` under the hood.
Additionally this change now allows to add other folders than the inbox,
for example the Trash, Spam or Drafts folders to be added on a per-account
basis. Using extraOptions is not possible here, as those are lazily
loaded on mailbox open and thus would appear at the bottom and not sorted
by account.
This commit also changes the default sidebar format string to use %D
instead of %B because %B will ignore named mailboxes and show the folder
name instead.
Fluidsynth's systemd unit currently has a hard dependency on the
pulseaudio systemd service. Since fluidsynth can use other sound
services (e.g., pipewire-pulse), this should be configurable. This
commit adds the relevant option.
PR #2238
When the 'fields' setting is not set in htoprc, the htop program won't read any
of the settings. Provide a default value for fields in case it's not explicitly
set by the user.
This adds two new options: 'programs.neovim.coc.{enable,settings}`.
These settings offer a simple interface over `xdg.configFile."nvim/coc-settings.json`,
using the standard Nix' syntax instead of a multiline string.
