On 30/03/14 21:44, Carter Schonwald wrote:

Mark: will we try to have hp use 7.8.2? A whole bunch of bug fixes are planned for that, and likewise the patches for simplifying the cpp configuration as part of the settings files are slated for 7.8.2

I'd also like to recommend that 7.8.2 is used for similar reasons.

On Sunday, March 30, 2014, Mark Lentczner wrote:

...

SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8... I'd like to get going on nailing down package versions.

I've been working intently on the new Haskell Platform build process (see the new-build branchhttps://github.com/haskell/haskell-platform/tree/new-build), and have been building platforms against the release. Here is the description of versions I'm working with:

[ incGHC "7.8" , incGHCLib "array" "0.5.0.0" , incGHCLib "base" "4.7.0.0" , incGHCLib "bytestring" "0.10.4.0" , incGHCLib "Cabal" "1.18.1.3" , incGHCLib "containers" "0.5.4.0" , incGHCLib "deepseq" "1.3.0.2" , incGHCLib "directory" "1.2.0.2" , incGHCLib "filepath" "1.3.0.2" , incGHCLib "haskell2010" "1.1.1.1" , incGHCLib "haskell98" "2.0.0.3" , incGHCLib "hpc" "0.6.0.1" , incGHCLib "old-locale" "1.0.0.6" , incGHCLib "old-time" "1.1.0.2" , incGHCLib "pretty" "1.1.1.1" , incGHCLib "process" "1.2.0.0" , incGHCLib "template-haskell" "2.9.0.0" , incGHCLib "time" "1.4.1" , incGHCLib "transformers" "0.3.0.0"

, notWindows $ incGHCLib "unix" "2.7.0.1" , onlyWindows $ incGHCLib "Win32" "2.3.0.1"

, incLib "async" "2.0.1.5" , incLib "attoparsec" "0.10.4.0" , incLib "case-insensitive" "1.1.0.3" , incLib "cgi" "3001.1.7.5" , incLib "fgl" "5.4.2.4" , incLib "GLUT" "2.5.0.2" , incLib "GLURaw" "1.4.0.0" , incLib "haskell-src" "1.0.1.5" , incLib "hashable" "1.2.1.0" , incLib "html" "1.0.1.2" , incLib "HTTP" "4000.2.10" , incLib "HUnit" "1.2.5.2" , incLib "mtl" "2.1.2" , incLib "network" "2.4.2.2" , incLib "OpenGL" "2.9.1.0" , incLib "OpenGLRaw" "1.4.0.0" , incLib "parallel" "3.2.0.4" , incLib "parsec" "3.1.5" , incLib "primitive" "0.5.2.1" , incLib "QuickCheck" "2.6" , incLib "random" "1.0.1.1" , incLib "regex-base" "0.93.2" , incLib "regex-compat" "0.95.1" , incLib "regex-posix" "0.95.2" , incLib "split" "0.2.2" , incLib "stm" "2.4.2" , incLib "syb" "0.4.1" , incLib "text" "1.1.0.0" , incLib "unordered-containers" "0.2.3.3" , incLib "vector" "0.10.9.1" , incLib "xhtml" "3000.2.1" , incLib "zlib" "0.5.4.1"

, incTool "cabal-install" "1.18.0.3" , incTool "alex" "3.1.2" , incTool "happy" "1.19.2"

, incTool "hscolour" "1.20.3" , incTool "haddock" "2.14.0"

Haddock 2.14.0 was effectively an internal release. If the platform were to be released today, you should be using 2.14.1. It contains some extra bugfixes. Following up on my request for waiting until 7.8.2, this will again go up after further bugfixes follow (at the moment doc building is broken for certain packages due to some Clang problems).

...

]

However, there are some issues to contend with:

*Haddock* - is there any reason not to use the version built and distributed with GHC 7.8?

There is no reason to do so as long as you pick the release with the various bugfixes in place.

...

*Shipped w/GHC* - GHC 7.8 ships with several more packages than we include in the platform. I want to review how these are handled:

*possibly include in platform*

- binary-0.7.1.0 - ghc-prim-0.3.1.0 - hoopl-3.10.0.0

*shouldn't include in platform* - bin-package-db-0.0.0.0 - integer-gmp-0.5.1.0 - rts-1.0

*shipped with GHC, but not registered in pkg-db, yet possible useful to include in platform:*

- haskeline-0.7.1.2 - terminfo-0.4.0.0 - xhtml-3000.2.1 -- already in platform, but HP re-builds it... seems silly?

*cgi* - no longer builds, and we've been unwilling to bring it forward because it pulls in MonadCatchIO-mtl

*hscolour* - never approved as part of platform, but we use it to generate the haddock in both GHC and the Platform - shouldn't we just include it?

*New packages:* Last time we had a bunch we wanted... but timing, especially vis-a-vis 7.8 and the new Builder classes, caused us to delay them. Shall we include:

aeson

dlist (needed by aeson, which version?)

scientific (needed by aeson - or get aeson to subsume that code?)

*anything else? now's the time to propose!*

- Mark

+1 for aeson merely because there are so many packages nowadays that depend on it, it seems like it would be a worthwhile addition but I don't have strong feelings otherwise. -- Mateusz K.

On 30/03/14 23:43, Mark Lentczner wrote:

*happy *bumped to* 1.19.3* *alex *bumped to* 3.1.3* *haddock *bumped to* 2.14.1*

*- but question about tying to GHC release still open: The concern is since GHC ships with it's doc built with the haddock executable it ships, will we have problems building the rest of the docs with a later haddock -- and having all the cross references work?*

It will work provided that the Haddock used has not had the interface file version changed. While we don't plan on doing this, I don't see why this is a concern: you're planning to use Haddock that ships with the GHC version you're going to use, right? All the documentation that will come with it will be generated with the same version.

As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info.

I don't think there's an official plan but the window for 7.8.1 features is pretty much closed but there are still fixes &c that people want in. I think it has been pretty much agreed to (at least in #ghc on Freenode) that 7.8.2 is happening although I can't speak for the GHC team here.

I'm very reluctant to hold out for an unknown GHC release. Unless we have good reason to think that GHC 7.8.1 is a bad release and will leave scads of people with broken build systems.... I'd like to continue to plan on releasing HP in mid May (so on schedule for 2014.2.0.0). As such, unless the turn of 7.8.2 comes within a week or two of 7.8.1 - let's stick with 7.8.1.

Well, 7.8.1 is not actually out yet but from what I gather, 7.8.2 is to follow very soon afterwards. Again, this is just hearsay. As I mentioned, we have a pretty bad bug to do with Clang where everyone on OSX won't be able to build docs for certain libraries. I believe Austin found a workaround but I don't know if he's planning to monkey-patch that into 7.8.1 or not (and if he is, we'll have to bump the Haddock version anyway). I am sure there are other problems holding up the release at this point. Perhaps it would be worthwhile asking on ghc-devs?

Finally - note that part of my big push to totally re-write the Haskell Platform is so that we can all feel more confident turning a version more quickly if we need. If 7.8.2 comes out this Summer, and we think it is an important enough improvement - we can turn HP too.

- Mark

​

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Mateusz K.

Simon Peyton Jones wrote

We have not begun to think about when to release 7.8.2. It’ll depend on what issues show up in 7.8.1 and how urgent they seem to be. We have delayed 7.8.1 for ages, and given masses of warning about the release, so I’d be sad if there are known, show-stopping bugs in it that we already know about. If there really really really are, maybe we should delay 7.8.1 further. But that process can go on indefinitely (as we have already seen), so I’m pretty reluctant.

But I’d certainly listen to a consensus view from the HP team. You represent our customers.

If I've understood #8736 correctly, GHCi on Windows can't load modules that were compiled with --dynamic-too. That's a pretty nasty regression, as --dynamic-too will now be the default for anything used by TH. -- View this message in context: http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next-release-2... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

I would have expected 7.8.1 will need some work before it is ready for the platform and holding up 7.8.1 further seems like a bad idea, so isn’t 7.8.2 the first real 7.8 candidate for the platform? Is there any reason why we cannot base 2014.2.0.0 on 7.6.3 again? Chris From: Simon Peyton-Jones Date: Monday, 31 March 2014 07:55 To: Mark Lentczner , "haskell-platform@projects.haskell.org" , Haskell Libraries Subject: RE: Gearing up (again) for the next release: 2014.2.0.0 As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info. We have not begun to think about when to release 7.8.2. It’ll depend on what issues show up in 7.8.1 and how urgent they seem to be. We have delayed 7.8.1 for ages, and given masses of warning about the release, so I’d be sad if there are known, show-stopping bugs in it that we already know about. If there really really really are, maybe we should delay 7.8.1 further. But that process can go on indefinitely (as we have already seen), so I’m pretty reluctant. But I’d certainly listen to a consensus view from the HP team. You represent our customers. Simon From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Mark Lentczner Sent: 30 March 2014 23:44 To: haskell-platform@projects.haskell.org; Haskell Libraries Subject: Re: Gearing up (again) for the next release: 2014.2.0.0 happy bumped to 1.19.3 alex bumped to 3.1.3 haddock bumped to 2.14.1

