haskellPackages: update stackage and hackage#125977
Conversation
If we don't pass buildTarget to ./Setup copy and buildTarget is not empty it will try installing targets that don't exist and thus fail.
Make sure they are all prefixed with haskellPackages: except for update-hackage.sh which changes the top-level attribute all-cabal-hashes.
|
GHC 8.10.5 failure on my mac, seems like a (lack of) sandboxing issue: I'll look into making GHC take xattr from the right location. |
|
The doctest failures seem to be related to this GHC issue. We may not be able to update GHC until 8.10.6. A somewhat accurate impression of the state of |
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
This reverts commit 683d06d. upstream resolved the issue we were experiencing.
|
I'm fairly convinced that upgrading to 8.10.5 in this manner doesn't make sense. We could patch the issue causing the regressions, but we haven't set up aarch64-darwin bootstrap yet, so there is no actual benefit for us in upgrading. I'll rebase the 8.10.5 changes out of this branch and open a separate PR for it. Also be warned that there will be a force push to this branch soon. |
7720995 to
13c72a9
Compare
GHC calls otool on darwin which is contained in the stdenv.cc.bintools.bintools derivation and thus needs adding to the runtime PATH of GHC. Since this is toolchain specific technically, we check for cctools instead of darwin (although I don't know if GHC or nixpkgs work on macOS without cctools). This fixes usage of GHC in an environment where otool is not available and more specifically in stdenvNoCC which is used by writers.writeHaskell. Resolves #123228.
useLdGold previously just checked for useLLVM which (currently) implies `linker == "lld"`. However more accurate is to check the `linker` of the `targetPlatform` as it actually tells us which bintools package we can expect. `linker == "bfd"` implies that we are using the `binutils` package, so gold is available, so we can use it unless musl is the libc. `linker == "gold"` implies that gold is the default linker already and we should absolutely use it.
ghc: check for targetPlatform.linker to determine if gold is available
tests added breaking constraints which seem safe to lift. Co-authored-by: sterni <sternenseemann@systemli.org>
Stackage Nighly recently upgraded their version of hackage-db from 2.1.0 to 2.1.1. 2.1.1 had a compatibility fix for Cabal 3.4 [1]. However it did not increase the version bound on Cabal nor fails to compile with Cabal 3.2, so Stackage was able to update it. Unfortunately hackage-db with Cabal 3.2 causes observable issues [2] in cabal2nix, so we need to downgrade it for all compilers that still ship a Cabal version < 3.4. Also ideally we should update the constraints for hackage-db 2.1.0 and hackage-db 2.1.1 on hackage. See also [3]. [1]: NixOS/hackage-db#12 [2]: NixOS/cabal2nix#501 [3]: NixOS/hackage-db#14
Upgrade to 0.16 which has GHC 9.0.x support. Interesting since cabal2nix depends on memory.
0.29 supports GHC 9.0.x which is why we upgrade. Interesting because cabal2nix depends on cryptonite.
GHC 9.0.x seems to require that the `Main` module also defines the `main` IO action and does not just import it. This is the case with mono-traversable's test suite which is why we (temporarily) disable it.
Adds support for GHC 9.0.x which we also test by compiling it with all available GHC versions on Hydra.
Test suite doesn't build with GHC 9.0.1 and since upstream is currently not invested in fixing it, we (temporarily) disable it. Upside: we can build hoogle again. Soostone/retry#71
|
Handing over to @maralorn now, the queued builds didn't finish in time sadly. Our CI aggregate jobs all succeed on |
haskell-updates build report from hydraevaluation 1677793 of nixpkgs commit c0d39d2 as of 2021-06-12 16:30 UTC Build summary
Unmaintained packages with build failure31 job(s)
Unmaintained packages with failed dependency75 job(s)
Report generated with maintainers/scripts/haskell/hydra-report.hs |
|
Marvelous this build report without any pings. Note: the two unfinished x86 builds are |
Linker failure outputs look like they are related to the GClosure stuff, so lets try disabling that flag on arm — originally the upstream cabal file disabled that flag by default if arch != x86_64-linux || != sparc64, so this seems to be actually correct.
This commit has been generated by maintainers/scripts/haskell/mark-broken.sh
This Merge
This PR is the regular merge of the
haskell-updatesbranch intomaster.This branch is being continually built and tested by hydra at https://hydra.nixos.org/jobset/nixpkgs/haskell-updates.
I will aim to merge this PR by 2021-06-11. If I can merge it earlier, there might be successor PRs in that time window. As part of our rotation @maralorn will continue these merges from 2021-06-12 to 2021-06-26.
haskellPackages Workflow Summary
Our workflow is currently described in
pkgs/development/haskell-modules/HACKING.md.The short version is this:
haskell-updates(normally at the beginning of a merge window).haskell-updatesintomasterevery two weeks.mergeablejob is succeeding on hydra.This is the follow-up to #125429.
This PR aims to update our default GHC version to 8.10.5.GHC 8.10.5 has been tested as part of this PR. The conclusion is that it's not worth updating for now: #125977 (comment) New PR for GHC 8.10.5 is #126195.If I get to it, I have the following additional plans to work towards improvements of mostly our GHC derivation, but they are not a hard requirement for merging this PR:
get(faill because of rust as well)tests.writers.x86_64-darwinto work againgeneric-builder.nix(haskell-generic-builder: allow passing flags to the test suite(s) #126364)x86_64-darwinandaarch64-linuxbuilds by updatingunsupported-platforms