GHC 9.8.4 tracking ticket

changed milestone to %9.8.4

marked the checklist item Add the release to the status page, including a link to the milestone. as completed

marked the checklist item Add the release to the status page, including a link to the milestone. as incomplete

changed the description

marked the checklist item Ensure that the Migration page is up-to-date as completed

marked the checklist item Check that Unicode database in base (libraries/base/cbits/README.Unicode) reflects current standard release (http://www.unicode.org/versions/latest/). as completed

marked the checklist item Remove "Included libraries" sections from old release notes as completed

marked the checklist item autoconf scripts updated as completed

marked the checklist item Release notes (docs/users_guide/x.y.z-notes.rst) written as completed

I have prepared https://gitlab.haskell.org/ghc/ghc/-/pipelines/103184 as a possible release pipeline for %9.8.4.

However, in the meantime we discovered another bug, this time in in os-string (or, rather, the bits of it vendored by filepath-1.4), which Zubin points out will affect HLS rather heavily. I think we may need to scuttle this pipeline and try again once a new filepath release has been cut with https://github.com/haskell/filepath/pull/240.

A new filepath release has been cut. I have bumped the submodule in f0ab9204 and started a new release pipeline: https://gitlab.haskell.org/ghc/ghc/-/pipelines/103364

It appears I will need to run yet another pipeline due to the release of unix-2.8.6.0 (#25502).

As well, during triage we decided that we should attempt to backport !10568 (closed) (addressing #22010 (closed)) as we have seen a few i386 users affected by potential Unique overflows.

The latest release pipeline https://gitlab.haskell.org/ghc/ghc/-/pipelines/103460 has almost passed. The head.hackage failures are all expected due to the unfortunate changes in deepseq. The only remaining concern is that the hadrian-multi job is now failing, making noise about unix and filepath. This seems foreboding...

The error is:

[ 236 of 1142] Compiling System.Posix.Env.PosixString ( /mnt/data/exp/ghc/ghc-9.8/.hadrian_ghci_multi/stage0/libraries/unix/build/System/Posix/Env/PosixString.hs, nothing )[unix-2.8.6.0-inplace]

libraries/unix/System/Posix/Env/PosixString.hsc:49:1: error:
    Could not find module ‘System.OsPath.Data.ByteString.Short’
    Perhaps you meant
      System.OsPath.Data.ByteString.Short (needs flag -package-id filepath-1.4.100.4)
      System.OsPath.Data.ByteString.Short (needs flag -package-id filepath-1.4.301.0)
      System.OsPath.Data.ByteString.Short.Hidden
   |
49 | import qualified "filepath" System.OsPath.Data.ByteString.Short as B
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

However, as expected, the response file for unix contains a dependency on filepath:

-hide-all-packages
-no-user-package-db
-package-env -
-package-db .hadrian_ghci_multi/stage0/inplace/package.conf.d
-this-unit-id unix-2.8.6.0-inplace
-package-id base-4.18.1.0
-package-id bytestring-0.12.1.0-inplace
-package-id filepath-1.4.301.0-inplace
-package-id time-1.12.2-inplace
...
-i/mnt/data/exp/ghc/ghc-9.8/libraries/unix
...

Moreover, the package registration for filepath-1.4.301.0-inplace contains System.OsPath.Data.ByteString.Short in its exposed-modules list.

Consulting with @mpickering, the problem here is that unix now uses package-qualified imports, yet Hadrian doesn't pass -this-package-name in its generated command-line.

I have opened #25509 (closed) fixing this issue and fixed it in !13628 (closed) .

It looks like it is now time for another release pipeline.

mentioned in issue #25509 (closed)

The next pipeline is https://gitlab.haskell.org/ghc/ghc/-/pipelines/103472.

I also realized that CentOS 7 still disabled Sphinx output. I suspect that may be due to an honest issue with the environment but I have speculatively started another release pipeline with Sphinx enabled (except for PDF output, which is highly unlikely to work in the existing image) on that platform in case this actually does work. If not then I plan to release with CentOS 7 being the one bindist lacking a manpage as this release has more than consumed its budget.

The pipeline for this is https://gitlab.haskell.org/ghc/ghc/-/pipelines/103482.

As I expected, the CentOS 7 build fails as sphinx is not present. Looking deeper, the reason is that the distribution ships an utterly ancient sphinx-1.1.3, which is almost certainly unable to build our documentation. The only other step that could be pursued would be to rebuild the image, including sphinx installed via pip. However, this would be significant work for unclear payoff on a platform that likely no one uses to fix an issue that we have already decided isn't worth fixing before 9.10. I will put this aside and bring the matter up with @maerwald.

marked the checklist item Ensure that submodules are on released tags (the below is produced using this script): as completed

marked the checklist item Non-released submodules up-to-date: as completed

GHC 9.8.4 tracking ticket

Pre-release checklist

Release candidate checklist (major-only)

Release checklist

Post-release checklist

Child items ...

Activity