We were caching this insecure package as part of a decision during 23.05, we will now cache
openssl-1.1.1u too as this is now the de-facto OpenSSL package on 23.05, which is EOL.
Until the 11 September 2023, those two packages will be built and cached by Hydra so they can be used
by users without recompilation penalties.
This is an exception due to mismatched release windows and should not set any precedent
without community discussion in coordination with release managers.
This change exposes symbol override that accidentally caused job loss on hydra:
$ nix repl ./release.nix
error: jobs: Unexpected attribute collision between 'jobs' and 'pkgs': stdenvBootstrapTools
Added assert makes sure attribute clashes would not be re-introduced.
Commit 5643714dea introduced a tiny
bug, neglecting to pass the `pkgs` parameter to `release.nix`.
This bug went unnoticed because commit
e663518d18 had introduced a much larger
bug: an attribute collision resulted in `stdenvBootstrapTools` being
shadowed, and therefore never evaluated. As a result, the missing
`pkgs` parameter did not lead to an error.
This commit passes the missing parameter so that fixing the
larger/earlier bug will not cause an eval failure.
This reverts commit 7141ab0f0b.
reverting this for now to unblock staging-next
{UNKNOWN}: aggregate job ‘tested’ failed with the error: nixpkgs.tests.packageTestsForChannelBlockers.curl.withCheck.x86_64-linux: does not exist
at /nix/store/9i92scfqz5idhmjrmjnqhrvjgyydzfns-hydra-perl-deps/lib/perl5/site_perl/5.34.0/Catalyst/Model/DBIC/Schema.pm line 526
we can't add 'nixpkgs.curl.tests' to hydra jobs due to 'tests' (and 'passthru') being stripped
TODO: add a function in lib-release.nix to get derivations and add `.x86_64-linux` to them
then we can just point release files to nixpkgs.tests.packageTestsForChannelBlockers instead of
nixpkgs.tests.packageTestsForChannelBlockers.curl.withCheck
Removing Python 2 because it's EOL and most packages don't use it
anymore.
Also replace thunderbird with firefox because more people use it and it
feels better maintained in general
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 70f1335f8d)