- but question about tying to GHC release still open: The concern is since GHC ships with it's doc built with the haddock executable it ships, will we have problems building the rest of the docs with a later haddock -- and having all the cross references work?

As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info. I'm very reluctant to hold out for an unknown GHC release. Unless we have good reason to think that GHC 7.8.1 is a bad release and will leave scads of people with broken build systems.... I'd like to continue to plan on releasing HP in mid May (so on schedule for 2014.2.0.0). As such, unless the turn of 7.8.2 comes within a week or two of 7.8.1 - let's stick with 7.8.1. Finally - note that part of my big push to totally re-write the Haskell Platform is so that we can all feel more confident turning a version more quickly if we need. If 7.8.2 comes out this Summer, and we think it is an important enough improvement - we can turn HP too. - Mark ​ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Thanks Simon for confirming the status. Short: I see no reason not to proceed with 7.8.1 in the next HP. Long: On Mon, Mar 31, 2014 at 2:44 AM, Chris Dornan wrote:

I would have expected 7.8.1 will need some work before it is ready for the platform and holding up 7.8.1 further seems like a bad idea, so isn’t 7.8.2 the first real 7.8 candidate for the platform?

This has been a common sentiment here. But I believe that 7.8.1, and GHC in general, is being released with due diligence toward stability on all three major OS platforms. I don't expect to see this release, or any GHC release going forward that immediately needs to be retracted, or breaks for many users, or should be avoided. Of course GHC will ship with bugs - all large software does. We cannot ever wait for a bug-free release. Or even "relatively bug-free" or "no show stoppers" release, because with this many developers, maintainers, committers, and just sheer volume of code, we will never all agree here on the platform team what constitutes those states. If we start delaying for some unknown future release... we'll be waiting for 7.8.3 and 7.8.4, etc... We must trust that the GHC team will triage bugs and release when ready. With software this big, we all have a responsibility to stable and dependable releases. - Mark

On 30/03/14 23:43, Mark Lentczner wrote:

*happy *bumped to* 1.19.3* *alex *bumped to* 3.1.3* *haddock *bumped to* 2.14.1*

*- but question about tying to GHC release still open: The concern is since GHC ships with it's doc built with the haddock executable it ships, will we have problems building the rest of the docs with a later haddock -- and having all the cross references work?*

As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info.

I'm very reluctant to hold out for an unknown GHC release. Unless we have good reason to think that GHC 7.8.1 is a bad release and will leave scads of people with broken build systems.... I'd like to continue to plan on releasing HP in mid May (so on schedule for 2014.2.0.0). As such, unless the turn of 7.8.2 comes within a week or two of 7.8.1 - let's stick with 7.8.1.

Finally - note that part of my big push to totally re-write the Haskell Platform is so that we can all feel more confident turning a version more quickly if we need. If 7.8.2 comes out this Summer, and we think it is an important enough improvement - we can turn HP too.

- Mark

​

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hi again, We had just released Haddock 2.14.2 containing some minor (but nice) bugfixes and that's the version that 7.8.1 will ship with. I don't know if it matters to you (are you just going with what version ships with GHC?) but I thought I'd let you know so you can update your list. Thanks -- Mateusz K.

On Thu, Apr 10, 2014 at 2:32 PM, Yitzchak Gale wrote:

A serious bug was inadvertently included in the released 7.8.1:

https://ghc.haskell.org/trac/ghc/ticket/8978

Well.. that's pretty ick. M. Snoyberg - when you say "broken a number of my packages", do you mean the Yesod suite? Let's see how GHC central decides to handle this... if it is a quick turn with just this fix, then we'll be able to move to 7.8.2 quickly. If not, then depending on what packages are broken with it, we'll need to decide the next course of action. -Mark

On Friday, April 11, 2014, Mark Lentczner wrote:

On Thu, Apr 10, 2014 at 2:32 PM, Yitzchak Gale javascript:_e(%7B%7D,'cvml','gale@sefer.org');

...

wrote:

...

A serious bug was inadvertently included in the released 7.8.1:

https://ghc.haskell.org/trac/ghc/ticket/8978

Well.. that's pretty ick. M. Snoyberg - when you say "broken a number of my packages", do you mean the Yesod suite?

Let's see how GHC central decides to handle this... if it is a quick turn with just this fix, then we'll be able to move to 7.8.2 quickly. If not, then depending on what packages are broken with it, we'll need to decide the next course of action.

-Mark

I've gotten reports on three or four different packages so far. But the problem is that I'm now getting reports of build failures on packages that seemed to succeed when I first tested, so I don't know exactly what's going on. Note that these are regressions since rc2. What I'd really like to do is get the candidate release build and run a stackage build with it to see if there are any other regressions. Michael

On Fri, Apr 11, 2014 at 6:36 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

michael, yes, these are a bug that snuck in POST RC2, its getting fixed this week. Contact Austin and ask for a binary, or build from 7.8 tip

I just woke up, came downstairs, and kicked off a GHC build. If anyone has a Linux 64-bit binary ready and can send me the link, I'll be able to test that much sooner. Someone has also reported a second bug, which may or may not be fixed by the proposed 7.8.2[1]. Hopefully I'll have more information in the next few hours. Michael [1] https://github.com/yesodweb/yesod/issues/713

On Thu, Apr 10, 2014 at 11:30 PM, Michael Snoyman wrote:

...

On Friday, April 11, 2014, Mark Lentczner wrote:

...

On Thu, Apr 10, 2014 at 2:32 PM, Yitzchak Gale wrote:

...

A serious bug was inadvertently included in the released 7.8.1:

https://ghc.haskell.org/trac/ghc/ticket/8978

Well.. that's pretty ick. M. Snoyberg - when you say "broken a number of my packages", do you mean the Yesod suite?

Let's see how GHC central decides to handle this... if it is a quick turn with just this fix, then we'll be able to move to 7.8.2 quickly. If not, then depending on what packages are broken with it, we'll need to decide the next course of action.

-Mark

I've gotten reports on three or four different packages so far. But the problem is that I'm now getting reports of build failures on packages that seemed to succeed when I first tested, so I don't know exactly what's going on. Note that these are regressions since rc2.

What I'd really like to do is get the candidate release build and run a stackage build with it to see if there are any other regressions.

Michael

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Fri, Apr 11, 2014 at 8:26 AM, Michael Snoyman wrote:

On Fri, Apr 11, 2014 at 6:49 AM, Michael Snoyman wrote:

...

On Fri, Apr 11, 2014 at 6:36 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

michael, yes, these are a bug that snuck in POST RC2, its getting fixed this week. Contact Austin and ask for a binary, or build from 7.8 tip

I just woke up, came downstairs, and kicked off a GHC build. If anyone has a Linux 64-bit binary ready and can send me the link, I'll be able to test that much sooner.

Someone has also reported a second bug, which may or may not be fixed by the proposed 7.8.2[1]. Hopefully I'll have more information in the next few hours.

Michael

[1] https://github.com/yesodweb/yesod/issues/713

OK, my GHC build is now complete. I can confirm that the original bug has in fact been fixed. I can also confirm that Yesod issue 713 about yesod-auth is *also* resolved, even though it was not part of the original GHC ticket. Furthermore, the entire yesod-platform compiles (after fixing a language-javascript version number).

I'm going to go ahead with a Stackage build to look for any other regressions, which should be complete in the next 4 hours or so (maybe less). But from the Yesod world, you can consider tip[1] signed off on.

Michael

[1] SHA: 5dd87133d47595974b9eeefcd3b6fd1a6bc2e95d

