Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
(branch-equivalent to commit 374e6bcc40)
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev 0128fbb0a5
result/bin/apply-formatting $NIXPKGS_PATH
`pkgs.zfs_unstable` is pre-release software and may very well have
critical bugs that make it unsuitable for general use. As such, we
should not recommend it as a general solution to the problem of "my
Kernel is too new for stable ZFS".
The fully-qualified name would certainly be a lot here, but `with` can
still be unclear even with narrow scope. A short `let` adds clarity
without significantly increasing verbosity.
This was incorrectly getting `lib.version` which is e.g.
`"24.11pre-git"`, but should have been the ZFS package version. However,
the condition, at least per the comment, is reversed and should be
instead `versionOlder cfgZfs.package.version "2.2.0"`. However, the
entire premise seems to be incorrect, as ZFS 2.2.6 includes the spl
module. Since the previous condition here was effectively always true,
it would initially seem the best move is to remove the conditional
altogether and always include the spl kmod. However, going back to
4360a87c45 where this condition was added,
the intent appears to be that spl was no longer needed here in
the-pre-release ZFS (long since in all supported versions), due to it
being merged into ZFS mainline. Given that intent and that our boot
tests on all versions succeed without including it in the initrd, remove
it.
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.
services.nfs.settings is added for options that go into /etc/nfs.conf.
There are services.nfs.server.extraNfsdConfig and
services.nfs.extraConfig, but they have drawbacks. They overlap in
scope (nfs.extraConfig can also add nfsd options). They require that one
writes INI syntax. They often produce nfs.conf files with duplicate
section names, which is confusing.
This deprecates services.nfs.server.extraNfsdConfig and
services.nfs.extraConfig.
services.nfs.settings cannot be used together with
services.nfs.server.extraNfsdConfig or services.nfs.extraConfig.
This just adds complexity and confusion. Once-upon-a-time, there was no
`package` and only `enableUnstable`, but now it is just confusing to
have both, as it would be possible to do e.g. `package = pkgs.zfs` and
`enableUnstable = true`, but then `enableUnstable` does nothing.
This adds compatibility with newer kernels, which fixes
nixosTests.zfs.series_2_1, which broke when the default kernel version
was bumped.
This means we no longer need the removeLinuxDRM option at all, but
I've kept it around as a no-op so people can leave it set in case the
same thing happens again in future.
ZFS no longer tries to use GPL-only symbols on aarch64.
Tested by building nixosTests.zfs.stable (modified to use Linux 6.6)
and nixosTests.zfs.unstable.
this lets us *dis*able filesystem explicitly, as is required by e.g. the
zfs-less installer images. currently that specifically is only easily
possible by adding an overlay that stubs out `zfs`, with the obvious
side-effect of also removing tooling that could run without the kernel
module loaded.
Encountered boot errors in pool with `listsnapshots=on` getKeyLocations should ignore snapshots as they will not be well-handled by createImportService later on
When `config.boot.zfs.enableUnstable` is set to true, grub was built with the `zfs` package even though the rest of the system uses the `zfsUnstable` package.
The effect of this can only be seen when `zfs` and `zfsUnstable` actually differ (which is not currently the case), for example when overriding one of them locally.
This simplifies the setup to receive emails from the ZFS Event Daemon
by relying on the sendmail wrapper defined by other modules such as
msmtp or Postfix.
This is more similar to how other modules like smartd deal with email
configuration.
The user is no longer required to define and rebuild their own ZFS
package to add email support.
GitHub: closes https://github.com/NixOS/nixpkgs/issues/132464
