| 22 Sep 2025 |
 Wolfgang Walther | sterni should we cherry-pick all the fixes we're not making to staging-next into haskell-updates? | 11:44:41 |
| Wolfgang Walther | * sterni should we cherry-pick all the fixes we're now making to staging-next into haskell-updates? | 11:44:47 |
 maralorn | My suggestion would be to pause work on h-u until staging-next is merged? | 11:57:22 |
| Wolfgang Walther | For possibly a full week or more? | 12:09:35 |
| maralorn | Is that unreasonable? | 12:15:35 |
 sterni (he/him) | I think it makes sense to stage a bunch of set rebuilding changes on the branch and use a time when the x86_64-linux queue has calmed down a bit to get through it | 12:24:16 |
| sterni (he/him) | 24.11 rebuilds everything again | 12:24:21 |
| Wolfgang Walther | Imho, yes. That's essentially just making the next cycle much longer. | 12:24:21 |
| sterni (he/him) | package set update seems to eval already at https://github.com/NixOS/nixpkgs/pull/445051 | 12:26:38 |
| maralorn | I mean ideally the next cycles will be very quick, anyway. | 12:26:55 |
| maralorn | Well, I mean anything that we want to do we can obviously do on the branch. I was just thinking that it might not be necessary to do the cherry-picks. | 12:28:36 |
| maralorn | * Well, I mean anything that we want to do we can obviously do on the branch. No need to stop working. I was just thinking that it might not be necessary to do the cherry-picks. | 12:29:03 |
| Wolfgang Walther | I'm just worrying about merge conflicts that we would have to resolve later. By picking the commits now, we can probably avoid most of them. | 12:33:01 |
| Wolfgang Walther | But maybe there won't be too many, if we don't have too many changes in the cycle anyway. | 12:33:21 |
| sterni (he/him) | I think it does make sense also just to have visibility on those packages as well | 12:34:11 |
| sterni (he/him) | but may be inconsequential if staging-next is quick… | 12:34:23 |
| maralorn | I mean, tbf. nixpkgs commit history is a mess anyway. So we can probably just do it … | 12:34:58 |
| sterni (he/him) | https://github.com/NixOS/nixpkgs/pull/443159 can also go into haskell-updates | 12:54:47 |
| sterni (he/him) | I think half of all haskell related commits from the last two months exist twice already | 12:55:26 |
| maralorn | You would probably have had it easier to convince me in this discussion if you had informed me that one of the PRs not being able to merge because the missing cherry-picks mad conflicts more likely was mine. | 18:01:25 |
| 23 Sep 2025 |
|  kenji changed their display name from a-kenji to kenji. | 10:39:01 |
 Teo (he/him) | Is there an easy way to create a dev shell where I can use GHC with the llvm backend? Ideally without having to recompile ghc | 12:25:26 |
| Teo (he/him) | Oh wait maybe it's fine with stuff just being on the PATH | 12:27:39 |
| Teo (he/him) | it spews some warnings about versions but continues anyway | 12:27:54 |
| sterni (he/him) | teo (they/he): (ghc.withPackages.override { useLLVM = true; }) (p: [ … ]) it's even documented :-) | 13:26:01 |
| sterni (he/him) | though you still have to pass -fllvm that's a misleading name (thanks to me) | 13:26:23 |
| Teo (he/him) | Nice thanks! Yeah it's a bit silly. Hopefully we will have better ways to specify these things soon. | 13:36:24 |
| Teo (he/him) | * Nice thanks! Yeah it's a bit silly. Hopefully we will have better ways to specify these things soon (through like the toolchain specification or something). | 13:37:07 |
 Alex | In reply to @teoc:matrix.org
Nice thanks! Yeah it's a bit silly. Hopefully we will have better ways to specify these things soon. The replaceStdenv stuff already exists, but it won't save you from rebuilding GHC. | 19:02:13 |
|  yliceee changed their display name from λlice to yliceee. | 20:01:46 |
