GHC-8.8.1 / base-4.13 / MonadFail / ... breakages

[phadej]

• aeson
• basement
• binary (0.8 ... 0.8.6)
• cereal
• colour
• control-monad-omega
• dlist
• free
• json
• jose
• language-c
• machines
• optparse-applicative
• pipes
• prettyprinter
• socks
• QuickCheck
• text (1.2.3.0, 1.2.3.1)
• time
• transformers-0.5.5.2
• vector-th-unbox-0.2.1.6

See also

• Adapt to MonadFail-related changes in base-4.13.0.0 hvr/head.hackage#111
• More MonadFail-related patches hvr/head.hackage#112
• Even more GHC 8.8-related patches hvr/head.hackage#117
• some packages have bounds in place, some doesn't.

[RyanGlScott]

Could I request that aeson released have their upper version bounds on base revised to < 4.13? The lack of upper version bounds is currently causing failing build plans to be chosen with GHC 8.8.1 on Travis. See here for one example.

EDIT: On second thought, Travis is passing --allow-newer=base anyway, so this won't actually help me at the moment. So this isn't urgent.

[phadej]

haskell-ci script have allow-newer: base, so how upper bounds would help?

…

On 28 Apr 2019, at 17.41, Ryan Scott ***@***.***> wrote: Could I request that aeson released have their upper version bounds on base revised to < 4.13? The lack of upper version bounds is currently causing failing build plans to be chosen with GHC 8.8.1 on Travis. See here for one example. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[RyanGlScott]

I edited my previous comment to state that realization, although I now realize that you wouldn't see that if you're only reading e-mail notifications. My bad.

[phadej]

No worries It’s good to know that there will be breakage, this issue is exactly to collect the list; and then fix stuff

…

On 28 Apr 2019, at 18.34, Ryan Scott ***@***.***> wrote: I edited my previous comment to state that realization, although I now realize that you wouldn't see that if you're only reading e-mail notifications. My bad. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[quasicomputational]

Two more for the pile needing revisions of old versions:

• colour

• json

[cartazio]

curiously: in some CI i've got, i'm seeing the bad time version picked up for 8.8.1RC / hackage head https://travis-ci.org/haskell/primitive/jobs/533885678#L912

[recursion-ninja]

I think we may need to add polyparse to the list since the hackage "bug tracker" link directs here and polyparse doesn't build with the alpha version of ghc-8.8.1.

[phadej]

@recursion-ninja that's different, polyparse has the correct bounds, but indeed might not build with GHC-8.8.1 if you relax them. That's different issue. And seems as I uploaded polyparse, I might actually do another upload when it's time.

There's a bunch of packages in https://github.com/hackage-trustees/malcolm-wallace-universe which I completely forgot about.

[recursion-ninja]

@phadej I'm not sure what you mean. polyparse still looks broken to me. If there's an updated repository from which I can get newer, compatible code I would love to set that in my project.cabal and/or stack.yaml file(s).

/tmp/stack31990/polyparse-1.12.1/src/Text/ParserCombinators/HuttonMeijer.hs:66:4: error:
polyparse                        >     ‘fail’ is not a (visible) method of class ‘Monad’
polyparse                        >    |
polyparse                        > 66 |    fail            = Fail.fail
polyparse                        >    |    ^^^^
polyparse                        >    

[quasicomputational]

memory will also need its bounds adjusted.

E: And also asn1-encoding.

[phadej]

The maintainer author of memory (edit and asn1-encoding) have been asked multiple times to put version bounds on dependencies, in memory and other packages.

It's one reason, why I simply avoid packages by that person. (It's difficult, but not impossible).

Please, open issues to their issue trackers, as that author simply ignores anything coming from Hackage trustees.

TL;DR I personally refuse to revise memory as the author is ignorant for the work trustees do.

[vmchale]

What's the status of the time package? It seems its bounds are too loose: https://matrix.hackage.haskell.org/#/package/time

[phadej]

@vmchale time is "fine". it works ok when it's a dependency.

[hvr]

• vector-th-unbox revised (upstream ticket https://github.com/liyang/vector-th-unbox/issues/22#issuecomment-527014591)

• json revised (cc @yav)

  • https://hackage.haskell.org/package/json-0.9.3/revisions/
  • https://hackage.haskell.org/package/json-0.9.2/revisions/

[cartazio]

@phadej to clarify/expand: you mean that the build failure on hackage matrix happens only when its a local source tree / checkout build, rather than normally as a pkg we cabal install, right?

[vmchale]

With the latest happy release, I believe the language-c bounds are now going to cause breakages.

[phadej]

language-c reviewed.

[athas]

vector-binary-instances could also do with a bump for base. There is a upstream pull request.

[phadej]

not allowing newer base is not a breakage (i.e. there are no errors reported by compiler), as far as this issue is concerned.

[quasicomputational]

hnix will also be broken soon, but that's being masked by dependency failures.

[phadej]

@quasicomputational hnix is in miserable state even without masking: https://matrix.hackage.haskell.org/#/package/hnix (edit: worth it's own issue, if that package is important to not nix users)

[phadej]

I made revisions for ~4 recent years of jose versions. That should be good enough.