I would strongly urge that any new tarballs be released under new names, and that the old tarballs be kept in place. Changing existing tarball URLs silently causes breakage for Nix, and, I would imagine, for any other build systems that are particularly concerned with reproducibility. Nix packages based on GHC use an SHA-256 hash of the tarball to check it when downloading, which of course will be broken by any change, no matter how minor. Of course, this doesn't necessarily impact the version number directly. On Tue, Apr 4, 2017 at 8:15 AM, Phyx wrote:

We have discussed a few options on what to do, but haven't gotten a conclusion/concensus yet.

Last we talked one option was presented to just re-tar the 7.10.3 and 8.0.2 tarballs with the fix. The gcc wrapper does not affect code generation of the compiler, it's just there to correct paths that are hard-coded in gcc because it was built to be used in MSYS2.

7.10.3 would be needed since we still support bootstrapping using it. This would be the easiest solution.

Ben what do you think about changing the already released tarballs? Or would you prefer a full new release?

On Tue, 4 Apr 2017, 09:18 Simon Peyton Jones via ghc-devs, < ghc-devs@haskell.org> wrote:

...

Yikes that sounds bad!

I just wanted to raise awareness and offer myself to do guided grunt work (if there is any) to push out a hotfix/inplace patch release for GHC 8.0.2.

Help would be fantastic. Phyx, Ben, etc: do we have a plan?

Simon

*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Sebastian Graf *Sent:* 04 April 2017 09:12 *To:* ghc-devs *Subject:* Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

Hi,

when the Creators Update finally hits Windows 10 stable on April 11th (next week), every currently available GHC will be broken by it.

See [1] for the previous discussion, [2] and [3] for the tickets discussing this. From what I read on the GHC 8.2 status wiki page, there might be an interval of some weeks where it will not be possible to compile a Haskell program on any up-to-date Windows 10 installation.

I just wanted to raise awareness and offer myself to do guided grunt work (if there is any) to push out a hotfix/inplace patch release for GHC 8.0.2.

Greetings,

Sebastian

[1] http://haskell.1045720.n5.nabble.com/FW-GHC-on-Windows- 10-15019-td5853491.html

[2] https://ghc.haskell.org/trac/ghc/ticket/13411

[3] https://ghc.haskell.org/trac/ghc/ticket/13472 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Phyx writes:

We have discussed a few options on what to do, but haven't gotten a conclusion/concensus yet.

Tamar and I have discussed this on IRC in the passed. I tend to agree that we will need to, at the very least, put out a new 8.0.2. I'm not sure about 7.10. Moreover, there is reportedly a non-negligible fraction of users still using 7.8 releases, although I'm not keen on going back that far given that this was pre-submodules.

Last we talked one option was presented to just re-tar the 7.10.3 and 8.0.2 tarballs with the fix. The gcc wrapper does not affect code generation of the compiler, it's just there to correct paths that are hard-coded in gcc because it was built to be used in MSYS2.

7.10.3 would be needed since we still support bootstrapping using it. This would be the easiest solution.

Ben what do you think about changing the already released tarballs? Or would you prefer a full new release?

We certainly can't change the existing tarballs. However, we could just push out a 7.10.4 (or perhaps 7.10.3b, I'm unsure) release with binary distributions for Windows only. There are a few unrelated patches on the ghc-7.10 branch that weren't present in 7.10.3, but I believe they are quite low-risk. Cheers, - Ben