Can cabal-install 3.12.1 build with hashable-1.5?

[juhp]

It would be nice to have cabal-install back in Stackage Nightly.

Unfortunately due to hashable-1.5, cabal-install-3.12.1 does not build there.

Is it possible to relax the upper bound?

Otherwise hopefully 3.14+ may improve the situation...

[geekosaur]

We ran into a road bump with updating the dependency, IIRC (and checking PRs agrees). I think hashable-1.5 is okay with cabal-install 3.12.

[geekosaur]

Also 3.14 should have the updated dependency bound already, and I think 3.16-to-come got rid of it entirely. (Correction: the removal got backported, so if Stackage can be updated to a 3.14 release then there should be no problem.)

[juhp]

Stackage can't update (until ghc-9.12) that is the point :-) We always need the cabal-install for the version of ghc Cabal.

Like any good distro :-)

[juhp]

I can try a PR for the 3.12 branch I guess - though really we need a revision.

[geekosaur]

I think PRs for 3.12 are closed since we ditched the LTS thing until we can get GHC to play along with it (little point in an LTS if we have to rev every ghc major version, which are happening rather quickly these days). I would suggest a local validate with --constraint=hashable==1.5 --disable-documentation (the latter due to a bug in validate that was fixed for 3.14) to test, then we can proceed with the revbump.

[juhp]

Hmm okay... couldn't we validate on the branch - anyway sure then I will try to test it locally.

I guess the 3.12 branch could in principle have diverged from the release...

[juhp]

I would argue though that this project really should validate cabal-install releases can build against the corresponding latest ghc minor release - that would be a useful service to distros and the ecosystem.

To put it differently: we should aim to always have cabal-install available in Stackage LTS and Nightly.

[geekosaur]

It's not supposed to have diverged, and in fact I was checking it regularly while we were hoping to use it as an LTS branch.

[geekosaur]

I would argue though that this project really should validate cabal-install releases can build against the corresponding latest ghc minor release - that would be a useful service to distros and the ecosystem.

https://github.com/haskell/cabal/blob/master/.github/workflows/check-sdist.yml

[geekosaur]

hm, actually I think that's the reverse. (We need to ensure it works with the Cabal in the ghc release.) We do validate against latest minor release normally, but someone needs to update that periodically and we've forgotten a few times.

[geekosaur]

I should also note that we don't (and in general can't, without a reorganization of our CI) validate older versions of cabal-install. In particular, validate is pretty brittle. IIRC 3.10.x validate broke some time back, not helped by several breaking changes in some minor releases (notably 3.10.3, which is what led to the check-sdist job).

[juhp]

