This reverts commit 3838a0a7e7.
This was previously used on aarch64-unknown-linux-musl, but now that
that platform has an up-to-date bootstrap and can build current
patchelf, there's no longer any need to keep this around.
This reverts commit e22d0b49a9.
No longer needed now that we have an up-to-date
aarch64-unknown-linux-musl bootstrap.
Since the original commit, patchelf_0_14 was renamed to
patchelfStable. There's no longer any need for it to have a name
other than "patchelf", but I've kept "patchelfStable" around as an
alias in case anybody's using it.
This PR applies the patches which fix a MIPS-specific bug in patchelf.
The patches are applied only if targetPlatform.isMips in order to:
1. Not cause a mass-rebuild on the mainstream platforms
2. Make this PR acceptable for inclusion in `master` rather than
`staging`.
This is the very last commit needed in order for Hydra to be able to
produce a bootstrap-files tarball for mips64el (the other one is in
`staging-next`).
This PR can be reverted after the next release of patchelf lands in
nixpkgs.
The C++ compiler in our musl bootstrap for aarch64 is too old to build
the latest version of patchelf, so we need to use the latest version
that builds with that compiler to get a new bootstrap.
The C++ compiler in our musl bootstrap for aarch64 is too old to build
the latest version of patchelf, so introduce a package for the most
recent version it's capable of building that we can use to get a new
bootstrap.
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).
This is a partial revert of #58715. Bumping the default caused problems
described in #69213. I tested that the vscode corruption happened even
with the 0.10 pre-release, so I'm keeping patchelfUnstable on 0.10
(patchelfUnstable shouldn't cause a large rebuild anyway)