Why not backport #11209 instead?

IIRC these are actually just a requirement of Fedora; there's no actual backporting or etc. requirement, just a metadata update, as with the earlier ticket for 3.12. (Well, for 3.16 we probably do want to backport if needed. That said, I thought we'd fixed this before the branch.)

No it is for future stackage as is the other one too: hence the stackage ticket.
Will be needed when Stackage nightly moves to ghc-9.14.

Would be great if cabal kept up with upstreams more proactively.

Why not backport #11209 instead?

I would like both: 3.14 should not be ahead of 3.16

Why not backport #11209 instead?

I would like both: 3.14 should not be ahead of 3.16

Yes, I mean, why not backport #11209 twice instead? In particular, it has some more code changes, which is probably required (tar has changed its API). But, in general, it's better to backport things.

It's not strictly required, but the new API fixes a bug where you can run out of file descriptors.

Ah I see sorry (would help if I actually opened the link my bad) - I wrongly assumed you were talking about my other PR.

Sure we can if it is easy - my concern is only to lift the tar bound: let me try to rebase then later

Okay I cherry-picked @geekosaur's PR commit

I see 3.16 still doesn't have the bound changed. Is this PR ready for review? If so could you set the needs-review label? It will unfortunately need 2 reviews, because it's not technically a backport.

@Mikolaj, it still needs only one review. Backports skip the cooldown, not the second review.

@geekosaur: I stand corrected.

@juhp: in that case, please kindly set the merge_me label (unless you'd prefer to skip the 3.16.1.0 release, but we can't guarantee there's going to be 3.16.2.0).

Merge Queue Status

✅ The pull request has been merged

This pull request spent 1 hour 56 minutes 25 seconds in the queue, including 1 hour 45 minutes 31 seconds running CI.
The checks were run on draft #11319.