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.
With the release of 2.3.0-rc, we know that 2.3.0 will be coming sometime
soon. Per the [ZFS release policy][1], only the current and previous
releases are expected to be supported, so 2.1.x will become unsupported.
Unfortunately upstream does not have any specific timelines, so we do
not know when it will become unsupported, but when it does we will
likely backport the removal. As such, begin warning of imminent removal.
[1]: 6187b19434/RELEASES.md
The `zfs` alias already has equivalent semantics. Instead, make this
like zfs_2_1 so folks who want to pin a specific release series can do
so easily and clearly to have more control over when more substantial
updates occur.
Rename all tests to match the pkg attr they are testing.
Let's test / on ZFS and /boot on ZFS in separate tests since the GRUB integration for ZFS seems to be not very well maintained.
If the test breaks in the future it's easier to figure out that ZFS on /boot is at fault and either fix the issue or disable the test.
The new test creates a ZFS pool where all features not compatible with GRUB2 are disabled. The dataset is then mounted on /boot and we check that the installer correctly generates a bootable configuration.
Try to use as many ZFS features as possible to verify that GRUB can handle them.
This re-introduces the old stable ZFS version we had in the past following
the many predicted issues of ZFS 2.2.x series, that is much more stable
than any further ZFS version at the moment.
I am also removing myself from maintenance of any further ZFS versions as I am
planning to quit ZFS maintenance at some point.
In the meantime, for users like me who depend on ZFS for critical operations, here is a ZFS version
that is known to work for LTS kernels.
It's better to utilize the boot process and systemd mechanisms to test
these zfs features, rather than manually simulating the same behavior
with testScript.
Right now, the latest kernel is version 5.19, for which there is no
compatible upstream release for ZFS. However, our NixOS VM test always
uses linuxPackages_latest and thus will fail with an evaluation error
most of the time when a new mainline kernel is released.
Since we expose a latestCompatibleLinuxPackages attribute for the ZFS
packages, we already know what's the latest kernel version that is
supported so let's use that instead of linuxPackages_latest.
Signed-off-by: aszlig <aszlig@nix.build>