As a first PoC, at least revising hashable and open-browser (even cabal-install-3.14 doesn't allow 0.4 yet...) builds fine in current Stackage Nightly.

[juhp]

I opened #10946 for master

[juhp]

( $ ./validate.sh --constraint=hashable==1.5 --disable-documentation --with ghc-9.10.2 Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] trying: cabal-testsuite-3 (user goal) [__1] next goal: cabal-testsuite:setup.Cabal (dependency of cabal-testsuite) [__1] rejecting: cabal-testsuite:setup.Cabal-3.14.2.0, cabal-testsuite:setup.Cabal-3.14.1.1, cabal-testsuite:setup.Cabal-3.14.1.0, cabal-testsuite:setup.Cabal-3.14.0.0, cabal-testsuite:setup.Cabal-3.12.1.0, cabal-testsuite:setup.Cabal-3.12.0.0 (constraint from maximum version of Cabal

I wish cabal-install could just say "I (3.10.3) am too old to build this"... )

[juhp]

Hmm I got to:

$ cabal-3.14.2 run --constraint hashable==1.5 --disable-documentation cabal-validate:exe:cabal-validate -- --with ghc-9.10.2
Configuration is affected by the following files:
- cabal.project
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: Cabal-tree-diff-3.12.0.0 (user goal)
[__1] trying: tree-diff-0.3.4 (dependency of Cabal-tree-diff)
[__2] next goal: hashable (dependency of tree-diff)
[__2] rejecting: hashable; 1.4.7.0/installed-4sYUjiqCRWp1Ivr6Bfittp, 1.5.0.0, 1.4.7.0, 1.4.6.0, 1.4.5.0, 1.4.4.0, 1.4.3.0, 1.4.2.0, 1.4.1.0, 1.4.0.2, 1.4.0.1, 1.4.0.0, 1.3.5.0, 1.3.4.1, 1.3.4.0, 1.3.3.0, 1.3.2.0, 1.3.1.0, 1.3.0.0, 1.2.7.0, 1.2.6.1, 1.2.6.0, 1.2.5.0, 1.2.4.0, 1.2.3.3, 1.2.3.2, 1.2.3.1, 1.2.3.0, 1.2.2.0, 1.2.1.0, 1.2.0.10, 1.2.0.9, 1.2.0.8, 1.2.0.7, 1.2.0.6, 1.2.0.5, 1.2.0.4, 1.2.0.3, 1.2.0.2, 1.2.0.1, 1.2.0.0, 1.1.2.5, 1.1.2.4, 1.1.2.3, 1.1.2.2, 1.1.2.1, 1.1.2.0, 1.1.1.0, 1.1.0.0, 1.0.1.1, 1.0.1.0, 1.0.0 (constraint from command line flag requires ==1.5)
[__2] fail (backjumping, conflict set: hashable, tree-diff)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: hashable, tree-diff, Cabal-tree-diff

Maybe I don't understand the constraints: naively tree-diff-0.3.4 seems to allow hashable-1.5

Is it not good enough that cabal-install can build with hashable-1.5?

[geekosaur]

I think this is just a vagary in how versions are compared: the actual constraint has to be --constraint hashable==1.5.0.0. Sorry for the abbreviation.

[juhp]

Right duh, indeed, my bad

[juhp]

$ cabal-3.14.2 run --constraint hashable==1.5.0.0 --disable-documentation cabal-validate:exe:cabal-validate -- -w ghc-9.10.2 --with-cabal cabal-3.14.2
:
Resolving dependencies...
═══ print-config ════════════════════════════════════════════════════════════════════════compiler:          ghc-9.10.2
cabal-install:     cabal-3.14.2
jobs:              16
steps:             print-config print-tool-versions build lib-tests cli-tests time-summary
Hackage tests:     NoHackageTests
verbose:           False
extra compilers:   
extra RTS options: 
print-config finished after 0.00s
Total time so far: 0.02s

═══ print-tool-versions ═════════════════════════════════════════════════════════════════$ ghc-9.10.2 --version
The Glorious Glasgow Haskell Compilation System, version 9.10.2

Finished after 0.02s: ghc-9.10.2 --version
Total time so far: 0.05s
$ cabal-3.14.2 --version
cabal-install version 3.14.2.0
compiled using version 3.14.2.0 of the Cabal library

Finished after 0.00s: cabal-3.14.2 --version
Total time so far: 0.05s
print-tool-versions finished after 0.03s
Total time so far: 0.05s

═══ build ══════════════════════════════════════════════════════════════════════════════════ build (dry run) ═════════════════════════════════════════════════════════════════════$ cabal-3.14.2 build --jobs=16 --with-compiler=ghc-9.10.2 --builddir=dist-newstyle-validate-ghc-9.10.2 --project-file=cabal.validate.project Cabal cabal-testsuite Cabal-tests Cabal-QuickCheck Cabal-tree-diff Cabal-described cabal-install cabal-install-solver cabal-benchmarks --dry-run
Resolving dependencies...
Configuration is affected by the following files:
- cabal.validate.project
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] next goal: Cabal (user goal)
[__0] rejecting: Cabal; 3.14.2.0, 3.14.1.1, 3.14.1.0, 3.14.0.0 (constraint from user target requires ==3.12.1.0)
[__0] trying: Cabal-3.12.1.0
[__1] trying: base-4.20.1.0/installed-ba26 (dependency of Cabal)
[__2] trying: cabal-benchmarks-3 (user goal)
[__3] trying: cabal-benchmarks:*test
[__4] next goal: tasty-bench (dependency of cabal-benchmarks *test)
[__4] rejecting: tasty-bench; 0.4.1, 0.4 (conflict: cabal-benchmarks *test => tasty-bench>=0.3.5 && <0.4)
[__4] rejecting: tasty-bench-0.3.5 (conflict: base => ghc-prim==0.12.0/installed-dbbc, tasty-bench => ghc-prim<0.12)
[__4] rejecting: tasty-bench; 0.3.4, 0.3.3, 0.3.2, 0.3.1, 0.3, 0.2.5, 0.2.3, 0.2.2, 0.2.1, 0.1, 0.2.4, 0.2 (conflict: cabal-benchmarks *test => tasty-bench>=0.3.5 && <0.4)
[__4] fail (backjumping, conflict set: base, cabal-benchmarks, tasty-bench, cabal-benchmarks:test)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, Cabal, cabal-benchmarks, cabal-benchmarks:test, tasty-bench
Try running with --minimize-conflict-set to improve the error message.
Failed with exit code 1 after 1.63s: cabal-3.14.2 build --jobs=16 --with-compiler=ghc-9.10.2 --builddir=dist-newstyle-validate-ghc-9.10.2 --project-file=cabal.validate.project Cabal cabal-testsuite Cabal-tests Cabal-QuickCheck Cabal-tree-diff Cabal-described cabal-install cabal-install-solver cabal-benchmarks --dry-run
Total time so far: 1.69s
build failed after 1.63s
Total time so far: 1.69s

