Many terminal packages don't cross compile, so the `terminfo`
NixOS module was not usable for nixos configurations that are
cross-compiled.
Terminfo files (AFAIK) are small files that contain data about
terminal capability, so they should never have any runtime
dependencies that would cause any executables or otherwise
incompatible outputs from the `buildPlatform` to leak into the
nixos config's closure.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
resolvconf.conf is a shell script and unlike resolv.conf, multiple
nameservers are specified by space separating them instead of adding
multiple lines.
Fixes: fc060cc3cb
The update-lingering activation script currently fails during rebuilds.
This happens when removing a user with linger enabled.
The call to loginctl disable-linger runs for the non-existent user.
This returns an error code which causes the failure.
To mitigate this, this PR removes any residual linger files.
These are files named for the user in /var/lib/systemd/linger.
A simple check for user existence determines whether to delete the file.
This happens before the call to disable-linger to avoid any errors.
Fixes#283769.
Nix has a suprising behavior where if the option `extra-foo` is set before `foo`, then setting `foo` overwrites the setting for `extra-foo`. This is reported as https://github.com/NixOS/nix/issues/9487, and will likely not be fixed any time soon.
This works around this issue by always putting `extra-*` settings after non-extra ones in the nixos-generated `/etc/nix.conf`.
Follow-up to #269551
Avoid creating a new instance of nixpkgs to access two variables.
`pkgs.pkgsi686Linux` was being accessed whenever the feature is being
used or not.
A second instance of nixpkgs is being created in
`nixos/modules/config/stub-ld.nix` and can be disabled by setting
`environment.ldso32 = null` or `environment.stub-ld.enable = false`.
Both combined fixes this error:
error: attribute 'i686-linux' missing
Portals are global so we can just link them globally.
There might, in theory, be some unexpected system-path contamination
(e.g. when a portal package installs its executables to `/bin`)
but I think the risk is relatively minor compared to the added complexity.
While at it, let’s point the environment variable to system-path.
That will allow changes to installed portals to apply without having to re-log in.
x-d-p only looks for portal definitions in one of two places:
- datadir (which we cannot install anything to, since Nix packages are immutable)
- when `XDG_DESKTOP_PORTAL_DIR` environment variable is set, the path specified therein
(meant for tests, disables looking for portal configuration anywhere else)
Let’s introduce our own `NIX_XDG_DESKTOP_PORTAL_DIR` environment variable
that will only control the portal definitions lookup.
We will not use it for searching for configuration
because it would require looking in the parent directory
and `XDG_CONFIG_DIRS` variable is sufficient for us.
After 4b128008c5 it took me a while in a
test setup to find out why `root` didn't have the password anymore I
declared in my config.
Because of that I got reminded how the order of preference works for the
password options:
hashedPassword > password > hashedPasswordFile
If the user is new, initialPassword & initialHashedPassword are also
relevant. Also, the override is silent in contrast to any other
conflicting definition in NixOS.
To make this less surprising I decided to warn in such a case -
assertions would probably break too much that technically works as
intended.
Also removed the `initialHashedPassword` for `root`. This would cause a
warning whenever you set something in your own config and a `!` is added
automatically by `users-groups.pl`.
`systemd-sysusers` also seems to implement these precedence rules, so
having the warning for that case also seems useful.
