| 30 Mar 2026 |
 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 |
| 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 | 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 | 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 | yes, sure may be worth refactoring | 11:32:56 |
| alexfmpe | The pre check exports, that is | 11:33:02 |
| sterni | 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 |
| sterni | w.r.t. your specific question if you look at the GHC_PACKAGE_PATH stuff, we have a way of preventing our wrapper from setting that if you need cabal. But i expect it'll break in a different way then. | 11:35:18 |
| sterni | if someone has a lot of spare time they could investigate making an opt in alternative generic-builder.nix code path that uses cabal-install which could have some advantages | 11:36:17 |
| alexfmpe | I suspect stack also doesn't set it. First saw this when packaging haskell-debugger and IIRC stack test also got tripped up, only cabal test was green | 11:36:57 |
| sterni | cabal sets GHC_ENVIRONMENT which is annoying to replicate manually unfortunately. | 11:37:26 |
| sterni | but it also doesn't do everything for some use cases you need to run cabal v2-exec -- cabal v2-test (i think path being set) | 11:37:52 |
| alexfmpe | In reply to @sternenseemann:systemli.org
if someone has a lot of spare time they could investigate making an opt in alternative generic-builder.nix code path that uses cabal-install which could have some advantages That's huh, big. Right now I'm only trying to fix a couple packages without excessive copy pasting | 11:38:01 |
| sterni | don't worry about it, I don't think it solves much we are facing right now. cabal-install also has plenty of problems. | 11:39:18 |
| sterni | i just feel like it may be wise long term since every solution for rough spots in cabal nowadays get designed around cabal-install v2-commands and they are often implemented poorly in Setup.hs to the degree that they are outright broken e.g. https://github.com/haskell/cabal/issues/11598 | 11:40:37 |
| sterni | (the build-tool-depends thing btw si another example for a stupid hack packages use to get the executable into PATH for the test suite) | 11:41:00 |
| alexfmpe | I do think it's worth looking into at some point down the line, just have a bunch of other cabal2nix/haskellPackages stuff on my queue already | 11:57:27 |