I guess I am confused why isn't it just using the Cabal and cabal-install from source or rather I am not very sure what the expected behavior is...

Am I doing this right? Maybe I need to install cabal-3.12.1.0??

ps Is the concern that cabal-install might build but fail at runtime?

[geekosaur]

The complaint is that your ghc (9.10.2) is too new: tasty-bench won't build with the ghc-prim that ships with it. Try it with 9.8.

[Bodigrim]

@juhp I revised tasty-bench-0.3.5, you can cabal update and try again.

[juhp]

Thanks that helped a lot.

Now got to:

═══ cli-tests ══════════════════════════════════════════════════════════════════Configuration is affected by the following files:
- cabal.validate.project
$ /var/home/petersen/haskell/cabal/dist-newstyle-validate-ghc-9.10.2/build/x86_64-linux/ghc-9.10.2/cabal-install-3.12.1.0/t/long-tests/build/long-tests/long-tests --num-threads 16 --hide-successes
File modification time resolution calibration completed, maximum delay
observed: 0.653 ms. Will be using delay of 20.0 for test runs.
Using --quickcheck-replay=2795787633019717434
Using --quickcheck-replay=586336127015765602
Using --quickcheck-replay=-5797542063669474555
Using --quickcheck-replay=5538852474748624750
Using --quickcheck-replay=4169503393406851991
Using --quickcheck-replay=-5415754170473367617
Using --quickcheck-replay=-989708492354304616
Using --quickcheck-replay=5866478618681702180
rm 'file/B'
rm 'file/C'
rm 'file/B'
rm 'file/B'
rm 'file/B'
rm 'file/B'
Long-running tests
  UnitTests.Distribution.Client.VCS
    git
      check VCS test framework:                                                 FAIL (9.84s)
        *** Failed! Exception: 'ExitFailure 128' (after 2 tests and 5 shrinks):
        BranchingRepoRecipe [Left (TaggedCommits "tag_FTL" [Commit [Right (SubmoduleAdd "file/D" "awullspiohoygyqdghsk" (Commit [Left (FileUpdate "file/C" "$*1nOIb<cj"),Left (FileUpdate "file/A" "yXo[^.#i4]"),Right (SubmoduleAdd "file/E" "aznlxlcucnzygerrolqf" (Commit [Left (FileUpdate "file/A" "-,NRkfuk^,")]))]))]])]
        Use --quickcheck-replay=533402 to reproduce.
        Use -p '/git.check VCS test framework/' to rerun this test only.
      cloneSourceRepo:                                                          FAIL (8.78s)
        *** Failed! Exception: 'ExitFailure 128' (after 2 tests and 3 shrinks):
        BranchingRepoRecipe [Left (TaggedCommits "tag_RI" [Commit [Right (SubmoduleAdd "file/A" "czmmtrpilyckdducpqco" (Commit [Left (FileUpdate "file/C" "'rxZX-}&%,"),Right (SubmoduleAdd "file/E" "excbqedpfopzydjeqlty" (Commit [Left (FileUpdate "file/E" "%M=K`Vl8d<")]))]))]])]
        Use --quickcheck-replay=898811 to reproduce.
        Use -p '/git.cloneSourceRepo/' to rerun this test only.
      syncSourceRepos:                                                          FAIL (9.34s)
        *** Failed! Exception: 'ExitFailure 128' (after 2 tests and 5 shrinks):
        RepoDirSet 1
        SyncTargetIterations 1
        PrngSeed 2097978624333837942
        BranchingRepoRecipe [Left (TaggedCommits "tag_DKZMK" [Commit [Right (SubmoduleAdd "file/E" "hmyveztovihwxbmhdlyr" (Commit [Left (FileUpdate "file/A" "XDTZ`N*Q02"),Left (FileUpdate "file/C" "IY4<abRLvn"),Left (FileUpdate "file/A" "v;'8qZ_U;9"),Left (FileUpdate "file/B" "{TiMRGNJ'J"),Left (FileUpdate "file/A" "0AXi+p(/\\z")]))]])]
        Use --quickcheck-replay=89209 to reproduce.
        Use -p '/git.syncSourceRepos/' to rerun this test only.

