| Commit message (Collapse) | Author | Age |
|---|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
|
|
|
|
| |
* treewide: remove unused variables
* making ofborg happy
|
| |\
| |
| | |
nixos: allow customizing the kernel RANDSTRUCT seed
|
| | | |
|
| | |
| |
| |
| | |
PR #42838 wrongly started to ignore extraConfig. This fixes that.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This should make the composability of kernel configurations more straigthforward.
- now distinguish freeform options from tristate ones
- will look for a structured config in kernelPatches too
one can now access the structuredConfig from a kernel via linux_test.configfile.structuredConfig
in order to reinject it into another kernel, no need to rewrite the config from scratch
The following merge strategies are used in case of conflict:
-- freeform items must be equal or they conflict (mergeEqualOption)
-- for tristate (y/m/n) entries, I use the mergeAnswer strategy which takes the best available value, "best" being defined by the user (by default "y" > "m" > "n", e.g. if one entry is both marked "y" and "n", "y" wins)
-- if one item is both marked optional/mandatory, mandatory wins (mergeFalseByDefault)
|
| |\ \
| |/
|/| |
linux: flag to indicate 32bit emulation support
|
| | |
| |
| |
| |
| | |
Motivated by the need to warn users trying to build configurations that depend
on being able to run 32bit apps on 64bit kernels.
|
| |/ |
|
| |
|
|
|
| |
Want to get this out of here for 18.09, so it can be deprecated
thereafter.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a string to describe kernel config, use a nix
attribute set, then converted to a string.
- allows to override the config, aka convert 'yes' into 'modules' or
vice-versa
- while for now merging different configs is still crude (last spec wins),
at least there should be only one CONFIG_XYZ value compared to the current string
config where the first defined would be used and others ignored.
[initial idea by copumpkin in 2016, a major rebase to 2018 by teto]
|
| | |
|
| |
|
|
|
| |
Otherwise get the error 'Argument list too long' when running builder
with a very long kernelConfig
|
| |
|
|
| |
- Easy override of autoModules and preferBuiltin and kernelArch parameters (currently living in `hostSystem` set).
|
| |
|
|
| |
and passes parameters in a single set
|
| |
|
|
|
| |
This reverts commit ae040525d8aa01e81ffd1d1c97c908a6e63c819f.
gcc7 is the default now.
|
| | |
|
| |
|
|
|
| |
I expect we will revert this after general upgrade to gcc7.
See https://github.com/NixOS/nixpkgs/issues/34383
|
| |\
| |
| |
| |
| | |
Conflicts:
pkgs/os-specific/linux/kernel/generic.nix
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
common-config.nix has:
${kernelPlatform.kernelExtraConfig or ""}
and indeed kernelExtraConfig is in hostPlatform.platform, and not in
hostPlatform. (Ugh.).
|
| |/
|
|
|
|
|
| |
- defined buildLinux as generic.nix instead of manual-config.nix. This
makes kernel derivations a tad more similar to your typical derivations.
- moved $buildRoot to within the source folder, this way it doesn't have to be created before the unpackPhase
and make it easier to work on kernel source without running the unpackPhase
|
| | |
|
| | |
|
| |
|
|
| |
default
|
| | |
|
| | |
|