| 9 Aug 2025 |
 sterni | at least last I checked | 22:15:40 |
 emily | well, we do build quite a lot of stuff when bumping LLVM | 22:32:12 |
| emily | at least | 22:32:14 |
| emily | so it may be a special case in terms of bindings | 22:32:17 |
| 10 Aug 2025 |
| sterni | Haskell bindings get frequently overlooked in my experience | 00:44:17 |
| sterni | though we haven't had Haskell LLVM bindings where an up to date version is readily available | 00:44:43 |
| sterni | llvm-hs never uploaded anything after 9.0.1 to Hackage and I never bothered to work out how usable the llvm-12 branch was | 00:45:40 |
| sterni | now that's all kind of irrelevant | 00:45:46 |
| emily | I mean more "when we bump LLVM people are building full Darwin systems" | 02:00:07 |
| 11 Aug 2025 |
 lambdatheultimatealias | I can see a few of us have fixes in Hackage for Ghc 9.12. Should we be waiting for the next run of the Hackage update script on the haskell-updates branch or running it ourselves and submitting the relevant patch as a PR? Also is there a way of knowing in general whether another pull from Hackage is planned to avoid unnecessary PRs? | 10:49:49 |
| sterni | I'll probably do another one, maybe we'll get Stackage LTS 24.4 even | 14:57:19 |
| 13 Aug 2025 |
|  Mrjt. joined the room. | 05:53:57 |
|  aveltras joined the room. | 09:38:45 |
 Artem | is there a reasonable tutorial for how to start helping with failures in https://github.com/NixOS/nixpkgs/pull/429810? haskell-modules/HACKING.md says "Steps to fix Haskell packages that are failing to build is out of scope for this document" | 15:27:38 |
 maralorn | https://discourse.nixos.org/t/call-for-contributions-we-are-updating-to-ghc-9-10-2/67756 | 15:32:11 |
| Artem | I'm trying to unbrake some packages from liquidhaskell ecosystem. One package's test suite assumes Z3 is available in the PATH. What's a better way to fix it: dontCheck or add z3 as a dependency somewhere (where?). | 16:27:58 |
| emily | probably nativeCheckInputs | 16:28:52 |
| Artem | @emily this looks plausible except I don't see it ever be used inside haskell-modules. I see a bunch of those in other *-modules, but they have a different setup, so I'm not sure where to put these nativeCheckInputs for a haskell package | 16:37:37 |
 Alyssa Ross | Where would you put extra buildInputs or nativeBuildInputs? | 16:41:27 |
| Alyssa Ross | Those must be used somewhere | 16:41:36 |
| Artem | I'm not really seeing those in haskell-modules either | 16:48:14 |
| Alyssa Ross | I do, in configuration-nix.nix | 16:48:55 |
| Alyssa Ross | oh, addBuildDepend sounds relevant | 16:49:10 |
| Alyssa Ross | It doesn't look like there's an equivalent for nativeCheckInputs, so add one? | 16:50:52 |
| maralorn | I love how this extra abstraction layer in the haskell builder trips up proficient nixpkgs users … otoh I am always confused how those fields are called in the default builder. 😄 | 16:50:52 |
| maralorn | There is testSystemdDepends. | 16:52:21 |
| Alyssa Ross | Is that nativeCheckInputs though? | 16:52:52 |
| maralorn | testPkgconfigDepends ? [ ],
testDepends ? [ ],
testHaskellDepends ? [ ],
testSystemDepends ? [ ],
testFrameworkDepends ? [ ],
| 16:53:01 |
| Artem |
There is testSystemdDepends.
with testSystemDepends it seems like it, thanks
| 16:53:52 |
| Artem | *
There is testSystemdDepends.
with testSystemDepends it seems like it, thanks
| 16:53:59 |
