| 30 Mar 2026 |
 sterni (he/him) | In practice, throwing away the cache you accrue with the RC is not a big deal, but if it was e.g. GHC 9.10.4-rc1, you'd still have to wait for 7k jobs to be built while not gaining testing any change you can actually merge unless you wait on whatever schedule the actual release gets published | 11:40:47 |
| sterni (he/him) | given that we currently have a 1-2 week waiting period after a bump has been finished until it reaches master, this delays ordinary package updates massively. | 11:41:26 |
| sterni (he/him) | teo (they/he): does QuasiQuotes also work for cross? does that use byte code and internal interpreter or what? | 12:00:55 |
 Teo (he/him) | So QuaiQuotes is just syntax sugar for $(quoteExp "...") etc, so it works the same as regular splices. You should be able to use it with the external interpreter if you have that set up | 12:05:47 |
| sterni (he/him) | okay but it does need the external interpreter | 12:06:12 |
| 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 |
