| 30 Mar 2026 |
 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 |
| Teo (he/him) | 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 |
| 5 Apr 2026 |
| alexfmpe | there's a couple packages calling cabal executables in their test suites that I tried to fix with addTestToolDepend self.cabal-install that then fail with
Error: [Cabal-8123]
Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).
| 00:30:02 |
| alexfmpe | I dunno where that GHC_PACKAGE_PATH is coming from. is this something worth addressing on nixpkgs? if not, could I somehow fix upstream? | 00:31:05 |
| 6 Apr 2026 |
 Alex |
,("Use interpreter","NO")
,("cross compiling","NO")
,("Build platform","riscv64-unknown-linux")
,("Host platform","riscv64-unknown-linux")
,("Target platform","riscv64-unknown-linux")
,("Have interpreter","NO")
Why is my native RISC-V GHC 9.8.4 build missing the TH interpreter and GHCi support?
I've never seen this happen for a native build before, and I can't find anything that explains this in Nixpkgs or Hadrian's source code.
I have an old native 9.6.6 build lying around and it has ("Have interpreter","YES") as expected.
Both were built using Nixpkgs' default settings with a cross-compiled GHC 9.4.8. | 08:47:00 |
| Alex | Oh, nevermind, I found the issue.
I removed this patch while upgrading Nixpkgs because the default GHC (9.10) has the commit, but then later found that to get there I needed to first build 9.6 or 9.8, which don't have the commit. | 08:50:58 |
| alexfmpe | Nix on macos room (unlinkable right now) is asking what is the purpose of ghc-standalone-archive | 11:25:47 |
 sterni (he/him) | alexfmpe: see
- https://github.com/haskell/cabal/issues/2358
- https://github.com/NixOS/nixpkgs/pull/312859
- https://github.com/haskell/cabal/issues/10090
for some context
| 11:27:52 |
| sterni (he/him) | ask Shea Levy, I guess. I assume it is intended for building a static archive of Haskell libs you can link into iOS applications. I have never seen anybody talking about it or using it, so I'm fine with removing it personally. | 11:31:03 |
| alexfmpe | In reply to @sternenseemann:systemli.org
alexfmpe: see
- https://github.com/haskell/cabal/issues/2358
- https://github.com/NixOS/nixpkgs/pull/312859
- https://github.com/haskell/cabal/issues/10090
for some context
Ah got it. Mind if I cook up a couple utils for these unfortunately common test suite tweaks? HOME/tmpDir, ghc_package_path | 11:32:34 |
| sterni (he/him) | yes, sure may be worth refactoring | 11:32:56 |
| alexfmpe | The pre check exports, that is | 11:33:02 |
| sterni (he/him) | the thing is that there can't really be a generic solution for everything because there are a lot of mutually incompatible approaches to solving this at the moment. | 11:34:22 |
| alexfmpe | Sure, but we can have a ready made sane default | 11:34:50 |
