Changes the evaluation order in that it evaluates assertions before
warnings, so that eg. the following would work:
{ config, lib, ... }:
{
options.foo = lib.mkOption {
type = lib.types.bool;
default = true;
description = "...";
};
options.bar = lib.mkOption {
type = lib.types.bool;
default = false;
description = "...";
};
config = lib.mkMerge [
(lib.mkIf config.bar {
system.build.bar = "foobar";
})
(lib.mkIf config.foo {
assertions = lib.singleton {
assertion = config.bar;
message = "Bar needs to be enabled";
};
systemd.services.foo = {
description = "Foo";
serviceConfig.ExecStart = config.system.build.bar;
};
})
];
}
This is because the systemd module includes definitions for warnings
that would trigger evaluation of the config.system.build.bar definition.
The original pull request references a breakage due to the following:
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
However, changing the eval order between asserts and warnings clearly is
a corner case here and it only happens because of the aforementioned
usage of warnings in the systemd module and needs more discussion.
Nevertheless, this is still useful because it lowers the evaluation time
whenever an assertion is hit, which is a hard failure anyway.
Introduced by 0f3b89bbed.
If services.nixosManual.showManual is enabled and
documentation.nixos.enable is not, there is no
config.system.build.manual available, so evaluation fails. For example
this is the case for the installer tests.
There is however an assertion which should catch exactly this, but it
isn't thrown because the usage of config.system.build.manual is
evaluated earlier than the assertions.
So I split the assertion off into a separate mkIf to make sure it is
shown appropriately and also fixed the installation-device profile to
enable documentation.nixos.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @oxij
- Use socket-activated epmd - that way there won't be any trouble when
more than one erlang system is used within a single host.
- Use new automation-friendly configuration file format
- Use systemd notifications instead of buggy 'rabbitmqctl wait' for
confirming successful server startup.
'wait' bug: https://github.com/rabbitmq/rabbitmq-server/issues/463
- Use 'rabbitmqctl shutdown' instead of 'stop', because it's not
pid-file based
- Use sane systemd unit defaults from RabbitMQ repo:
https://github.com/rabbitmq/rabbitmq-server/blob/master/docs/rabbitmq-server.service.example
- Support for external plugins
This reverts commit f777d2b719.
cc #34409
This breaks evaluation of the tested job:
attribute 'diskInterface' missing, at /nix/store/5k9kk52bv6zsvsyyvpxhm8xmwyn2yjvx-source/pkgs/build-support/vm/default.nix:316:24
Most importantly, this sets PrivateTmp, ProtectHome, and ProtectSystem
so that Chrony flaws are mitigated, should they occur.
Moving to ProtectSystem=full however, requires moving the chrony key
files under /var/lib/chrony -- which should be fine, anyway.
This also ensures ConditionCapability=CAP_SYS_TIME is set, ensuring
that chronyd will only be launched in an environment where such a
capability can be granted.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
or else at least the following config will fail with an evaluation error
instead of an assert
```
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
```
This reverts commit 67c8c49177.
'nix run nixos.firefox' is *not* supposed to work - the Nix 2.x
interface attempts to standardize on nixpkgs.*, to get rid of the
nixos/nixpkgs confusion that existed with the channels interface. So
let's not bring that confusion back.
Because when I see "config.system.build.manual.manual" after I forgot
what it means I ask "Why do I need that second `.manual` there again?".
Doesn't happen with `config.system.build.manual.manualHTML`.
Without this the graphical installer has no way to open the manual.
You can fix it yourself by installing any HTML browser but this might
be unfamiliar to users new to NixOS and without any other way to open
the manual. The downside is it will also increase download sizes.
Fixes#46537
/run/rmilter is set by systemd, and have root:root ownership, which
prevent pid file to write.
This fix suggested to be promoted to 18.09 branch.
(Although rmilter itself is deprecated, and I plan to remove it, after
18.09 would be released)
Add package libratbag and service module ratbagd
Libratbag contains ratbagd daemon and ratbagctl cli to configure
buttons, dpi, leds, etc. of gaming mice.
Add mvnetbiz to maintainers.
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
This allows the definition of a custom derivation of Exim,
which can be used to enable custom features such as LDAP and PAM support.
The default behaviour remains unchanged (defaulting to pkgs.exim).
1. Simplify the command by reading directly from /etc/machine-id which
is already a random, lower-case hex string
2. Previously, the command output could be too short because of missing
leading digits. This is now fixed.
For update-mime-database to work, you must have to have some mime
packages installed. In some DEs like XFCE this is not guaranteed to
happen. In that case just skip the update-mime-database call.
Fixes#46162
That way the built-in web server is usable by default but users can use
$HOME/web directly (instead of having to use a symlink), if they want to
customize the webpage.
Without a group the gid will default to 65534 (2^16 - 2) which maps to
"nogroup". IMO it makes more sense to explicitly set a valid group.
Adding pkgs.sks to environment.systemPackages is not required (IIRC we
want to avoid bloating environment.systemPackages). Instead it seems
like a better idea to make the relevant binaries available to the user
sks and enable useDefaultShell so that "su -l sks" can be used for
manual interaction (that way the files will always have the correct
owner).
This commit adds the following
* the uucp user
* options for HylaFAX server to control startup and modems
* systemd services for HylaFAX server processes
including faxgettys for modems
* systemd services to maintain the HylaFAX spool area,
including cleanup with faxcron and faxqclean
* default configuration for all server processes
for a minimal working configuration
Some notes:
* HylaFAX configuration cannot be initialized with faxsetup
(as it would be common on other Linux distributions).
The hylafaxplus package contains a template spool area.
* Modems are controlled by faxgetty.
Send-only configuration (modems controlled by faxq)
is not supported by this configuration setup.
* To enable the service, one or more modems must be defined with
config.services.hylafax.modems .
* Sending mail *should* work:
HylaFAX will use whatever is in
config.services.mail.sendmailSetuidWrapper.program
unless overridden with the sendmailPath option.
* The admin has to create a hosts.hfaxd file somewhere
(e.g. in /etc) before enabling HylaFAX.
This file controls access to the server (see hosts.hfaxd(5) ).
Sadly, HylaFAX does not permit account-based access
control as is accepts connections via TCP only.
* Active fax polling should work; I can't test it.
* Passive fax polling is not supported by HylaFAX.
* Pager transmissions (with sendpage) are disabled by default.
I have never tested or used these.
* Incoming data/voice/"extern"al calls
won't be handled by default.
I have never tested or used these.
Take two of #40708 (4fe2898608).
That PR attempted to bidirectionally default `config.nixpkgs.system` and
`config.nixpkgs.localSystem.system` to each be updated by the other. But
this is not possible with the way the module system works. Divergence in
certain cases in inevitable.
This PR is more conservative and just has `system` default `localSystem`
and `localSystem` make the final call as-is. This solves a number of
issues.
- `localSystem` completely overrides `system`, just like with nixpkgs
proper. There is no need to specify `localSystem.system` to clobber the
old system.
- `config.nixpkgs.localSystem` is exactly what is passed to nixpkgs. No
spooky steps.
- `config.nixpkgs.localSystem` is elaborated just as nixpkgs would so
that all attributes are available, not just the ones the user
specified.
The remaining issue is just that `config.nixpkgs.system` doesn't update
based on `config.nixpkgs.localSystem.system`. It should never be
referred to lest it is a bogus stale value because
`config.nixpkgs.localSystem` overwrites it.
Fixes#46320
This adds several improvements the previously introduced
`services.weechat` module:
* Dropped `services.weechat.init` as the initialization script can now
be done on package-level since 2af41719bc using the `configure`
function.
* Added `sessionName` option to explicitly configure a name for the
`screen` session (by default: weechat-screen).
* Added `binary` option to configure the binary name (e.g.
`weechat-headless`).
* Added docs regarding `screen` session and `weechat.service`.
Previously it was only possible to use very simple Riemann config.
For more complicated scenarios you need a directory of clojure
files and the config file that riemann starts with should be in this
directory.
