7.8 branch is created, HEAD is now open, and a note on merges

Hello all, I've just created the 7.8 branch after tying off some of the final loose ends. In its current state, I expect the branch as it is now to become RC1 within the day. I plan on starting builds for the following soon: - OS X 10.7 and OS X 10.9 - Linux i386/amd64 (likely based on Debian Wheezey) - Windows i386/amd64 (many thanks to Kyrill Briantsev for the heroic last-minute linker fixes!) I'll send a (GPG-signed) email containing SHA1 hashes when they're done. Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): - Older glibc-2.5 based systems (e.g. CentOS, - a few users have talked about this wrt binary releases, where I don't think GHC works.) - FreeBSD - Pali, if you'd like to do this, feel free, and let me know. This means I'll (mostly) be waiting around today, so feel free to shoot questions. As of now, this means HEAD is now version 7.9, and you're free to push wacky experiments or changes now, if you've been holding off. You'll probably want to clean your whole tree, since this means the interface file versions etc will change. Finally, we picked up a good amount of new committers this year, so let's remind people of the merging policy: what happens if you need to merge something you did to the 7.8 branch? There are two main avenues for this to happen: * Someone reports a bug against the 7.8 RC on Trac. You decide to fix it and do so. Now what? 1) Please commit the bug to master, and confirm it's a fix. 2) Go to the bug, and instead of closing it, change the ticket status to 'merge'. 3) I will cherry-pick it over to the 7.8 branch for you - nothing else needed. * There's not a recorded bug, but you do push a change, and you think it should be merged (maybe a typo or something.) In this case, I'd ask you please CC me on the email sent to ghc-commits@haskell.org which is related to your commit, and just say "Please merge" or somesuch. I'll come over the commits with such a response. This goes for all changes - submodule updates, typos, real fixes, etc. It's likely me and Herbert will restrict the Gitolite permissions to only allow the two of us to touch the ghc-7.8 branch. So it's really important you put us in the loop, ASAP. If you don't do one of these two things, it's highly likely I will miss it, and not merge it. If you have questions, please ask me or Herbert. If there's a merge conflict, we can discuss it. Thanks -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On Wed, Jan 29, 2014 at 10:49 AM, Austin Seipp
Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): [..] - FreeBSD - Pali, if you'd like to do this, feel free, and let me know.
Sure, I can do it.
This means I'll (mostly) be waiting around today, so feel free to shoot questions.
I guess it would useful to know exactly which version to build. That is, is it enough to do release builds (by setting RELEASE to "yes") with the HEAD of the ghc-7.8 branch (of today)...?

Thanks!
I'll follow up with you shortly. My plan was actually to create a
fingerprint of the repository, so you can just checkout a tree, use
the fingerprint, and build the RC from that. The setup would just be a
default perf build (i.e. no custom build.mk at all, just a regular
boot+configure+make+binary-dist.)
Right now I'm going over a few final touch-ups with Herbert before I
start building everything (we might cherry-pick one or two minor
things to base here momentarily.) After that I'll fingerprint and send
it out.
Also, for RCs, I believe we traditionally keep RELEASE=NO, so the
version number doesn't come off as "7.8" but as "7.8.<date>" instead -
indicative of it being "not the final version". So you shouldn't need
to tweak anything - just use the fingerprint and build.
On Wed, Jan 29, 2014 at 6:47 AM, Páli Gábor János
On Wed, Jan 29, 2014 at 10:49 AM, Austin Seipp
wrote: Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): [..] - FreeBSD - Pali, if you'd like to do this, feel free, and let me know.
Sure, I can do it.
This means I'll (mostly) be waiting around today, so feel free to shoot questions.
I guess it would useful to know exactly which version to build. That is, is it enough to do release builds (by setting RELEASE to "yes") with the HEAD of the ghc-7.8 branch (of today)...?
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On Wed, Jan 29, 2014 at 2:13 PM, Austin Seipp
Right now I'm going over a few final touch-ups with Herbert before I start building everything (we might cherry-pick one or two minor things to base here momentarily.)
Okay. By the way, are you aware of this error (and there may be similar ones -- it is due to the version bump, so it happens with ghc-7.8): utils/haddock/src/Haddock/InterfaceFile.hs:85:2: error: #error Unsupported GHC version gmake[1]: *** [utils/haddock/dist/build/.depend.haskell] Error 1 gmake: *** [all] Error 2
So you shouldn't need to tweak anything - just use the fingerprint and build.
Excellent!

