HEAD vs Hackage status report
I spent a little time the other day building all of Hackage with GHC HEAD. Here's a quick writeup of what I found. Total packages: 5564 Succeeded with 7.6.3: 3234 Succeeded with HEAD: 2061 Succeeded with 7.6.3 *but failed with HEAD: 1186* (A few dozen packages built with HEAD, but not with 7.6.3, which is why the numbers don't add up.) I think the condensed version of the story is that we're actually in good shape, the above numbers notwithstanding. There are only a few categories of build regression, which I detail below. Except for one genuine bug, the rest (at least those I've seen so far) are upgrade details that could be written about in release notes or a blog post. There currently exists just one panic-related bug, which prevents all 23 packages in the Snap web framework from building: ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130923 for x86_64-unknown-linux): dmdTransformDictSelSig: split failed<http://ghc.haskell.org/trac/ghc/ticket/8329> Of the 1186 packages that build with 7.6.3 but not HEAD: 311 fail due to cabal being unable to solve dependency constraints. As usual, most (195) have excessively tight constraints on base. 37 packages fail due to GeneralizedNewtypeDeriving and the new role infrastructure, due to the following failures in packages upon which they depend. 12 language-c-0.4.2 the last parameter of ‛Error’ is at role Nominal 11 logfloat-0.12.1 the last parameter of ‛IArray’ is at role Nominal 5 diagrams-lib-0.7.1.1 the last parameter of ‛Transformable’ is at role Nominal 4 smallcheck-1.0.4 the last parameter of ‛MonadLogic’ is at role Nominal 2 monadiccp-0.7.6 the last parameter of ‛ReaderM’ is at role Nominal 2 histogram-fill-0.8.1.0 the last parameter of ‛BinEq’ is at role Nominal 1 acme-schoenfinkel-0.1.1 the last parameter of ‛ArrowApply’ is at role Nominal There's quite a bit of transitive primop-related breakage. 364 template-haskell-2.8.0.0 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 48 primitive-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 6 primitive-0.5.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ Most of the breakage could be fixed by loosening the dependencies on the template-haskell and primitive packages, and here are the rest. 63 uulib-0.9.15 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 20 utf8-light-0.4.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 19 safeint-0.5.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 16 permutation-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 9 floatshow-0.2.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 9 bytestring-show-0.3.5.5 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 8 STMonadTrans-0.3.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 7 hashtables-1.1.0.2 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 2 word24-1.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 2 arithmoi-0.4.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 1 word8-0.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 1 IORefCAS-0.2.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ Roughly 45 packages are broken by changes to Typeable.
On 2013-09-30 at 08:26:10 +0200, Bryan O'Sullivan wrote: [...]
Most of the breakage could be fixed by loosening the dependencies on the template-haskell and primitive packages, and here are the rest.
Btw/fyi, as one of the new killer features of Hackage 2, incorrect build-deps were supposed to be fixable easily by editing the .cabal directly (e.g. by a team of devoted Hackage trustees) and thus fix-up the build-deps on Hackage w/o needing to upload a full new release, but see https://github.com/haskell/hackage-server/issues/52 Cheers, hvr
On Mon, Sep 30, 2013 at 12:36 AM, Herbert Valerio Riedel <hvr@gnu.org> wrote:
On 2013-09-30 at 08:26:10 +0200, Bryan O'Sullivan wrote:
Most of the breakage could be fixed by loosening the dependencies on the template-haskell and primitive packages, and here are the rest.
Btw/fyi, as one of the new killer features of Hackage 2, incorrect build-deps were supposed to be fixable easily by editing the .cabal directly (e.g. by a team of devoted Hackage trustees) and thus fix-up the build-deps on Hackage w/o needing to upload a full new release, but see
Being one of those trustees and seeing the large number of failures I kinda doubt the viability of this approach. I for one don't feel like manually editiing ~200 package's descriptions manually. -- Johan
On Mon, 2013-09-30 at 08:00 -0700, Johan Tibell wrote:
On Mon, Sep 30, 2013 at 12:36 AM, Herbert Valerio Riedel <hvr@gnu.org> wrote:
On 2013-09-30 at 08:26:10 +0200, Bryan O'Sullivan wrote:
Most of the breakage could be fixed by loosening the dependencies on the template-haskell and primitive packages, and here are the rest.
Btw/fyi, as one of the new killer features of Hackage 2, incorrect build-deps were supposed to be fixable easily by editing the .cabal directly (e.g. by a team of devoted Hackage trustees) and thus fix-up the build-deps on Hackage w/o needing to upload a full new release, but see
Being one of those trustees and seeing the large number of failures I kinda doubt the viability of this approach. I for one don't feel like manually editiing ~200 package's descriptions manually.
I would not expect many individuals to look at all of hackage. Rather most volunteers would focus on some subset that they're interested in. Look at how distros manage these things. For example Gentoo has teams who look after particular areas (e.g. the Haskell team, the php team etc). Also, automation (but still a human in the loop). -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
On Sun, Sep 29, 2013 at 11:26 PM, Bryan O'Sullivan <bos@serpentine.com> wrote:
I spent a little time the other day building all of Hackage with GHC HEAD. Here's a quick writeup of what I found.
Thanks for taking the time to do this. It should really help the quality of this release. In general I think we should try to do this before each release. I believe you wrote some tooling to making this easier. Do you mind sharing it? -- Johan
Bryan That’s amazingly helpful thank you. I undertake to fix the dmdTransformDictSelSig: split failed<http://ghc.haskell.org/trac/ghc/ticket/8329> problem, by the end of this week at the latest. I’m agnostic about the rest… that is, is there anything we might do to ameliorate? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Bryan O'Sullivan Sent: 30 September 2013 07:26 To: ghc-devs@haskell.org Subject: HEAD vs Hackage status report I spent a little time the other day building all of Hackage with GHC HEAD. Here's a quick writeup of what I found. Total packages: 5564 Succeeded with 7.6.3: 3234 Succeeded with HEAD: 2061 Succeeded with 7.6.3 but failed with HEAD: 1186 (A few dozen packages built with HEAD, but not with 7.6.3, which is why the numbers don't add up.) I think the condensed version of the story is that we're actually in good shape, the above numbers notwithstanding. There are only a few categories of build regression, which I detail below. Except for one genuine bug, the rest (at least those I've seen so far) are upgrade details that could be written about in release notes or a blog post. There currently exists just one panic-related bug, which prevents all 23 packages in the Snap web framework from building: ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130923 for x86_64-unknown-linux): dmdTransformDictSelSig: split failed<http://ghc.haskell.org/trac/ghc/ticket/8329> Of the 1186 packages that build with 7.6.3 but not HEAD: 311 fail due to cabal being unable to solve dependency constraints. As usual, most (195) have excessively tight constraints on base. 37 packages fail due to GeneralizedNewtypeDeriving and the new role infrastructure, due to the following failures in packages upon which they depend. 12 language-c-0.4.2 the last parameter of ‛Error’ is at role Nominal 11 logfloat-0.12.1 the last parameter of ‛IArray’ is at role Nominal 5 diagrams-lib-0.7.1.1 the last parameter of ‛Transformable’ is at role Nominal 4 smallcheck-1.0.4 the last parameter of ‛MonadLogic’ is at role Nominal 2 monadiccp-0.7.6 the last parameter of ‛ReaderM’ is at role Nominal 2 histogram-fill-0.8.1.0 the last parameter of ‛BinEq’ is at role Nominal 1 acme-schoenfinkel-0.1.1 the last parameter of ‛ArrowApply’ is at role Nominal There's quite a bit of transitive primop-related breakage. 364 template-haskell-2.8.0.0 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 48 primitive-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 6 primitive-0.5.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ Most of the breakage could be fixed by loosening the dependencies on the template-haskell and primitive packages, and here are the rest. 63 uulib-0.9.15 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 20 utf8-light-0.4.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 19 safeint-0.5.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 16 permutation-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 9 floatshow-0.2.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 9 bytestring-show-0.3.5.5 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 8 STMonadTrans-0.3.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 7 hashtables-1.1.0.2 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 2 word24-1.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 2 arithmoi-0.4.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 1 word8-0.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 1 IORefCAS-0.2.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ Roughly 45 packages are broken by changes to Typeable.
I'll take a look at the roles failures. It would be helpful to know if we've found bugs in libraries' code or if this is just the "no-role-polymorphism" problem. On Oct 1, 2013, at 4:13 AM, Simon Peyton-Jones wrote:
Bryan
That’s amazingly helpful thank you.
I undertake to fix the dmdTransformDictSelSig: split failed problem, by the end of this week at the latest.
I’m agnostic about the rest… that is, is there anything we might do to ameliorate?
Simon
From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Bryan O'Sullivan Sent: 30 September 2013 07:26 To: ghc-devs@haskell.org Subject: HEAD vs Hackage status report
I spent a little time the other day building all of Hackage with GHC HEAD. Here's a quick writeup of what I found.
Total packages: 5564
Succeeded with 7.6.3: 3234
Succeeded with HEAD: 2061
Succeeded with 7.6.3 but failed with HEAD: 1186
(A few dozen packages built with HEAD, but not with 7.6.3, which is why the numbers don't add up.)
I think the condensed version of the story is that we're actually in good shape, the above numbers notwithstanding. There are only a few categories of build regression, which I detail below. Except for one genuine bug, the rest (at least those I've seen so far) are upgrade details that could be written about in release notes or a blog post.
There currently exists just one panic-related bug, which prevents all 23 packages in the Snap web framework from building:
ghc: panic! (the 'impossible' happened)
(GHC version 7.7.20130923 for x86_64-unknown-linux):
dmdTransformDictSelSig: split failed
Of the 1186 packages that build with 7.6.3 but not HEAD:
311 fail due to cabal being unable to solve dependency constraints. As usual, most (195) have excessively tight constraints on base.
37 packages fail due to GeneralizedNewtypeDeriving and the new role infrastructure, due to the following failures in packages upon which they depend.
12 language-c-0.4.2 the last parameter of ‛Error’ is at role Nominal
11 logfloat-0.12.1 the last parameter of ‛IArray’ is at role Nominal
5 diagrams-lib-0.7.1.1 the last parameter of ‛Transformable’ is at role Nominal
4 smallcheck-1.0.4 the last parameter of ‛MonadLogic’ is at role Nominal
2 monadiccp-0.7.6 the last parameter of ‛ReaderM’ is at role Nominal
2 histogram-fill-0.8.1.0 the last parameter of ‛BinEq’ is at role Nominal
1 acme-schoenfinkel-0.1.1 the last parameter of ‛ArrowApply’ is at role Nominal
There's quite a bit of transitive primop-related breakage.
364 template-haskell-2.8.0.0 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
48 primitive-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
6 primitive-0.5.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
Most of the breakage could be fixed by loosening the dependencies on the template-haskell and primitive packages, and here are the rest.
63 uulib-0.9.15 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
20 utf8-light-0.4.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
19 safeint-0.5.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
16 permutation-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
9 floatshow-0.2.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
9 bytestring-show-0.3.5.5 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
8 STMonadTrans-0.3.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
7 hashtables-1.1.0.2 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
2 word24-1.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
2 arithmoi-0.4.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
1 word8-0.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
1 IORefCAS-0.2.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’
Roughly 45 packages are broken by changes to Typeable.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
We could advertise the breakage list and or email all the various maintainers? On Tuesday, October 1, 2013, Simon Peyton-Jones wrote:
Bryan****
** **
That’s amazingly helpful thank you.****
** **
I undertake to fix the dmdTransformDictSelSig: split failed<http://ghc.haskell.org/trac/ghc/ticket/8329> problem, by the end of this week at the latest.****
** **
I’m agnostic about the rest… that is, is there anything we might do to ameliorate?****
** **
Simon****
** **
*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org <javascript:_e({}, 'cvml', 'ghc-devs-bounces@haskell.org');>] *On Behalf Of *Bryan O'Sullivan *Sent:* 30 September 2013 07:26 *To:* ghc-devs@haskell.org <javascript:_e({}, 'cvml', 'ghc-devs@haskell.org');> *Subject:* HEAD vs Hackage status report****
** **
I spent a little time the other day building all of Hackage with GHC HEAD. Here's a quick writeup of what I found.****
** **
Total packages: 5564****
Succeeded with 7.6.3: 3234****
Succeeded with HEAD: 2061****
Succeeded with 7.6.3 *but failed with HEAD: 1186*****
** **
(A few dozen packages built with HEAD, but not with 7.6.3, which is why the numbers don't add up.)****
** **
I think the condensed version of the story is that we're actually in good shape, the above numbers notwithstanding. There are only a few categories of build regression, which I detail below. Except for one genuine bug, the rest (at least those I've seen so far) are upgrade details that could be written about in release notes or a blog post.****
** **
There currently exists just one panic-related bug, which prevents all 23 packages in the Snap web framework from building:****
** **
ghc: panic! (the 'impossible' happened)****
(GHC version 7.7.20130923 for x86_64-unknown-linux):****
dmdTransformDictSelSig: split failed<http://ghc.haskell.org/trac/ghc/ticket/8329> ****
** **
Of the 1186 packages that build with 7.6.3 but not HEAD:****
** **
311 fail due to cabal being unable to solve dependency constraints. As usual, most (195) have excessively tight constraints on base.****
** **
37 packages fail due to GeneralizedNewtypeDeriving and the new role infrastructure, due to the following failures in packages upon which they depend.****
** **
12 language-c-0.4.2 the last parameter of ‛Error’ is at role Nominal ****
11 logfloat-0.12.1 the last parameter of ‛IArray’ is at role Nominal****
5 diagrams-lib-0.7.1.1 the last parameter of ‛Transformable’ is at role Nominal****
4 smallcheck-1.0.4 the last parameter of ‛MonadLogic’ is at role Nominal****
For future reference (my own future reference, most likely), here are why these packages break: On Sep 30, 2013, at 2:26 AM, Bryan O'Sullivan wrote:
12 language-c-0.4.2 the last parameter of ‛Error’ is at role Nominal Legit error. The Error class has Typeable as a superclass, and using GND in that scenario is very dodgy, at best.
11 logfloat-0.12.1 the last parameter of ‛IArray’ is at role Nominal This should be fixed with "lazier" checking during GND, as detailed here: http://www.haskell.org/pipermail/glasgow-haskell-users/2013-October/022836.h...
5 diagrams-lib-0.7.1.1 the last parameter of ‛Transformable’ is at role Nominal Legit error. The library assumed that a newtype and its base type had the same behavior when passed to a certain type family. It is conceivable that a much-souped-up version of roles could identify that this assumption has been made and then check the assumption, but there are no plans for this.
4 smallcheck-1.0.4 the last parameter of ‛MonadLogic’ is at role Nominal Error caused by lack of role abstraction.
2 monadiccp-0.7.6 the last parameter of ‛ReaderM’ is at role Nominal Error caused by lack of role abstraction.
2 histogram-fill-0.8.1.0 the last parameter of ‛BinEq’ is at role Nominal Legit error. BinEq has a superclass Bin that has an associated type.
1 acme-schoenfinkel-0.1.1 the last parameter of ‛ArrowApply’ is at role Nominal Error caused by lack of role abstraction.
The "role abstraction" errors could be solved by a rather simple extension to the roles mechanism, I think… I will detail in a fresh email so that the idea doesn't get lost in this thread. Richard
participants (7)
-
Bryan O'Sullivan -
Carter Schonwald -
Duncan Coutts -
Herbert Valerio Riedel -
Johan Tibell -
Richard Eisenberg -
Simon Peyton-Jones