Wow, Stackage built a lot faster than I thought... I wonder if GHC 7.8 compiles code faster. Below is the list of build failures, which is a few less than failed with 7.8.0rc2. So yet another signoff that we're good to go on the 7.8.2 release. Michael cabal: Error: some packages failed to install: MFlow-0.4.4 depends on Workflow-0.8.0.8 which failed to install. Workflow-0.8.0.8 failed during the building phase. The exception was: ExitFailure 1 categories-1.0.6 failed during the building phase. The exception was: ExitFailure 1 comonad-extras-4.0 failed during the building phase. The exception was: ExitFailure 1 compdata-0.7.0.1 failed during the building phase. The exception was: ExitFailure 1 criterion-0.8.0.2 depends on statistics-0.10.5.2 which failed to install. crypto-cipher-benchmarks-0.0.5 depends on statistics-0.10.5.2 which failed to install. encoding-0.7 failed during the configure step. The exception was: user error ( /tmp/encoding-0.7-7743/encoding-0.7/Data/Static.hs:39:28: Couldn't match expected type 'Bool' with actual type 'Int#' In the expression: eqWord# v (int2Word# 4294967295#) In the expression: if eqWord# v (int2Word# 4294967295#) then Nothing else (if (I# (word2Int# v)) > 1114111 then error (show (I# (word2Int# v)) ++ " is not a valid char (" ++ show (I# i) ++ ")") else Just (chr (I# (word2Int# v)))) ) gitlib-3.0.2 failed during the building phase. The exception was: ExitFailure 1 gitlib-cmdline-3.0.1 depends on gitlib-3.0.2 which failed to install. gitlib-libgit2-3.0.1 depends on gitlib-3.0.2 which failed to install. gitlib-s3-3.0.2 depends on gitlib-3.0.2 which failed to install. gitlib-test-3.0.1 depends on gitlib-3.0.2 which failed to install. groundhog-0.4.2.2 failed during the building phase. The exception was: ExitFailure 1 groundhog-mysql-0.4.2.2 depends on groundhog-0.4.2.2 which failed to install. groundhog-postgresql-0.4.2.2 depends on groundhog-0.4.2.2 which failed to install. groundhog-sqlite-0.4.2.2 depends on groundhog-0.4.2.2 which failed to install. groundhog-th-0.4.2.2 depends on groundhog-0.4.2.2 which failed to install. monad-peel-0.1.1 failed during the building phase. The exception was: ExitFailure 1 mysql-simple-0.2.2.4 depends on pcre-light-0.4 which failed to install. parsestar-1.4 failed during the building phase. The exception was: ExitFailure 1 pcre-light-0.4 failed during the building phase. The exception was: ExitFailure 1 recursion-schemes-4.0 failed during the building phase. The exception was: ExitFailure 1 statistics-0.10.5.2 failed during the building phase. The exception was: ExitFailure 1 syb-extras-0.3 failed during the building phase. The exception was: ExitFailure 1 uniqueid-0.1.1 failed during the building phase. The exception was: ExitFailure 1

On Fri, Apr 11, 2014 at 9:43 AM, Simon Peyton Jones wrote:

OK, my GHC build is now complete. I can confirm that the original bug has in fact been fixed. I can also confirm that Yesod issue 713 about yesod-auth is *also* resolved, even though it was not part of the original GHC ticket. Furthermore, the entire yesod-platform compiles (after fixing a language-javascript version number).