3 out of 91 tests failed (11.79s)
Cloning into '/var/home/petersen/tmp/vcstest-194416/src/file/B'...
fatal: transport 'file' not allowed
fatal: clone of '/var/home/petersen/tmp/vcstest-194416/submodules/pudezbjnsrelfbvrejds' into submodule path '/var/home/petersen/tmp/vcstest-194416/src/file/B' failed
Cloning into '/var/home/petersen/tmp/vcstest-194415/submodules/czmmtrpilyckdducpqco/file/E'...
fatal: transport 'file' not allowed
fatal: clone of '/var/home/petersen/tmp/vcstest-194415/submodules/excbqedpfopzydjeqlty' into submodule path '/var/home/petersen/tmp/vcstest-194415/submodules/czmmtrpilyckdducpqco/file/E' failed
:
:
Cloning into '/var/home/petersen/tmp/vcstest-194414/src/file/E'...
fatal: transport 'file' not allowed
fatal: clone of '/var/home/petersen/tmp/vcstest-194414/submodules/hmyveztovihwxbmhdlyr' into submodule path '/var/home/petersen/tmp/vcstest-194414/src/file/E' failed
Cloning into '/var/home/petersen/tmp/vcstest-194414/submodules/awullspiohoygyqdghsk/file/E'...
fatal: transport 'file' not allowed
fatal: clone of '/var/home/petersen/tmp/vcstest-194414/submodules/aznlxlcucnzygerrolqf' into submodule path '/var/home/petersen/tmp/vcstest-194414/submodules/awullspiohoygyqdghsk/file/E' failed
Failed with exit code 1 after 11.82s: /var/home/petersen/haskell/cabal/dist-newstyle-validate-ghc-9.10.2/build/x86_64-linux/ghc-9.10.2/cabal-install-3.12.1.0/t/long-tests/build/long-tests/long-tests --num-threads 16 --hide-successes
Total time so far: 4:42.20
cli-tests failed after 12.04s
Total time so far: 4:42.20

which naively looks unrelated to this change.

Also can I bundle open-browser bump together in this PR?: this is also needed for Stackage LTS 23

[ulysses4ever]

Also can I bundle open-browser bump together in this PR?

SGTM

[ulysses4ever]

fatal: transport 'file' not allowed

does look unrelated but a little strange: Linux CI has been more stable (less flaky) than others.

[geekosaur]

That failure is due to git not allowing file transport by default any more for security reasons. There's a ticket for it but I'm busy today and don't have time to dig for it.

[ulysses4ever]

Thanks @geekosaur! Indeed, it's

• https://github.com/haskell/cabal/issues/9626

[ulysses4ever]

So, the reason for the file transport error is that https://github.com/haskell/cabal/pull/10329 was never backported to 3.12 @juhp. That's fine.

[ulysses4ever]

Based on the results of the above experiment, I revised the hashable bound for 3.12.1.0: https://hackage.haskell.org/package/cabal-install-3.12.1.0/revisions/