Rootston is just a reference compositor so it doesn't make that much
sense to have a module for it. Upstream doesn't really like it as well:
"Rootston will never be intended for downstream packages, it's an
internal thing we use for testing." - SirCmpwn [0]
Removing the package and the module shouldn't cause much problems
because it was marked as broken until
886131c243. If required the package can
still be accessed via wlroots.bin (could be useful for testing
purposes).
[0]: https://github.com/NixOS/nixpkgs/issues/38344#issuecomment-378449256
This patch uses the library function `lib.escapeShellArg` to improve
the handling of shell aliases in the NixOS module `bash`, copying the
corresponding change made to the `zsh` module in commit
1e211a70cb (for which GitHub pull
request #47471 was filed).
This patch resolves GitHub issue #16973.
This change presumably also should be copied to the `fish` module, but
I don't know `fish` syntax so that won't be done by me.
GitHub: CloseNixOS/nixpkgs#16973.
The init script slightly differs depending on which shell is in use.
So for bash it should be in the interactiveShellInit as well.
In this case we don't need a mkIf as `bash` is enabled by default
on NixOS.
Previously single quotes were used by default for aliases and the module
never warned about possible collisions when having a shell alias which
relies on single quotes.
Adding `escapeShellArg` works around this fixes the issue and ensures that a
properly quoted value is written to `/etc/zshrc`.
The autojump plugin in oh-my-zsh assumes autojump.zsh resides in
/run/current-system/sw/share/autojump/ but these links are not created
by default.
The new programs.autojump.enable option forces the creation of these
links.
The `pkgs.yabar` package is relatively old (2016-04) and contains
several issues fixed on master. `yabar-unstable` containsa recent master
build with several fixes and a lot of new features (I use
`yabar-unstable` for some time now and had no issues with it).
In the upstream bugtracker some bugs could be fixed on ArchLinux by
simply installing `yabar-git` (an AUR package which builds a recent
master).
To stabilize the module, the option `programs.yabar.package` now
defaults to `pkgs.yabar-unstable` and yields a warning with several
linked issues that are known on `pkgs.yabar`.
The test has been refactored as well to ensure that `yabar` actually
starts (and avoid non-deterministic random success) and takes a
screenshot of a very minimalistic configuration on IceWM.
Fixes#46899
Some programs like eog seem to need dconf accessible on dbus.
Without this change I get
(eog:1738): dconf-WARNING **: 21:20:52.770: failed to commit changes to
dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
ca.desrt.dconf was not provided by any .service files
A shared exported guard `__NIXOS_SET_ENVIRONMENT_DONE` is introduced that can
be used to prevent child shells from sourcing `system.build.setEnvironment`
the second time.
This fixes e.g. `nix run derivation` when run from e.g. ZSH through the console or
ssh. Before this Bash would resource the common environment resetting the `PATH`
environment variable.
We also export `system.build.setEnvironment` to `/etc/set-environment` making it
easy to reset the common environment with `. /etc/set-environment` when
needed and to grep for environment variables in `/etc` (which was the
motivation of #30418).
This reverts changes made in b00a3fc6fd
(the original #30418).
In the last year `programs.oh-my-zsh` gained more complexity and since
the introduction of features like `customPkgs` which builds a
`ZSH_CUSTOM` path from a sequence of derivation a documentation may be
fairly helpful to make the knowledge how to use the module and how to
package new ZSH plugins visible.
See https://github.com/NixOS/nixpkgs/pull/43282#issuecomment-410770432
If multiple third-party modules shall be used for `oh-my-zsh` it has to
be possible to create another env which composes all the packages.
Now it can be done like this:
```
{ pkgs, ... }:
{
programs.zsh.enable = true;
programs.zsh.ohMyZsh = {
enable = true;
customPkgs = with pkgs; [
lambda-mod-zsh-theme
nix-zsh-completions
];
theme = "lambda-mod";
plugins = [ "nix" ];
};
}
```
Please keep in mind that this is not compatible with
`programs.zsh.ohMyZsh.custom`, only one of these options can be used
ATM.
Each package should store its outputs into
`$out/share/zsh/<output-name>`. Completions (and ZSH-only) extensions
should live in the `fpath` (`$out/share/zsh/site-functions`), plugins in
`.../plugins` and themes in `.../themes` (please refer to
fdb6bf6ed68c2f089ae6c729dfeaa3eddea2ce6a and 406d64aad162b3a4881747be4e24705fb5182573).
All scripts in `customPkgs` will be linked together using `linkFarm` to
provide a single directory for all scripts from all derivations in
`customPkgs` as suggested in https://github.com/NixOS/nixpkgs/pull/43282#issuecomment-410396365.
This reverts commit 095fe5b43d.
Pointless renames considered harmful. All they do is force people to
spend extra work updating their configs for no benefit, and hindering
the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by
definition anything in a NixOS module has something to do with NixOS...
The `zsh-autosuggestions` package provides several configuration options
such as a different highlight style (like `fg=cyan` which is easier to
read).
With `rename.nix` the old `programs.zsh.enableAutosuggestions` is still
functional, but yields the following warning like this during evaluation:
```
trace: warning: The option `programs.zsh.enableAutosuggestions' defined in `<unknown-file>' has been renamed to `programs.zsh.autosuggestions.enable'.
```
The module provides the most common `zsh-autosuggestions` (highlight
style and strategy) as options that will be written into the interactive
shell init (`/etc/zshrc` by default). Further configuration options can
be declared using the `extraConfig` attr set:
```
{
programs.zsh.autosuggestions.extraConfig = {
"ZSH_AUTOSUGGEST_BUFFER_MAX_SIZE" = "buffer_size";
};
}
```
A full list of available configuration options for `zsh-autosuggestions`
can be viewed here: https://github.com/zsh-users/zsh-autosuggestions/blob/v0.4.3/README.md
Adds programs.mosh.withUtempter (default: true).
The option enables -with-utempter for mosh, allowing it to write to
/var/run/utmp and thus making connected sessions appear in the output
of `who -a`.
For that, a guid-wrapper is required. Also, the path to the `utempter` was
hardcoded in the resulting binary until now (so it could never been found),
thus, libutempter was patched accordingly to point to
/run/wrappers/bin/utempter which at least works when the wrapper is
configured.
`xsslock` (which was originally packaged in 6cb1d1aaaf)
is a simple screensaver which connects a given screen locker (e.g.
`i3lock`) with `logind`. Whenever `loginctl lock-sessions` is invoked
the locker will be used to lock the screen. This works with its power
management features (e.g. `lid switch`) as well, so the PC can be locked
automatically when the lid is closed.
The module can be used like this:
```
{
services.xserver.enable = true;
programs.xss-lock.enable = true;
programs.xss-lock.lockerCommand = "i3lock";
}
```
Because it improves out-of-the-box user experience a lot (IMHO).
(zsh completion is already on by default.)
Remove "programs.bash.enableCompletion = true" from
nixos-generate-config.pl, which feels superflous now.
Expose the path to a lesskey file as a module option. This makes it
possible to maintain a single lesskey file, used for both NixOS and
non-nix systems. An example of how this can be done follows.
1. Write a derivation that fetches lesskey from a known location:
{ stdenv, fetchgit }:
stdenv.mkDerivation {
name = "foo";
src = fetchgit { .. };
phases = [ "unpackPhase" "installPhase" ];
installPhase = "mkdir -p $out && cp $src/lesskey $out/lesskey";
}
2. Set programs.less.configFile to the corresponding path:
programs.less = {
enable = true;
configFile = "${pkgs.foo}/lesskey";
};
This patch is heavily inspired by bd0d8ed807 which added
a setcap wrapper for `mtr` in order to allow running `mtr` without
`sudo`. The need for the capability `cap_net_raw` that can be registered using
`setcap` has been documented in the Arch Wiki: https://wiki.archlinux.org/index.php/Capabilities#iftop
A simple testcase has been added which starts two machines, one with a
setcap wrapper for `iftop`, one without. Both testcases monitor the
bandwidth usage of the machine using the options `-t -s 1` once, the
machine with setcap wrapper is expected to succeed, the `iftop` on the
machine without setcap wrapper is expected to return a non-zero exit
code.
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
* digitalbitbox: init at 2.2.2
The commits that lead to this have been squashed from independent
commits see branch @vidbina/add/digitalbitbox-wip that did the
following:
- 0a3030fa0ec digitalbitbox: init at 2.2.2
- c18ffa3ffd4 digitalbitbox: moved meta to EOF
- 0c5f3d6972a digitalbitbox: using preConfigure + configureFlags
- a85b1dfc3fd digitalbitbox: nativeBuildInputs
- 90bdd35ef0f digitalbitbox: autoreconfHook
- 91810eea055 digitalbitbox: default installPhase & makeWrapper
- 90e43fb7e2a digitalbitbox: doc rm $PWD hack & printf-tee deal
- fd033b2fe5a digitalbitbox: cleanup, alphabetically sort attrs
- c5907982db3 digitalbitbox: added hardware module
- 88e46bc9ae0 digitalbitbox: added program module
- amend to change name: dbb-app -> digitalbitbox
- amend to add install instructions based on feedback
(https://github.com/NixOS/nixpkgs/pull/33787#issuecomment-362813149)
- amend to add longDescription
- moved program to its own dir
- overridable udev rules handling
- added docs to manual
- added package attr to program module
- added package attr to hardware module
* digitalbitbox: use libsForQt5.callPackage
The default cache directory set by oh-my-zsh is $ohMyZsh/cache which
lives in the Nix store in our case. This causes issues with several
completion plugins provided by oh-my-zsh.
sg and newgrp only changes the current user session and should be
available to users even if the "users.mutableUsers" option is set.
These are common, useful commands.
chfn does modify the /etc/passwd GECOS field which is also controlled
by the option "users.users.<name?>.description", so it's less
appropriate to make it available when "users.mutableUsers" is set.
However, because CHFN_RESTRICT in login.defs is never set in current
NixOS the chfn functionality is never available to users anyway and
may as well have its SUID disabled, as only root is able to use it.
This is recommended in the chfn man page in this case.
To make the configuration of `yabar` more pleasant and easier to
validate, a NixOS module will be quite helpful.
An example config could look like this:
```
{
programs.yabar = {
enable = true;
bars.top.indicators.exec = "YA_DATE";
};
}
```
The module adds a user-controlled systemd service which runs `yabar` after
starting up X.
