| 27 Aug 2025 |
 toonn | It is geared towards supporting Haskell packages in Nixpkgs rather than Haskell development. | 13:51:44 |
| toonn | For development without the goal of packaging for Nixpkgs, I'd recommend simply using Cabal or Stack as you would on any other system. | 13:52:43 |
 Thibaut | Thanks. I understand now 👍️ | 13:52:45 |
| Thibaut | I just use the dhall tools so it's fine for me | 13:53:01 |
| 28 Aug 2025 |
 bglgwyng | It seems haskell.nix doesn't handle private repository in cabal.project(repository ... stanza) correctly | 06:22:32 |
| bglgwyng | It tries to download the package while building which leads the build to failure | 06:23:00 |
| bglgwyng | * It tries to download packages from the private repository while building which leads the build to failure | 06:23:15 |
 maralorn | bglgwyng: The haskell.nix maintainers don’t follow this channel very actively I think. | 08:27:12 |
| maralorn | alexfmpe: FYI: https://github.com/NixOS/nixpkgs/pull/429810/commits/faa6bed4eda2a1aa2d8e7501f4bdc9e3d8b3a8f9 | 08:27:33 |
| maralorn | We still get the eval error for reflex-dom, will need to figure out how to fix that … | 08:28:07 |
| bglgwyng | Do we have a better place to ask haskell.nix related questions? I posted an issue in haskell.nix issue tracker a week ago, but didn't get any response. | 08:33:24 |
| bglgwyng | By the way, I was looking for solutions that use plan.json to reproduce builds, and thought that haskell.nix is the one. Do we have alternatives? I'm ok with generating plan.json manually . | 08:35:25 |
| maralorn | I am sadly not aware of one. | 08:37:02 |
| maralorn | No, that is an often and rightly lamented shortcoming of the nixpkgs tooling. | 08:37:41 |
 Teo (he/him) | I wouldn't be surprised if that's the case. I think the IOG people use a custom Hackage so something is supported | 10:23:48 |
| Teo (he/him) | * I wouldn't be surprised if that's the case. Although I think the IOG people use a custom Hackage so something is supported | 10:27:12 |
 sterni (he/him) | Thibaut: we are updating to the latest version of dhall as part of https://github.com/NixOS/nixpkgs/pull/429810. We could use some help fixing build failures in the dhall-related packages: https://hydra.nixos.org/eval/1818002?filter=dhall&compare=1817909&full= | 13:14:48 |
 emily | how should we handle llvm-ffi in https://github.com/NixOS/nixpkgs/pull/437137? I think it's not great to break CI here, and I question whether we really want llvm-ffi to be using the latest possible LLVM version rather than the one for our default llvmPackages? | 20:17:05 |
| emily | it would make sense if the warning was triggered only for haskell-updates, but it just blocks eval for any PR instead | 20:17:34 |
| emily | and in this case it's asking for an upgrade to an LLVM version that the Haskell library version on master doesn't really support | 20:18:28 |
| emily | I'm tempted to say we just comment out the warning until a better way of doing it is found? | 20:21:53 |
| emily | (which I think would look like: "if the default llvmPackages was bumped and we're on haskell-updates, then warn Haskell maintainers") | 20:22:30 |
| maralorn | emily: Sadly, I have no clue and would have to research the supported versions llvm-ffi. Generally deactivating a warning that blocks you while pinging involved people seems fine. Possibly the person with the most bandwidth to think about this is wolfgangwalther who is not here but is already part of the conversation on github. | 20:28:47 |
| emily | I talked about the warning with sterni in #staging:nixos.org recently :) | 20:29:04 |
| emily | but I don't recall what the concrete conclusion was | 20:29:09 |
| maralorn | Well, I’ll take the opportunity and join that room now. | 20:30:46 |
| sterni (he/him) | llvm-ffi 21.0.0.2 should support LLVM 21 proper | 20:33:42 |
| emily | we don't have that on master, though | 20:34:33 |
| sterni (he/him) | Either bump it manually until the upgrade trickles through via haskell-updates or remove the warning as long as the build doesn't break either should work. | 20:34:57 |
| emily | we could cherry-pick it but it feels dubious for updating an LLVM off an rc to get blocked on this when we haven't even bumped the default version yet | 20:35:01 |
