We take the idris2 projects version of the derivation. Originally,
Idris2 did not maintain their own nix derivation, so we created our
own. Now they maintain their own derivation, so we should try to
keep ours as close to theirs.
This change comes with the following differences:
* support files are in its own output, instead of packaged with idris2
- This makes it necessary to provide --package for contrib and network
!!! This is a breaking change !!!
* IDIRS2_PREFIX is set to ~/.idris2 instead of pointing to nix-store
- This makes --install work as expected for the user
* Properly set IDRIS2_PACKAGE_PATH
* non-linux platform uses chez-racket instead of chez
This renames our `firmwareLinuxNonfree` package to `linux-firmware`.
There is prior art for this in multiple other distros[1][2][3].
Besides making the package more discoverable by those searching for the
usual name, this also brings it in-line with the `kebab-case` we
normally see in `nixpkgs` pnames, and removes the `Nonfree` information
from the name, which I consider redundant given it's present in
`meta.license`.
The corresponding alias has been added, so this shouldn't break
anything.
[1]: https://archlinux.org/packages/core/any/linux-firmware/
[2]: https://src.fedoraproject.org/rpms/linux-firmware
[3]: https://packages.gentoo.org/packages/sys-kernel/linux-firmware
This is a useful utility for monitoring network performance over time
using a combination of MTR and Prometheus. Also adding a service definition.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Previously we allocated subuids automatically for all normal users.
Make this explicitly configurable, so that one can use this for system
users too (or explicitly disable for normal users). Also don't allocate
automatically by default if a user already has ranges specified statically.
When startWhenNeeded is enabled, a brute force attack on sshd will cause
systemd to shut down the socket, locking out all SSH access to the machine.
Setting TriggerLimitIntervalSec to 0 disables this behavior.
a few things should've used buildPackages/nativeBuildInputs to not not require
the host architecture for building docs. tested by building aarch64-linux docs
on x86_64-linux, and the result looks good.
In https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/153
the user target names for GSD components has been renamed for example
from `gsd-a11y-settings.target` to `org.gnome.SettingsDaemon.A11ySettings.target`,
and nowadays `gsd-*.target` are just symbolic links of `/dev/null` and will be
removed in the future.
At the same time, as mentioned in d27212d466,
we are adding `systemd.user.targets.<name>.wants` stuff here only because
systemd.packages doesn't pick the .wants directories. Nowadays those GSD components
are managed in `/etc/systemd/user/gnome-session@gnome.target.d/gnome.session.conf`
so it should be safe to remove them.
In this commit we also try to pick up those new .wants directories, see also
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/41.0/plugins/meson.build#L57
Result of `cd /nix/store/iqzy2a6wn9bq9hqx7pqx0a153s5xlnwp-gnome-settings-daemon-41.0; find | grep wants`:
```
./share/systemd/user/gnome-session-x11-services-ready.target.wants
./share/systemd/user/gnome-session-x11-services-ready.target.wants/org.gnome.SettingsDaemon.XSettings.service
./share/systemd/user/gnome-session-x11-services.target.wants
./share/systemd/user/gnome-session-x11-services.target.wants/org.gnome.SettingsDaemon.XSettings.service
```
Result of `cd /nix/store/armzljlnsvc1gn0nq0bncb9lf8fy32zy-gnome-settings-daemon-3.34.0; find | grep wants`:
```
./lib/systemd/user/gnome-session-initialized.target.wants
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-a11y-settings.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-color.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-datetime.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-power.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-housekeeping.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-keyboard.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-media-keys.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-screensaver-proxy.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-sharing.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-sound.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-smartcard.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-wacom.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-print-notifications.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-rfkill.target
./lib/systemd/user/gnome-session-initialized.target.wants/gsd-wwan.target
./lib/systemd/user/gnome-session-x11-services.target.wants
./lib/systemd/user/gnome-session-x11-services.target.wants/gsd-xsettings.target
```
This never configured where SNI should log to, as it's up to the user to
provide the full sniproxy config (which can be configured to log to a
file).
This option only produced a ExecStartPre script that created the folder.
Let's use LogsDirectory to create it. In case users want to use another
directory for logs, they can override LogsDirectory or set their own
ExecStartPre script.
