Updated almost exclusively by r-ryantm. Backports are frequently
missed, and only caught up with after I sort them out, despite me not
using or caring about this package. I don't think linux_lqx is being
maintained to the standards people expect of kernels in Nixpkgs.
Update zfs_unstable as well.
Not changing default zfs yet. This is also to make it easier to backport
this PR while keeping the 25.11 default unchanged.
Since I started touching this subsystem, I found the name confusing
since this is the part where we actually compile the kernel and we have
a ready-to-use configuration.
The stated goal of the commit introducing it[1] is to provide a function
to
> make it possible to build a kernel with a user provided .config.
Considering that this is supposed to be a differentiation from other
build mechanisms and nowadays this is the only way to build kernels in
nixpkgs, I figured that `build.nix` is a better name.
`pkgs.linuxManualConfig` isn't renamed on purpose: Kloenk and I are
planning to do more involved work and it may become necessary to change
parts of the API. So asking users to do a migration now just to add
another one soon isn't worth it.
[1] bf7467cbb1
Presently, we can only override or extend specific versions of
linuxPackages_*. This is not ideal for a overlay which adds a kernel
module or overrides the version for a Linux package because we must
override every version individually. Python has introduced a pattern,
"pythonPackagesExtensions" which is an array of extensions (functions)
to modify a given pythonPackages. CUDA has recently done the same with
_cuda.extensions. Apply this approach to kernelPackages as well.
Closes#447657Closes#447562Closes#447563
Ignoring a kernel and whenever it breaks having somebody pop up to do
the update is NOT an acceptable approach to maintaining a kernel
package.
Since there's apparently not enough interest (which is understandable
because that's a kernel that... just removes things), I think a full-blown
removal is the only way forward.
Also, to be clear upfront: the only future this should have is
maintenance in a downstream-project by somebody caring enough. To me, a
re-add is out of question since it'd contradict the "no new downstream
kernel rule".
When you set the bcachefs userspace tools with:
```nix
boot.bcachefs.package = /* custom pacakge */;
```
This now also changes the kernel package. The NixOS module now calls
on the nested `cfg.package.kernelModule` expression with
`kernelPackages.callPackage`. This will enable overriding both
userspace and kernel space from e.g. upstream git.
There's no reason for us to be packaging old versions of perf. You
don't need to match it with a kernel version. Let's build it from the
latest kernel sources, so it'll get kept up to date.
This attribute was supposed to be set on derivations, to make the
release tools recurse into them. The remaining uses were all on regular
attrsets, though, so this is safe to remove.
EOL upstream.
We only have one hardened kernel at the moment now because
LTS == latest available. This situation would've also happened before
the cleanup since 6.13/6.14 were removed in June already[1].
[1] 23b573705d
