While using very old compilers is a fair usecase, it induces a maintenance churn as
we collect more and more LLVM versions for the LLVM maintainers.
Especially when we need to backport uniform changes to the whole tree,
furthermore, it consumes and waste CI resources.
This will allow us to regenerate our woefully out-of-date
aarch64-unknown-linux-gnu musl bootstrap tools, which can't compile
lots of modern code.
We could technically also do i686-unknown-linux-musl bootstrap tools,
but I don't know if there's demand for that, so it's best to wait and
see if somebody asks for it before we commit Hydra to it.
This will allow buliding bootstrap tools for platforms with
non-default libcs, like *-unknown-linux-musl.
This gets rid of limitedSupportSystems/systemsWithAnySupport. There
was no need to use systemsWithAnySupport for supportDarwin, because it
was always equivalent to supportedSystems for that purpose, and the
only other way it was used was for determining which platforms to
build the bootstrap tools for, so we might as well use a more explicit
parameter for that, and then we can change how it works without
affecting the rest of the Hydra jobs.
Not affecting the rest of the Hydra jobs is important, because if we
changed all jobs to use config triples, we'd end up renaming every
Hydra job. That might still be worth thinking about at some point,
but it's unnecessary at this point (and would be a lot of work).
I've checked by running
nix-eval-jobs --force-recurse pkgs/top-level/release.nix
that the actual bootstrap tools derivations are unaffected by this
change, and that the only other jobs that change are ones that depend
on the hash of all of Nixpkgs. Of the other jobset entrypoints that
end up importing pkgs/top-level/release.nix, none used the
limitedSupportedSystems parameter, so they should all be unaffected as
well.
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).
