| 30 Mar 2026 |
 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 |
| MangoIV | I personally don’t care about it being nix drvs but about the size of the package set. | 12:54:29 |
| teo (they/he) | 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 (they/he) | 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 (they/he) | https://gitlab.haskell.org/ghc/head.hackage/-/issues/72 there was a working branch but it never got merged | 13:21:50 |
 sterni | MangoIV: the package set size is completely unknown for the non default version though | 13:30:00 |
| sterni | for older versions than the default it's pretty good in general, but newer ones is pretty spotty usually | 13:30:29 |
| sterni | 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 | MangoIV: teo (they/he) see also https://github.com/NixOS/nixpkgs/pull/146381 | 13:39:10 |
| teo (they/he) | 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 (they/he) | 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 |
| teo (they/he) | i should have a bit more free time after ZuriHac hopefully as well | 14:02:29 |
| MangoIV | I'm not confident about the quality of the ram package, yet. | 14:08:00 |
 maralorn | True, the enthusiasm for vibe coding by the same author sadly decreases trust in code quality. | 14:13:08 |
| maralorn | I mean my thinking would be: That would still help with catching at least all build errors which we would notice immediately on adding the new minor version. Of course it won’t give ghc the full test coverage of nixpkgs and I agree I don’t think it would be fair to do that with nixos-community resources. | 14:15:03 |
 Janus | It was a mess with the vibe-coded removal and re-addition of stuff, but it's good that an attempt is being made to take over the package. Jappie has good intentions and seems to open to constructive feedback. | 16:29:09 |
| Janus | * It was a mess with the vibe-coded removal and re-addition of stuff, but it's good that an attempt is being made to take over the package. Jappie has good intentions and seems open to constructive feedback. | 16:29:29 |
| MangoIV |
Jappie has good intentions and seems open to constructive feedback.
He definitely does, but that doesn't make me less caucious of vibe coding
| 16:30:38 |
|  andreaspk joined the room. | 18:38:03 |
