Currently, you need to override `stdenv.hostPlatform` to request a
compressed kernel on AArch64, and the kernel configuration is split
between the central structured configuration and string snippets in
platform definitions. This has consequently made the latter bitrot
terribly. Since the platform‐specific logic is now very limited after
cleaning up the detritus, we can move it into the kernel derivation
and expose the relevant configuration there for anyone who wants to
customize it further or needs to read it out.
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
This partially reverts commit 845e340ed9.
This re-introduces the `pos` juggling previous done.
The rationale used in the commit was:
> This is long obsolete since the versions are maintained in a JSON
> file now.
That is only accurate for `mainline`. Other in-tree kernels are
maintained in different ways. This led to a loss of information.
Before (cf3f5c4def):
```
nix-repl> linux_latest.meta.position
".../pkgs/os-specific/linux/kernel/mainline.nix:34"
nix-repl> linux_rpi0.meta.position
".../pkgs/os-specific/linux/kernel/linux-rpi.nix:20"
```
After (2fb006b87f):
```
nix-repl> linux_latest.meta.position
".../pkgs/os-specific/linux/kernel/build.nix:558"
nix-repl> linux_rpi0.meta.position
".../pkgs/os-specific/linux/kernel/build.nix:558"
```
This is also observable for out-of-tree kernels:
```
nix-repl> pkgs.linux_jovian.meta.position
".../Jovian-NixOS/pkgs/linux-jovian/default.nix:11"
nix-repl> :r # after updating the Nixpkgs input
nix-repl> pkgs.linux_jovian.meta.position
"/nix/store/xjjq52iwslhz6lbc621a31v0nfdhr5ks-source/pkgs/os-specific/linux/kernel/build.nix:558"
```
This also conveniently works around the root cause of an
`stdenv.mkDerivation`-based `pos` infrec regression when using the
kernel package version in a NixOS configuration to conditionally
apply kernel patches.
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
This is something I introduced in 63185299f4
to make sure the `version`/`src` attributes point to the files that declare
the version such that we get pinged by ofborg for updates.
This is long obsolete since the versions are maintained in a JSON file
now. Also, the kernel team is listed as owner in the ci/OWNERS file for
the entire subtree, so we definitely get pinged by CI nowadays.
Hence, remove the hackery.
This reverts commit ddaa949afe.
This was reverted as part of a bulk revert of all kernel changes in a
certain time period — as far as I know there was no actual
justification for reverting this change in particular. The original
rationale for making this change stands: it's nice for new platforms
not to have to copy the defaults over and over in
lib/systems/platforms.nix.
When enableCommonConfig is set to false, we should limit the config
options that are implicitly enabled. extraConfig for
aarch64-multiplatform brings in platform-specific configuration and
limits the ability to create a trimmed down kernel configuration for a
particular board.
PR #431115 changed extraStructuredConfig to structuredExtraConfig to
follow the deprecation warning about `extraConfig`. However,
`extraStructuredConfig` was mentioned in several places in the docs that
weren't addressed. Also, using this would silently fail since the code
in question would still accept the old key.
This patch updates the docs accordingly and throws an error if the
code-path is reached and `extraStructuredConfig` is being used.
The .unwrapped attributes are not correctly spliced. Use the top
level attributes instead, which are spliced correctly.
Fixes: e9b2edb491 ("linux: un-simplify toolchain selection")
If we're going to use the unwrapped versions, we should do so
consistently in both parts of the kernel build, not mix and match.
Fixes: e9b2edb491 ("linux: un-simplify toolchain selection")
This reverts commit 70cc251554.
This commit caused gcc to be pulled in as a target compiler for
pkgsLLVM.
Co-authored-by: Tristan Ross <tristan.ross@midstall.com>
Asserting the hostplatform for `linux` is bad, because it can't be
caught by CI. For the `linux` package itself, it doesn't make a
difference, because it also has `meta.platforms = linux` set, so this
will fail evaluation - and in a way that can nicely be caught by CI.
The dependencies pkg-config and ncurses are for building tools to use on
build, so they should be depsBuildBuild.
This fixes "make $makeFlags nconfig" for cross.
Currently, kernel update scripts can't be triggered, given that
`passthru` doesn't propagate to the [final
passthru](59138c7667/pkgs/os-specific/linux/kernel/generic.nix (L300)).
This change introduces `extraPassthru` for properly propagating it.
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.
The ongoing RISC-V breakage may become version independent in the
future, move it to the correct condition before updating it with the
full list of supported architectures.
While at it, simplify the remaining rustc-specific conditions into an
`availableOn`.
It's not a nice experience to wait for a kernel build, only to notice
the options you set didn't actually do anything, because Nixpkgs'
kernel configuration script just prints a warning if an option that
should have been set isn't set in the final kernel config.
Ideally, I think we'd never allow config errors, but we certainly
don't have to torelate them for aarch64, when CI for kernel changes
can ensure we don't accidentally break the build with x86-specific
options.
I've tested that configuration of all mainline kernels still works on
aarch64.
Override `finalAttrs.finalPackage` instead of `kernel` from the let-in
block to make configEnv behave in accordance with overrideAttrs of the
result package.
Continuation of commit f10331cf2e ("buildLinux: passthru by
<pkg>.overrideAttrs instead of lib.extendDerivation")
When we set CROSS_COMPILE to set the toolchain prefix, everything
works out of the box without using absolute paths everywhere. This
removes a lot of duplication from the kernel derivations.
Even when building with pkgsLLVM.stdenv where ld is ld.lld and not
binutils ld, the build picks up binutils ld for linking. This prevents
features from working that require ld.lld.
The reason is that when the LD environment variable is not set, Linux
defaults to `ld` as a linker and ld is:
/nix/store/zznja5f8v3jafffyah1rk46vpfcn38dv-gcc-wrapper-13.3.0/bin/ld
GNU ld (GNU Binutils) 2.42
This ld comes from pkgsLLVM.buildPackages.stdenv.cc.
Fix by being more specific about which tools we want to build with.
This just extends what manual-config.nix has already done for quite a
while to avoid similar problems for other tools.
It's important to pass LD and other toolchain environment variables to
`make config` in generate-config.pl, because otherwise `make config`
will also make decisions based on the wrong toolchain.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
This was added for use by ZFS, but it turned out that `pname == "linux"`
is sufficient enough and has better coverage since many of our Linux
variants do not have an existing `passthru.isX`, and instead are
identifiable by a different pname.
For use by consumers that want to iterate over all Linux Kernel packages
to, e.g., find the latest “vanilla” version that matches some version
constraint. (E.g. This will soon be used by ZFS’s
latestCompatibleLinuxPackages)
Linux kernel drvs were all just "linux-x.y.z". This allows variants to
distinguish themselves in package names (i.e. "linux-libre").
Repology uses pname for matching
https://github.com/repology/repology-rules/issues/445. This should fix our
kernel variants not showing up on Repology.
Currently things like `buildLinux { inherit src version; }` fail because of
`callPackage` auto-inserting `kernelPatches`, which is both a `buildLinux`
argument and a `pkgs` toplevel attribute, with completely different semantics.
Avoid that entirely by splitting the call into two - one for arguments we want
from `callPackage`, and one for everything else.