Blargh, I'll fix this shortly. Thanks Pali.
On Wed, Jan 29, 2014 at 7:16 AM, Páli Gábor János
On Wed, Jan 29, 2014 at 2:13 PM, Austin Seipp
wrote: Right now I'm going over a few final touch-ups with Herbert before I start building everything (we might cherry-pick one or two minor things to base here momentarily.)
Okay. By the way, are you aware of this error (and there may be similar ones -- it is due to the version bump, so it happens with ghc-7.8):
utils/haddock/src/Haddock/InterfaceFile.hs:85:2: error: #error Unsupported GHC version gmake[1]: *** [utils/haddock/dist/build/.depend.haskell] Error 1 gmake: *** [all] Error 2
So you shouldn't need to tweak anything - just use the fingerprint and build.
Excellent!
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Austin,
Blargh, I'll fix this shortly. Thanks Pali.
Please do. I also hit upon this bug. I could build GHC head yesterday but not today. P.S. Even if this is fixed, "validate" does not work on my Mac recently due to a haddock problem of the xhtml library. Does anyone see this problem? --Kazu

On 29/01/14 14:04, Kazu Yamamoto (山本和彦) wrote:
Austin,
Blargh, I'll fix this shortly. Thanks Pali.
Please do. I also hit upon this bug. I could build GHC head yesterday but not today.
P.S.
Even if this is fixed, "validate" does not work on my Mac recently due to a haddock problem of the xhtml library. Does anyone see this problem?
--Kazu
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
I'll try building now. What's the error? -- Mateusz K.

