-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update contrib #10
Update contrib #10
Conversation
a5e3e87
to
6180e5b
Compare
b62c084
to
2c74520
Compare
1dd8791
to
476696e
Compare
Are the 2 CI failures the problematic ones? These are with old GHCs only, right? |
Yes, but the source packages still work on those older GHCs so ideally we should be able to as well. |
For the GHC 8.4.4 failure:
It thinks the installed version of the ghc package, 8.4.4 specifically depends on the installed version of the binary package, 0.8.5.1, when in actual fact ghc-8.4.4 on hackage can use binary |
In fact, ghc package is not re-installable currently, so cabal is doing the right thing, but communicating it wrongly: haskell/cabal#8501 |
Why do we depend on binary here ? Neither containers nor vector does. Even more unexpectedly, whey are we depending on ghc? |
Oh, I see, ghc dep comes from and the binary dep as well. Perhaps this test should be disabled for the old GHCs? |
Sadly, currently, anything that depends on boot packages needs to work with the versions of their deps they have been compiled with and the boot packages can't be recompiled. The kind GHC folk are working on lifting this restriction ("reinstallable ghc library", if I'm not mistaken). |
OK, yes #haskell also convinced me the current task is impossible. Simplest solution probably is indeed to disable that test for older GHCs. binary dep is for instances. They could be lifted out into a separate package if the dependency continues causing problems, but I think we can avoid that for the time being. |
476696e
to
d0668f3
Compare
GHC 8.2 failure is probably blocked on well-typed/cborg#302 |
those older versions depend on ghc-heap-view which depends on ghc. this is a fundamental package whose deps cannot be upgraded as part of an install plan. unfortunately, newer contrib packages depend on a newer 'binary' package, which is one of those packages that cannot be upgraded.
d0668f3
to
2dfa793
Compare
well-typed/cborg#302 is done. |
it needs to be released to hackage of course, for the failing CI to have a hope of succeeding |
oh |
It is, https://hackage.haskell.org/package/serialise-0.2.6.0/revisions/ |
So probably a restart of CI would be enough? |
OK I guess they released the PR to hackage before it was merged, as the date shows Oct 23 but the PR was merged just a few days ago. I restarted the CI yesterday already and it's still failing. Taking a look, this is because:
Probably, the simplest solution is to drop support for the older GHC in |
…here it is unsupported
afff7ac
to
11828d2
Compare
Yes, they seem to have applied a revision on Hackage ahead of the PR, possibly without even knowing about each other. |
This reverts commit 4992932.
No description provided.