The user information would have helped diagnose the empty GECOS issue
we had with the Hydra Darwin builders recently and the OS information
seems generally nice to have.
Hydra can handle packages that `throw` but not attributes that
disappear depending on platform, and it seems okay for evaluation to
fail here for non‐Linux platforms.
This is some thing introduced in 2017 to work around a problem that
no longer seems to exist. Nothing uses it except its own test, which
these days passes even with the standard `clangStdenv`.
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"
```
gcc-4.9.4 was released in Aug 3, 2016, 8 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
This is to ensure that Haskell users on platforms that lack official
bindists still have a convenient means of getting GHC running natively.
In my admittedly somewhat limited testing on RISC-V, GHC 8.10.7 is able
to bootstrap native builds for 9.2.8 and 9.4.5. GHC 9.2.8 and 9.4.5 are
unable to bootstrap themselves and 9.6.2 when cross-compiled.
If you're looking at this commit to see whether you can safely upgrade
the compiler used here to remove 8.10, please try cross-compiling 9.0 or
later and then booting a native GHC with it.
Everything gets moved into the `ci/` top-level directory.
We keep behind `maintainers/scripts/check-by-name.sh` and `pkgs/test/check-by-name/pinned-version.txt` as they are going to cause CI errors and confusion until we get all the way through the various channels.
They'll be removed in about a week or so.
Rationale: Since RFCs 140 and 146, the old category-based hierarchy is
deprecated and obsolete, and a new approach took place: packages should be as
self-contained as possible.
This paradigm is reflected in many new strict checks that prohibit a package to
refer to files outside its directory tree.
Following this spirit, this commit essentially moves nixpkgs
pkgs/test/default.nix to ./tests/default.nix.
Further, to keep the top-level `tests` attribute, a green alias is kept in the
place of older file.
The generated file sets its own directory as the source, including the
generated file itself, which causes rebuilds when that file is
reformatted. We can avoid this by overriding the source with a filtered
version and using that throughout the tests.
See https://github.com/NixOS/nixpkgs/pull/320572 for more context
The source included way more files than it really needed.
This commit limits it to exactly those it needs.
This also makes sure that no rebuild is necessary when any Nix
file changes, in particular useful when we reformat the Nix files.
The previously used pattern was introduced in #318614, but technically
leaked the default flags into the global scope. While this would
probably not make much of a practical difference, making concatTo
support default values is a much cleaner approach.
