about summary refs log tree commit diff
path: root/pkgs/top-level/release-lib.nix
AgeCommit message (Collapse)AuthorFilesLines
2024-03-08Avoid `with lib;` at the top level in pkgs/top-level/release-lib.nixPhilip Taron1-15/+50
This drops the following attributes: 1. _mapTestOnHelper 2. crossMaintainers 3. mkPkgsFor As they were only used in this file.
2022-11-25release-lib: add support for riscv64-linuxNick Cao1-0/+2
(cherry picked from commit NickCao@3422a2203e7a2ffa4402bd9750d3de55939c8c8a)
2022-06-18release-lib.nix: make packagePlatforms respect badPlatformssternenseemann1-1/+2
packagePlatforms previously ignored badPlatforms, probably because it is a fairly [recent] addition. While check-meta.nix doesn't implement it using subtractLists, it is basically equivalent to the following logic: platformSet - badPlatformSet (= effectivePlatformSet) which we implement using subtractLists (which has somewhat confusing currying-optimized argument order). This flaw was discovered when testing #177901 which heavily uses badPlatforms. [recent]: https://github.com/NixOS/nixpkgs/commit/b0482248fefbf3b6cdd9c92053cfb49778a3a3a8
2022-05-03nixos/lxd: improve testsPatryk Wychowaniec1-1/+1
- Make tests/lxd.nix use NixOS's lxdMeta & lxdImage to avoid relying on 3rd party containers such as Alpine Linux for testing purposes. - Merge tests/lxd-image.nix into tests/lxd.nix, since now both have a similar structure. - Extract duplicated inline LXD configuration into a separate file, - Add passthru.lxd-nftables & passthru.lxd-image-server.
2021-05-17hydra jobset support for aarch64-darwinVladimír Čunát1-0/+2
2020-11-26release-lib: Don't use tryEval for packagePlatformsSilvan Mosberger1-3/+1
This use of tryEval causes hydra to fully ignore evaluation failures of packages that occur while trying to evaluate the hydra platforms it should be built on. This includes failures that occur during evaluation of: - The `.type` attribute value - The `.meta.hydraPlatforms` or `.meta.platforms` attribute value - The `.version` attribute, since this can determine whether `.meta.position` is set - For non-derivations, `.recurseForDerivations` or `.recurseForRelease` Here's a minimal `release.nix` file, showcasing how a `.version` failure is ignored: let packages = pkgs: { success = pkgs.stdenv.mkDerivation { name = "success"; }; ignoredFailure = pkgs.stdenv.mkDerivation { pname = "ignored-failure"; version = throw "version error"; }; caughtFailure = pkgs.stdenv.mkDerivation { name = "caught-failure"; src = throw "src error"; }; }; releaseLib = import <nixpkgs/pkgs/top-level/release-lib.nix> { packageSet = args: packages (import <nixpkgs> args); supportedSystems = [ "x86_64-linux" ]; }; in releaseLib.mapTestOn (releaseLib.packagePlatforms releaseLib.pkgs) Evaluating this with `hydra-eval-jobs` before this change yields: $ hydra-eval-jobs release.nix -I nixpkgs=/path/to/nixpkgs warning: `--gc-roots-dir' not specified error: "error: --- ThrownError --- hydra-eval-jobs\nsrc error" { "caughtFailure.x86_64-linux": { "error": "error: --- ThrownError --- hydra-eval-jobs\nsrc error" }, "success.x86_64-linux": { "description": "", "drvPath": "/nix/store/q1sw933xd9bxfx6rcp0kqksbprj1wmwj-success.drv", "homepage": "", "isChannel": false, "license": "", "maintainers": "", "maxSilent": 7200, "nixName": "success", "outputs": { "out": "/nix/store/7awrz6hss4jjxvgbwi4wlyikncmslb7a-success" }, "schedulingPriority": 100, "system": "x86_64-linux", "timeout": 36000 } } Where you can see that there is no job for the `ignoredFailure` derivation. Compare this to after this change: $ hydra-eval-jobs release.nix -I nixpkgs=/path/to/nixpkgs warning: `--gc-roots-dir' not specified error: "error: --- ThrownError --- hydra-eval-jobs\nsrc error" error: "error: --- ThrownError --- hydra-eval-jobs\nversion error" { "caughtFailure.x86_64-linux": { "error": "error: --- ThrownError --- hydra-eval-jobs\nsrc error" }, "ignoredFailure": { "error": "error: --- ThrownError --- hydra-eval-jobs\nversion error" }, "success.x86_64-linux": { "description": "", "drvPath": "/nix/store/q1sw933xd9bxfx6rcp0kqksbprj1wmwj-success.drv", "homepage": "", "isChannel": false, "license": "", "maintainers": "", "maxSilent": 7200, "nixName": "success", "outputs": { "out": "/nix/store/7awrz6hss4jjxvgbwi4wlyikncmslb7a-success" }, "schedulingPriority": 100, "system": "x86_64-linux", "timeout": 36000 } } Notice how `ignoredFailure` is now part of the result.
2020-06-12release-lib: Avoid filtering twiceJohn Ericson1-1/+1
We were using `supportedMatches` both when getting the list of platforms, and before `genAttrs` the derivation for each. Now we just filter the second time,
2020-06-04release-lib.nix: remove innacurate platform groupsMatthew Bauer1-5/+0
Removes three platform groups which imply that only linux support: - x11Supported - gtkSupported - ghcSupported replace with just linux
2018-11-29systems/examples.nix: move riscv function to let bindingMatthew Bauer1-1/+1
Makes it easier to use mapAttrs with lib.systems.examples. Now every entry in it are legitimate systems.
2018-11-05release-lib: Fix `pkgsFor`John Ericson1-1/+1
2018-11-01release-lib: Fallback on uncached rather than error for unknown crossSystemJohn Ericson1-4/+3
The `ensureUnaffected` the tests purposefully use an absurd crossSystem. Also sheevaplug and pogoplug share the same config.
2018-11-01release-lib: Cache cross nixpkgs evals tooJohn Ericson1-36/+60
This will help with release-cross.nix eval time. It also allowed me to share code between the cross and native helpers.
2018-03-19lib: Messed up `or` operator precedenceJohn Ericson1-1/+1
Github broke oddly on my previous PR, so I tested and merged by hand. Otherwise ofborg would have caught this.
2018-03-19release-lib: Filter supportedSystems with `meta.platforms`-style patternsJohn Ericson1-12/+31
Instead of intersecting system strings, we filter with the sort of patterns used in `meta.platforms`. Indicating this change `forTheseSystems` has been renamed to `forMatchingSystems`, since the given list is now patterns to match, and not the systems themselves. [Just as with `meta.platforms`, systems strings are also supported for backwards compatibility.] This is more flexible, and makes the `forMatchingSystems` and packagePlatforms` cases more analogous.
2018-03-19lib: Factor in tiny bit of `meta.platform` checkingJohn Ericson1-11/+5
I need it in stdenv and release-lib, so that seems motivation enough.
2018-03-15release-lib: Adapt to work with new meta.platformsJohn Ericson1-1/+12
`packagePlatforms` now filters `supportedSystems` with the new-style `meta.platforms`, rather than just plopping it in as is.
2018-03-14treewide: get rid of platforms.allButJohn Ericson1-1/+1
Negative reasoning like `allBut` is a bad idea with an open world of platforms. Concretely, if we add a new, quite different sort of platform, existing packages with `allBut` will claim they work on it even though they probably won't.
2018-01-16nixos/release.nix: Move forAllSystems to release-libTuomas Tynkkynen1-0/+1
There's already a similar forTheseSystems in release-lib, so be more consistent.
2018-01-16release-lib: forAllSupportedSystems -> forTheseSystemsTuomas Tynkkynen1-3/+3
I'm going to move forAllSystems from nixos/release.nix, and these functions sound too similar while doing different things.
2017-12-31pkgs/release-lib: evaluate nixpkgs on armv6l and armv7l (#32641)Ben Wolsieffer1-0/+4
2017-08-12nixpkgs release: Fix Darwin-only jobsTuomas Tynkkynen1-1/+1
Currently the logic of generating nixpkgs Hydra jobs is to walk through the pkgs evaluated for system = "x86_64-linux", collect any derivations and their meta.platforms values. However, that doesn't work for packages whose meta.platforms doesn't include x86_64-linux, as just evaluating their meta attribute raises an error so they get skipped completely. As a less-intrusive fix (i.e. anything than rewriting the current package enumeration logic), allow passing `config.allowUnsupportedSystem = true` to permit evaluating packages regardless of their platform and use that in the package listing phase. Fixes #25200
2017-04-17Merge pull request #24610 from Ericson2314/platform-normalizationJohn Ericson1-1/+9
Platform normalization
2017-04-17lib: Fix system parsing, and use for doubles listsJohn Ericson1-0/+5
The old hard-coded lists are now used to test system parsing. In the process, make an `assertTrue` in release lib for eval tests; also use it in release-cross
2017-04-17top-level: Less indirection for lib in release*.nixJohn Ericson1-1/+4
2017-04-11release(-lib).nix: add nixpkgsArgs parameterBjørn Forsman1-5/+3
This allows customizing the nixpkgs arguments by the caller. My use case is creating a personal nixpkgs channel containing some unfree packages. The default is still to not build unfree packages, so for nixpkgs this is no functional change.
2017-03-08nixpkgs: add aarch64-linux to release-libFranz Pletz1-0/+2
cc #23638
2017-01-25top-level: no more need to expose `splicedPackages`John Ericson1-3/+2
This was just done temporarily on the last cross-overhauling PR for testing purposes.
2017-01-24top-level: Introduce `buildPackages` for resolving build-time depsJohn Ericson1-2/+3
[N.B., this package also applies to the commits that follow it in the same PR.] In most cases, buildPackages = pkgs so things work just as before. For cross compiling, however, buildPackages is resolved as the previous bootstrapping stage. This allows us to avoid the mkDerivation hacks cross compiling currently uses today. To avoid a massive refactor, callPackage will splice together both package sets. Again to avoid churn, it uses the old `nativeDrv` vs `crossDrv` to do so. So now, whether cross compiling or not, packages with get a `nativeDrv` and `crossDrv`---in the non-cross-compiling case they are simply the same derivation. This is good because it reduces the divergence between the cross and non-cross dataflow. See `pkgs/top-level/splice.nix` for a comment along the lines of the preceding paragraph, and the code that does this splicing. Also, `forceNativeDrv` is replaced with `forceNativePackages`. The latter resolves `pkgs` unless the host platform is different from the build platform, in which case it resolves to `buildPackages`. Note that the target platform is not important here---it will not prevent `forcedNativePackages` from resolving to `pkgs`. -------- Temporarily, we make preserve some dubious decisions in the name of preserving hashes: Most importantly, we don't distinguish between "host" and "target" in the autoconf sense. This leads to the proliferation of *Cross derivations currently used. What we ought to is resolve native deps of the cross "build packages" (build = host != target) package set against the "vanilla packages" (build = host = target) package set. Instead, "build packages" uses itself, with (informally) target != build in all cases. This is wrong because it violates the "sliding window" principle of bootstrapping stages that shifting the platform triple of one stage to the left coincides with the next stage's platform triple. Only because we don't explicitly distinguish between "host" and "target" does it appear that the "sliding window" principle is preserved--indeed it is over the reductionary "platform double" of just "build" and "host/target". Additionally, we build libc, libgcc, etc in the same stage as the compilers themselves, which is wrong because they are used at runtime, not build time. Fixing this is somewhat subtle, and the solution and problem will be better explained in the commit that does fix it. Commits after this will solve both these issues, at the expense of breaking cross hashes. Native hashes won't be broken, thankfully. -------- Did the temporary ugliness pan out? Of the packages that currently build in `release-cross.nix`, the only ones that have their hash changed are `*.gcc.crossDrv` and `bootstrapTools.*.coreutilsMinimal`. In both cases I think it doesn't matter. 1. GCC when doing a `build = host = target = foreign` build (maximally cross), still defines environment variables like `CPATH`[1] with packages. This seems assuredly wrong because whether gcc dynamically links those, or the programs built by gcc dynamically link those---I have no idea which case is reality---they should be foreign. Therefore, in all likelihood, I just made the gcc less broken. 2. Coreutils (ab)used the old cross-compiling infrastructure to depend on a native version of itself. When coreutils was overwritten to be built with fewer features, the native version it used would also be overwritten because the binding was tight. Now it uses the much looser `BuildPackages.coreutils` which is just fine as a richer build dep doesn't cause any problems and avoids a rebuild. So, in conclusion I'd say the conservatism payed off. Onward to actually raking the muck in the next PR! [1]: https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
2016-12-27release-cross: Factor out system filteringJohn Ericson1-4/+5
2016-12-27release-cross: Use the same genAttrs logic for `testOnCross` as `testOn`John Ericson1-4/+3
Eventually we'll want to test cross-compiling *from* various platforms. For now, its good to be consistent.
2016-11-28Build all derivations at least for 64bit LinuxDomen Kožar1-1/+1
2016-09-11release-lib: Remove unused allowTexliveBuilds optionTuomas Tynkkynen1-2/+0
This is dead code since the old monolithic TeXLive was dropped in da421bc75f98c1b19f214a3b6b7cda07dc4c088b.
2016-06-22Replace `./../*` with `../*` in Nix expressions (#16414)John Ericson1-1/+1
2016-03-13Replace references to all-packages.nix, by references to the top-level of ↵Nicolas B. Pierron1-1/+1
nixpkgs repository.
2015-12-16copy-tarballs.pl: Revive extracting all tarballs from release.nixEelco Dolstra1-2/+9
2015-07-17release-lib.nix: set inHydra anyways, it might be useful some dayPeter Simons1-0/+1
2015-07-17release-lib: rename config option "inHydra" to "allowTexliveBuilds"Peter Simons1-2/+2
Also, take the value of that attribute as an argument to the module so that Hydra maintainers who don't mind building TexLive have a chance to do so.
2015-06-25Don't build texLive in HydraEelco Dolstra1-0/+1
It's way too big (texlive-core-2014 alone is > 1.5 GB).
2015-05-28cygwin: stdenvFlorian Friesdorf1-0/+2
2015-03-20Rename scrubDrv -> hydraJob and make it more effectiveEelco Dolstra1-1/+1
It now strictly evaluates all remaining attributes, preventing unevaluated thunks that cannot be garbage-collected. It's also applied to all jobs in Nixpkgs' release.nix. This reduces hydra-eval-jobs' memory consumption on the 14.12 release-combined jobset from 5.1 GB to 2.0 GB.
2015-03-20release-lib: SimplifyEelco Dolstra1-55/+23
2015-03-20release-lib.nix: Style cleanupEelco Dolstra1-21/+21
2015-01-06TweakEelco Dolstra1-2/+2
2015-01-06Remove scheduling prioritiesEelco Dolstra1-16/+4
This was only used for stdenv and is pretty obsolete now.
2014-11-14release-lib: add option to use another package setNikolay Amiantov1-2/+2
2014-09-03release: do not process broken packages, we induce they don't have platforms ↵Luca Bruno1-0/+2
at all
2013-11-05Only show/build a package on the platforms listed in meta.platformsEelco Dolstra1-5/+3
The function ‘mkDerivation’ now checks whether the current platform type is included in a package's meta.platform field. If not, it throws an exception: $ nix-build -A linux --argstr system x86_64-darwin error: user-thrown exception: the package ‘linux-3.10.15’ is not supported on ‘x86_64-darwin’ These packages also no longer show up in ‘nix-env -qa’ output. This means, for instance, that the number of packages shown on x86_64-freebsd has dropped from 9268 to 4764. Since meta.platforms was also used to prevent Hydra from building some packages, there now is a new attribute meta.hydraPlatforms listing the platforms on which Hydra should build the package (which defaults to meta.platforms).
2013-05-15mercurial: Update to 2.6.1Eelco Dolstra1-1/+1
Also, set a default for web.cacerts so that the system certificates on NixOS are used.
2013-03-26release-lib.nix: Make the set of supported platforms an argumentEelco Dolstra1-4/+2
2013-03-26Add an "unstable" aggregate to replace the "unstable" viewEelco Dolstra1-1/+1
Views are obsolete, aggregates are the declarative replacement.