| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Fixes #296448
|
|
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.
|
|
buildLinux: Fix result derivation overriding with `passthru` via `stdenv.mkDerivation` instead of `lib.extendDerivation`
|
|
|
|
Refactor expression trivially with `lib.toFunction`.
|
|
|
|
|
|
With the current patching situation around enabling Linux to build
with whatever rustc/bindgen version we have in nixpkgs, it feels like
supporting a Rust-by-default build at this time is not fully
justified.
Co-authored-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
|
|
|
|
|
|
linux.configfile: remove unused kernelTarget attr
|
|
|
|
https://github.com/NixOS/nixpkgs/pull/191540 indirectly broke kernel
passthru.tests; calling the testsForLinuxPackages and testsForKernel functions
with some args intended for some other exposed test-internal function.
Organise the passed-through functions under `passthru` to prevent this from
happening.
|
|
As far as I can tell this is unused since f95d214cfdf.
Fixes: f95d214cfdf ("Implement generic kernel build via manual-config")
Fixes: https://github.com/NixOS/nixpkgs/issues/234084
|
|
This reverts commit febe4776287fd81b9dc0fd88a8bcb686765c8a6b.
|
|
This reverts commit 01b36425890182d3a1898c27d479189a7c496646.
|
|
As far as I can tell this is unused since f95d214cfdf.
Fixes: f95d214cfdf ("Implement generic kernel build via manual-config")
Fixes: https://github.com/NixOS/nixpkgs/issues/234084
|
|
With this change, we can do a reasonable default build of Linux for
configurations that do not have a corresponding platforms.nix entry,
and where the user has not explicitly specified the linux-kernel
values. This allows us to do best effort builds for obscure
architectures (I tested a build for s390x).
The platformName binding has not been used since
70cb7050f5c ("Trying to make the linux kernels also cross-build."),
so I removed it.
|
|
All "pc" kernel configurations in lib.systems.examples build fine
without errors when cross compiling.
|
|
Document the `linux.override` way first, then `linuxManualConfig`.
Add a `linux.configEnv` passthru attribute for quickly getting a
`make nconfig`-ready shell.
|
|
Reverts https://github.com/NixOS/nixpkgs/commit/7c7c83e2335c3aa6f26a4f9c905c49c430b5be09 which was
only needed for the minimal-kernel.nix test module and clutters the call site.
stdenv can still be overridden with `linuxManualConfig.override { stdenv = ...; }`.
|
|
|
|
|
|
The kernel checks the version of pahole at configuration time to know
if it supports features like split BTFs. If pahole doesn't exist,
all of that gets disabled in the config file, so the kernel ends up
built without split BTFs, despite having a working pahole for the actual
build.
|
|
|
|
With this change it's ensured that `builtins.unsafeGetAttrPos` actually
points to `<nixpkgs/pkgs/os-specific/linux/kernel/linux-x.y.nix>` when
retrieving the position of `src` or `version` of
`linuxPackages.kernel`.
This is relevant to make sure that ofborg pinging maintainers on kernel updates
actually works[1]. While the underlying issue should be fixed in ofborg
or Nix itself, this is IMHO a pragmatic change to ensure that all kernel
maintainers are automatically notified on updates.
[1] https://github.com/NixOS/nixpkgs/pull/143113#issuecomment-953319957
|
|
Unfortunately, there seems to be no way of referencing an overridable version of
the package you're in, so it had to be stubed to work at all.
This isn't important for our current, very basic kernel nixosTests but might
become important when we add more sophisticated ones.
|
|
|
|
We should be using the _same_ buildPackages when we generate the
configuration (which happens in buildLinux) as when we actually build
the kernel (which happens in linuxManualConfig).
This change enforces that when we callPackage `manual-config.nix` we
pass on whatever `buildPackages` that `buildLinux` itself was called
with.
|
|
This allows users to override custom kernel packages (e.g. linux_xanmod)
that set their own structuredExtraConfig with ease.
|
|
This is just for practicity, as it allows users of buildLinux to pass
along extra flags they need in the kernel's make invocation. This makes,
for example, supporting LLVM _much_ easier, and could enable us in the
future to provide clang-built kernels.
|
|
This enforces that the configuration generated will obey any/all flags
set in the platform/stdenv configuration. This is crucial, for example,
if you'd like to build a kernel using clang.
Without this patch, anything you set in
`stdenv.hostPlatform.linux-kernel.makeFlags` is wholly ignored during
config generation, causing (for example) any changes in the desired
toolchain (e.g. `LLVM`, `LLVM_IAS`) to not be reflected in the generated
config, and for the subsequent build to fail.
|
|
linux: improve cross compilation with clang
|
|
set HOST* variables for host build tools
* do not assume the host compiler is gcc
* pass all build tools to make
|
|
Conflicts:
pkgs/development/python-modules/panel/default.nix
pkgs/os-specific/linux/kernel/generic.nix
pkgs/servers/home-assistant/default.nix
|
|
|
|
|
|
Nixpkgs hasn't supported grsecurity kernels since 2017, so unless
anybody is manually enabling the grsecurity feature to make these
small kernel tweaks this is dead code.
This means we don't actually support any "features" in the kernel
common-config any more, but I've left the argument there because it's
conceivable we could have some again in future.
|
|
Xen is now enabled unconditionally on kernels that support it, so the
xen_dom0 feature doesn't do anything. The isXen attribute will now
produce a deprecation warning and unconditionally return true.
Passing in a custom value for isXen is no longer supported.
|
|
|
|
Second attempt of 8929989614589ee3acd070a6409b2b9700c92d65; see that
commit for details.
This reverts commit 0bc275e63423456d6deb650e146120c39c1e0723.
|
|
This is a stdenv-rebuild, and should not be merged
into master
This reverts commit 8929989614589ee3acd070a6409b2b9700c92d65.
|
|
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
|
|
|
|
|
|
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
|
|
Addresses https://github.com/NixOS/nixpkgs/issues/71803:
Kernel options are not merged as described, especially the "optional"
aspects. The error silences legitimate warnings.
|
|
adds _file so that nix may have a chance to display what file the conflictings settings come
from.
|
|
|
