| 30 Mar 2026 |
 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 |
| 9 Apr 2026 |
|  eliasp joined the room. | 14:13:34 |
| eliasp | Hi
I have very little knowledge when it comes to the general Haskell ecosystem/build process etc - I'm struggling with applying a custom patch via haskell.lib.compose.appendPatch to a package (hledger).
It fails applying the patch, complaining it can't find the file targeted in the patch…
> applying patch /nix/store/s3f1dgvk0ddzp87sg9j2npb7j7avdanw-imp-add-continue-rule-for-CSV-import.patch
> can't find file to patch at input line 3
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |--- a/hledger-lib/Hledger/Read/RulesReader.hs
> |+++ b/hledger-lib/Hledger/Read/RulesReader.hs
> --------------------------
> File to patch:
> Skip this patch? [y]
> Skipping patch.
Do I need to do anything special to apply patches to Haskell packages? Couldn't find anything relevant to my problem in the docs. | 14:18:02 |
| eliasp | Oh, nvm - just realized I'm being stupid and should apply the patch to hledger-lib instead of hledger 🤦 | 14:19:14 |
| sterni | you also need to use the relative argument of fetchpatch so the paths are correct | 15:28:12 |
| 10 Apr 2026 |
|  @epimonic:matrix.org left the room. | 11:46:02 |
