| 22 Sep 2025 |
 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 (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 | 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 (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 |
| 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 |
| 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? | 09:00:44 |
| maralorn | I can’t think of anything straightforward. Best ideas is a) there is a second override which negates your first override b) you are mistakingly not actually passing a different random. I can think of wilder theories, but they will be even more likely to be wrong. | 09:30:59 |
| bglgwyng | I tried overriding it at the last place like,
{ packages.hip = config.cabal-projects.default.packages.hip.override { random = config.cabal-projects.default.packages.random; }; }
but still same
| 09:32:13 |
| sterni | bglgwyng: Haskell dependencies need to be propagated, so any given package sees its transitive Haskell dependency closure. random is pretty common, so probably somewhere the non overridden random is visible. Cabal is free to pick any version within bounds. | 10:58:17 |
| sterni | hip doesn't have bounds on random at all, so maybe it picks another version? You can force it a specific version via the --constraint configure flag, but you'll likely run into trouble with this since Haskell isn't designed for multiple versions of the same package being linked into the same end product. | 10:59:55 |
| sterni | The only robust way of overridding a package that occurs multiple times in the dependency closure of a give package is to use overrideScope and recompiling (a large portion of) the dependency closure. | 11:00:42 |
| sterni | or do you mean something else by "not affected by"? | 11:01:07 |
| bglgwyng | No. your understanding is correct | 11:02:43 |
| bglgwyng | I should check for it now, but I'm so sure that I override every package depends on random with the same version of random | 11:03:14 |
| bglgwyng | So transitively depended random should be the same | 11:03:37 |
