stack: Built against deprecated `rio-0.1.23.0` (which has a serious bug), and fails

[mpilgrem]

Nixpkgs version

• Stable (25.11)

Describe the bug

See:

• nixpkgs project version of Stack 3.7.1: Infinite <<loop>> commercialhaskell/stack#6824
• rio-0.1.22.0 to 0.1.23.0: GHC now deadlocks on compiling pantry & kmonad commercialhaskell/rio#264

The 'official' build of Stack 3.7.1 is built against rio-0.1.22.0 but the nixpkgs project appears to have built a version of 'Stack 3.7.1' against now-deprecated rio-0.1.23.0. rio-0.1.24.0 fixes a serious bug in rio-0.1.23.0.

Steps to reproduce

See the Stack issue above.

Expected behaviour

That the nixpkgs projects 'Stack 3.7.1' behaves like the 'official' Stack 3.7.1.

Screenshots

No response

Relevant log output

Additional context

No response

System metadata

I am not a nix-shell user.

Notify maintainers

@cdepillabout

---

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

[galenhuntington]

This would be fixed by #466258 (which upgrades rio to a non-broken version), which is still a draft. Perhaps there is a way to get this backported into 25.11, or even just the rio upgrade. As of now, Stack is completely unusable (at least for me) in stable nixpkgs.

[NorfairKing]

@mpilgrem thanks for opening this.
I agree, this makes stack useless in nixos-25.11.
Let's please backport this.

[JonnieCache]

It's broken on unstable as well, not just 25.11. I set my flake to 25.05 and stack 3.5.1 works, but haskell-language-server doesnt build.

[sternenseemann]

This has been fixed by #460624 (7600c464345c8) which will be part of the next staging-next iteration. Corresponding change for 25.11: #470484

[sternenseemann]

25.11 is done. We could pick basically the same change onto master to accelerate the fix into channels, though it would need to be reverted manually later.

[iopq]

jtt9340/aoc2025@e5fdca2

this is the work-around

[srghma]

indeed the <<loop>> disappeared, but master doesnt contain this fix yet IIUC