This reverts commit 88b014f3ae.
While these packages are not accessible via hackage's UI or API, they
still appear in the snapshot and now cause failed builds. They need to
be fully removed (excluded) once that's possible with hackage2nix.
Also, rearrange the GHC‐related release notes to be in order of
most likely to matter to anyone.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
This was used for bootstrapping GHC on powerpc64le, but it's unclear
whether that actually still works. It makes no sense to pretend to
support it, when it's most likely broken, but we can't even verify.
Also the bootstrap chain will be broken once we drop GHC 8.10.7, so we
might as well drop the whole thing.
This affects haskelPackages.mkDerivation, ghcWithPackages and
hoogleWithPackages which means that it is not possible to re-introduce
a ghcjs derivation downstream and create a ghcjs package set with an up
to date Nixpkgs.
The previous approach of selecting the highest possible LLVM version
brought complications, especially when the latest LLVM release candidate
was properly released and the llvm-ffi version on master didn't support
this properly, yet. This would result in an eval failure that was
impossible to properly solve on master.
We only introduced the logic of selecting the latest LLVM version,
because we didn't know about the cabal flags supporting lower LLVM
versions at first. We then stuck with this approach. However, we can
also just always use the default LLVM version that is present in
`llvmPackages`. This is more in the spirit of a *default* version
anyway.
This will not result in any eval failures / warnings. There is only one
failure mode: `haskellPackages.llvm-ffi` not supporting the new default
LLVM version. In this case it's perfectly fine to wait for an update of
llvm-ffi via `haskell-updates`.
These dependencies need to be pulled from the same unstable commit that
cabal2nix is pulled from, otherwise changes to any of them will not be
in effect and possibly break the build.
This looks like a badly designed property test suite which fails to
exclude values that can't exhibit correct behavior (NaN), but it could
also theoretically be a correctness issue. Haven't gotten a response from
upstream. Kicking the package a few times usually gets the test suite to
succeed, but I'm kind of sick of that game.
Stackage LTS 24 contains git-annex (contrary to LTS 23). I believe this
resulted in a downgrade of git-annex when switching to LTS 23. We'll
want to continue using the latest version of git-annex. At the very
least, this will fix the trouble we're having with its test suite on
haskell-updates.
