| 27 Jan 2026 |
 sterni | woobilicious: that's just the library it also exposes, but should be easy to add a bin output and set mainProgram manually (since it can't be determined automatically). | 10:03:30 |
 @jboy:utwente.io | I guess this is the relevant issue. | 13:54:08 |
| @jboy:utwente.io | * I guess this is the relevant issue (regarding newer pandoc releases). | 13:54:33 |
 maralorn | Correct. | 14:01:02 |
 alexfmpe | well poop, looks like running iserv-proxy for cross template haskell requires __darwinAllowLocalNetworking = true on the package that uses TH, maybe we'll want that whole "use unix domain socket" bit sooner than expected
we hadn't noticed this before we couldn't even try it
a) cross from aarch64-darwin is broken alltogether: https://gitlab.haskell.org/ghc/ghc/-/issues/24939
b) the 'soft' cross of pkgsStatic was also broken: https://github.com/NixOS/nixpkgs/pull/484571 | 23:14:31 |
| alexfmpe | * well poop, looks like running iserv-proxy for cross template haskell requires __darwinAllowLocalNetworking = true on the package that uses TH, maybe we'll want that whole "use unix domain socket" bit sooner than expected
we hadn't noticed this before because we couldn't even try it
a) cross from aarch64-darwin is broken alltogether: https://gitlab.haskell.org/ghc/ghc/-/issues/24939
b) the 'soft' cross of pkgsStatic was also broken: https://github.com/NixOS/nixpkgs/pull/484571
| 23:14:56 |
| 28 Jan 2026 |
|  m changed their display name from Supreme Allied Commander Mayhem, Lord of the Nine Stars to GOD EMPEROR MAYHEM - OVERSEER OF ENTROPY AND THE SECOND LAW. | 00:37:02 |
 Daniel Firth | Hey guys. We're looking at trying to include the cardano-node in nixpkgs. I'm thinking of ways to do this and obviously since it involves CHaP and also significantly deviates from stackage just on the hackage dependencies I'm wondering if you have any thoughts on what you would accept as a way to this. | 11:35:25 |
| Daniel Firth | * Hey guys. We're looking at trying to include the cardano-node in nixpkgs. I'm thinking of ways to do this and obviously since it involves CHaP and also significantly deviates from stackage just on the hackage dependencies I'm wondering if you have any thoughts on what you would accept as a way to do this. | 11:35:37 |
| maralorn | What’s CHaP? | 11:39:30 |
| maralorn | I am pretty sure there are examples on how to package non-hackage packages in nixpkgs. | 11:40:13 |
| maralorn | Including some with a non-neglectable number of overrides. | 11:40:47 |
| maralorn | Actually I think even cachix does it. | 11:41:01 |
|  Robin Stumm joined the room. | 11:48:38 |
| Robin Stumm | https://github.com/IntersectMBO/cardano-haskell-packages | 11:49:23 |
| Daniel Firth | We could be looking at more than 50% of the build plan would be custom, so 300 or more packages. | 11:52:13 |
| maralorn | Oooh. | 11:54:09 |
| maralorn | I mean I wonder how large that would be in comparison to other large derivation packages in nixpkgs. Like those with a checked in npm or cargo lock. | 11:55:36 |
| Daniel Firth | It would be more or less exactly the same size as the equivalent horizon expression here. https://gitlab.horizon-haskell.net/package-sets/horizon-cardano
nix build 'git+https://gitlab.horizon-haskell.net/package-sets/horizon-cardano#horizon-cardano'
| 11:57:33 |
| maralorn | If you can encapsulate it cleanly (i.e. without interfering with the rest of haskellPackages) and the size is manageable it seems fine-ish. Of course there is then also the matter of maintainership. It mustn’t become a burden on the haskell team. | 11:57:39 |
| Daniel Firth | That would be one option to just upstream the whole horizon expression under haskellPackages.horizon.cardano, if that's something nixpkgs would accept. | 11:58:10 |
| Daniel Firth | Would be much easier than trying to solve which parts of nixpkgs could be reused. | 11:58:36 |
| Daniel Firth | * It would be more or less exactly the same size as the equivalent horizon expression here. https://gitlab.horizon-haskell.net/package-sets/horizon-cardano
nix build 'git+https://gitlab.horizon-haskell.net/package-sets/horizon-cardano#cardano-node'
| 11:58:56 |
| maralorn | I am sceptical. Also curious what the others think. | 12:01:00 |
| maralorn | Maybe we can have this discussion more organized on a GitHub issue? | 12:01:32 |
| Daniel Firth | It would basically be a wholly independent package set. It might reuse the ghc definition but nothing else. | 12:01:42 |
| Daniel Firth | Sure. I'll write it up. | 12:01:46 |
 toonn | What is the goal? Are there existing dependents that would be desirable to package for users? | 12:03:40 |
| toonn | End-users, not developer-users. | 12:03:54 |
| Daniel Firth | The goal is to package cardano-node for end users yes, not developers. But maintaining the build plan for cardano-node manually in nixpkgswith overrides and whatnot would be infeasible. | 12:05:21 |
