| 5 Dec 2025 |
 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 |
| 7 Dec 2025 |
|  Robert Evans joined the room. | 18:46:24 |
| Robert Evans set a profile picture. | 19:02:47 |
| iopq | <<loop>> | 19:40:04 |
 sterni (he/him) | then that issue is completely unrelated to Nixpkgs, given that that's a Haskell RTS error?! | 21:55:41 |
| sterni (he/him) | https://www.stackage.org/diff/lts-24.23/nightly-2025-12-07 | 21:57:46 |
| 9 Dec 2025 |
|  andromeda joined the room. | 04:42:52 |
| andromeda | hallo | 04:45:22 |
| andromeda | does anyone have a Nix flake that builds a package for Hackage without using Cabal? Like without having the 'redundancy' of a Nix build specification in the flake and a Cabal specification in the .cabal file? | 04:46:23 |
 Alex | In reply to @andromeda:tchncs.de
does anyone have a Nix flake that builds a package for Hackage without using Cabal? Like without having the 'redundancy' of a Nix build specification in the flake and a Cabal specification in the .cabal file?
builds a package for Hackage without using Cabal
AFAIK Hackage always requires a Cabal description by design. | 04:47:50 |
| andromeda | hmm I could use the metadata defined in the flake to create a .cabal at build time for reproducibility | 05:02:12 |
| andromeda | oder? | 05:02:28 |
| andromeda | 
Download 20251209_06h35m40s_grim.png | 05:35:58 |
| andromeda | goodness what is Cabal's problem /j | 05:36:10 |
|  @felineterrorist:matrix.org joined the room. | 06:47:19 |
 MangoIV | No and it’s both a bad idea and it’s misguided.
- nixpkgs haskell support (and Haskell.nix) uses cabal anyway so you don’t get around it
- nobody except nix users will be able to build your package
- nix flakes are even worse on that sense
- please don’t upload things to hackage that people cannot build for that reason.
My tip is to use cabal as the source of truth.
| 08:42:50 |
