Release branch from 6½ years ago, no update in 3½ years, unsupported
upstream, and unused in tree.
This finally resolves the tangled conditionals in `all.nix`, albeit in
a way I assume amjoseph wouldn’t have been too fond of. `default.nix`
still has some gnarly stuff in there. So it goes…
The attrNamesOnly feature is used by
pkgs/top-level/release-attrpaths-superset.nix to return a superset of
all attributes that might be built by Hydra.
Before this change it would include all attribute paths to derivations that could
be found recursively, ignoring the recurseForDerivations and
recurseForRelease attributes that control Hydra's recursion.
This had the effect that it would end up with ~266000 attributes, most of which definitely won't be built by Hydra. We can remove those while staying true to the superset notion to end up with just ~97000, a reduction of ~63.6%! This also comes with an eval time reduction from 31.7s to 18.7s (-41.0%)!
As an example, all derivations in pypy310Packages don't get included
anymore, because it doesn't have a `.recurseForDerivations` set.
As a nice side effect, with `--arg enableWarnings false`, no more
warnings are printed, because things like
`checkpointBuildTools.mkCheckpointedBuild` (which is deprecated) isn't
being recursed to anymore.
Olm was marked as vulnerable in e4767b47.
The issue, however, is controversial and the practical ability to
exploit its vulnerabilities has not been demostrated: ultimately the
users are invited to decide for themselves.
Given that, hydra should still build and distribute the packages
depending on olm to avoid expensive builds in the event the users
decide it's acceptable to continue using these packages.
In https://github.com/NixOS/nixpkgs/pull/328582 we broke the nixpkgs
release.nix by committing an unsound tarball. We comment out freebsd for
now until this has been replaced with a proper public one.
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.
