As many of you likely saw recently, GHC 7.10.1 release candidate 1 was just released. As usually occurs with this process, there is currently lots of breakage in the Haskell library ecosystem. Herbert asked me today if I had plans to throw Stackage at the GHC 7.10 release candidate.

I've used Stackage in the past to be a catalyst to test out packages before release. Until now, I've needed to wait until people relax their upper bounds on Hackage to do a proper test. However, it would be useful to get more information up front. With the newly overhauled Stackage build system, this turned out to be easy: just skip the bounds checks, and pass --allow-newer to cabal configure.

I've already opened an issue about restrictive upper bounds preventing GHC 7.10 packages, namely Cabal, base, bytestring, deepseq, ghc, template-haskell, time and transformers. The rest of this blog post will cover issues I ran into while running the actual build, ignoring version bound constraints.

haddock --hoogle is broken

This is easily reproducible. Unpack a package (BoundedChan in this case) and run:

$ cabal haddock --hoogle
Running Haddock for BoundedChan-
Preprocessing library BoundedChan-
Haddock coverage:
 100% ( 10 / 10) in 'Control.Concurrent.BoundedChan'
haddock: internal error: expectJust getPackageDetails

After this error message, I disabled --hoogle. I've already opened a Trac ticket for this.

Build and test errors

I turned off reporting of packages that failed due to a build failure in one of their dependencies, since at this point it's simply noise. With those filtered out, the following are the primary build and test failures:

Altogether, 355 packages attempted builds, with 62 failures. Stackage normally builds about 820 packages, so approximately 465 packages depend on a package which failed to build.

I've uploaded a tarball with all of the build and test logs included. If there are any questions about the results, let me know. I've saved all changes for this build system to the ghc7.10 branch of the stackage repo, so I'll be able to easily run this analysis again in the future.

Do you like this blog post and need help with industrial Haskell, Rust or DevOps? Contact us.

Share this