Commit Graph

1206 Commits

Author SHA1 Message Date
Daiderd Jordan
779ec14402 Merge pull request #25921 from dtzWill/feature/llvm-manpages
llvm-4/clang-4: Build and install man pages
2017-05-28 20:29:21 +02:00
Vladimír Čunát
8004e79415
Merge branch 'master' into staging 2017-05-24 03:24:06 +02:00
John Ericson
eaa509f33a stdenv: Rename isGNU to isHurd as GNU is a userland
Elsewhere, things called GNU indeed includes GNU/Linux or GNU/Hurd, but this
predicate was defined excluding Linux regardless of userland.
2017-05-22 13:55:26 -04:00
Frederik Rietdijk
99cfab07b9 Merge remote-tracking branch 'upstream/master' into HEAD 2017-05-22 09:21:40 +02:00
John Ericson
1dc6f15de9 stdenv: define is* predicates with hostPlatform.is*
This is a saner default until stdenv's are removed altogether
2017-05-22 00:25:02 -04:00
John Ericson
c5c6606048 lib: Infer libc field of platform if not specified
This is especially useful when not cross compiling. It means we can
remove the `stdenv.isGlibc` predicate too.

Additionally, use this to simplify the logic to choose the
appropriate libiconv derivation.
2017-05-22 00:25:02 -04:00
Daiderd Jordan
1e23b49f46
darwin-stdenv: allow clang-unwrapped.man 2017-05-21 12:40:07 +02:00
John Ericson
7e096024d7 glibc: Fix for cross 2017-05-19 18:44:24 -04:00
Vladimír Čunát
e9aeb55f3b
Merge branch 'master' into staging 2017-05-18 11:24:18 +02:00
John Ericson
bfa8f30499 linux cross stdenv: Use the cross stdenv and nativeBuildInputs
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.
2017-05-17 15:33:05 -04:00
John Ericson
5870795cc6 linux cross stdenv: Fix eval errors
`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.
2017-05-17 13:42:51 -04:00
Vladimír Čunát
fa5d543770
Merge branch 'master' into staging 2017-05-06 13:24:28 +02:00
Vladimír Čunát
ef5844be6c
stdenv: disable audit-tmpdir on non-Linux for now
Without changing any hashes.
2017-05-06 13:19:07 +02:00
Dan Peebles
c217f59344 darwin.make-bootstrap-tools.test: fix build breakage
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.
2017-05-05 21:34:28 -04:00
Eelco Dolstra
94d164dd7f
Add a setup hook for detecting $TMPDIR references in RPATHs and wrapper scripts 2017-05-04 20:23:57 +02:00
Domen Kožar
e057e5927e Merge pull request #25427 from aneeshusa/fix-meta-priority-types
Fix meta priority types
2017-05-02 09:38:32 +02:00
Aneesh Agrawal
d3acf9891c stdenv: More useful error message on bad meta attrs
This helps in debugging meta attribute type errors,
which are now enforced as of commit
90b9719f4f.
2017-05-02 01:45:30 -04:00
Dan Peebles
f3a05a0fb3 stdenv: disable checkMeta by default until issues resolved
https://github.com/NixOS/nixpkgs/pull/25304#issuecomment-298385426
2017-05-01 13:51:12 -04:00
Michael Raskin
bcbafdefc4 Merge pull request #25035 from elitak/cross-staging
Add some ARM platforms
2017-05-01 13:30:32 +02:00
Eric Sagnes
7004919243 stdenv-generic: add meta attributes checks 2017-04-29 17:07:01 +09:00
Dan Peebles
90b9719f4f treewide: fix the remaining issues with meta attributes 2017-04-29 04:24:34 +00:00
Dan Peebles
1a4ca220e1 treewide: fix assorted issues revealed by the meta checker
Turns out a couple of the licenses were wrong, as well as being strings.
2017-04-28 23:07:42 -04:00
Dan Peebles
32ae4bfc20 stdenv-generic: add meta attribute checking
This is turned off by default but I think we should fix all packages to
respect it and then turn it on by default
2017-04-28 18:12:18 -04:00
John Ericson
761af14778 Merge pull request #25227 from obsidiansystems/cross-purge-binutilsCross
Purge binutilsCross
2017-04-26 09:09:06 -04:00
John Ericson
295315cc87 binutilsCross: Remove and use binutils instead always
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
2017-04-25 21:36:19 -04:00
John Ericson
85b4d30c0b binutils: Respect the targetPlatform
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
2017-04-25 21:31:50 -04:00
John Ericson
6cb0f0bcd9 Merge pull request #25225 from Ericson2314/linux-cross-stdenv-eval
linux cross stdenv: Pull platforms from lib to cut eval time
2017-04-25 20:01:46 -04:00
John Ericson
78bb5f5f37 linux cross stdenv: Pull platforms from lib to cut eval time 2017-04-25 19:57:05 -04:00
John Ericson
75441dd64a Merge pull request #25194 from obsidiansystems/host-target-unconfuse
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!
2017-04-24 19:07:48 -04:00
John Ericson
af6e4c5b0d Merge pull request #25190 from obsidiansystems/ios-stdenv-tiny-refactor
crossStdenv on iphone: Just get info from `targetPlatform`
2017-04-24 16:57:54 -04:00
John Ericson
49c99b70cf cross-stdenv: Only prune most overrides in the final stage
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.
2017-04-24 16:31:53 -04:00
John Ericson
db5a921945 crossStdenv on iphone: Just get info from targetPlatform 2017-04-24 16:12:26 -04:00
Tuomas Tynkkynen
84982c28de Merge remote-tracking branch 'upstream/master' into staging 2017-04-24 15:04:43 +03:00
John Ericson
863d79b364 top-level: Introduce targetPackages and a "double link fold"
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 :)
2017-04-23 14:01:12 -04:00
Eric Litak
c3eca1f8dc platforms: add pogoplug4 (armv5tel softfloat) 2017-04-19 14:09:56 -07:00
Eric Litak
3b7395683c platforms: add scaleway-c1 (armv7 sans NEON) 2017-04-19 14:09:56 -07:00
Frederik Rietdijk
e0abe74baf Merge remote-tracking branch 'upstream/master' into HEAD 2017-04-18 11:25:43 +02:00
Tuomas Tynkkynen
28f87e4141 stdenv: ARM bootstrap: Update bootstrap tarballs to latest hydra-built ones
Fixes sandboxed build of glibc. Discussion about a similar failure on aarch64 at:
8bfa9f528c.

Picked from the following cross-trunk evaluation:
http://hydra.nixos.org/eval/1349278 based on nixpkgs
commit 1f32d4b4eb.

armv5tel job: http://hydra.nixos.org/build/51569718
armv6l job: http://hydra.nixos.org/build/51569717
armv7l job: http://hydra.nixos.org/build/51569713
2017-04-15 01:52:33 +03:00
Vladimír Čunát
f7a4f146c9
Merge branch 'master' into staging
This includes a fix for a bad merge.
2017-04-14 19:22:02 +02:00
Vladimír Čunát
f3ceb764e4
Merge #23374: mkDerivation: simplify non-cross builds
Don't pass buildInputs to stdenv builder in nativeBuildInputs.
2017-04-14 11:01:10 +02:00
Tuomas Tynkkynen
1f32d4b4eb make-bootstrap-tools.nix: Fix bzip2
Apparently our native bzip2 builds switched to using dynamic libraries at some point.
2017-04-13 17:22:55 +03:00
Dan Peebles
72d9016b8b darwin.make-bootstrap-tools: fix to use LLVM 4
This should now roughly match the bootstrap tools we're using on Darwin
2017-04-08 16:38:48 -04:00
Dan Peebles
b9e558597d stdenv-darwin: bump to use LLVM 4.0 & new bootstrap tools 2017-04-07 14:36:21 -04:00
Tuomas Tynkkynen
20d9edff17 stdenv: aarch64: Update bootstrap tarballs
Hopefully fixes sandboxed build of glibc on aarch64, as discussed on
8bfa9f528c.

Picked from the following cross-trunk evaluation:
http://hydra.nixos.org/eval/1341395 based on nixpkgs
commit bb3ef8a95c.

build job: http://hydra.nixos.org/build/50125932

(busybox's hash not changing is not a bug!)
2017-03-15 19:17:52 +02:00
Tuomas Tynkkynen
ce56c99edc mkDerivation: 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.
2017-03-02 03:26:48 +02:00
Graham Christensen
a9c875fc2e
nixpkgs: allow packages to be marked 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.
2017-02-24 07:41:05 -05:00
Graham Christensen
59d61ef34a Revert "nixpkgs: allow packages to be marked insecure" 2017-02-23 09:41:42 -05:00
Graham Christensen
38771badd3
nixpkgs: allow packages to be marked 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.
2017-02-17 20:49:49 -05:00
John Ericson
f6ef6b56fe Merge pull request #22387 from Ericson2314/cross-3-platforms
cross stdenv: let build package's build deps resolve to native packages
2017-02-05 17:41:31 -05:00
John Ericson
5eaea6cee0 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.
2017-02-05 12:01:53 -05:00