Also sending to the list.
---------------------------
Kazu,
I fixed the __GLASGOW_HASKELL__ check on both HEAD and the 7.8 branch.
As for the bug you are talking of - yes, I made a release note about
this the other day. The problem is that due to a bad interaction with
Clang, somehow the module downsweep gets broken in an odd way
(presumably due to something being preprocessed incorrectly.) This
does not affect every library actually - but xhtml is one of them (for
example, 'text' works fine on Mavericks using Clang.) I also haven't
yet pinned down why for example GHC is fine, but Haddock is not
(considering they should mostly do the same thing.)
Unfortunately I do not have any more time to fix this, because keeping
the RC delayed continuously has a cost (and it's been delayed a lot.)
I will reapproach this problem shortly after the first RC is done as
it will undoubtly cause some issues. But I just don't have time at
this exact moment to fix it (which may end up in integrating cpphs
into GHC. I'm not sure yet.)
For the record, this error occurs fairly late in the ./validate script
- it's for testing the in-place binary distribution after a build, but
before the testsuite is run. In the mean time, you can just do 'cd
testsuite && make fast' to run all your tests after you have seen this
error. I simply do not have a sensible, easy fix right now.
I sincerely apologize since this is annoying. But I really am out of
time right now and I think we'll have to eat this one for the RC.
(I should also note that, in the Real World, this will only make a
difference in documentation building, not package installation. The
xhtml library actually installs just fine - it is the doc generation
which fails.)
On Wed, Jan 29, 2014 at 8:04 AM, Kazu Yamamoto
Austin,
Blargh, I'll fix this shortly. Thanks Pali.
Please do. I also hit upon this bug. I could build GHC head yesterday but not today.
P.S.
Even if this is fixed, "validate" does not work on my Mac recently due to a haddock problem of the xhtml library. Does anyone see this problem?
--Kazu
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Hi Austin, It seems to me that the patch for Cabal in ticket 8266 is still missing: https://ghc.haskell.org/trac/ghc/ticket/8266 diff --git a/Cabal/Distribution/Simple/GHC.hs b/Cabal/Distribution/Simple/GHC.hs index c7ea633..78cdcbb 100644 --- a/Cabal/Distribution/Simple/GHC.hs +++ b/Cabal/Distribution/Simple/GHC.hs @@ -867,11 +867,6 @@ buildOrReplLib forRepl verbosity pkg_descr lbi lib clbi = do ghcOptDynLinkMode = toFlag GhcDynamicOnly, ghcOptInputFiles = dynamicObjectFiles, ghcOptOutputFile = toFlag sharedLibFilePath, - -- For dynamic libs, Mac OS/X needs to know the install location - -- at build time. - ghcOptDylibName = if buildOS == OSX - then toFlag sharedLibInstallPath - else mempty, ghcOptPackageName = toFlag pkgid, ghcOptNoAutoLinkPackages = toFlag True, ghcOptPackageDBs = withPackageDB lbi, If Duncan is busy at this moment, can you take over the merge job? --Kazu
Hello all,
I've just created the 7.8 branch after tying off some of the final loose ends.
In its current state, I expect the branch as it is now to become RC1 within the day. I plan on starting builds for the following soon:
- OS X 10.7 and OS X 10.9 - Linux i386/amd64 (likely based on Debian Wheezey) - Windows i386/amd64 (many thanks to Kyrill Briantsev for the heroic last-minute linker fixes!)
I'll send a (GPG-signed) email containing SHA1 hashes when they're done.
Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it):
- Older glibc-2.5 based systems (e.g. CentOS, - a few users have talked about this wrt binary releases, where I don't think GHC works.) - FreeBSD - Pali, if you'd like to do this, feel free, and let me know.
This means I'll (mostly) be waiting around today, so feel free to shoot questions.
As of now, this means HEAD is now version 7.9, and you're free to push wacky experiments or changes now, if you've been holding off. You'll probably want to clean your whole tree, since this means the interface file versions etc will change.
Finally, we picked up a good amount of new committers this year, so let's remind people of the merging policy: what happens if you need to merge something you did to the 7.8 branch? There are two main avenues for this to happen:
* Someone reports a bug against the 7.8 RC on Trac. You decide to fix it and do so. Now what?
1) Please commit the bug to master, and confirm it's a fix. 2) Go to the bug, and instead of closing it, change the ticket status to 'merge'. 3) I will cherry-pick it over to the 7.8 branch for you - nothing else needed.
* There's not a recorded bug, but you do push a change, and you think it should be merged (maybe a typo or something.) In this case, I'd ask you please CC me on the email sent to ghc-commits@haskell.org which is related to your commit, and just say "Please merge" or somesuch. I'll come over the commits with such a response.
This goes for all changes - submodule updates, typos, real fixes, etc. It's likely me and Herbert will restrict the Gitolite permissions to only allow the two of us to touch the ghc-7.8 branch. So it's really important you put us in the loop, ASAP.
If you don't do one of these two things, it's highly likely I will miss it, and not merge it. If you have questions, please ask me or Herbert. If there's a merge conflict, we can discuss it.
Thanks
-- Regards,
Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hello Kazu, ..as this is a Cabal issue, this needs to be handled upstream; could you please file an issue at https://github.com/haskell/cabal/issues/new and mention there that we need that to be cherry-picked into the `1.18` branch as well -- as soon as it's in the 1.18 branch, we can update the GHC source tree to include that fix. Thanks, hvr On 2014-01-30 at 02:05:39 +0100, Kazu Yamamoto (山本和彦) wrote:
Hi Austin,
It seems to me that the patch for Cabal in ticket 8266 is still missing:
https://ghc.haskell.org/trac/ghc/ticket/8266
diff --git a/Cabal/Distribution/Simple/GHC.hs b/Cabal/Distribution/Simple/GHC.hs index c7ea633..78cdcbb 100644 --- a/Cabal/Distribution/Simple/GHC.hs +++ b/Cabal/Distribution/Simple/GHC.hs @@ -867,11 +867,6 @@ buildOrReplLib forRepl verbosity pkg_descr lbi lib clbi = do ghcOptDynLinkMode = toFlag GhcDynamicOnly, ghcOptInputFiles = dynamicObjectFiles, ghcOptOutputFile = toFlag sharedLibFilePath, - -- For dynamic libs, Mac OS/X needs to know the install location - -- at build time. - ghcOptDylibName = if buildOS == OSX - then toFlag sharedLibInstallPath - else mempty, ghcOptPackageName = toFlag pkgid, ghcOptNoAutoLinkPackages = toFlag True, ghcOptPackageDBs = withPackageDB lbi,
If Duncan is busy at this moment, can you take over the merge job?

Hello Herbert,
Hello Kazu,
..as this is a Cabal issue, this needs to be handled upstream; could you please file an issue at
Done. https://github.com/haskell/cabal/issues/1660 --Kazu
participants (5)
-
Austin Seipp
-
Herbert Valerio Riedel
-
Kazu Yamamoto
-
Mateusz Kowalczyk
-
Páli Gábor János