ci: Probe boot packages from package db

changed the description

Nice, I like this approach much better than the ad hoc lifting of version bounds we were doing before.

Alas, this reveals that some packages still fail to build with the latest transformers/mtl. (Previously, the CI would just pick a build plan with older versions of these libraries rather than the versions bundled with GHC.) Do you plan to address these build failures, @bgamari?

I think as you have discovered the distinction between a bootPkg and an allowNewerPkg was there for a reason.

Perhaps so, but should there be a distinction? Personally, I'm inclined to go through the process of fixing the five or so packages that don't currently build so that we have a much clearer policy w.r.t. boot packages in the future. (I've lost track of the number of times I've had to explain to head.hackage users "oh, in order to reproduce the results from CI, you have to use --allow-newer on this specific subset of packages"... it's always felt strangely arbitrary to me.) I welcome opposing opinions on this, however.

added 1 commit

57723df4 - Adapt more packages to transformers-0.6.*/mtl-2.3.*

Compare with previous version

Thank you for picking this up, @RyanGlScott. It would otherwise have needed to wait until next week.

@mpickering, my sense is that this distinction is not tenable. It is simply too difficult to ensure that the package remains soluble with the tools that cabal currently provides us with.

added 1 commit

2732e19e - Add empty containers-0.6.8 patch

Compare with previous version

In general I don't see a reason why we should fix mtl installed for all build plans when the build plan for each package is computed individually. Most packages do not depend on ghc library and force the use of an already installed library.

My memory is that the mtl-2.3 bump caused many packages to fail to build, and allowing them to build with mtl-2.2.*.

added 1 commit

0d0e51c1 - Adapt language-bash patch to build with parsec-3.1.17.0

Compare with previous version

For some reason, all of the test-* jobs are now failing. An excerpt from the text-9.6 [x86_64] job:

Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] next goal: text (user goal)
[__0] rejecting: text-2.0.2 (constraint from project config
/builds/ghc/head.hackage/ci/run/test-all/cabal.project requires installed
instance)
[__0] rejecting: text-2.0.1, text-2.0, text-1.2.5.0, text-1.2.4.1,
text-1.2.4.0, text-1.2.3.2, text-1.2.3.1, text-1.2.3.0, text-1.2.2.2,
text-1.2.2.1, text-1.2.2.0, text-1.2.1.3, text-1.2.1.2, text-1.2.1.1,
text-1.2.1.0, text-1.2.0.6, text-1.2.0.5, text-1.2.0.4, text-1.2.0.3,
text-1.2.0.2, text-1.2.0.0, text-1.1.1.4, text-1.1.1.3, text-1.1.1.2,
text-1.1.1.1, text-1.1.1.0, text-1.1.0.1, text-1.1.0.0, text-1.0.0.1,
text-1.0.0.0, text-0.11.3.1, text-0.11.3.0, text-0.11.2.3, text-0.11.2.2,
text-0.11.2.1, text-0.11.2.0, text-0.11.1.13, text-0.11.1.12, text-0.11.1.11,
text-0.11.1.10, text-0.11.1.9, text-0.11.1.8, text-0.11.1.7, text-0.11.1.6,
text-0.11.1.5, text-0.11.1.3, text-0.11.1.2, text-0.11.1.1, text-0.11.1.0,
text-0.11.0.8, text-0.11.0.7, text-0.11.0.6, text-0.11.0.5, text-0.11.0.4,
text-0.11.0.3, text-0.11.0.2, text-0.11.0.1, text-0.11.0.0, text-0.10.0.2,
text-0.10.0.1, text-0.10.0.0, text-0.9.1.0, text-0.9.0.1, text-0.9.0.0,
text-0.8.1.0, text-0.8.0.0, text-0.7.2.1, text-0.7.1.0, text-0.7.0.1,
text-0.7, text-0.6, text-0.5, text-0.4, text-0.3, text-0.2, text-0.1
(constraint from user target requires ==2.0.2)
[__0] fail (backjumping, conflict set: text)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: text

I'm unclear why cabal complains with requires installed instance, since GHC 9.6 is indeed bundled with text-2.0.2. Any ideas what is going on here?

Do you need to update the text submodule in the head.hackage repo?

Possibly? But then again, cabal also gives a similar complaint about bytestring-0.12.0.2, and that is the version from the latest commit in the upstream bytestring repo, so it seems unlikely that bumping that submodule would change anything.

I wonder what the cabal.project uses for testing bytestring, text, etc. looks like in practice. Perhaps it contains conflicting constraints?

mentioned in merge request !328 (merged)

mentioned in merge request !342 (merged)

ci: Probe boot packages from package db

Merge request reports

Activity