We emit a few jobs conditionally on supportDarwin which only checked for
x86_64-darwin in the past. This change makes it more modular by
transforming it into an attribute set which holds the two darwin
arches. Jobs needing aarch64-darwin or x86_64-darwin are now only
emitted if their respective platform is actually in supportedSystems.
This issue was discovered because the staging-next-21.11 jobset had
commented out x86_64-darwin (presumably due to a build load issue).
Having pkgsLLVM.stdenv built with nixpkgs:trunk will make building
anything in pkgsLLVM decidedly less painful since it will eliminate
the need to build LLVM and clang locally, which shouldn't be as bad
on hydra.
Darwin is disabled for now since it doesn't evaluate correctly there
(infinite recursion problem with the SDK).
This reverts commit c23e9e12f8.
At this moment the benchmarking machine ("t2a") is unreachable from
outside due to IPv6 issues. (the "t4a" and "t4b" builders as well)
But even generally I can't see why this job should block channels,
provided that it won't remain broken over long term.
* Add pkgsMusl.stdenv to block nixpkgs channel
* Don’t include i686-linux for pkgs{Musl,Static}
musl bootstrapping is unavailable for i686-linux right now. so we can
just exclude it from hydra.
Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
This reverts commit 5e8545e723.
It breaks eval:
attribute 'rev' missing, at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-0-gleber.ewr1.nix.ci/pkgs/top-level/make-tarball.nix:106:39
This package is hardly used in Nixpkgs. Why is it considered
sufficiently important to block a channel?
It's been blocking the nixpkgs-unstable for 8 days now, so removing it
from release*.nix.
The comment in this file about why nox is here
was "Needed by travis-ci to test PRs", and we
for sure don't use travis-ci anymore.
Instead we're making nixpkgs-review a deliverable
because it's included in the PR template as a tool
to use. We also swapped out nox for nixpkgs-review
in the PR template, so I believe this makes sense
here because it was changed.
This reverts commit 96d73edaf3.
IPv6 connectivity restored by ISP a few hours after I pushed
the workaround. Apparently it was something complicated;
I suppose that has to do with the issue appearing on Friday 13th
during full moon ;-)
Since friday the metrics machine (along with other replaceable ones)
has no public-IP connectivity. I hoped I'd be able to resolve this
with ISP quickly, but apparently not. Let's not block the channel
at least. The metrics data can get filled retrospectively by restarting
the individual Hydra jobs.
Unfortunately it is broken and I won’t have time to fix right now.
Most likely we will have to wait until the macOS 10.12 update to get
this one working again.
(cherry picked from commit 70f1335f8d64d1f8451b891d4fca4af08e607d09)
Hydra passes the full revision in to the input, which we pass through.
If we don't get this ,we try to get it from other sources, or default to
master which should have the definition in a close-ish location.
All published docs should have theURL resolve properly, only local
hackers will have the link break.
These are some parts of the release that I want to get working before
we release 18.09. There have been lots of improvements since 18.03 (as
well as some regressions). To make sure the release is well-tested we
need to add these apps in the jobset. Most of these are UI apps that
are now available.
List of new apps added to the release:
- wireshark
- firefox
- qtmultimedia (already in unstable)
- inkscape (already in unstable)
- gimp
- wireshark
- transmission
Also add ‘stack’. This is one of the Haskell packages hitting the
ARG_MAX limit on macOS (getconf ARG_MAX == 262144). This has not been
solved yet but it will need to be resolved by 18.09. Making it block
here will prevent this regression in the future.
[squashed] release: remove broken from darwin-tested
removes:
- gimp
- qtmultimedia
This reverts commit 0d8076b99c.
This has been causing people issues so it’s easiest to leave it off
for now. Eventually I will do an RFC or some other PR where we can
have more discussion on benefits of doing this in CI.
Fixes#44299
I still think it’s still worth keeping aliases out of Nixpkgs but we
don’t need to block evaluation on it.
This reverts commit 25c42e7736.
This commit is still causing evaluation errors (despite passing
OfBorg!)
Here is the current error:
error: undefined variable 'Log4Perl' at
/nix/store/n0gwyv3mcvm3hc9jrmkxjhmsrdjqzcqb-source/maintainers/scripts/nix-generate-from-cpan.nix:7:71
More investigation is needed
/cc @volth
This reverts commit 67d0a57ef9.
which caused evaluation errors in restricted eval mode, producing:
error: access to URI
'/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci' is
forbidden in restricted mode
nix-repl is not needed anymore because Nix 2.0 comes with repl already. Anyway nix-repl is broken right now on Hydra because Nix 1.11 is broken.
https://hydra.nixos.org/build/74933091
13d6681ce7 crippled it unintentionally.
Also remove the incorrect/non-existing stdenv.i686-linux;
building the bootstrap tools should be a good-enough test anyway.
13d6681ce7 crippled it unintentionally.
Also remove the incorrect/non-existing stdenv.i686-linux;
building the bootstrap tools should be a good-enough test anyway.
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
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.
