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
As proposed in #346018 (not closing the ticket, this affects other
variants as well).
The packaging for hardened is in a pretty sad state: it was lagging
several patch-releases behind and nobody seems to care. The update
script aged poorly: the automatic removal was flat-out broken, several
type annotations are plain wrong (`list[int] != packaging.Version`).
This patch is an attempt to reduce the scope for the maintainer team
drastically to provide _some_ maintenance again by only packaging latest
LTS and latest stable.
Also, remove the top-level attributes for this. I still don't see any
compelling reason to give hardly used flavours that special treatment.
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.
