With a dependency chain like
a -> b -> c
it was not possible to e.g. add a `meta.problems.removal` to b, because that would cause b to be entirely unavailable as a dependency.
This PR slightly lifts that restriction by allowing both a and b to be marked with such a problem without causing a CI failure.
This is useful for:
- Having a problem on a package that needs to be removed but still has dependents (which then also need a problem)
- Having a problem on a package that is aliased under another attribute, which counts as a dependency
This is very similar to how the aliases.nix overlay can be removed to
prevent usage of them in Nixpkgs itself, but this config attribute
allows preventing use of other existing attributes in Nixpkgs.
Needed for a follow-up commit.
The default stdenvNoCC is constructed via stdenv.override and inherited
the parent stdenv's name verbatim. Every bootstrap stage thus produced
two derivations with identical names (one with a C compiler, one
without), which made bootstrap traces and per-stage drv counts
ambiguous.
Appending '-no-cc' makes each stage's stdenv/stdenvNoCC pair uniquely
identifiable in store paths and graph traces.
When pkgsStatic is already musl, we can let pkgsMusl simply be a no-op.
As the interaction of pkgsStatic and pkgsMusl machinery is currently
broken, this fixes pkgsStatic.pkgsMusl.stdenv.
`appendOverlays []` returned `self` (the unspliced inner fixpoint)
while `import nixpkgs {}` returns `pkgs.__splicedPackages` (the
spliced version). This caused `pkgs.makeWrapper` and similar
spliced packages to lose their `__spliced` attribute after passing
through `appendOverlays`, breaking cross-compilation in NixOS
modules.
The NixOS `nixpkgs.nix` module calls `cfg.pkgs.appendOverlays
cfg.overlays`, and when no overlays are defined, the empty-list
short-circuit returned unspliced packages. This meant
`nativeBuildInputs = [ pkgs.makeWrapper ]` in NixOS modules would
evaluate the host-platform makeWrapper (which throws in cross
context) instead of being spliced to buildPackages.makeWrapper.
Fix by returning `self.__splicedPackages` instead of `self` for
the empty-list case.
this was done manually, fixing the eval and any remaining stuff of the previous commit
together with the previous commit this shouldn't create any rebuilds
For the regular user, this still throws early whenever an attribute
tries to use `pkgsi686Linux`. For CI, this doesn't throw, but instead
overwrites `mkDerivation` to return only derivations marked as
`meta.broken`. This propagates to all reverse dependencies and allows
filtering out these attributes nicely on unsupported platforms.
this equates to -fno-strict-aliasing
this is not a particularly new flag and is supported by all our
gcc and clang versions.
add to pkgsExtraHardening's defaultHardeningFlags.
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.
Darwin includes its SDK in `extraBuildInputs`, which isn’t needed in
`stdenvNoCC` because it depends on a compiler. Including it greatly
increases the size of the `stdenvNoCC` closure (by ~1 GiB).
This wasn’t an issue in the past when darwin included CoreFoundation
because CoreFoundation on its own is very small. Now that it includes
the whole SDK and links some bintools, it pulls in 300~400 MiB for the
SDK plus another ~445 MiB for LLVM.
Fixes#371465
When using pkgsCross with a system that ends up the same as the
localSystem, then modifications for package sets like pksgMusl need to
be done for **both** localSystem and crossSystem. Consider the following
on x86_64-linux:
pkgsCross.gnu64.pkgsMusl
Before this change, this would result in a musl buildPlatform, but a gnu
hostPlatform. This breaks the promise of "stacking" package sets on top
of each other.
After this change, it results in a musl buildPlatform and a musl
hostPlatform. This works better.
One could expect this to result in the same as pkgsCross.musl64, i.e. a
gnu buildPlatform and a musl hostPlatform, however I couldn't get this
to work without increasing memory usage for ci/eval by many, many GB.
This is caused by usage of pkgsi686Linux inside the main package set,
which follows the same hybrid pattern.
The various pkgsXYZ top-level package sets did not pass localSystem /
crossSystem to lower levels, so far. This change propagates original
arguments to lower levels, which include the overrides made by an upper
package sets.
There is an extensive test-suite to test various combinations of package
sets in pkgs/test/top-level. There are a few basic promises made:
- Package sets must be idempotent. pkgsMusl.pkgsMusl === pkgsMusl.
- Once pkgsCross is used any subsequent package sets should affect the
**host platform** and not the build platform. Examples:
- pkgsMusl.pkgsCross.aarch64-multiplatform is a cross compilation from
musl to glibc/aarch64
- pkgsCross.aarch64-multiplatform.pkgsMusl is a cross compilation to
musl/aarch64
- Modifications from an earlier layer should not be lost, unless
explicitly overwritten. Examples:
- pkgsStatic.pkgsMusl should still be static.
- pkgsStatic.pkgsCross.gnu64 should be static, but with glibc instead
of musl.
Exceptions / TODOs:
- pkgsExtraHardening is currently not idempotent, because it applies the
same flags over and over again.
Supersedes #136549Resolves#114510Resolves#212494Resolves#281596
No change, just move appendOverlays and extend to the bottom, since they
will be changed much less often. This makes it easier to compare the
other package sets side-by-side.
pkgsLLVM introduced an unwanted target offset, as can be seen with the
following commands.
Before this commit:
```
$ nix eval --system x86_64-linux -f . pkgsCross.aarch64-multiplatform.buildPackages.stdenv.hostPlatform.config
"x86_64-unknown-linux-gnu"
$ nix eval --system x86_64-linux -f . pkgsCross.aarch64-multiplatform.buildPackages.pkgsLLVM.stdenv.hostPlatform.config
"aarch64-unknown-linux-gnu"
Explaination: These two should be the same, since the only difference
between them is the addition of "pkgsLLVM". The buildPackages of the
pkgsCross set should have a hostPlatform which is the native platform.
```
After this commit:
```
$ nix eval --system x86_64-linux -f . pkgsCross.aarch64-multiplatform.buildPackages.stdenv.hostPlatform.config
"x86_64-unknown-linux-gnu"
$ nix eval --system x86_64-linux -f . pkgsCross.aarch64-multiplatform.buildPackages.pkgsLLVM.stdenv.hostPlatform.config
"x86_64-unknown-linux-gnu"
```
