make formatting of build-depends consistent

[peterbecich]

*.cabal files in this project presently have a mix of formatting of build-depends.

Make them all consistent with:
https://cabal.readthedocs.io/en/3.4/cabal-package.html

There are no changes to any dependencies.

Please read Github PR Conventions and then fill in one of these two templates.

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[ulysses4ever]

Seems fine to me. Maybe a candidate to .git-blame-ignore-revs?..

[ulysses4ever]

Thanks!

[peterbecich]

@ulysses4ever can this be merged?

[ffaf1]

I added the squash+merge me label @peterbecich. Let us sit tight for 48 hours and it will be auto-merged.

[peterbecich]

@ffaf1 , incidentally, can manual merge be disabled? How can we configure this repo so only the Bot can merge?

[peterbecich]

@ffaf1 , a second question, if you squash this PR and change the commit hash, that will break .git-blame-ignore-refs https://github.com/haskell/cabal/pull/10714/files#diff-f247fbfbe928b907db42554d0b3006b28dd11c25a59be031abda73b11a2c934a right?

[ffaf1]

@ffaf1 , a second question, if you squash this PR and change the commit hash, that will break .git-blame-ignore-refs

Indeed, well spotted. I set it back to merge me.

incidentally, can manual merge be disabled? How can we configure this repo so only the Bot can merge?

Good question, I don't have an answer. I will ask in Matrix.

[ffaf1]

This was a reply I got, and I agree with it.

“multiple times in my experience something has broken CI such that we needed to manually merge something to fix it (usually some dependency). not sure restricting that to admins is wise, sometimes admins aren't around as with the holiday break[.]”

an more:

“I don't remember a single time when admins "were not around". We have plenty of admins these days. On the other hand, I remember plenty of accidental merges via the button by new or returning contributors. Hence, I am all for disabling the merge button for non-admins.”

[ulysses4ever]

Thanks for raising the issue about the merge button @peterbecich ! I'll try to raise this issue at the upcoming Cabal meeting (this Thursday, the 16th). I think it makes sense to restrict it to admins only.

[peterbecich]

@Mikolaj remove fddf792 please

The commit hashes have changed so it has no purpose now, it is not critical.

[ffaf1]

It is an automated bot action, let me see if I can block the merge queue… Or we will just put the correct hash after the fact.

[Mikolaj]

Maybe this is a rare case where manual merging is in order so that Mergify does not rebase and so invalidate the hashes. If so, @peterbecich, please feel free to use the button after rebasing manually and updating the commit with the hashes one last time.

[mergify]

This pull request has been removed from the queue for the following reason: pull request dequeued.

Pull request #10714 has been dequeued. The pull request rule doesn't match anymore. The following conditions don't match anymore:

• label=merge me
• any of: [🔀 queue conditions]
  • all of: [📌 queue conditions of queue default]
    • any of: [🛡 GitHub branch protection]
      • check-neutral = Validate post job
      • check-skipped = Validate post job
      • check-success = Validate post job

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.

If you want to requeue this pull request, you need to post a comment with the text: @mergifyio requeue

[ulysses4ever]

One merge option that fits this case is the "merge+no rebase" label, I believe. In that case Mergify won't touch the original commits. Of course, it's too little too late because the commits have been updated, so someone needs to update the SHA in the text file, and then put the "merge+no rebase" label...