Well that's a relief. I'm very sorry about the post-RC2 bug. It was my fault; I was fixing a bug that people wanted fixed (#8913) and managed to introduce a new one, and one that no regression test caught.

Simon

I really appreciate the quick turnaround on this Simon, you saved me many hours of pain and suffering with this fix! Maybe we should consider including a Stackage run in the pre-release procedure, as it's likely to catch these kinds of corner cases. I'd be happy to volunteer to do that, I simply hadn't realized that there were changes to 7.8.1 not present in rc2. Michael

On Fri, Apr 11, 2014 at 9:53 AM, Henning Thielemann < schlepptop@henning-thielemann.de> wrote:

Am 11.04.2014 07:26, schrieb Michael Snoyman:

OK, my GHC build is now complete. I can confirm that the original bug

...

has in fact been fixed. I can also confirm that Yesod issue 713 about yesod-auth is *also* resolved, even though it was not part of the original GHC ticket. Furthermore, the entire yesod-platform compiles (after fixing a language-javascript version number).

If you have made a working executable for 64-bit Linux - can I get it from you? I'd like to test the bugfix, too.

Sorry, I'm out of the house right now and don't have remote access to make the binary available. I likely won't be able to get this out until my Saturday night actually. Michael

Am 11.04.2014 13:34, schrieb Michael Snoyman:

I actually made it home earlier than expected. If someone can provide me with the command to create a binary tarball, I can upload it somewhere in the next few hours.

In the meantime I got around to build ghc myself. I am currently building the problematic packages with ghc-7.9.20140410. So far, everything goes smooth.

On Thu, Apr 10, 2014 at 4:13 PM, Mark Lentczner wrote:

M. Snoyberg

Grand apologies, Michael Snoyman. This is what comes of trying to continue to work while on vacation! I'll be back in a few days (and shifting into high HP gear!) - Mark "at the beach" Lentczner

I just released updated versions of the OpenGL packages: * OpenGLRaw 1.5.0.0 * GLURaw 1.4.0.1 * OpenGL 2.9.2.0 * GLUT 2.5.1.1 Apart from a few changes/additions, the main motivation was to get rid of the nasty K&R-style CPP features, so these packages should now compile out of the box on Mac OS X/with clang. It would be nice if these new versions made it into the new platform release.

Did you notice and pick up the latest version of fgl from a few weeks ago? On 21 May 2014 13:34, Mark Lentczner wrote:

On Mon, May 19, 2014 at 8:57 AM, Sven Panne wrote:

...

* OpenGLRaw 1.5.0.0 * GLURaw 1.4.0.1 * OpenGL 2.9.2.0 * GLUT 2.5.1.1

Done.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

I know for my distro (Exherbo) they don't want to ship a different version of Cabal than that shipped by GHC so as to simplify dependency matters. It might also pose some problems with packages like haskell-docs which depend on the ghc library. On 21 May 2014 15:38, Johan Tibell wrote:

I already brought this up with Mark offline, but I thought I post it here too: there were some recent bugfixes to cabal-install dependency solver that I think are worthwhile to ship.

Right now the fixes are only in cabal-install 1.20, which requires Cabal 1.20. GHC 7.8, which will ship with the HP, ships with Cabal 1.18. I don't know if shipping both Cabal 1.18 and 1.20 in the HP will lead to problems. If so, I can backport the cabal-install changes to 1.18. Thoughts?

On Wed, May 21, 2014 at 7:34 AM, Ivan Lazar Miljenovic wrote:

...

Did you notice and pick up the latest version of fgl from a few weeks ago?

On 21 May 2014 13:34, Mark Lentczner wrote:

...

On Mon, May 19, 2014 at 8:57 AM, Sven Panne wrote:

...

* OpenGLRaw 1.5.0.0 * GLURaw 1.4.0.1 * OpenGL 2.9.2.0 * GLUT 2.5.1.1

Done.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Michael Snoyman wrote:

I'd be concerned about having two versions of Cabal ship. I can quickly lead to user confusion when loading code in ghci (messages where `Foo` does not match `Foo`). Admittedly, most users won't be depending on the Cabal library themselves most of the time, but I still think it's a good idea to avoid the problem if possible.

I also think that shipping two versions of Cabal is a bad idea. This would bite every user of ghc(-as-a-library), which depends on Cabal and cannot be upgraded, as I learned a couple of days ago while building lambdabot. Bertram

Johan Tibell wrote:

...

...there were some recent bugfixes to cabal-install... the fixes are only in cabal-install 1.20, which requires Cabal 1.20. GHC 7.8, which will ship with the HP, ships with Cabal 1.18.

Mark Lentczner wrote:

all's well... Johan back ported the changes, so we'll be shipping a rev'd but compatible cabal-install along with the Cabal lib that comes with GHC 7.8.2.

Great to see this! Is there an updated timetable (after the GHC 7.8.2 setback)? Thanks, Yitz

On Mon, May 26, 2014 at 3:49 PM, Yitzchak Gale wrote:

Johan Tibell wrote:

...

...

I don't know if shipping both Cabal 1.18 and 1.20 in the HP will lead to problems. If so, I can backport the cabal-install changes to 1.18.

Mark Lentczner wrote:

...

all's well... Johan back ported the changes

So it's moot for this release. But in principle, what would have been the problem with having the platform installers ship with the 1.20 executable, or build the 1.20 executable in a sandbox for installers that build it, and then still ship with Cabal-1.18. in the libraries?

I don't think it's a problem, two different version of a package can happily coexist in a package DB after all. There's a theoretical diamond dependency problem if some other package in HP links against Cabal. I mostly backported the change to be conservative, as I couldn't foresee all possible issues.

On 26 May 2014 23:49, Yitzchak Gale wrote:

Johan Tibell wrote:

...

...

I don't know if shipping both Cabal 1.18 and 1.20 in the HP will lead to problems. If so, I can backport the cabal-install changes to 1.18.

Mark Lentczner wrote:

...

all's well... Johan back ported the changes

So it's moot for this release. But in principle, what would have been the problem with having the platform installers ship with the 1.20 executable, or build the 1.20 executable in a sandbox for installers that build it, and then still ship with Cabal-1.18. in the libraries?

Linux distros that don't use pre-built binaries, especially source-based ones where having cabal-install-1.2 would require building Cabal-1.20? (Then again, unless it's people learning Haskell and being told to install the platform, I would imagine that many people on Linux wouldn't use the platform itself and just install whatever libraries they want.)

On a related note: are we sure that we want cabal-install to print the upgrade message whenever a newer version is available on hackage? If we believe it might be a problem to have a version of Cabal installed that is inconsistent with the one bundled with GHC, then why are we telling people to install it?

Maybe have that as a config option? It's still helpful for people that built cabal-install themselves and know what they're doing? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On 27 May 2014 20:23, Yitzchak Gale wrote:

I wrote:

...

...

So it's moot for this release. But in principle, what would have been the problem with having the platform installers ship with the 1.20 executable, or build the 1.20 executable in a sandbox for installers that build it, and then still ship with Cabal-1.18. in the libraries?

Ivan Lazar Miljenovic wrote:

...

Linux distros that don't use pre-built binaries, especially source-based ones where having cabal-install-1.2 would require building Cabal-1.20?

It would be built only on the machine building the package, and there only inside a sandbox. It would not need to be part of the distro itself.

Source-based distros build everything on every machine, and I don't know of any that use sandboxes (as that would defeat part of the point).

...

(Then again, unless it's people learning Haskell and being told to install the platform, I would imagine that many people on Linux wouldn't use the platform itself and just install whatever libraries they want.)

Generally, it makes sense for *users* of Haskell - whether beginners or not - to start with the platform. People working on developing the Haskell ecosystem might start with a more recent GHC, but even then the platform often makes sense as a default starting point.

*shrug* I always only installed the packages that I needed.

...

...

On a related note: are we sure that we want cabal-install to print the upgrade message whenever a newer version is available on hackage?

...

Maybe have that as a config option? It's still helpful for people that built cabal-install themselves and know what they're doing?

Makes sense.

Thanks, Yitz

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Well - here's where we are: I'm still trying to finish the new build for the platform. The work can be seen here: haskell/haskell-platform at new-buildhttps://github.com/haskell/haskell-platform/tree/new-build *Please check over the current state of the packages and versions for 2014.1: * https://github.com/haskell/haskell-platform/blob/new-build/hptool/src/Releas... ​ *If you make distributions*, please see the README and try building, at very build the source tar ball, then run through your packaging process. Even better would be if you can get you packaging process integrated into the build. If you feel like helping there are several areas that need help: - If you want to hack the build, check out the TO DO list: https://github.com/haskell/haskell-platform/blob/new-build/notes/BUILD-NEW#L... - The wiki (now on github) can use some love: Home · haskell/haskell-platform Wikihttps://github.com/haskell/haskell-platform/wiki - The issue list (now on github) can use some love: Issues · haskell/haskell-platformhttps://github.com/haskell/haskell-platform/issues?state=open - If you want to hack the plan for automatically generating the website, contact me - If you want to hack the plan for including automated testing into the build, contact me - If you want to bring up a continuous build system for the platform (pretty please), contact me Let's make it happen! - Mark

Mark Lentczner wrote:

Well - here's where we are:

Excellent report, thanks!

I'm still trying to finish the new build for the platform... If you feel like helping there are several areas that need help:

If you want to hack the build, check out the TO DO list: https://github.com/haskell/haskell-platform/blob/new-build/notes/BUILD-NEW#L...

Could we please add each of these to the issue tracker, and tag the ones that are release blockers? Would you like me to do that? I can't do the tagging though, because I don't know which are blockers, and anyway I'm not an admin. I guess "tagging" in this context actually means "attaching to a milestone", right?

The wiki (now on github) can use some love: Home · haskell/haskell-platform Wiki

The issue list (now on github) can use some love: Issues · haskell/haskell-platform

If you want to hack the plan for automatically generating the website, contact me

If you want to hack the plan for including automated testing into the build, contact me

If you want to bring up a continuous build system for the platform (pretty please), contact me

Could we please add each of the above items to the issue tracker? Including the issue tracker meta-issue.

Let's make it happen!

Go go go! Thanks, Yitz

Mark Lentczner wrote:

I've added the bigger items to the issue tracker.

Thanks!

...

I'm a bit reluctant to add the items from BUILD-NEW's TO DO list, as that list fluctuates fast and furious (or should, at any rate.) Most of the items are very small... just pick one and do it and submit a pull request. If the task is near the top of the list and looks complex - I'm probably on it, so contact me first...

OK, well, I felt I didn't completely understand almost any of them. So I thought the issue tracker would be a good place to clarify them. More importantly - I'd like to know what the most important bottlenecks are for getting the next HP out the door, and what are some good places to jump in to help with that. Thanks, Yitz

On 28 May 2014 14:05, Mark Lentczner wrote:

*Please check over the current state of the packages and versions for 2014.1:*

https://github.com/haskell/haskell-platform/blob/new-build/hptool/src/Releas...

What will happen to haskell-platform.cabal? -Jens

On 28 May 2014 14:05, Mark Lentczner wrote:

*If you make distributions*, please see the README and try building, at very build the source tar ball, then run through your packaging process. Even better would be if you can get you packaging process integrated into the build.

Is there any way to avoid the need for ghc-bindist.tar.gz? It seems one has to download a ghc bin tarball even to build a source tarball or haskell-platform.cabal? - Jens

On 26 May 2014 22:49, Yitzchak Gale wrote:

On a related note: are we sure that we want cabal-install to print the upgrade message whenever a newer version is available on hackage? If we believe it might be a problem to have a version of Cabal installed that is inconsistent with the one bundled with GHC, then why are we telling people to install it?

+1 I have started patching it out for Fedora anyway. Jens

Actually, changing my opinion here. If there was an argument to _add_ cgi to the platform I'd be very dubious. Legacy considerations and history aside, cgi doesn't feel like a core/common thing that is necessary to have in the platform, and it probably hasn't been for many years. If Anders doesn't get around to fixing it up, I think we should have no compunctions dropping it, and I'd be shocked if there was much in the way of complaint. --G On 4/2/14, 8:36 PM, Gershom Bazerman wrote:

cc: Anders Kaseorg.

Anders: What would you like to do about this situation? Is it possible to revert to the non monadcatchio interface with throwCGI and catchCGI? Or would you like to switch to the exceptions package which people are considering including in the platform?

--G

On 3/31/14, 5:03 AM, Gregory Collins wrote:

...

On Sun, Mar 30, 2014 at 10:06 PM, Mark Lentczner mailto:mark.lentczner@gmail.com> wrote:

*cgi* - no longer builds, and we've been unwilling to bring it forward because it pulls in MonadCatchIO-mtl

Should we remove it from the platform?

G -- Gregory Collins mailto:greg@gregorycollins.net>

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Mon, Apr 7, 2014 at 6:56 PM, Gershom Bazerman wrote:

... cgi doesn't feel like a core/common thing that is necessary to have in the platform ...

Considering the range of facilities provided by other language platforms (see my HIW talk two years agohttp://www.haskell.org/haskellwiki/HaskellImplementorsWorkshop/2012/Lentczne...), cgi, or some method of serving HTTP requests is well within a reasonable, common library collection these days. We should have a HTTP client as well. - mark

On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman wrote:

I know people have raised security concerns about using the tls package due to lack of testing relative to OpenSSL, but I'm not sure if those arguments are so valid given recent events[5].

Yeah, I've been meaning to mention this issue -- I have definitely been among those in the past pushing for OpenSSL as the only sensible solution (conventional crypto wisdom is that you stick to tried and true, well-tested solutions) but I might change my tune on this. Sure, the Haskell tls library might potentially be vulnerable to unknown side chaining or timing attacks (and there is C code in there), but I don't see much chance of buffer overflows leading to secret key disclosure (!) coming out of our camp. Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the Hackage package versioning policy and until this is fixed I think that issue precludes it from being included in the platform. As far as HTTP clients go there is also http-streams ( http://hackage.haskell.org/package/http-streams) which is itself very nice and (unsurprisingly) what I would vote for. Given that we already have an HTTP client library in the platform (even though it's not really so great) and there are multiple viable alternatives, I don't think we can pick a replacement to go into the platform yet, especially if it would pull in one of the streaming libraries. I've considered nominating io-streams for inclusion into the platform (it's a very nice and high-quality library, if I do say so myself) but I haven't because the matter simply isn't settled yet and I don't think it's right to canonize one approach over the others. G -- Gregory Collins

On Tue, Apr 8, 2014 at 6:29 PM, Gregory Collins wrote:

On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman wrote:

...

I know people have raised security concerns about using the tls package due to lack of testing relative to OpenSSL, but I'm not sure if those arguments are so valid given recent events[5].

Yeah, I've been meaning to mention this issue -- I have definitely been among those in the past pushing for OpenSSL as the only sensible solution (conventional crypto wisdom is that you stick to tried and true, well-tested solutions) but I might change my tune on this. Sure, the Haskell tls library might potentially be vulnerable to unknown side chaining or timing attacks (and there is C code in there), but I don't see much chance of buffer overflows leading to secret key disclosure (!) coming out of our camp.

Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the Hackage package versioning policy and until this is fixed I think that issue precludes it from being included in the platform.

I'm sure you can guess that I disagree with this statement. But I also find it absurd in the given context: the Haskell Platform package we're discussing right now (cgi) doesn't follow the PVP! Beyond just trying to force the rest of the world to adhere to the PVP, what actual reason is there to require Haskell Platform packages adhere to the PVP? I assume you're referring to the fact that tls doesn't include upper bounds on its dependencies, because it certainly *does* follow PVP's versioning guidelines on its own version number. But once a package is included in the platform, there's no opportunity for build failures since the platform will be locking down versions of all its dependencies. So besides trying to find another means of enforcing PVP adherence on the rest of us, what value is there in this new requirement?

As far as HTTP clients go there is also http-streams ( http://hackage.haskell.org/package/http-streams) which is itself very nice and (unsurprisingly) what I would vote for. Given that we already have an HTTP client library in the platform (even though it's not really so great) and there are multiple viable alternatives, I don't think we can pick a replacement to go into the platform yet, especially if it would pull in one of the streaming libraries. I've considered nominating io-streams for inclusion into the platform (it's a very nice and high-quality library, if I do say so myself) but I haven't because the matter simply isn't settled yet and I don't think it's right to canonize one approach over the others.

http-client has no dependency on any streaming data library. The codebase- while it's moved from a few different libraries over the years- has been publicly available since 2010[1]. It has bindings for tls and openssl, as well as interfaces for conduit and pipes. It has a large number of packages on Hackage already depending on it (at least 104[2] via http-conduit, though there are other libraries that depend on http-client directly). None of this touches on the technical merits of the two libraries; in particular, http-client provides a much more robust connection sharing mechanism than what is available in http-streams. Michael [1] http://hackage.haskell.org/package/http-enumerator-0.0.0 [2] http://packdeps.haskellers.com/reverse/http-conduit

I don't think either of us was actually proposing it for the HP, and certainly not for this cycle. I was actually surprised that Mark mentioned an HTTP client library at all, given that HTTP is already in the platform. But if there's interest in replacing it in a later cycle, I would propose http-client. On Tue, Apr 8, 2014 at 7:11 PM, Carter Schonwald

wrote:

so it sounds like theres a clear agreement to not include a new http lib in HP this cycle? :))))

On Tue, Apr 8, 2014 at 11:54 AM, Michael Snoyman wrote:

...

On Tue, Apr 8, 2014 at 6:29 PM, Gregory Collins wrote:

...

On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman wrote:

...

I know people have raised security concerns about using the tls package due to lack of testing relative to OpenSSL, but I'm not sure if those arguments are so valid given recent events[5].

Yeah, I've been meaning to mention this issue -- I have definitely been among those in the past pushing for OpenSSL as the only sensible solution (conventional crypto wisdom is that you stick to tried and true, well-tested solutions) but I might change my tune on this. Sure, the Haskell tls library might potentially be vulnerable to unknown side chaining or timing attacks (and there is C code in there), but I don't see much chance of buffer overflows leading to secret key disclosure (!) coming out of our camp.

Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the Hackage package versioning policy and until this is fixed I think that issue precludes it from being included in the platform.

I'm sure you can guess that I disagree with this statement. But I also find it absurd in the given context: the Haskell Platform package we're discussing right now (cgi) doesn't follow the PVP!

Beyond just trying to force the rest of the world to adhere to the PVP, what actual reason is there to require Haskell Platform packages adhere to the PVP? I assume you're referring to the fact that tls doesn't include upper bounds on its dependencies, because it certainly *does* follow PVP's versioning guidelines on its own version number. But once a package is included in the platform, there's no opportunity for build failures since the platform will be locking down versions of all its dependencies.

So besides trying to find another means of enforcing PVP adherence on the rest of us, what value is there in this new requirement?

...

