Re: GHC 8.2.1-rc1 source tarball availability

I don't know how to produce a binary distribution but I did do a build on Mac OS 10.12.4 with XCode 8.3. It went flawlessly and subjectively seemed much faster than previous builds. I then did a cabal install of hlint and verified that hlint worked. On Tue, Apr 4, 2017 at 1:22 AM Ben Gamari

Re: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

Ryan Trinkle writes: > 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

Re: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

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.

Re: GHC 8.2.1-rc1 source tarball availability

Alan & Kim Zimmerman writes: > There is no tag in the source tree, which commit has been used? > As I mention in the message, I intentionally held off on pushing the tag to avoid the need to force push in case this commit ends up being bad. The tarball was produced from

Re: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

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

Re: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

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

RE: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

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-boun...@haskell.org]

Re: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

Also note that a minimal patch already exists which will ship in GHC 8.2: https://git.haskell.org/ghc.git/commitdiff/018ac7f4b2f7345e28d21fb1f99b44dbc79f6e85 It's 'just' a matter of packaging that up in a hotfix. On Tue, Apr 4, 2017 at 10:12 AM, Sebastian Graf wrote: > Hi,

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

Re: GHC 8.2.1-rc1 source tarball availability

$ tar xOf ghc-8.2.0.20170404-src.tar.xz ghc-8.2.0.20170404/GIT_COMMIT_ID ; echo d67f0471cd3584c5a548ff30c9023b599b598d3e On Tue, Apr 4, 2017 at 9:01 AM Alan & Kim Zimmerman wrote: > There is no tag in the source tree, which commit has been used? > > Alan > > On 4 April

Re: GHC 8.2.1-rc1 source tarball availability

There is no tag in the source tree, which commit has been used? Alan On 4 April 2017 at 06:21, Ben Gamari wrote: > > tl;dr: If you would like to produce a binary distribution for GHC >8.2.1-rc1 then let me know, grab the source distribution and >start