| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
This is a cross derivation---it's built on one platform to run on
another---so let's structure it like all the other cross derivations.
|
|
|
|
|
|
|
|
| |
`pkgsNoParams` was removed by me, but then #25035 was merged using it,
leading to an unbound identifier.
It would be nice to get travis to do build release-cross.nix or
something to catch these things.
|
|
|
|
|
|
|
| |
In the extremely unlikely case that our store hash path ends in several
digits (as is the case right now), the Darwin ld will try to interpret
those digits as a version number and barf. To avoid that, we pass in the
SDK version explicitly to stop it from trying to figure it out from iffy
context.
|
|\
| |
| | |
Fix meta priority types
|
| |
| |
| |
| |
| |
| | |
This helps in debugging meta attribute type errors,
which are now enforced as of commit
90b9719f4fc95e54400a66bffcc8044c568cfa4b.
|
|/
|
| |
https://github.com/NixOS/nixpkgs/pull/25304#issuecomment-298385426
|
|\
| |
| | |
Add some ARM platforms
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| | |
Turns out a couple of the licenses were wrong, as well as being strings.
|
| |
| |
| |
| | |
This is turned off by default but I think we should fix all packages to
respect it and then turn it on by default
|
|\ \
| | |
| | | |
Purge binutilsCross
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
See previous commit for what was done to `binutils` to make this
possible.
There were some uses of `forcedNativePackages` added. The
combination of overrides with that attribute is highly spooky: it's
often important that if an overridden package comes from it, the
replaced arguments for that package come from it. Long term this
package set and all the spookiness should be gone and irrelevant:
"Move along, nothing to see here!"
No hashes should be changed with this commit
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use `buildPackages.binutils` to get build = host != target binutils,
i.e. the old `binutilsCross`, and use
`buildPackages.buildPackages.binutils` to get build = host = target
binutils, i.e. the old `binutils`.
`buildPackages` chains like this are supposed to remove the need for
all such `*Cross` derivations. We start with binutils because it's
comparatively easy.
No hashes of cross-tests should be changed
|
|\| |
| | |
| | | |
linux cross stdenv: Pull platforms from lib to cut eval time
|
| | | |
|
|\| |
| | |
| | |
| | |
| | | |
stdenv.cross is a silly attribute that needs to go leaving the well-defined hostPlatform and targetPlatform. This PR doesn't remove it, but changes its definition: before it tracked the target platform which is sometimes more useful for compilers, and now it tracks the host platform which is more useful for everything else. Most usages are libraries, falling in the "everything else" category, so changing the definition makes sense to appease the majority. The few compiler (gcc in particular) uses that exist I remove to use targetPlatform --- preserving correctness and becoming more explicit in the process.
I would also update the documentation aside mentioning stdenv.cross as deprecated, but the definition given actually erroneously assumes this PR is already merged!
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before all overrides were also pruned in the previous stage, now
only gcc and binutils are, because they alone care about about the
target platform. The rest of the overrides don't, so it's better to
preserve them in order to avoid spurious rebuilds.
|
|\| |
| | |
| | | |
crossStdenv on iphone: Just get info from `targetPlatform`
|
| | | |
|
|\| | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Each bootstrapping stage ought to just depend on the previous stage, but
poorly-written compilers break this elegence. This provides an easy-enough
way to depend on the next stage: targetPackages. PLEASE DO NOT USE IT
UNLESS YOU MUST!
I'm hoping someday in a pleasant future I can revert this commit :)
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes sandboxed build of glibc. Discussion about a similar failure on aarch64 at:
https://github.com/NixOS/nixpkgs/commit/8bfa9f528c88243578246798c7c2ddde045e0de0.
Picked from the following cross-trunk evaluation:
http://hydra.nixos.org/eval/1349278 based on nixpkgs
commit 1f32d4b4eb50a78613cc9a3866c4d50d03fbe2b0.
armv5tel job: http://hydra.nixos.org/build/51569718
armv6l job: http://hydra.nixos.org/build/51569717
armv7l job: http://hydra.nixos.org/build/51569713
|
|\|
| |
| |
| | |
This includes a fix for a bad merge.
|
| |
| |
| |
| | |
Apparently our native bzip2 builds switched to using dynamic libraries at some point.
|
|\ \
| |/
|/|
| | |
Don't pass buildInputs to stdenv builder in nativeBuildInputs.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When not cross compiling, nativeBuildInputs and buildInputs have
identical behaviour. Currently that is implemented by having
mkDerivation do a concatenation of those variables in Nix code and pass
that to the builder via the nativeBuildInputs attribute.
However, that has some annoying side effects, like `foo.buildInputs`
evaluating to `[ ]` even if buildInputs were specified in the nix
expression for foo.
Instead, pass buildInputs and nativeBuildInputs in separate variables as
usual, and move the logic of cross compilation vs. native compilation to
the stdenv builder script. This is probably a tiny bit uglier but
fixes the previous problem.
Issue #4855.
|
| |
| |
| | |
This should now roughly match the bootstrap tools we're using on Darwin
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Hopefully fixes sandboxed build of glibc on aarch64, as discussed on
https://github.com/NixOS/nixpkgs/commit/8bfa9f528c88243578246798c7c2ddde045e0de0.
Picked from the following cross-trunk evaluation:
http://hydra.nixos.org/eval/1341395 based on nixpkgs
commit bb3ef8a95c9659596b8a34d27881cd30ffea2f9f.
build job: http://hydra.nixos.org/build/50125932
(busybox's hash not changing is not a bug!)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a package's meta has `knownVulnerabilities`, like so:
stdenv.mkDerivation {
name = "foobar-1.2.3";
...
meta.knownVulnerabilities = [
"CVE-0000-00000: remote code execution"
"CVE-0000-00001: local privilege escalation"
];
}
and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:
error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate.
Known issues:
- CVE-0000-00000: remote code execution
- CVE-0000-00001: local privilege escalation
You can install it anyway by whitelisting this package, using the
following methods:
a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to
`nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
like so:
{
nixpkgs.config.permittedInsecurePackages = [
"foobar-1.2.3"
];
}
b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘foobar-1.2.3’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:
{
permittedInsecurePackages = [
"foobar-1.2.3"
];
}
Adding either of these configurations will permit this specific
version to be installed. A third option also exists:
NIXPKGS_ALLOW_INSECURE=1 nix-build ...
though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a package's meta has `knownVulnerabilities`, like so:
stdenv.mkDerivation {
name = "foobar-1.2.3";
...
meta.knownVulnerabilities = [
"CVE-0000-00000: remote code execution"
"CVE-0000-00001: local privilege escalation"
];
}
and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:
error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate.
Known issues:
- CVE-0000-00000: remote code execution
- CVE-0000-00001: local privilege escalation
You can install it anyway by whitelisting this package, using the
following methods:
a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to
`nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
like so:
{
nixpkgs.config.permittedInsecurePackages = [
"foobar-1.2.3"
];
}
b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘foobar-1.2.3’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:
{
permittedInsecurePackages = [
"foobar-1.2.3"
];
}
Adding either of these configurations will permit this specific
version to be installed. A third option also exists:
NIXPKGS_ALLOW_INSECURE=1 nix-build ...
though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.
|
|\
| |
| | |
cross stdenv: let build package's build deps resolve to native packages
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the "sliding window" principle:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Vanilla packages: build = native; host = native; target = native;
3. Vanilla packages: build = native; host = native; target = native;
n+3. ...
Each stage's build dependencies are resolved against the previous stage,
and the "foreigns" are shifted accordingly. Vanilla packages alone are
built against themsevles, since there are no more "foreign"s to shift away.
Before, build packages' build dependencies were resolved against
themselves:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Build packages: build = native; host = native; target = foreign;
n+2. ...
This is wrong because that principle is violated by the target
platform staying foreign.
This will change the hashes of many build packages and run packages, but
that is OK. This is an unavoidable cost of fixing cross compiling.
The cross compilation docs have been updated to reflect this fix.
|
| |
| |
| |
| | |
Broken after commit 17a344a ("binutils: Add lib output").
|
|/
|
|
|
|
| |
The former is still respected as a fallback for config.nix for
backwards compatibility (but not for overlays because they're a new
feature).
|
|
|
|
| |
This should fix the NSS build.
|
|
|
|
|
|
|
|
| |
Picked from the following cross-trunk evaluation:
http://hydra.nixos.org/eval/1326772#tabs-still-succeed based on nixpkgs
commit 264d42b9cfc3edf16e945164a45b31185e47422a.
dist job: http://hydra.nixos.org/build/47094514
|
|\
| |
| | |
Aarch64 (ARM64) support
|
| |
| |
| |
| |
| | |
These are temporary and will be switched to Hydra-build ones once all
the aarch4 changs are merged.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Our bootstrap tools are actually broken right now due to busybox not
working when invoked directly from a store path. (It says e.g.
"0qqqw19y4gmknajw8vg4fvhx9gxdqlhz-busybox: applet not found").
Make this test actually fail in such case, the next commit will fix the
problem with busybox.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is required for Aarch64 since a lot of source tarballs ship with
outdated configure scripts that don't recognize aarch64. Simply
replacing the config.guess and config.sub with new versions from
upstream makes them build again.
This same approach is used by at least Buildroot and Fedora. In
principle this could be enabled for all architectures but
conditionalizing this on aarch64 avoids a mass rebuild on x86.
|
| | |
|
|/
|
|
|
| |
This was just done temporarily on the last cross-overhauling PR for
testing purposes.
|
| |
|
| |
|