| 26 Aug 2025 |
 maralorn | In reply to @morgan.arnold:matrix.org
Hm, maybe I'm being a bit stupid trying to turn this into a flake. I guess I could just keep the existing nix stuff from the template? I'm just mildly annoyed about not being able to use nix develop. I thought that I would just be able to do something like inputs.nixpkgs = import ./nix/nixpkgs {};, in my flake but if I do this I get the error "expected a set but got a thunk", so I guess I've misunderstood something? Well. The problem causing your error message is that flakes only look like nix but only a subset is allowed. | 07:09:25 |
| maralorn | The problem from what I can tell is that the template uses multiple overrides to fix the build not just pinning nixpkgs. That's why you still encountered an error when you pinned the correct nixpkgs. | 07:10:13 |
| maralorn | The old style equivalent to nix develop would be nix-shell | 07:11:09 |
| 27 Aug 2025 |
 Artem | Thanks guys for posting all the updates on the 9.8->9.10 PR. Very informative and helpful for explaining how the many processes work. ❤️ | 00:39:27 |
|  Thibaut joined the room. | 13:35:37 |
| Thibaut | Hello! Is this the space to ask for a package update? I am interested in the dhall packages 🙏 | 13:39:23 |
 toonn | Thibaut: Aren't they part of Stackage? | 13:42:26 |
| Thibaut | I wasn't sure what was Stackage reading the nixpkgs stuff, indeed it is!
I guess it is normal that the stackage version is different from the last github's release? apparently it is, 1.42.2 matches github's version 23.1.0, so it looks up to date? | 13:46:22 |
| toonn | Thibaut: It depends on the Stackage snapshot. But Nixpkgs is more or less a recent Stackage snapshot with everything else filled in from Hackage. | 13:51:16 |
| 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 |
