Skip to content

haskellPackages: update stackage and hackage#125977

Merged
maralorn merged 29 commits intomasterfrom
haskell-updates
Jun 12, 2021
Merged

haskellPackages: update stackage and hackage#125977
maralorn merged 29 commits intomasterfrom
haskell-updates

Conversation

@sternenseemann
Copy link
Copy Markdown
Member

@sternenseemann sternenseemann commented Jun 6, 2021

This Merge

This PR is the regular merge of the haskell-updates branch into master.

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:

  • We regularly update the Stackage and Hackage pins on haskell-updates (normally at the beginning of a merge window).
  • The community fixes builds of Haskell packages on that branch.
  • We aim at at least one merge of haskell-updates into master every two weeks.
  • We only do the merge if the mergeable job is succeeding on hydra.
  • If a maintained package is still broken at the time of merge, we will only merge if the maintainer has been pinged 7 days in advance. (If you care about a Haskell package, become a maintainer!)

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:

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.
@github-actions github-actions bot added the 6.topic: haskell General-purpose, statically typed, purely functional programming language label Jun 6, 2021
Make sure they are all prefixed with haskellPackages: except for
update-hackage.sh which changes the top-level attribute
all-cabal-hashes.
@ofborg ofborg bot added 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. 8.has: clean-up This PR removes packages or removes other cruft 8.has: package (new) This PR adds a new package labels Jun 6, 2021
@sternenseemann
Copy link
Copy Markdown
Member Author

GHC 8.10.5 failure on my mac, seems like a (lack of) sandboxing issue:

ln -s ghc-8.10.5 "/nix/store/qjixylxsm5rv0zn7zvzz2pfjpifwcq25-ghc-8.10.5/bin/ghc"
/nix/store/yzvj23zkg314xjywc3dmzdlqchkqq4m0-coreutils-8.32/bin/install -c -m 755 -d "/nix/store/qjixylxsm5rv0zn7zvzz2pfjpifwcq25-ghc-8.10.5/share/man"
/nix/store/yzvj23zkg314xjywc3dmzdlqchkqq4m0-coreutils-8.32/bin/install -c -m 755 -d "/nix/store/qjixylxsm5rv0zn7zvzz2pfjpifwcq25-ghc-8.10.5/share/man/man1"
/nix/store/yzvj23zkg314xjywc3dmzdlqchkqq4m0-coreutils-8.32/bin/install -c -m 644  docs/users_guide/build-man/ghc.1 "/nix/store/qjixylxsm5rv0zn7zvzz2pfjpifwcq25-ghc-8.10.5/share/man/man1"
if [ -e "/usr/bin/xattr" ]; then "/usr/bin/xattr" -c -r .; fi
Traceback (most recent call last):
  File "/usr/bin/xattr-2.7", line 7, in <module>
    from pkg_resources import load_entry_point
  File "/nix/store/h9832pvm0airim7nfc5n7xvqqb7hzl24-python3.8-setuptools-54.2.0/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1367
    raise SyntaxError(e) from e
                            ^
SyntaxError: invalid syntax
make[1]: *** [ghc.mk:833: install_darwin] Error 1
make: *** [Makefile:128: install] Error 2
builder for '/nix/store/rqjwrp4j5zy8r8wn47l3mqkpfc1105c4-ghc-8.10.5.drv' failed with exit code 2
cannot build derivation '/nix/store/an3yqv76k9r9b2yr4syav49q886krfbz-hello-1.0.0.2.drv': 1 dependencies couldn't be built
error: build of '/nix/store/an3yqv76k9r9b2yr4syav49q886krfbz-hello-1.0.0.2.drv' failed

I'll look into making GHC take xattr from the right location.

@sternenseemann
Copy link
Copy Markdown
Member Author

sternenseemann commented Jun 8, 2021

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 haskellPackages can be found here — build failures aren't too many it seems so far, but I'm concerned about the degraded quality. Also some of the packages that transitively fail are important to us (like termonad, …).

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.
@sternenseemann
Copy link
Copy Markdown
Member Author

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.

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.
@sternenseemann sternenseemann linked an issue Jun 8, 2021 that may be closed by this pull request
sternenseemann and others added 7 commits June 8, 2021 22:17
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>
These attribute names were converted into aliases in the following
changes:

* 62733b3
* #104776

cabal2nix-unstable has been updated to be aware of these changes in
7a9080d, so these aliases should no
longer cause issues when evaluating with `allowAliases = false`.
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.
@sternenseemann
Copy link
Copy Markdown
Member Author

sternenseemann commented Jun 11, 2021

haskell-updates build report from hydra

evaluation 1677383 of nixpkgs commit f8c8bb0 as of 2021-06-11 19:12 UTC

Build summary

Almost all darwin builds are still queued. @maralorn I think all the failures of your packages are because of flaky tests / killed builds. I'll try restarting a few jobs and see if the problem resolves itself.

Platform Failed ❌ DependencyFailed ❗ TimedOut ⌛🚫 Unfinished ⏳ Success ✔️
aarch64-linux 📱 32 73 8 6557
x86_64-darwin 🍎 3 18 5329 1285
x86_64-linux 🐧 14 21 1 6674

Maintained packages with failed dependency

Unmaintained packages with build failure

38 job(s)

Unmaintained packages with failed dependency

113 job(s)

Report generated with maintainers/scripts/haskell/hydra-report.hs

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
@sternenseemann
Copy link
Copy Markdown
Member Author

Handing over to @maralorn now, the queued builds didn't finish in time sadly. Our CI aggregate jobs all succeed on x86_64-linux (or at least should according to my local testing), so it is just a case of waiting for the queue, checking for extra regressions and marking the remaining failures as broken.

@maralorn
Copy link
Copy Markdown
Member

haskell-updates build report from hydra

evaluation 1677793 of nixpkgs commit c0d39d2 as of 2021-06-12 16:30 UTC

Build summary

Platform Failed ❌ DependencyFailed ❗ TimedOut ⌛🚫 Unfinished ⏳ Success ✔️
aarch64-linux 📱 31 71 3 6561
x86_64-darwin 🍎 5348 1285
x86_64-linux 🐧 11 5 2 6690

Unmaintained packages with build failure

31 job(s)

Unmaintained packages with failed dependency

75 job(s)

Report generated with maintainers/scripts/haskell/hydra-report.hs

@maralorn
Copy link
Copy Markdown
Member

Marvelous this build report without any pings. Note: the two unfinished x86 builds are maintained and mergeable which are waiting for the darwin builds.

sternenseemann and others added 6 commits June 12, 2021 18:37
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: haskell General-purpose, statically typed, purely functional programming language 8.has: clean-up This PR removes packages or removes other cruft 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The haskell writer is broken on darwin

5 participants