It's expected that attributes in the top-level package set will all use
that package set, but this wasn't the case for the bootstrap tools.
This led some very confusing behaviour:
- pkgsMusl.stdenvBootstrapTools would build glibc bootstrap tools
- stdenvBootstrapTools was _always_ cross compiled, even if
Nixpkgs wasn't, because it always set crossSystem. This also didn't
match the behaviour of using make-bootstrap-tools.nix as an
entrypoint, where crossSystem would default to null.
For the Linux stdenv, I've made the ideal fix, which is to make pkgs an
argument rather than taking the arguments for pkgs, and then
re-importing it. This means it'll always use exactly the same package
set that's calling it, and should also mean faster eval due to not
importing Nixpkgs twice.
The Darwin stdenv is more complicated, and I'm not able to easily test
it, so I wasn't confident in making the same fix there. Instead, I've
just made sure crossSystem and localSystem are set to the correct values
so they're not always cross compiled and match the parent package set's.
It would still be preferable if somebody could make Darwin's
make-bootstrap-tools.nix take pkgs as an argument, rather than all the
arguments for pkgs.
it may be what the license handling code does, but it's confusing and not very useful
Co-authored-by: Adam Joseph <54836058+a-m-joseph@users.noreply.github.com>
These servers apparently no longer exist, since September 2, 2021[1].
If somebody needs this for non-Scaleway machines, they should suggest
its reintroduction with a different name.
[1]: https://news.ycombinator.com/item?id=27192757
Instead of requiring the platforms be equal, use `isCompatible` to
determine if we can execute tests. The upside of this is that we now
can execute tests for natively cross compiled package sets like
pkgsStatic, pkgsLLVM and pkgsCross.musl64 etc.
canExecute is like isCompatible, but also checks that the Kernels are
_equal_, i.e. that both platforms use the same syscall interface. This
is crucial in order to actually be able to execute binaries for the
other platform.
isCompatible is dropped, since it has changed semantically and there's
no use case left in nixpkgs.
the motivation for this is to simplify stdenv and ease the job of
reviewers due to them needing to tell contributors about the defacto
rule that configureFlags should be a list of strings
stdenv: deprecate addCoverageInstrumentation adapter
this used to be used in nixos/tests but it hasn't been used in nixpkgs
for years
stdenv: deprecate replaceMaintainersField adapter
it was added in 2009 in 01e98e49b1
by nbp
there are no uses of it in nixpkgs now
stdenv: deprecate validateLicenses adapter
it was added in 2009 in b29073af25
unfreePredicate is now handled in ./pkgs/stdenv/generic/check-meta.nix
so this is unnecessary
This warning logs when a package has no maintainers. It will stay silent
if `meta.maintainers` is not set at all, only complaining when it is an
empty list. In the future a separate warning could be added to allow for
that stricter behavior. Or this warning could be changed.
This will allow for adding more validity types in the future, such as a
warning type. (which is in the next commit in this series)
This is NOT a breaking change because validity.valid is never exposed
outside of `stdenv.mkDerivation`.
This PR adds Hydra-generated bootstrap tarballs for powerpc64le-linux.
I'll be following the script established in PR to tarballs.nixos.org.
Files came from this Hydra build:
https://hydra.nixos.org/build/172142499
Which used nixpkgs revision 49a83445c2
to instantiate:
/nix/store/gj272sd56gsj6qpyzh4njpfzwdhviliz-stdenv-bootstrap-tools-powerpc64le-unknown-linux-gnu.drv
and then built:
/nix/store/n81pljbd8m0xgypm84krc2bnvqgjrfxx-stdenv-bootstrap-tools-powerpc64le-unknown-linux-gnu
I downloaded these files from Hydra with the following commands:
```
STOREPATH=n81pljbd8m0xgypm84krc2bnvqgjrfxx-stdenv-bootstrap-tools-powerpc64le-unknown-linux-gnu
OPTIONS="--option binary-caches https://cache.nixos.org"
nix store add-file \
--name bootstrap-tools.tar.xz \
$(nix-store ${OPTIONS} -r /nix/store/${STOREPATH})/on-server/bootstrap-tools.tar.xz
nix store add-path \
--name busybox \
$(nix-store ${OPTIONS} -r /nix/store/${STOREPATH})/on-server/busybox
```
As @lovesegfault requested in #151399, here are the the `sha256sum`s
of all the `on-server` components for extra verification:
```
$ sha256sum /nix/store/n81pljbd8m0xgypm84krc2bnvqgjrfxx-stdenv-bootstrap-tools-powerpc64le-unknown-linux-gnu/on-server/*
036d062869f7accf0ad89714d12029469dfe6af504f9b226d61eb7d808ad4735 /nix/store/n81pljbd8m0xgypm84krc2bnvqgjrfxx-stdenv-bootstrap-tools-powerpc64le-unknown-linux-gnu/on-server/bootstrap-tools.tar.xz
6bc05832180f5075f4458c32eb0a5e2b673f605884dce01822be474f4e0a63ee /nix/store/n81pljbd8m0xgypm84krc2bnvqgjrfxx-stdenv-bootstrap-tools-powerpc64le-unknown-linux-gnu/on-server/busybox
```
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
This isn't really desirable in general, but given that Nix itself
currently relies on this behaviour and that we don't want to break
backwards compatibility we should support it for now, maybe
deprecating it in the future.
This reverts commit c1ef87e8d0.
I didn't realize that it would rebuild all linux stdenvs;
I certainly don't want to incur such a rebuild at this point.
