Call for Contributions: We are updating to GHC 9.10.2

Development
1

Hello everyone,

we are currently in the process of updating the default version of GHC from 9.8.4 to 9.10.2. This is accompanied with an update from the Stackage LTS 23 to the Stackage LTS 24 package set, so we will be getting, e.g pandoc 3.7 and shellcheck 0.11.0:

Some initial work has already been completed, mainly focussing on fixing eval regressions and getting basic tooling to compile again. Now, the first build of the entire package set on Hydra has been completed, boasting about 1300 new failures. We would like to ask for your help fixing as many of the remaining regressions as possible.

I want to thank all contributors already in advance, also in the name of @NixOS/haskell.

How to Help

The main ways to help is by looking into build regressions of Haskell packages and figuring out if and how to fix them. To find regressions…

  • you can look at the Hydra jobset for the haskell-updates branch. Why not check whether your favorite Haskell package is broken or packages you otherwise depend on have regressed?
  • A more concise build report based on the Hydra jobset is available (I’ll probably post updated versions of the build report in the PR as time goes on). You can expand a list at the bottom that shows broken packages ordered by reverse dependencies – fixing these packages will probably have the biggest impact. If you’re a maintainer of a Haskell package that broke, you should have been tagged on the PR as well.

For a given regression, try to figure out what went wrong then…

  • If applicable, write a patch and submit it upstream. This is great because it doesn’t just help us and can also be done if you’re familiar with Haskell, but not necessarily with the sometimes unwieldy Nixpkgs Haskell infrastructure! Be sure to let us know about relevant PRs/patches e.g. on this thread.
  • Write a Nixpkgs pull request, targeting haskell-updates, to add a workaround for a regression. If applicable, also open an issue with the upstream project, so we can track when this workaround can be removed again. I’ve included some pointers on how to do this below.

Unfortunately, for testing builds locally you need to be using x86_64-linux to be able to substitute builds from the haskell-updates jobset since it is the only platform we test at the moment. (It may be nice to add aarch64-darwin when we have the Hydra resources to spare.)

Adding a Workaround

(mostly copied from Call for Contributions: We are updating to GHC 9.0.2)

Assuming you found packages you are interested in, here’s how to fix them: Package builds for Haskell are fixed by updating the base package description via a set of haskellPackages overlays located in pkgs/development/haskell-modules/configuration-*.nix. The ones you’ll probably be needing to touch are:

  • configuration-common.nix: for general fixes that are not tied to a specific GHC version or platform and expected to be temporary (i.e. the issue should be fixed upstream as well)
  • configuration-ghc-*.nix: Compiler version specific fixes. Note that we prefer version agnostic fixes, so rather use CPP and introduce a patch in configuration-common.nix than introduce a hard dependency on GHC >= 9.10 in a patch.
  • The other configurations are:
    • configuration-nix.nix: for fixes that are needed because of the nature of Nix/nixpkgs compared to other environments
    • configuration-arm.nix, configuration-darwin.nix: Platform specific workarounds

You can look into these files, especially configuration-common.nix, for inspiration how fixes typically look. The available helper functions are defined at the place of their definition and the nixpkgs manual. Typical fixes are:

  • Lifting version constraints on a dependency using the doJailbreak function, e.g. if a package has an unnecessarily strict upper constraint on base (< 4.20).
  • Picking upstream patches using appendPatches.
  • Disabling a broken test suite using dontCheck. Note, though, that we try to make them work whenever possible, so verify that the failure is definitely harmless before disabling a test suite.
  • If you need to inject something into the derivation phases etc. use overrideCabal.

When you’ve found a fix for a package, make sure to add a comment next to your override explaining why it is needed and ideally link an issue or PR that needs to be resolved upstream for us to drop the override (if no issues exist, do open one). All fixes should naturally be PR-ed against the haskell-updates branch.

Background information on how maintenance of haskellPackages works can be found here

Common Problems

Looking at the failures so far, it seems to me that the following things are responsible for most of the failures:

  • We are using QuickCheck >= 2.15 now. A lot of packages have a constraint of QuickCheck < 2.15 on their test suites. In most cases, this can just be relaxed (via doJailbreak or a patch).
  • We are using filepath >= 1.5 now which may break some packages.
  • We are using text >= 2.1.2 now. This breaks most packages that import Data.Text without further specification because text-2.1.2 added Data.Text.show which clashes with Prelude.show. These failures require applying an upstream patch or writing and submitting one.
  • We are using hashable >= 1.5 now. In most cases this just needs bounds to be relaxed.
  • We are using containers >= 0.7 now. A lot of packages have a constraint of <0.7, but this can probably be lifted in most cases.
  • We are using data-default >= 0.8 now. This means that all data-default-instances-* packages are more or less irreparabely broken and packages depending on them need to be migrated away. Packages that depend on data-default-class < 0.2 need their bounds relaxed if they don’t need any instances of Data.Default, otherwise migrated to data-default. C.f. the data-default changelog.
11 Likes
2

The automatically updated status page works again, so you can use that to look for failures again.

3

First Eval with Stackage LTS 24.6

4

The test suite of say which a few packages depend on is currently affected by a bug in text 2.1.2. This is resolved by text 2.1.3 which will be bundled with GHC 9.10.3 which hopefully releases in early September. The announcement for 9.10.3-rc4 says:

If all goes well the final release will be available the week of 1 September 2025.

This has the potential to delay landing the update, unfortunately though we may be heading for that time frame anyways. I personally won’t have the spare time to finish the bump until mid to late September unfortunately.

Also refer to my writeup on the haskell-updates PR.

2 Likes