Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump time upper bound to acccomodate 1.14 #9848

Merged
merged 1 commit into from
Apr 6, 2024

Conversation

bgamari
Copy link
Contributor

@bgamari bgamari commented Mar 27, 2024

Just as it says on the tin.

Copy link
Collaborator

@geekosaur geekosaur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just did this in xmonad a couple days ago too. Note that, since it's a bootlib, you'll need a --constraint to test it.

@bgamari bgamari added the merge me Tell Mergify Bot to merge label Mar 27, 2024
@andreasabel
Copy link
Member

andreasabel commented Mar 27, 2024

Yes this is untested, CI passing says nothing here.
@bgamari Have you tested the build locally on your machine, with -c 'time >= 1.14' ?

@geekosaur
Copy link
Collaborator

geekosaur commented Mar 27, 2024

I'm running validate.sh locally with a constraint: in cabal.project.validate. Note that this also requires allow-newer: time because not all of our dependencies have been updated for time 1.14 yet.

ETA: validate passed

@bgamari
Copy link
Contributor Author

bgamari commented Mar 27, 2024

@bgamari Have you tested the build locally on your machine, with -c 'time >= 1.14' ?

Yes, I tested it in my GHC tree.

@geekosaur
Copy link
Collaborator

Hm, actually this just updates Cabal and Cabal-syntax whereas I just validated the whole thing. Is a follow-up PR a good idea?

@bgamari
Copy link
Contributor Author

bgamari commented Mar 28, 2024

I only bumped Cabal and Cabal-syntax as this is what I need to bump the time submodule in GHC.

@geekosaur
Copy link
Collaborator

geekosaur commented Mar 28, 2024

That's fine, it's what I figured. But from a Cabal dev POV, I've already done everything necessary to bump cabal-install as well, so I'm asking if I should go for it. After all, we'll have to deal with it eventually anyway.

@andreasabel
Copy link
Member

I wish we could get started to test cabal with GHC 9.10 in general, but we will run into hashable not being ready:

@bgamari Is there something to be done about that? The maintainer does not seem to respond atm. Maybe the GHC team is aware of hashable blocking the road and has a plan...?

@bgamari
Copy link
Contributor Author

bgamari commented Mar 28, 2024

@andreasabel unfortunately I don't have any particular plan here. It would be very nice if we cabal-install provided a finer-grained variant of --allow-newer (e.g. #7896) since it would then at least be more likely that one could work around the issue with more specific constraints.

@phadej, perhaps you can comment here as hashable's maintainer of record?

@phadej
Copy link
Collaborator

phadej commented Mar 28, 2024

@bgamari comment on what?

hashable has specifically bitten by releasing / doing compatibility work for unreleased GHC and then redoing it, so I'm no in interest to support first alpha. If head.hackage doesn't work for you, it's not my problem. Isn't head.hackage there so you don't need to bother maintainers for GHC head / alpha testing?

geekosaur added a commit that referenced this pull request Mar 28, 2024
Note that #9848 covers Cabal and Cabal-syntax already.
@andreasabel
Copy link
Member

@phadej wrote:

hashable has specifically bitten by releasing / doing compatibility work for unreleased GHC and then redoing it, so I'm no in interest to support first alpha. If head.hackage doesn't work for you, it's not my problem. Isn't head.hackage there so you don't need to bother maintainers for GHC head / alpha testing?

Well, if I understand the problem correctly, it is primarily the incompatibility of hashable with filepath-1.5 which causes the problem. filepath-1.5 is already released. Not supporting it yet is just delaying the inevitable. And it makes evaluating filepath-1.5 much harder (so that most won't bother supporting it yet either). Now it also makes evaluating GHC 9.10 much harder.
hashable has 1000 users on Stackage alone, should they all do their own source-package-repository workaround?

@Bodigrim
Copy link
Collaborator

hashable has 1000 users on Stackage alone, should they all do their own source-package-repository workaround?

I know two simple workarounds:

  • Use head.hackage and force -c 'hashable +os-string'.
  • Or don't use head.hackage and force -c 'filepath < 1.5'.

@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Mar 29, 2024
@Mikolaj
Copy link
Member

Mikolaj commented Apr 6, 2024

Let me try to verify if the CI failure is a fluke or not.

@Mikolaj
Copy link
Member

Mikolaj commented Apr 6, 2024

@mergify rebase

Copy link
Contributor

mergify bot commented Apr 6, 2024

rebase

✅ Branch has been successfully rebased

@Mikolaj
Copy link
Member

Mikolaj commented Apr 6, 2024

@bgamari: do I understand right that this should be backported to 3.12? I guess, you already apply this patch to your checkout of Cabal 3.12 in GHC 9.10?

Edit: and, if so, are any other such PRs pending? It would be unfortunate to release 3.12.0.0 without them...

Edit2: maybe this should have a checkbox in #9729?

@mergify mergify bot merged commit 661aeca into haskell:master Apr 6, 2024
55 checks passed
@Mikolaj
Copy link
Member

Mikolaj commented Apr 6, 2024

@mergify backport 3.12

Copy link
Contributor

mergify bot commented Apr 6, 2024

backport 3.12

✅ Backports have been created

mergify bot added a commit that referenced this pull request Apr 6, 2024
Bump time upper bound to acccomodate 1.14 (backport #9848)
Mikolaj pushed a commit that referenced this pull request Apr 16, 2024
Note that #9848 covers Cabal and Cabal-syntax already.
mergify bot pushed a commit that referenced this pull request Apr 18, 2024
Note that #9848 covers Cabal and Cabal-syntax already.

(cherry picked from commit 65842cb)
erikd pushed a commit to erikd/cabal that referenced this pull request Apr 22, 2024
Note that haskell#9848 covers Cabal and Cabal-syntax already.
Mikolaj pushed a commit that referenced this pull request Apr 23, 2024
Note that #9848 covers Cabal and Cabal-syntax already.

(cherry picked from commit 65842cb)
Mikolaj pushed a commit that referenced this pull request May 1, 2024
Note that #9848 covers Cabal and Cabal-syntax already.

(cherry picked from commit 65842cb)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days merge me Tell Mergify Bot to merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants