summary refs log tree commit diff
path: root/pkgs/stdenv
Commit message (Collapse)AuthorAge
* darwin.make-bootstrap-tools.test: fix build breakageDan Peebles2017-05-05
| | | | | | | 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.
* Merge pull request #25427 from aneeshusa/fix-meta-priority-typesDomen Kožar2017-05-02
|\ | | | | Fix meta priority types
| * stdenv: More useful error message on bad meta attrsAneesh Agrawal2017-05-02
| | | | | | | | | | | | This helps in debugging meta attribute type errors, which are now enforced as of commit 90b9719f4fc95e54400a66bffcc8044c568cfa4b.
* | stdenv: disable checkMeta by default until issues resolvedDan Peebles2017-05-01
|/ | | https://github.com/NixOS/nixpkgs/pull/25304#issuecomment-298385426
* Merge pull request #25035 from elitak/cross-stagingMichael Raskin2017-05-01
|\ | | | | Add some ARM platforms
| * platforms: add pogoplug4 (armv5tel softfloat)Eric Litak2017-04-19
| |
| * platforms: add scaleway-c1 (armv7 sans NEON)Eric Litak2017-04-19
| |
* | stdenv-generic: add meta attributes checksEric Sagnes2017-04-29
| |
* | treewide: fix the remaining issues with meta attributesDan Peebles2017-04-29
| |
* | treewide: fix assorted issues revealed by the meta checkerDan Peebles2017-04-28
| | | | | | Turns out a couple of the licenses were wrong, as well as being strings.
* | stdenv-generic: add meta attribute checkingDan Peebles2017-04-28
| | | | | | | | This is turned off by default but I think we should fix all packages to respect it and then turn it on by default
* | Merge pull request #25227 from obsidiansystems/cross-purge-binutilsCrossJohn Ericson2017-04-26
|\ \ | | | | | | Purge binutilsCross
| * | binutilsCross: Remove and use `binutils` instead alwaysJohn Ericson2017-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | binutils: Respect the targetPlatformJohn Ericson2017-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge pull request #25225 from Ericson2314/linux-cross-stdenv-evalJohn Ericson2017-04-25
|\| | | | | | | | linux cross stdenv: Pull platforms from lib to cut eval time
| * | linux cross stdenv: Pull platforms from lib to cut eval timeJohn Ericson2017-04-25
| | |
* | | Merge pull request #25194 from obsidiansystems/host-target-unconfuseJohn Ericson2017-04-24
|\| | | | | | | | | | | | | | 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!
| * | cross-stdenv: Only prune most overrides in the final stageJohn Ericson2017-04-24
| | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #25190 from obsidiansystems/ios-stdenv-tiny-refactorJohn Ericson2017-04-24
|\| | | | | | | | crossStdenv on iphone: Just get info from `targetPlatform`
| * | crossStdenv on iphone: Just get info from `targetPlatform`John Ericson2017-04-24
| | |
* | | Merge remote-tracking branch 'upstream/master' into stagingTuomas Tynkkynen2017-04-24
|\| |
| * | top-level: Introduce targetPackages and a "double link fold"John Ericson2017-04-23
| |/ | | | | | | | | | | | | | | | | 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 :)
* | Merge remote-tracking branch 'upstream/master' into HEADFrederik Rietdijk2017-04-18
|\|
| * stdenv: ARM bootstrap: Update bootstrap tarballs to latest hydra-built onesTuomas Tynkkynen2017-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge branch 'master' into stagingVladimír Čunát2017-04-14
|\| | | | | | | This includes a fix for a bad merge.
| * make-bootstrap-tools.nix: Fix bzip2Tuomas Tynkkynen2017-04-13
| | | | | | | | Apparently our native bzip2 builds switched to using dynamic libraries at some point.
* | Merge #23374: mkDerivation: simplify non-cross buildsVladimír Čunát2017-04-14
|\ \ | |/ |/| | | Don't pass buildInputs to stdenv builder in nativeBuildInputs.
| * mkDerivation: Don't pass buildInputs to stdenv builder in nativeBuildInputsTuomas Tynkkynen2017-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | darwin.make-bootstrap-tools: fix to use LLVM 4Dan Peebles2017-04-08
| | | | | | This should now roughly match the bootstrap tools we're using on Darwin
* | stdenv-darwin: bump to use LLVM 4.0 & new bootstrap toolsDan Peebles2017-04-07
| |
* | stdenv: aarch64: Update bootstrap tarballsTuomas Tynkkynen2017-03-15
|/ | | | | | | | | | | | | 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!)
* nixpkgs: allow packages to be marked insecureGraham Christensen2017-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Revert "nixpkgs: allow packages to be marked insecure"Graham Christensen2017-02-23
|
* nixpkgs: allow packages to be marked insecureGraham Christensen2017-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #22387 from Ericson2314/cross-3-platformsJohn Ericson2017-02-05
|\ | | | | cross stdenv: let build package's build deps resolve to native packages
| * cross stdenv: let build package's build deps resolve to native packagesJohn Ericson2017-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | make-bootstrap-tools{,-cross}.nix: Fix build after binutils changesTuomas Tynkkynen2017-02-04
| | | | | | | | Broken after commit 17a344a ("binutils: Add lib output").
* | ~/.nixpkgs -> ~/.config/nixpkgsEelco Dolstra2017-02-01
|/ | | | | | The former is still respected as a fallback for config.nix for backwards compatibility (but not for overlays because they're a new feature).
* stdenv: make is64bit evaluate true on aarch64Tuomas Tynkkynen2017-01-29
| | | | This should fix the NSS build.
* stdenv: Aarch64 bootstrap: Update bootstrap tarballs to hydra-built onesTuomas Tynkkynen2017-01-29
| | | | | | | | 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
* Merge pull request #22117 from dezgeg/aarch64-for-mergeTuomas Tynkkynen2017-01-26
|\ | | | | Aarch64 (ARM64) support
| * stdenv: Add aarch64 bootstrap filesTuomas Tynkkynen2017-01-25
| | | | | | | | | | These are temporary and will be switched to Hydra-build ones once all the aarch4 changs are merged.
| * make-bootstrap-tools.nix test: Use busybox from storeTuomas Tynkkynen2017-01-25
| | | | | | | | | | | | | | | | 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.
| * stdenv: Add updateAutoconfGnuConfigScriptsHook for aarch64Tuomas Tynkkynen2017-01-25
| | | | | | | | | | | | | | | | | | | | | | 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.
| * stdenv: Bringup aarch64 architecture supportTuomas Tynkkynen2017-01-25
| |
* | top-level: no more need to expose `splicedPackages`John Ericson2017-01-25
|/ | | | | This was just done temporarily on the last cross-overhauling PR for testing purposes.
* top-level: Only splice as needed for performanceJohn Ericson2017-01-24
|
* top-level: `crossSystem` is no longer exposed to packages. Use `*Platform`.John Ericson2017-01-24
|
* cross-stdenv: Inline useless bindings and reindentJohn Ericson2017-01-24
| | | | Semantics should be unchanged
* top-level: Lay the groundwork for `{build,host,target}Platform`John Ericson2017-01-24
| | | | | | | | | | | | The long term goal is a big replace: { inherit system platform; } => buildPlatform crossSystem => hostPlatform stdenv.cross => targetPlatform And additionally making sure each is defined even when not cross compiling. This commit refactors the bootstrapping code along that vision, but leaves the old identifiers with their null semantics in place so packages can be modernized incrementally.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-01 17:54:12 +0000