Sourcehut went a year with no update in nixpkgs, the packages did not
build for months, the module has issues at runtime, one of the
maintainers stopped using NixOS entirely and the other two don't respond
to issues.
Upstream has since also deprecated the Arch Linux and Debian
repositories to install Sourcehut. The only official way that remains is
Alpine Linux on x86_64-linux.
With networkmanager we can provide a much more welcoming network setup
experience in the installer and it costs us less than 10 MB with this
configuration on the minimal ISO.
By default, for new profiles it will enable DHCP and RA and allow
interactive reconfiguration through `nmtui` or `nmcli`. Especially the
TUI interface is very easy to pick up and removes the need for typing in
manual commands when setting up the WLAN connection.
It is unclear where this list originated, but it doesn't make sense to
ship it with all networkmanager installations. The most excessive plugin
is openconnect, that ships a 250 MB closure including webkitgtk.
Instead users now have to specify the plugins they want explicitly. I
updated the option to give hints on how to find them as best as I can.
There is no point in having a special option to enable strongswan, when
we can just parse the intent from the plugin list instead.
Also pick up relevant runtime dependency information from the plugin
package instead of providing additional options or hardcoding them.
Various issues were introduced in the latest update that required module
changes. This can be attributed to an apparent lack of attention for
which I apologize.
This is the easiest pick for new users to get their footing on NixOS.
NetworKManager allows managing a wide variety of different network
interface types interactively and with ease. It replaces `useDHCP` since
its default profiles for Ethernet and WLAN come with DHCP enabled by
default.
Wrapping programs is commonly done using `symlinkJoin`, which symlinks the man pages to the derivation that is actually installed. `-type f` by itself simply ignores such symlinks.
This fixes postfix' membership in the postfix-tlspol group, since
memberships in a dynamically allocated group don't seem to work out.
Additionally this fixes a typo in the systemd hardening and the test now
prints the results of systemd-analyze security.
This option does not configure sendmail itself because it is impossible
as sendmail is an alias for many things and could mean msmtp or postfix
or exim or something else.
Instead we rely on the PROTOCOL setting as initially proposed #384582
and based on that open up the sandboxing settings because if the user
configures sendmail, they want it to work and not have to configure yet
another things.
Also makes postfix specific things conditional on postfix being enabled
as msmtp does not need them.
Also we can set SENDMAIL_PATH unconditionally as every wrapper I am
aware of uses that path.
Fixes typo in assertion: `initialPromt` -> `initialPrompt`
This typo causes the module to fail with:
```
error: A definition for option `assertions' is not of type `list of unspecified value'. Definition values:
- In `/nix/store/.../nixos/modules/services/home-automation/wyoming/faster-whisper.nix': <function>
```
The typo was introduced in the v2.5.0 update.
When running with a xfs root partition and using systemd for stage 1
initrd, I noticed in journalctl that fsck.xfs always failed to execute.
The issue is that it is trying to use the below sh interpreter:
`#!/nix/store/xy4jjgw87sbgwylm5kn047d9gkbhsr9x-bash-5.2p37/bin/sh -f`
but the file does not exist in the initrd image.
/nix/store/xy4jjgw87sbgwylm5kn047d9gkbhsr9x-bash-5.2p37/bin/**bash**
exists since it gets pulled in by some package, but the rest of the
directory is not being pulled in.
boot/systemd/initrd.nix mentions that xfs_progs references the sh
interpreter and seems to explicitly try to address this by adding
${pkgs.bash}/bin to storePaths, but that's the wrong bash package.
Update the `storePaths` value to pull in `pkgs.bashNonInteractive`
rather than `pkgs.bash`.
These derivation output one or more disk image files and metadata in
JSON, none of which seem to be good targets for patchelf, stripping
or other things that typically happen in fixupPhase.
I noticed that specifically shebang patching took a long time when
building bigger images, roughly doubling build times at times.
This might be due to a traversal of an entire disk images, dozens of
gigabytes in size while looking for interpreters.
All tests in
nix-build -A nixosTests.systemd-repart
passed, but no further testing was done yet.
