Oops. Pushed! On 21/12/25 15:37, Shayne Fletcher wrote:

Awesome. Thank-you! There appears not to be a ghc-9.0.2-release tag. Might this be addressed please?

Could you explain what you mean about the containers source not being "clean"? On Sun, Jan 23, 2022, 2:31 AM Jens Petersen wrote:

First of all a big thank you and congratulations on the highly anticipated 9.0.2 release.

I have been putting off this mail for a while: I actually built it last month right away in Fedora's new ghc9.0 package (available now for all current Fedora releases). Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to 9.0.2, since nightly-2022-01-10. :-)

However two points I wanted to mention:

- firstly (minor), the libraries/containers source is not clean (which explains why the tarball is so big)

- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400

I can't really see any good way to resolve this in the short term.

Thanks, Jens

On Sun, 26 Dec 2021 at 04:23, Zubin Duggal wrote:

...

The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/).

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

There's no such directory in the Hackage or GitHub source. I guess it must have crept in on the GHC side? On Sun, Jan 23, 2022, 4:13 AM Jens Petersen wrote:

On Sun, 23 Jan 2022 at 15:40, David Feuer wrote:

...

Could you explain what you mean about the containers source not being "clean"?

I forgot to say "in the source tarball" explicitly. If you look in libraries/containers/containers/dist-install, you can see what I am talking about. (I first discovered this because it broke the Fedora build - so I just remove it before building.)

Jens

On Sun, Jan 23, 2022, 2:31 AM Jens Petersen wrote:

...

...

First of all a big thank you and congratulations on the highly anticipated 9.0.2 release.

I have been putting off this mail for a while: I actually built it last month right away in Fedora's new ghc9.0 package (available now for all current Fedora releases). Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to 9.0.2, since nightly-2022-01-10. :-)

However two points I wanted to mention:

- firstly (minor), the libraries/containers source is not clean (which explains why the tarball is so big)

- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400

I can't really see any good way to resolve this in the short term.

Thanks, Jens

On Sun, 26 Dec 2021 at 04:23, Zubin Duggal wrote:

...

The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/).

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

I wrote WinIO a couple of times when I meant to type Win32. Sorry! On 23 January 2022 1:32:15 pm IST, Zubin Duggal wrote:

...

- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400

We needed to bump Win32 as per a request from the maintainer made at https://gitlab.haskell.org/ghc/ghc/-/issues/20017

Bumping it from 2.10.0 to 2.10.1.0 ran into https://github.com/haskell/win32/issues/174, which was fixed by https://github.com/haskell/win32/pull/175

Given this, our options at the time were:

1) Backport pull request #175 to 2.10.1 and wait for a new release of Win32

2) Revert https://github.com/haskell/win32/pull/160 in Win32 2.10, which is what caused WinIO/#174

3) Use Win32 2.12.0.1, which contains the requested fix(ghc/#20017), as well as the explicit exports added by #175, along with a few other minor changes from Win32 2.11 which I don't think are responsible for any of the pain discussed in the stackage issue.

I made the decision to go with option 3 in the interests of getting the release out.

However, if I understand correctly, we would still end up with the same problems as brought up in the stackage issue if we went with option 1.

We might have avoided some of this pain if we went with option 2 and reverted the offending commits from WinIO 2.10 instead of using explicit import lists. But removing features from a major release of a library didn't seem like a good idea at a time, and would have delayed the 9.0.2 release even more.

I hope this makes the reasoning for the decision clearer, and I do apologise for any pain caused. I did believe that under the circumstances bumping WinIO to 2.12.0.1 was the best way forward. Perhaps option 2 would have been better in retrospect, but at the time the benefits for such a change (in particular the regression in functionality) in a major release of Win32 were not so clear.

Cheers, Zubin _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users