| 22 Sep 2025 |
 sterni | 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 | 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 | I think it does make sense also just to have visibility on those packages as well | 12:34:11 |
| sterni | 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 | https://github.com/NixOS/nixpkgs/pull/443159 can also go into haskell-updates | 12:54:47 |
| sterni | 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 (they/he) | 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 (they/he) | Oh wait maybe it's fine with stuff just being on the PATH | 12:27:39 |
| teo (they/he) | it spews some warnings about versions but continues anyway | 12:27:54 |
| sterni | teo (they/he): (ghc.withPackages.override { useLLVM = true; }) (p: [ … ]) it's even documented :-) | 13:26:01 |
| sterni | though you still have to pass -fllvm that's a misleading name (thanks to me) | 13:26:23 |
| teo (they/he) | Nice thanks! Yeah it's a bit silly. Hopefully we will have better ways to specify these things soon. | 13:36:24 |
| teo (they/he) | * 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 |
| yliceee changed their profile picture. | 20:02:26 |
| yliceee changed their profile picture. | 20:04:24 |
| 24 Sep 2025 |
|  Magnolia Mayhem changed their profile picture. | 14:46:16 |
| Magnolia Mayhem changed their profile picture. | 19:45:13 |
| 25 Sep 2025 |
 bglgwyng | If a package is not affected by foo-package.override { random = ... }, which means random is not overridden but remains as the one in haskellPackages, what are some things I can try to investigate further | 08:53:03 |
| bglgwyng | The package overrides other than random works well | 08:53:22 |
