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:

• 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]

Thank you.

[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:

hackage-security/hackage-security/hackage-security.cabal

Lines 156 to 162 in c37c91c

	if flag(Cabal-syntax) && impl(ghc >= 8.2)
	build-depends: Cabal-syntax >= 3.7 && < 3.10
	else
	build-depends: Cabal >= 1.14 && < 1.26
	|| >= 2.0 && < 2.6
	|| >= 3.0 && < 3.7,
	Cabal-syntax < 3.7

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: 3152391

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.

• Should the "unconstrained build" be off by default for head.hackage haskell-CI/haskell-ci#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.