| 30 Mar 2026 |
 sterni | we could realistically add rcs as an extra attribute and test the versionedCompilerJobs but that's not much coverage | 11:12:17 |
| sterni | testing the main package set is only feasible for the main version, but I don't think we could actually do it since it just means we loose a few days of build time | 11:13:52 |
| sterni | in general, it's just not my impression that we can spare build time | 11:14:08 |
| sterni | if we had dedicated infra for that and a Hydra instance it would not be a problem of course | 11:14:32 |
 MangoIV | sterniwhat’s the procedure for 9.12.4 now? Will you add a potential patch to the compiler when we fix it? Or do you just disable the profiling build for ghcide? | 11:22:21 |
| sterni | I think we will patch like 9.12.3 | 11:24:32 |
| sterni | we still use 9.10 for most things so it's not that big a deal | 11:25:02 |
| MangoIV | Okay but after patching you’ll rebuild ghcide right | 11:26:17 |
 eveeifyeve | Did anyone in here see https://github.com/NixOS/nixpkgs/issues/504935? | 11:26:46 |
| sterni | yes we were pinged on it | 11:28:26 |
| sterni | yes | 11:28:38 |
| MangoIV | So I guess the total CI stress would be equal to just building it against an RC first, right? | 11:31:53 |
| sterni | well for the patch, I'd prepare the change, sanity check it on my own machine e.g. by building ghcide and merge it into an appropriate branch. For GHC 9.12, we build about 40 jobs, though some of them are quite expensive and cover a large dep closure (like HLS). | 11:38:09 |
| sterni | The thing is, with the patch, the change is done once it's patched. | 11:38:21 |
| sterni | For a release candidate, the thing is that you don't actually want to distribute that to users, so you'd have it on a staging-branch where it is tested. After which you still have to wait for the release and rebuild everything again with the released GHC version. | 11:39:07 |
| sterni | 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 | 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 | teo (they/he): does QuasiQuotes also work for cross? does that use byte code and internal interpreter or what? | 12:00:55 |
 teo (they/he) | 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 | okay but it does need the external interpreter | 12:06:12 |
| sterni | meh | 12:06:14 |
| teo (they/he) | 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 (they/he) | 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 (they/he) | * | 12:20:50 |
| teo (they/he) | * | 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 |
