All 5 daemon types can be enabled and configured through the module and the module both creates the ceph.conf required but also creates and enables specific services for each daemon, based on the systemd service files that upstream provides.
- split outputs (doc, man, out)
- a new runtime dependency on getconf
- fix up SCRIPTS_DIR in wrapper
- clean output folder of stray doc files
- add license & maintainer
Tested with `nixos/tests/rabbitmq.nix`, inside a docker image and manually.
novacom and novacomd build on aarch64, but the daemon
fails to start with something like:
novacomd[547]: unhandled level 2 translation fault (11) at 0x00000000, esr 0x92000046
So, uh, nevermind that then.
This is unlikely to break and is a cheap test.
I'd like to be notified if it stops working.
If this ever blocks anything and I've been notified
you have my blessing to remove this as I doubt
many folks depend on it.
Currently, when building NixOS from a git clone, Nix has to copy
the entire repo at >1GB into the store by default. That is not
necessary and causes a dumping large path message.
If you need the old behaviour for some reason, you will have to
specify it by passing the path to your repo explicitly as the
nixpkgs argument like this:
--arg nixpkgs '{outPath = ./.; revCount = 56789; shortRev = "gfedcba"; }'
We had problems to get borg's own test suite running.
This test is intended to perform a quick smoke test to see whether we
have missed not any important dependency necessary to create backups
with borg.
tested with:
$ nix-build nixos/release.nix -A tests.borgbackup.x86_64-linux
The existing callSubTests seems to already have special-cased code to
allow enabling subtests on a single specific system by looking at the
`system` attribute in the test arguments. Replace it with a new version
similar to the callTestOnTheseSystems because:
- It's consistent with the existing functions for creating
system-specific tests (though admittedly, the callSubTests special
case for `system` predates them)
- This approach allows limiting to multiple system types, the previous
one inherently allows only one system type.
- This also fixes the problem that if you pass in e.g.
supportedSystems = [ "aarch64-linux" ], you end up with a
tests.chromium job that silently runs on x86_64-linux.
- Finally, this causes renames of the jobs like:
tests.chromium -> tests.chromium.x86_64-linux to be consistent with
the rest of the tests.
Currently, even if you pass supportedSystems = [ "aarch64-linux" ] you
end up with e.g. `nixos.tests.docker` which actually silently runs on
x86_64-linux. Using the new callTestOnTheseSystems fixes that.
As a side-effect, this also causes a rename of
`nixos.tests.docker` -> `nixos.tests.docker.x86_64-linux`, which is IMHO
a good thing since it's makes them consistent with the rest of the
tests.
Currently, even if you pass `supportedSystems = [ "aarch64-linux" ]` you
end up with e.g. `nixos.iso_graphical.x86_64-linux` job. Using
forTheseSystems from release-lib avoids that.
This shouldn't affect the usual x86 trunk-combined jobset.
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.
apps.plugin requires capabilities for full process monitoring. with
1.9.0, netdata allows multiple directories to search for plugins and the
setuid directory can be specified here.
the module is backwards compatible with older configs. a test is
included that verifies data gathering for the elevated privileges. one
additional attribute is added to make configuration more generic than
including configuration in string form.