As far as HTTP clients go there is also http-streams ( http://hackage.haskell.org/package/http-streams) which is itself very nice and (unsurprisingly) what I would vote for. Given that we already have an HTTP client library in the platform (even though it's not really so great) and there are multiple viable alternatives, I don't think we can pick a replacement to go into the platform yet, especially if it would pull in one of the streaming libraries. I've considered nominating io-streams for inclusion into the platform (it's a very nice and high-quality library, if I do say so myself) but I haven't because the matter simply isn't settled yet and I don't think it's right to canonize one approach over the others.

http-client has no dependency on any streaming data library. The codebase- while it's moved from a few different libraries over the years- has been publicly available since 2010[1]. It has bindings for tls and openssl, as well as interfaces for conduit and pipes. It has a large number of packages on Hackage already depending on it (at least 104[2] via http-conduit, though there are other libraries that depend on http-client directly). None of this touches on the technical merits of the two libraries; in particular, http-client provides a much more robust connection sharing mechanism than what is available in http-streams.

Michael

[1] http://hackage.haskell.org/package/http-enumerator-0.0.0 [2] http://packdeps.haskellers.com/reverse/http-conduit

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Tue, Apr 8, 2014 at 7:13 PM, Gregory Collins wrote:

On Tue, Apr 8, 2014 at 5:54 PM, Michael Snoyman wrote:

...

I'm sure you can guess that I disagree with this statement. But I also find it absurd in the given context: the Haskell Platform package we're discussing right now (cgi) doesn't follow the PVP!

Another reason to get rid of it. Besides, it was grandfathered in when the platform was created, and several of the HP grandfathered libraries have (or had) fairly serious documentation or quality issues. Would "pretty" make the bar if it was nominated today?

Beyond just trying to force the rest of the world to adhere to the PVP,

...

what actual reason is there to require Haskell Platform packages adhere to the PVP? I assume you're referring to the fact that tls doesn't include upper bounds on its dependencies, because it certainly *does* follow PVP's versioning guidelines on its own version number. But once a package is included in the platform, there's no opportunity for build failures since the platform will be locking down versions of all its dependencies.

So besides trying to find another means of enforcing PVP adherence on the rest of us, what value is there in this new requirement?

It's not a new requirement, it's been there since the beginning of the Haskell Platform project if you would take the time to read http://trac.haskell.org/haskell-platform/wiki/VersionNumbers.

I don't read it that way at all. The PVP has two components: how to number your own packages, and how to place bounds on dependencies. That document says nothing at all about version bounds; it's referring explicitly to version numbers. You're doing this entire discussion a huge disservice by talking in absolutes like "doesn't obey the PVP." Furthermore, I asked you for concrete examples of how enforcing a PVP requirement on tls would help the Haskell Platform; you responded with a document. I'm not interested in having a legal battle here; I'm trying to make sure we're making good technical decisions. So is there a reason to enforce this requirement on HP packages? And finally, I don't think any of the recent additions to the Haskell Platform complied with this requirement. So why is it that you're only raising this concern now? If we are simply going to selectively enforce a policy, then we have given veto power to people for packages they don't like, which is a bad community process.

I do realize you're on the other side of this issue, that you've chosen to violate this longstanding established policy, that you may have good reasons for this, and that (sadly) nobody has added technological measures to Hackage to prevent you from doing so.

You made similar comments the last time the PVP was discussed on the libraries@ list. I don't feel the need to repeat what I- as well as others- responded to you then, as it applies equally here.

However, I suspect the policy is not going to change anytime soon: I don't think your side of the issue has the votes, nor is there an attractive enough counter-proposal.

I've written up a proposal[1] in the past few weeks, and have been discussing it with various people in the community. I was going to hold off on posting it another week or so to allow for some more private discussion of the finer points, but this thread made me realize that the "counter-proposal" needed to be brought to light already. I'm going to start a separate thread for discussion of the proposal, as this thread is the wrong place for it. Michael [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp

Am 09.04.2014 11:25, schrieb Gregory Collins:

On Wed, Apr 9, 2014 at 10:47 AM, Michael Snoyman mailto:michael@snoyman.com> wrote:

I don't read it that way at all. The PVP has two components: how to number your own packages, and how to place bounds on dependencies. That document says nothing at all about version bounds; it's referring explicitly to version numbers. You're doing this entire discussion a huge disservice by talking in absolutes like "doesn't obey the PVP."

The fourth bullet point in the first paragraph says explicitly: "We follow the Haskell Package Versioning Policy" and links to that document. I know you don't like it but please don't pretend like it isn't there.

As far as I understand, Michael referred to the PVP and you, Gregory, refer to the Haskell Platform policy.

On Wed, Apr 9, 2014 at 12:25 PM, Gregory Collins wrote:

On Wed, Apr 9, 2014 at 10:47 AM, Michael Snoyman wrote:

...

I don't read it that way at all. The PVP has two components: how to number your own packages, and how to place bounds on dependencies. That document says nothing at all about version bounds; it's referring explicitly to version numbers. You're doing this entire discussion a huge disservice by talking in absolutes like "doesn't obey the PVP."

The fourth bullet point in the first paragraph says explicitly: "We follow the Haskell Package Versioning Policy" and links to that document.

The PVP has two components: how to number your own packages, and how to

In a section talking about version numbers, not version bounds. I was pretty clear in what I said, so I'll repeat it: place bounds on dependencies. That document says nothing at all about version bounds; it's referring explicitly to version numbers. The Haskell Platform document is clearly talking about how to do version numbers, not how to place dependencies. Absurd analogy: if we're discussing spelling conventions in a library, and we say "we'll follow the British rules," that doesn't mean that date formats will automatically be British as well. I know you don't like it but please don't pretend like it isn't there.

If you're going to reduce this discussion to misconstruing what I'm saying, I think it's clear there's no purpose in continuing it. I've made my points: 1. We've never enforced this requirement in the past. 2. I disagree with your reading of the HP doc. 3. You have yet to demonstrate a single example of breakage to the HP that would be caused by including tls.

Furthermore, I asked you for concrete examples of how enforcing a PVP

...

requirement on tls would help the Haskell Platform; you responded with a document. I'm not interested in having a legal battle here; I'm trying to make sure we're making good technical decisions. So is there a reason to enforce this requirement on HP packages?

There are good reasons for following the package versioning policy as written, and this matter was debated when the policy was first proposed. We can debate it again (and we will, on the other thread), but this isn't about legalisms: packages that violate PVP break builds.

You're once again ignoring what I said. I'm not debating general application of the PVP rules. Specifically in the case of including a package in the Haskell Platform, what harm comes to the platform by including a package without upper bounds? The platform itself will lock down every single dependency for that package to a specific version, and therefore any bounds in the package itself are completely irrelevant. Michael

On Wed, Apr 9, 2014 at 1:15 PM, Erik Hesselink wrote:

...

3. You have yet to demonstrate a single example of breakage to the HP

On Wed, Apr 9, 2014 at 12:11 PM, Michael Snoyman wrote: that

...

would be caused by including tls.

I don't want to get involved in the arguments about the other technicalities, but we've had breakages with the tls suite of packages in the past due to lack of upper bounds. Here's one quoted from an email to Vincent Hanquez:

The problem was that tls 1.1.2 doesn't list an upper bound on its crypto-pubkey dependency, but doesn't build with the new 0.2.* releases.

I'm not arguing about upper bounds in general. I don't dispute (and never had!) that upper bounds can in many cases allow builds to succeed where they would otherwise fail. I'm speaking specifically about the case of the Haskell Platform, which makes all version bounds in the package itself irrelevant by hard-coding exact versions of all dependencies. Michael

On Wed, Apr 9, 2014 at 1:22 PM, Erik Hesselink wrote:

...

On Wed, Apr 9, 2014 at 1:15 PM, Erik Hesselink wrote:

...

On Wed, Apr 9, 2014 at 12:11 PM, Michael Snoyman wrote:

...

3. You have yet to demonstrate a single example of breakage to the HP that would be caused by including tls.

I don't want to get involved in the arguments about the other technicalities, but we've had breakages with the tls suite of packages in the past due to lack of upper bounds. Here's one quoted from an email to Vincent Hanquez:

The problem was that tls 1.1.2 doesn't list an upper bound on its crypto-pubkey dependency, but doesn't build with the new 0.2.* releases.

I'm not arguing about upper bounds in general. I don't dispute (and never had!) that upper bounds can in many cases allow builds to succeed where

On Wed, Apr 9, 2014 at 12:19 PM, Michael Snoyman wrote: they

...

would otherwise fail. I'm speaking specifically about the case of the Haskell Platform, which makes all version bounds in the package itself irrelevant by hard-coding exact versions of all dependencies.

Ah, of course, that makes sense: all dependencies have to be included in the platform as well. Sorry for the confusion.

No worries, it's a confusing subject ;) Michael

On Wed, Apr 9, 2014 at 2:43 PM, Johan Tibell wrote:

On Wed, Apr 9, 2014 at 12:19 PM, Michael Snoyman wrote:

...

I'm not arguing about upper bounds in general. I don't dispute (and never had!) that upper bounds can in many cases allow builds to succeed where they would otherwise fail. I'm speaking specifically about the case of the Haskell Platform, which makes all version bounds in the package itself irrelevant by hard-coding exact versions of all dependencies.

The packages in the HP still needs upper bounds as the user can install packages that require newer versions of packages that are in the platform and a lack of upper bounds in the platform packages would cause cabal to incorrectly try the HP version instead of installing a newer version, causing a build failure.

I'm afraid I don't follow what you're saying. Yes, the tls package could still be installed by someone who's not using the Haskell Platform, and then all the same reasons for having upper bounds apply. But I'm not sure how adding tls to the HP would somehow make this problem worse, which I *think* is what you're implying. Can you clarify? Michael

As a somewhat uninformed observer, I can't help thinking that "upper bounds on all packages plus cabal having the ability to ignore all upper bounds" is the best of both worlds. Am I missing something? Tom

On Wed, Apr 9, 2014 at 3:13 PM, Johan Tibell wrote:

On Wed, Apr 9, 2014 at 2:01 PM, Michael Snoyman wrote:

...

On Wed, Apr 9, 2014 at 2:43 PM, Johan Tibell wrote:

...

On Wed, Apr 9, 2014 at 12:19 PM, Michael Snoyman wrote:

...

I'm not arguing about upper bounds in general. I don't dispute (and never had!) that upper bounds can in many cases allow builds to succeed where they would otherwise fail. I'm speaking specifically about the case of the Haskell Platform, which makes all version bounds in the package itself irrelevant by hard-coding exact versions of all dependencies.

The packages in the HP still needs upper bounds as the user can install packages that require newer versions of packages that are in the platform and a lack of upper bounds in the platform packages would cause cabal to incorrectly try the HP version instead of installing a newer version, causing a build failure.

I'm afraid I don't follow what you're saying. Yes, the tls package could still be installed by someone who's not using the Haskell Platform, and then all the same reasons for having upper bounds apply. But I'm not sure how adding tls to the HP would somehow make this problem worse, which I *think* is what you're implying. Can you clarify?

I might be missing some context but I was trying to say that packages in the HP still need to have PVP compliant (upper) bounds or they might affect building of the same package outside the PVP (assuming that package has bounds). Put in another way, we still need bounds on the packages in the HP even if they're frozen wrt each other.

Then I don't think we're substantively disagreeing. The value of upper bounds on a package is not mitigated by its inclusion in the HP. And since the HP includes explicit version numbers on all of its dependencies, including a package without version bounds won't break the HP build. Michael

On 2014-04-08 16:29, Gregory Collins wrote:

On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman mailto:michael@snoyman.com> wrote:

I know people have raised security concerns about using the tls package due to lack of testing relative to OpenSSL, but I'm not sure if those arguments are so valid given recent events[5].

Yeah, I've been meaning to mention this issue -- I have definitely been among those in the past pushing for OpenSSL as the only sensible solution (conventional crypto wisdom is that you stick to tried and true, well-tested solutions) but I might change my tune on this. Sure, the Haskell tls library might potentially be vulnerable to unknown side chaining or timing attacks (and there is C code in there), but I don't see much chance of buffer overflows leading to secret key disclosure (!) coming out of our camp.

Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the Hackage package versioning policy and until this is fixed I think that issue precludes it from being included in the platform.

First of, you might want to read up on the difference between the definition of policy and rules/law. "obey" doesn't have its place here. Second, the tls/crypto ecosystem is following most of the PvP apart from "3 Dependencies in Cabal". Third, The PvP doesn't actually *enforce* any requirements on dependencies. I can only see CAN, SHOULD, MAY in the section 3. On the other hand, you can find MUST in section "2 Versions numbers", and as far I'm concerned the tls/crypto ecosystem is following each requirements in this section. Last, I don't have the luxury of time, and as the single maintainer of 16 packages of many thousands line of code (and many other packages if you don't count tls/crypto), I'ld rather spend my free unpaid time doing something useful (adding features, bugfixing,..) for the many currents users [1], than playing the upper-bound-catch-up game. When those rare breakage happens I get notification from the wonderful stackage and usually fix it in the day or so.

As far as HTTP clients go there is also http-streams (http://hackage.haskell.org/package/http-streams) which is itself very nice and (unsurprisingly) what I would vote for. Given that we already have an HTTP client library in the platform (even though it's not really so great) and there are multiple viable alternatives, I don't think we can pick a replacement to go into the platform yet, especially if it would pull in one of the streaming libraries. I've considered nominating io-streams for inclusion into the platform (it's a very nice and high-quality library, if I do say so myself) but I haven't because the matter simply isn't settled yet and I don't think it's right to canonize one approach over the others.

I find it ironic that you'ld rather enforce the PvP requirement (rationale 8.6) than the operating system one (rationale 8.4), and in the process leave the many windows users [2] in the dust with http-streams [3], for so called "violations" of part of the PvP with dubious interests. [1] https://hackage.haskell.org/packages/top " tls 6647, HsOpenSSL 563" [2] http://www.haskell.org/pipermail/ghc-devs/2014-April/004455.html [3] Unless you're planning to also vote for requiring/building openssl on windows (good luck with that !) as part of the windows haskell platform ? -- Vincent

I don't think we are going to include a package in the platform that was just changed today to work on Windows. Have you looked at building http-streams on top of http-client as pipes-http has done? That seems like the ideal solution if it is possible: then we can just include http-client in the platform. On Wed, Apr 9, 2014 at 5:32 AM, Gregory Collins wrote:

On Wed, Apr 9, 2014 at 2:19 PM, Vincent Hanquez wrote:

...

I find it ironic that you'ld rather enforce the PvP requirement (rationale 8.6) than the operating system one (rationale 8.4), and in the process leave the many windows users [2] in the dust with http-streams [3], for so called "violations" of part of the PvP with dubious interests.

I can have tls-streams ready in about 5 minutes if we decide to go that way.

G -- Gregory Collins

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hello Greg, On 2014-04-09 at 17:51:11 +0200, Greg Weber wrote:

I don't think we are going to include a package in the platform that was just changed today to work on Windows. Have you looked at building http-streams on top of http-client as pipes-http has done? That seems like the ideal solution if it is possible: then we can just include http-client in the platform.

Is the http-client API really mature enough (for being included in the HP) after having gone through 3 major version bumps in its rather short lifespan? I wouldn't be surprised if the http-client API required yet another major version bump in order to accomodate http-client. Cheers, hvr

On 2014-04-09 at 19:02:56 +0200, Michael Snoyman wrote:

On Wed, Apr 9, 2014 at 7:55 PM, Herbert Valerio Riedel wrote:

...

On 2014-04-09 at 17:51:11 +0200, Greg Weber wrote:

...

I don't think we are going to include a package in the platform that was just changed today to work on Windows. Have you looked at building http-streams on top of http-client as pipes-http has done? That seems like the ideal solution if it is possible: then we can just include http-client in the platform.

...

Is the http-client API really mature enough (for being included in the HP) after having gone through 3 major version bumps in its rather short lifespan? I wouldn't be surprised if the http-client API required yet another major version bump in order to accomodate http-client.

Do you mean to accommodate http-streams?

yes

If so, I doubt it: the streaming aspects of the library have been completely unchanged. For the record, the changes in the API were:

0.3: transition from failure to exceptions package 0.2: replace the original, placeholder API with the intended end-user API 0.1: initial pre-release

So it's not 3 major version bumps, it's two major version bumps, one of which being the first "real" release and the second being due to consolidated upstream packages. So the API isn't as unstable as it seems.

Sorry, my mistake, I was counting "major versions" but then actually went on and wrote "version bumps"

That said, I'm not actually advocating for including http-client in this revision: I think it's pretty late in the game for a new package in the platform, and I *do* think a few more months of testing to see if everyone's happy with the API makes a lot of sense.

On Wed, Apr 9, 2014 at 2:19 PM, Vincent Hanquez wrote:

Last, I don't have the luxury of time, and as the single maintainer of 16 packages of many thousands line of code (and many other packages if you don't count tls/crypto), I'ld rather spend my free unpaid time doing something useful (adding features, bugfixing,..) for the many currents users [1], than playing the upper-bound-catch-up game. When those rare breakage happens I get notification from the wonderful stackage and usually fix it in the day or so.

And re: this point: I don't have enough time for an epic mailing list flamewar today :), but I will say: - this behaviour makes life easier for you but causes many more build breakages for users - anecdotally, the tls ecosystem has been responsible for more build breakages in Snap than any other package (pre-1.0 we pulled it in via http-conduit for SSL blackbox testing). Just last week I had to fix a breakage in our testsuite caused by lack of upper bound on "cryptocipher": https://github.com/snapframework/snap-server/commit/d14f623833ce5bd3f6c5407e... and I can dig up lots of other examples - you don't get breakage notifications for packages that aren't on hackage And as a side note: please don't get me wrong, I am very happy that you guys are doing all this work for the community and publishing all of these nice high-quality packages, and I as a package author myself I appreciate how much time goes into bumping version bounds. I just wish we could solve that root issue with better tooling rather than mortgaging the future. Without upper bounds on deps, lim_{t -> ∞} P(build-ok) = 0 :( -- Gregory Collins

On Thu, Apr 10, 2014 at 4:01 PM, Vincent Hanquez wrote:

You could have notified me about the fact that you're still using an 1.5 year outdated package, I could reupload a newer tls-1.0.x branch package with the upper bound on cryptocipher. it would take me 1 minute.

That's sort of irrelevant IMO. Old code that was working fine before shouldn't rot just because it's old -- I've had plenty of breakages in this particular testsuite in the past (please just take my word for it and don't make me look them all up :)) where I was using some older version of http-enumerator/conduit, got into a tls/cryptocipher/etc build breakage because of the lack of upper bounds, tried to upgrade http-conduit to latest version and then got a bunch of build breakages because the http-conduit APIs had changed. At that point I have a project on my hands: sure I could track you down and ask you to add upper bounds to your old packages, or get on the Hackage upgrade treadmill and update that code to the latest version of that API, but your decision not to follow the PVP is what caused the breakage in the first place --- and as people have been complaining since you guys started on this "remove all the upper bounds" Don Quixote quest, build breakages due to this are inevitable unless you never change your APIs again. Frankly, just giving cabal the information it needed to generate a valid build plan was the lowest-friction option for me here. We don't use http-conduit in the git master snap-server testsuite anymore (precisely because I'm sick of fixing these build breakages), so I did the least amount of work possible to keep the 0.9-stable branch working. TL;DR: complaining because I didn't notify you that your decision to omit upper bounds caused me a build breakage seems weird to me: we've been protesting that this is an inevitable consequence for a long time now. G -- Gregory Collins

On Thu, Apr 10, 2014 at 5:02 PM, Vincent Hanquez wrote:

On 2014-04-10 15:22, Gregory Collins wrote:

...

On Thu, Apr 10, 2014 at 4:01 PM, Vincent Hanquez mailto:tab@snarc.org> wrote:

You could have notified me about the fact that you're still using an 1.5 year outdated package, I could reupload a newer tls-1.0.x branch package with the upper bound on cryptocipher. it would take me 1 minute.

That's sort of irrelevant IMO. Old code that was working fine before shouldn't rot just because it's old -- I've had plenty of breakages in this particular testsuite in the past (please just take my word for it and don't make me look them all up :)) where I was using some older version of http-enumerator/conduit, got into a tls/cryptocipher/etc build breakage because of the lack of upper bounds, tried to upgrade http-conduit to latest version and then got a bunch of build breakages because the http-conduit APIs had changed.

At that point I have a project on my hands: sure I could track you down and ask you to add upper bounds to your old packages, or get on the Hackage upgrade treadmill and update that code to the latest version of that API, but your decision not to follow the PVP is what caused the breakage in the first place --- and as people have been complaining since you guys started on this "remove all the upper bounds" Don Quixote quest, build breakages due to this are inevitable unless you never change your APIs again. Frankly, just giving cabal the information it needed to generate a valid build plan was the lowest-friction option for me here. We don't use http-conduit in the git master snap-server testsuite anymore (precisely because I'm sick of fixing these build breakages), so I did the least amount of work possible to keep the 0.9-stable branch working.

TL;DR: complaining because I didn't notify you that your decision to omit upper bounds caused me a build breakage seems weird to me: we've been protesting that this is an inevitable consequence for a long time now.

I never protested this is a consequence. Old unmaintained packages stop building eventually, this is just a fact that even the strict PvP *cannot* stop.

The simplest canonical example is that if I had follow the PvP in tls 1.0.x and have upper bounds on base, it would have stop building at the next ghc release.

This is false. It will not work on the new GHC, and it has never worked on the new GHC. It will, however, keep working on the GHC is was originally developed on, and will keep working there. This is a very desirable property. Also, you say 'old' packages. Right now, we cannot build things that are about a month old, due to dependencies missing upper bounds on their dependencies. Is one month 'old'? Erik

Everyone, Can we PLEASE keep PVP-related discussion out of this thread? And preferably in a thread with the word "PVP" in the subject, so it can be automatically deleted by my email filters? Thanks! Regards, Reid Barton On Thu, Apr 10, 2014 at 11:08 AM, Gregory Collins wrote:

On Thu, Apr 10, 2014 at 5:02 PM, Vincent Hanquez wrote:

...

At this point, I feel that the crux of your problem here seems to be linked to API changes more than upper bounds or PvP.

I don't understand how you arrived at that conclusion. I put the requisite upper bounds in, the build error went away. Clearly if you had followed PVP in the first place, this particular problem would not have occurred.

Nobody on the other side of this argument is claiming that upper bounds will prevent all build breakages: it just eliminates a large class of them.

G -- Gregory Collins

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I'd be open to including it. I've been working with Snoyman on it off and on, and it is pretty stable. Frankly, I've been on a quest to eradicate MonadCatchIO-transformers dependencies from my code ever since it added monads-tf support, as it drags in conflicts for the mtl and drives up random user complaints I receive. Sent from my iPad

On Mar 31, 2014, at 11:34 AM, Mark Lentczner wrote:

...

On Mon, Mar 31, 2014 at 8:18 AM, Edward Kmett wrote: mtl should bump to 2.1.3.1

Noted.

Should we be considering exceptions ready for the platform? The package cgi is in a bind as it uses mtl, and now uses MonadCatchIO-mtl.... but I'm assuming that exceptions would satisfy its needs, and is a more likely the way forward.

On Mon, Mar 31, 2014 at 10:32 AM, Nick Smallbone wrote:

Any chance of getting QuickCheck 2.7.3 in there?

Sounds good... but...

One complication is that we switched to a different random number generator because of some flaws with the one in System.Random. So we would also need to pull in the tf-random package (http://hackage.haskell.org/package/tf-random-0.4).

This is unfortunate. That package doesn't look like a likely candidate for the platform: It is new, and the API looks like it has been in rapid, non-stable development for the last month. Is is possible that you can make QC work with standard random package, and only use tf-random as an option? Is there something seriously flawed in random that should be fixed there? - Mark

Nick Smallbone-2 wrote

I would rather not switch back to StdGen. We have stumbled into situations in the past where we can't falsify a property just because StdGen can't come up with the right random values - while (thankfully) extremely rare, it makes me uncomfortable that it happens at all. This mostly happens when generating random functions.

Is StdGen so badly broken that it can't be fixed in a future version? -- View this message in context: http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next-release-2... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

On Mon, Apr 7, 2014 at 2:25 PM, Nick Smallbone wrote:

harry writes:

...

Nick Smallbone-2 wrote

...

I would rather not switch back to StdGen. We have stumbled into situations in the past where we can't falsify a property just because StdGen can't come up with the right random values - while (thankfully) extremely rare, it makes me uncomfortable that it happens at all. This mostly happens when generating random functions.

Is StdGen so badly broken that it can't be fixed in a future version?

The implementation of split is pretty broken. I suppose most people don't need split but, unfortunately, QuickCheck uses it heavily (the bind of the Gen monad splits the seed). I don't think anyone knows how to fix it, since there's no obvious reason why the current split should work at all!

Basic question: is the type of split wrong or just the implementation?

On Mon, Apr 7, 2014 at 4:18 PM, Nick Smallbone wrote:

On Monday 07 April, 2014 at 02:53 pm, Johan Tibell wrote:

...

...

...

Is StdGen so badly broken that it can't be fixed in a future version?

The implementation of split is pretty broken. I suppose most people don't need split but, unfortunately, QuickCheck uses it heavily (the bind of the Gen monad splits the seed). I don't think anyone knows how to fix it, since there's no obvious reason why the current split should work at all!

Basic question: is the type of split wrong or just the implementation?

Just the implementation. However, another question (which I don't know the answer to) is whether the type of StdGen allows for a proper implementation of split.

It would be nice if we could just fix StdGen and thus not require a whole new library. Will fixing StdGen make it even slower than it is today? I believe the new generator used in QC uses some cartographic hash function. I wonder if SipHash has been considered, as it's both fast and has good randomness properties (but perhaps not for splitting).

On Monday 07 April, 2014 at 04:32 pm, Johan Tibell wrote:

...

Just the implementation. However, another question (which I don't know the answer to) is whether the type of StdGen allows for a proper implementation of split.

It would be nice if we could just fix StdGen and thus not require a whole new library. Will fixing StdGen make it even slower than it is today?

That's the thing - I don't think anyone knows how to fix StdGen!

I believe the new generator used in QC uses some cartographic hash function. I wonder if SipHash has been considered, as it's both fast and has good randomness properties (but perhaps not for splitting).

I wonder too! I will ask Michał (the tf-random author) what he thinks of this. Nick

On Monday 07 April, 2014 at 06:04 pm, Johan Tibell wrote:

...

That's the thing - I don't think anyone knows how to fix StdGen!

I was, perhaps naively, hoping that we could just take the implementation of tf-random and dump it into StdGen!

Oh I see! I thought you were asking about taking the existing StdGen and somehow fixing split. I believe that StdGen and tf-random are about the same speed, with the winner depending on which benchmark you use. So I wouldn't expect any big change in performance. But tf-random does link against some C code to do the actual hashing, which I imagine is something we don't want StdGen to do. But maybe with something like SipHash we could make a pure Haskell version! Nick

haddock interoperates rather extremely closely with the ghc-api. Pulling it out would make something that already seems to go a bit out of sync with each release that much harder to keep in sync. It is also used to build the documentation for all the packages that ship with ghc out of the box. Pulled out I don't see a sane way to generate those docs. -Edward On Thu, Apr 3, 2014 at 8:32 AM, harry wrote:

Jens Petersen wrote

...

...

*Haddock* - is there any reason not to use the version built and distributed with GHC 7.8?

from the package perspective also, +1 for continuing to use the haddock in ghc.

Perhaps Haddock shouldn't be included with GHC either, now that we have HP for the batteries included distribution?

-- View this message in context: http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next-release-2... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Haddock now also relies on ghc-paths, a package that isn't in platform, nor, oddly, is in the GHC release. So, I'm going to presume, for releases going forward, that we'll take the Haddock that comes with GHC as the Platform's haddock. ​Good? - Mark

On Sat, Apr 5, 2014 at 9:24 AM, Mateusz Kowalczyk wrote:

There's an if clause in the Cabal file. If we're in the GHC tree when building, we set a symbol and then Haddock knows where to look for the libs. If we aren't, *then* we require ghc-paths.

AFAICT it has been this way since 2008.

Curious! I never had a problem building haddock as part of the platform before, but in the new build, I ran across the need for ghc-paths. Perhaps the old build isn't nearly as "hermetic" as I thought it was, and new one more so. It is also possible that GHC might have previously shipped with ghc-paths? - Mark

[about haddock and ghc-paths] On Sat, Apr 05, 2014 at 05:43:43PM +0100, Mateusz Kowalczyk wrote:

...

Perhaps the old build isn't nearly as "hermetic" as I thought it was, and new one more so. It is also possible that GHC might have previously shipped with ghc-paths?

I don't think it every did ship with ghc-paths, at least I can't think of a reason why it would.

AFAIK, ghc-paths always was separate from haddock and ghc, it's kind of a hack to provide default paths (of ghc, ghc-pkg, library and documentation directories) used by haddock. BTW: I already thought about amending haddock with a little autoconf (or similar) goo to get rid of ghc-paths... maybe I finally do this during our current OpenBSD release cycle (which means I would have a patch ready shortly *after* the release of HP 2014.2.0.0).

In any case, if you do require that you build Haddock yourself, adding ghc-paths to the platform should be no problem. It's pretty simple although I can't vouch for its suitability in the platform.

If only the haddock executable (not the libary) is to be included within the platform, wouldn't ghc-paths be a build-only dependency? This was at least still the case for haddock-2.13.2. Or did I miss some important change? Ciao, Kili

On Sat, Apr 5, 2014 at 1:34 PM, Matthias Kilian wrote:

BTW: I already thought about amending haddock with a little autoconf (or similar) goo to get rid of ghc-paths...

Please, no! I'd love to abolish autoconf as much as possible! And, I don't see the reason for it. Or, for that matter, this particular package.... If we wanted to remove the dependency on the package, we could just include the one file in the haddock source tree. NOW - that file, GHC/Paths.hs, exports four paths that it gets by using CPP, and relying that GHC will supply some #defines at CPP time. However, we built HP from a bindist of GHC. And that bindist includes (am I wrong?) an already built haddock.... which means that haddock was built with a ghc-paths that was compiled... at the time the bindist was made. But that is the wrong environment! Those paths are all wrong for when we build the platform because we take the binddist, configure it for a particular target environment, and make install it. And that target may very well configure it for different locations. So... my thinking is that I probably have to build haddock, and ghc-paths, afresh, and will need a way to build and use ghc-paths for building haddock, without bundling it in the platform.