Bumps for GHC 9.6

[andreasabel]

• Bump tested-with and Haskell CI to GHC 9.6.1 alpha, 9.4.4 and 9.2.6
• bump base, unix, Cabal-syntax

TODO:

• [x] Also bump the other CI

CI uses Cabal-syntax 3.9.0.0: https://github.com/haskell/hackage-security/actions/runs/4214000092/jobs/7314153972#step:15:1024

[andreasabel]

On GHC 9.6.0, Haskell CI fails in the "unconstrainted build" step because of a Cabal-syntax/Cabal misconfiguration: https://github.com/haskell/hackage-security/actions/runs/4214000236/jobs/7314154574

src/Hackage/Security/TUF/Layout/Repo.hs:9:1: error:
    Ambiguous module name ‘Distribution.Package’:
      it was found in multiple packages:
      Cabal-3.2.1.0 Cabal-syntax-3.8.1.0
  |
9 | import Distribution.Package
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^

The "unconstrained build" problem could fix itself once Cabal >= 3.9 is published. However, I am mystified how it arises.

[Mikolaj]

I forgot the details of the fiasco with "Ambiguous module name". Would putting the same bounds on Cabal in the place where Cabal-syntax is bound help? I see that's what we are doing in cabal-install.

[andreasabel]

I forgot the details of the fiasco with "Ambiguous module name". Would putting the same bounds on Cabal in the place where Cabal-syntax is bound help? I see that's what we are doing in cabal-install.

Not sure. Since hackage-security should only depend on Cabal-syntax for later versions of Cabal, we would not want to add Cabal to the build-depends in the Cabal-syntax case: https://github.com/haskell/hackage-security/blob/c37c91c48e0d21b587360534da8a852c5cdf4a74/hackage-security/hackage-security.cabal#L156-L162

The Cabal dependency must be pulled in by another dependency, otherwise I cannot explain the situation.

Note that Cabal-3.2.1.0 is usually not available for GHC 9.x, only on head.hackage: (FIXED:) https://gitlab.haskell.org/ghc/head.hackage/-/blob/823768eb1bd58c74820362c8e09d8981e0407dea/patches/Cabal-3.2.1.0.patch This patch only shows the changes to the code, not to the dependencies of Cabal-3.2.1.0.

So maybe this is just a problem with head.hackage, and we can ignore it for now. This is my suggestion, unless you have more insights into the problem.

[Mikolaj]

I think you mistakenly pasted the same link twice.

[andreasabel]

I think you mistakenly pasted the same link twice.

Indeed, thanks. Fixed.

[Mikolaj]

So maybe this is just a problem with head.hackage, and we can ignore it for now. This is my suggestion, unless you have more insights into the problem.

Makes sense. We can't get rid of head.hackage (without adding allow-newer), right?

[andreasabel]

Makes sense. We can't get rid of head.hackage (without adding allow-newer), right?

Indeed not.

I published revisions for all packages that were on hackage: https://github.com/haskell/hackage-security/commit/3152391d710bce42819898c3e1c7b703db01a131

2023-02-20T10:23:03Z AndreasAbel hackage-repo-tool-0.1.1.3-r2 2023-02-20T10:18:13Z AndreasAbel hackage-security-HTTP-0.1.1.1-r5 2023-02-20T10:15:30Z AndreasAbel hackage-security-0.6.2.3-r1

[andreasabel]

I noticed when I compared with #290 again that I missed a bump from Cabal<3.10 to <3.12 in hackage-security's testsuite. CI cannot catch this as it works with 3.9.0.0.

Added a new patch. This would then be revision 2. Shall I publish it? We could also wait until 3.10 is out for sure, or does this defeat the purpose?

[Mikolaj]

No hurry, I guess. This won't derail cabal's release, because it's only the test. I think these tests are not run in cabal CI either.

[andreasabel]

The "unconstrained build" problem could fix itself once Cabal >= 3.9 is published. However, I am mystified how it arises.

I think I understand it now. The "unconstraint build" head job has allow-newer for all GHC-shipped packages, which includes Cabal and Cabal-syntax. So, this is just an artefact; I turned the "unconstrained build" off now.

• https://github.com/haskell-CI/haskell-ci/issues/642

[andreasabel]

Squash and merge?

[Mikolaj]

Sounds good to me. Please do.

[andreasabel]

No hurry, I guess. This won't derail cabal's release, because it's only the test. I think these tests are not run in cabal CI either.

I did the revision anyway now so that the codebase here is in sync with hackage. (Otherwise, coming back here in the future I would be puzzled, not remembering the details...)

[Mikolaj]

Agreed, Andreas.