| 30 Mar 2026 |
 sterni (he/him) | meh | 12:06:14 |
 Teo (he/him) | yeah you either need internal or external | 12:06:28 |
 alexfmpe | MangoIV: sterni: what about doing it the other way around? say, teaching ghc.nix to build haskellPackages with local ghc | 12:17:32 |
| alexfmpe | non-haskell caching would come from nixos, and haskell packages caching is all invalidated at the slightest change to ghc working tree anyway | 12:19:15 |
| alexfmpe | IIUC the goal here is just to throw a testbed at RC | 12:19:40 |
| alexfmpe | and we have infra for that in nixpkgs (and nowadays for lots of cross targets) so ghc.nix can re-use just that? | 12:20:14 |
| Teo (he/him) | I think it would be reasonable to teach head.hackahe to use nix drvs. It used to do this in the past but it was undo for reasons | 12:20:34 |
| Teo (he/him) | * | 12:20:50 |
| Teo (he/him) | * | 12:21:07 |
 MangoIV | I mean that would also be fine. I don't know if we have the CI capacities but we may be able to make do. | 12:41:11 |
| MangoIV | I personally don’t care about it being nix drvs but about the size of the package set. | 12:54:29 |
| Teo (he/him) | yeah that's fair. for non-HEAD builds we really need to be building all of stackage/nixpkgs set in head.hackage for rcS | 12:56:19 |
| Teo (he/him) | We had this working a few years ago | 12:59:34 |
| MangoIV | are there issues for what needs to be done? | 13:08:16 |
| Teo (he/him) | https://gitlab.haskell.org/ghc/head.hackage/-/issues/72 there was a working branch but it never got merged | 13:21:50 |
| sterni (he/him) | MangoIV: the package set size is completely unknown for the non default version though | 13:30:00 |
| sterni (he/him) | for older versions than the default it's pretty good in general, but newer ones is pretty spotty usually | 13:30:29 |
| sterni (he/him) | especially since a lot of people who used to contribute fixes for those seem to have moved on (to haskell.nix? horizon haskell? no clue) | 13:30:53 |
| sterni (he/him) | MangoIV: teo (they/he) see also https://github.com/NixOS/nixpkgs/pull/146381 | 13:39:10 |
| Teo (he/him) | This looks cool! I'll take a look | 13:40:43 |
| MangoIV | this indeed looks cool. I wonder how bad the conflicts will be | 13:47:35 |
| MangoIV | but maybe there's some usable things in there. | 13:47:40 |
| MangoIV | that's fine. As long as we can discover this a posteriori, I think it's okay if we don't build all packages. | 13:48:53 |
| MangoIV | what changed? No maintenance hours? | 13:49:23 |
| Teo (he/him) | I think the main issue is just that it never got merged, so idk if it has coderotted or not. I want to rebase and merge it at some point and then we can iterate from there. But I struggle to find time to do anything other than keep head.hackage building with HEAD | 13:50:45 |
| alexfmpe | the vast majority of packages that don't build against newer versions is due to library bounds no? | 13:52:26 |
| alexfmpe | at least in recent GHCs | 13:52:38 |
| alexfmpe | deep subsumption was annoying, 9.6 was a bloodbath from mtl re-exports, but lately it's been pretty chill | 13:53:05 |
| alexfmpe | it's mostly things coupled with ghc internals that fail purely from a ghc bump
anything touching generics, template-haskell, etc | 13:55:27 |
| MangoIV | that's fair. I will ask if someone who can allocate resources can take co-ownership of this problem. | 14:00:07 |
