haskellPackages: update stackage and hackage

[maralorn]

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. You may be able to find an up-to-date Hydra build report at cdepillabout/nix-haskell-updates-status.

We roughly aim to merge these haskell-updates PRs at least once every two weeks. See the @NixOS/haskell team calendar for who is currently in charge of this branch.

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 #191788. Come to #haskell:nixos.org if you have any questions.

[sternenseemann]

@amjoseph-nixpkgs may be interesting for you to test ghcHEAD on powerpc64le-linux (native compiler). There's no rush though, I expect regressions and plan to fix them bit by bit, since there is no real requirement for ghcHEAD to be free of regressions.

[ghost]

@amjoseph-nixpkgs may be interesting for you to test ghcHEAD on powerpc64le-linux (native compiler). There's no rush though, I expect regressions and plan to fix them bit by bit, since there is no real requirement for ghcHEAD to be free of regressions.

ghc-9.3.20220406 builds on powerpc64le-linux with no problems.

I'm rebuilding the rest of my workstation environment with haskellPackages = haskell.packages.ghcHEAD (is there a better way of telling nixpkgs "use ghcHEAD unless told otherwise"?)

If there is some reasonably-sized set of "smoke test" packages that are expected to build everywhere that GHC does please let me know and I'll add it to my workstation set.

I managed to get NixOS to boot (#192672) on powerpc64le-linux, so perhaps I will be able to run a copy of Hydra on powerpc64le at some point.

[ghost]

@ofborg build haskell.packages.ghcHEAD.base-compat

[ghost]

I'm rebuilding the rest of my workstation environment with haskellPackages = haskell.packages.ghcHEAD

Only failure was base-compat (and its dependees), which also fails on x86_64-linux for me (and for OfBorg).

Of course a lot of stuff depends on base-compat, but what's left built okay.

[sternenseemann]

Only failure was base-compat (and its dependees), which also fails on x86_64-linux for me (and for OfBorg).

That is pretty much expected, the package set overrides for ghcHEAD are very much outdated.

ghc-9.3.20220406 builds on powerpc64le-linux with no problems.

Can you pull haskell-updates again and build ghc-9.5.20220921 which I'm interested in – it has to use the new hadrian build system. So far cross has regressed and x86_64-darwin native.

[sternenseemann]

For x86_64-darwin (and likely also aarch64-darwin) regression see

• https://gitlab.haskell.org/ghc/ghc/-/issues/20592
• https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7111

Not sure yet what this means for us.

Edit: Seems like the header doesn't exist in our libffi derivation. Gathering from context, this is an extra header apple ships?

[ghost]

Can you pull haskell-updates again and build ghc-9.5.20220921 which I'm interested in – it has to use the new hadrian build system. So far cross has regressed and x86_64-darwin native.

ghc-9.5.20220921 built successfully at mainline 84e79cf (i.e. right after this merged) on powerpc64le-linux.

[ghost]

However a lot of haskell.packages.ghcHEAD fails due to version upper bounds; I assume this is a problem on all platforms not just powerpc64le?

error: builder for '/nix/store/xnwn52z4md6vg8k98ygb5iz8r2rxcypv-integer-logarithms-1.0.3.1.drv' failed with exit code 1;
       last 10 log lines:
       > Configuring integer-logarithms-1.0.3.1...
       > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.9.0.0 supports
       > 'ghc' version < 9.4):
       > /nix/store/v6xasyj7spn4hvdrwi5zsjjdsh0ylas5-ghc-9.5.20220921/bin/ghc is
       > version 9.5.20220921
       > CallStack (from HasCallStack):
       >   withMetadata, called at libraries/Cabal/Cabal/src/Distribution/Simple/Utils.hs:368:14 in Cabal-3.9.0.0:Distribution.Simple.Utils
       > Error: Setup: Encountered missing or private dependencies:
       > ghc-prim <0.10
       >
       For full logs, run 'nix log /nix/store/xnwn52z4md6vg8k98ygb5iz8r2rxcypv-integer-logarithms-1.0.3.1.drv'.

[ghost]

I never really understood why cabal allows upper bounds on dependency versions. I guess this is because it has no way to encode "maximum version known to work"? It would be neat if there were a dependency manager which could express that concept without introducing full-on lockfiles.

[sternenseemann]

fails due to version upper bounds

That's expected, as said the overlay is pretty much stale.

I never really understood why cabal allows upper bounds on dependency versions.

Version numbers allow infering when any API breaking change may be done via PVP. In general it is wise (under the assumption that we are constraint-solving) to be more conservative, so that we avoid the situation of a valid install plan that fails to build. Hackage revisions allow updating the upper bounds without creating a new release altogether which in theory should make this system fairly sensible, but in practice maintainers are not that diligent.

Since we are not constraint solving, but curating a package set, we have a lot more issues with this approach than the average cabal-install user.