Compatibilty with GHC-9.4

haskell / hackage-security

Hackage security framework based on TUF (The Update Framework)

http://hackage.haskell.org/package/hackage-security

56 stars 48 forks source link

Compatibilty with GHC-9.4 #284

Closed ulysses4ever closed 2 years ago

ulysses4ever commented 2 years ago

Fix #283. There are two issues.

A bunch of Oleg's packages need to bump their bounds on base.
I added allow-newer for those in (1) in a separate branch and it failed on Windows with a mysterious linker error: https://github.com/ulysses4ever/hackage-security/runs/7934953899?check_suite_focus=true

ulysses4ever commented 2 years ago

Here are two PR's with CI results readily available:

https://github.com/ulysses4ever/hackage-security/pull/2 -- allow-newer; note that haskell-CI fails expectedly because it generates it's own cabal-project
https://github.com/ulysses4ever/hackage-security/pull/1 -- identical to this PR

the windows linker failure is probably due to a change in GHC 9.4 moving to the clang tool chain.

ulysses4ever commented 2 years ago

Opened a GHC ticket to inquire about the windows linking failure.

Bodigrim commented 2 years ago

@ulysses4ever On Windows GHC 9.4 requires Cabal 3.8 for successful linking, Cabal 3.6 will not work.

ulysses4ever commented 2 years ago

Great, thank you, Bodigrim!

I bumped the cabal version, and Oleg updated the bounds. The CI is all green now (no allow-newer)!

andreasabel commented 2 years ago

@ulysses4ever : Looks like you forgot haskell-ci regenerate. (Happens to me all the time...)

ulysses4ever commented 2 years ago

@andreasabel I should confess I had no idea... But now I see that it updates 9.2.1 to 9.2.4 which indeed should have been done before. I'll try to keep in mind...

There's a problem though:

❯ haskell-ci regenerate
No haskell-ci.sh, skipping bash regeneration
*INFO* Generating GitHub config for testing for GHC versions: ghc-head 7.4.2 7.6.3 7.8.4 7.10.3 8.0.2 8.2.2 8.4.4 8.6.5 8.8.4 8.10.7 9.0.2 9.2.4 9.4.1
Invalid option `--osx=8.4.4'

What's up with --osx? I updated the PR with the current state after this command but should I try to fix this error?

Bodigrim commented 2 years ago

haskell-ci regenerate uses command line from .travis.yml. Remove it and use haskell-ci github cabal.project.

ulysses4ever commented 2 years ago

@Bodigrim indeed, after removing .travis.yml the error has gone. Then, haskell-ci github cabal.project succeeds but doesn't change github workflow anyhow, but it already looks fine. Overall, I added one commit that just removes .travis.yml.

ulysses4ever commented 2 years ago

Thanks everyone for shepherding this! Any chance for a Hackage revision?

andreasabel commented 2 years ago

Any chance for a Hackage revision?

@Mikolaj is the hackage maintainer here and the first address for this.

Mikolaj commented 2 years ago

@ulysses4ever: you mean Hackage release? Of which packages?

BTW, great job. :)

ulysses4ever commented 2 years ago

@Mikolaj hackage-security. It's necessary for moving Cabal to 9.4.1. Revision with base bound bump would suffice I think.

Mikolaj commented 2 years ago

All right, I will revise all the changed bounds of hackage-security.

Will hackage-repo-tool in cabal CI work without revision/release for 9.4.1, though?

ulysses4ever commented 2 years ago

I hoped to get complete patch for cabal yesterday but something came up. I hope I can answer your question some time this week...

Mikolaj commented 2 years ago

I revised both hackage-security and hackage-repo-tool. I hope that should be enough.

juhp commented 2 years ago

I think the current hackage revision still doesn't allow Cabal-3.8, or does that need a new release?

(I can open a new issue if that is better.)

Mikolaj commented 2 years ago

The version on hackage doesn't suport GHC 9.4, but it should support Cabal 3.8. The Hackage package display is fooled by conditionals, I think. It seems to only display the first branch or something like that. Please let me know if your tests show otherwise or if you require support for GHC 9.4.