| 3 Dec 2025 |
iopq | I'm having difficulty compiling a project with another version of nixpkgs | 10:57:16 |
iopq | it works fine on my laptop | 10:57:22 |
iopq | and infinite loops on my desktop | 10:57:28 |
iopq | https://nest.pijul.com/iopq/proxy | 10:59:19 |
| 4 Dec 2025 |
iopq | reverting to an older nixpkgs revision fixes the issue | 07:47:37 |
sterni | this is not enough information to help you with your issue since we can’t guess what you are trying to do with what versions of nixpkgs what the error is | 10:50:02 |
| 5 Dec 2025 |
Magnus | I'm having problems with HLS for ghc 9.10.3 in nix 25.11. It dies and prints the following on stderr:
.haskell-language-server-9.10.3-unwrapped: internal error: ARR_WORDS object (0x4243c25cd8) entered!
Stack trace:
.haskell-language-server-9.10.3-unwrapped: Failed to get stack frames of current process: No DWARF information found: Success
0x74bfae92b970 set_initial_registers (/nix/store/6xdv0kj7ycq56l9sqip2hmxp237j78h4-ghc-9.10.3/lib/ghc-9.10.3/lib/x86_64-linux-ghc-9.10.3/libHSrts-1.0.2_thr-ghc9.10.3.so)
0x74bfae3becd0 dwfl_thread_getframes (/nix/store/1nqqjacc6dnj61jlpgz5hk9zdjbfidbr-elfutils-0.194/lib/libdw-0.194.so)
0x74bfae3be6eb get_one_thread_cb (/nix/store/1nqqjacc6dnj61jlpgz5hk9zdjbfidbr-elfutils-0.194/lib/libdw-0.194.so)
0x74bfae3bead4 dwfl_getthreads (/nix/store/1nqqjacc6dnj61jlpgz5hk9zdjbfidbr-elfutils-0.194/lib/libdw-0.194.so)
0x74bfae3bf042 dwfl_getthread_frames (/nix/store/1nqqjacc6dnj61jlpgz5hk9zdjbfidbr-elfutils-0.194/lib/libdw-0.194.so)
0x74bfae92c0b7 libdwGetBacktrace (/nix/store/6xdv0kj7ycq56l9sqip2hmxp237j78h4-ghc-9.10.3/lib/ghc-9.10.3/lib/x86_64-linux-ghc-9.10.3/libHSrts-1.0.2_thr-ghc9.10.3.so)
0x74bfae935437 rtsFatalInternalErrorFn (/nix/store/6xdv0kj7ycq56l9sqip2hmxp237j78h4-ghc-9.10.3/lib/ghc-9.10.3/lib/x86_64-linux-ghc-9.10.3/libHSrts-1.0.2_thr-ghc9.10.3.so)
0x74bfae93568f barf (/nix/store/6xdv0kj7ycq56l9sqip2hmxp237j78h4-ghc-9.10.3/lib/ghc-9.10.3/lib/x86_64-linux-ghc-9.10.3/libHSrts-1.0.2_thr-ghc9.10.3.so)
0x74bfae975d9b stg_ARR_WORDS_info (/nix/store/6xdv0kj7ycq56l9sqip2hmxp237j78h4-ghc-9.10.3/lib/ghc-9.10.3/lib/x86_64-linux-ghc-9.10.3/libHSrts-1.0.2_thr-ghc9.10.3.so)
(GHC version 9.10.3 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Anyone else seeing this, or able to offer some advice?
| 13:18:06 |
Teo (he/him) | I think this might be: https://github.com/haskell/haskell-language-server/issues/4674 | 13:18:59 |
maralorn | Magnus: Yes. You need to disable the hlint plugin. And someone needs to upstream this to nixpkgs master for now. | 13:20:03 |
maralorn | Use (pkgs.haskell.lib.compose.disableCabalFlag "hlint" pkgs.haskellPackages.haskell-language-server) | 13:20:50 |
maralorn | (and for clarification, this is agreeing with and supplementing teo (they/he)s answer.) | 13:21:27 |
Magnus | Ah, OK... losing hlint is a bit of a blow to the usability though :( | 13:23:18 |
maralorn | Magnus: I agree. You might consider switching to 9.12 where this problem does not happen. | 13:24:07 |
maralorn | The root cause resides somewhere around apply-refact I think where for some reason the decision was made to skip support for 9.10. Although I am not familiar with the details. | 13:24:54 |
Magnus | What's the state of 9.12 in 25.11? | 13:28:36 |
Magnus | maralorn: yes, I didn't really understand the details for that either. | 13:29:42 |
maralorn | Support is not as broad or good as 9.10 but I am using 9.12 in multiple projects and it‘s working fine. | 13:30:26 |
Magnus | All right, it's worth a try... I was so very happy to find that 9.10.3 worked so well with our projects at work. I ended up removing a bunch of overlays and stuff, and no breakages at all...until I started writing code that is 😞 | 13:31:45 |
maralorn | I mean you can still use hlint. Just not in hls I guess. | 13:33:13 |
emily | time to bump to 9.12 on unstable? :D | 13:35:00 |
Wolfgang Walther | That's tied to Stackage Nightly becoming Stackage 25 | 13:35:51 |
Teo (he/him) | From working on the work codebase's upgrade to 9.12, my impression is that there are very few breaking changes there | 13:36:00 |
maralorn | I doesn’t have to be. That’s just our policy. | 13:36:30 |
maralorn | * It doesn’t have to be. That’s just our policy. | 13:36:37 |
Wolfgang Walther | yeah, that's what I meant. It'd be odd to select the default packages from Stackage LTS 24, which is tied to GHC 9.10, but to use 9.12 as the default for them, though. | 13:38:12 |
Wolfgang Walther | I mean... we can already switch to Stackage Nightly on unstable, until it becomes LTS 25, though. Would give us a head start on the migration. | 13:39:06 |
Magnus | maralorn: it didn't even take that long to build that modified HLS 😄 and it is much more stable... as in it's been running without crashing for several minutes 😁 | 13:40:21 |
Magnus | Sounds like that's something worth taking a closer look at then. That's very good to know. | 13:41:05 |
| 6 Dec 2025 |
iopq | the current nightly doesn't compile my package, current stable does not either | 12:35:28 |
alexfmpe | ok, but why? what error is reported? | 19:53:36 |