| 20 Nov 2024 |
 alexfmpe | ah, no, build -> build | 18:48:58 |
| alexfmpe | I guess it ought to be host -> host for pkgsCross.....hello ? | 18:49:31 |
| alexfmpe | but IIUC what I'm seeing is build -> host also happening | 18:49:52 |
 sterni (he/him) | to build hello you first have to compile Setup.hs which you then execute on the build machine | 21:14:25 |
| sterni (he/him) | Setup then calls the GHC cross compiler to actually build hello | 21:14:36 |
| sterni (he/him) | build->build is the “normal ghc“ in this case | 21:15:39 |
| 21 Nov 2024 |
| alexfmpe | Hmmm right because compiling setup is not a separate derivation so both ghc get shoved in there | 00:03:41 |
 jean-paul. | Do Nix Haskell packages have a runtime dependency on ghc? I'm looking at nix-tree output for a package from callCabal2nix and I can get to ghc from it. | 01:00:29 |
 linj | you can use justStaticExecutables to reduce the closure size https://github.com/NixOS/nixpkgs/blob/23e89b7da85c3640bbc2173fe04f4bd114342367/pkgs/by-name/ni/nixfmt-rfc-style/package.nix#L35 | 01:09:11 |
| jean-paul. | Ah, neat. So the dependency is a result dynamic linking because there's something Haskell libraries need to link against that's part of ghc itself, thus pulling in all of ghc in nix runtime closure | 01:10:43 |
| jean-paul. | Oh dang, from 6.3GiB to 1.2GiB, niice | 01:14:21 |
| jean-paul. | tyvm linj | 01:15:57 |
| sterni (he/him) | sounds like you still pull in GHC? 1GB is still a lot | 12:00:25 |
| sterni (he/him) | or is this aarch64?! | 12:00:53 |
 pwmosquito | are we using nightly stackage or lts stackage? iirc it flip-flopped in the past, not sure which it is atm | 16:13:01 |
| pwmosquito | ah https://github.com/NixOS/nixpkgs/pull/346720/commits/41ffdf94002c38a2540a7d88dd2b7e57746627c1 impes LTS | 16:14:01 |
| pwmosquito | * ah https://github.com/NixOS/nixpkgs/blob/master/maintainers/scripts/haskell/update-stackage.sh#L9 says LTS | 16:14:57 |
 lxsameer | maralorn: hey buddy, remember the cabalfreeze2nix stuff? how do you suggest tackling the flags in the cabal freeze file? | 17:12:25 |
|  @panaeon:matrix.org left the room. | 17:19:20 |
 maralorn | Ah, yeah. It's quite high on my list by now. | 17:41:01 |
| lxsameer | In reply to @maralorn:maralorn.de
Ah, yeah. It's quite high on my list by now. I have some free time to work on it. I've been using it since we spoke last time | 18:46:38 |
| lxsameer | so far so good | 18:46:42 |
| lxsameer | only two issues | 18:46:50 |
| lxsameer |
- how should I address the flags in the freeze file? (using these flags means any package with flags won't be the same as the same package from nixpksg)
| 18:47:46 |
| lxsameer |
- Often I had to update the hackage pin on my nixpkgs fork
| 18:48:02 |
| lxsameer | on and one other things, some packages like zlib causes an infinit loop | 18:52:47 |
| maralorn | Re 1. I mean generally enabling those flags wouldn’t be that hard. However it would be interesting whether we can figure out if they are the default flags and then omit them. | 19:30:05 |
| maralorn | Re 2. well, that only happens if the hackage index you use to generate the freeze file is newer than the one nixpkgs. Maybe there is a way to couple that? | 19:30:58 |
| maralorn | Re 3. yeah, that’s because zlib is a haskell package and a system package. The haskell package needs the system package. As you can see in the hackage-packages.nix file in nixpkgs hackage2nix emits code which correctly overrides the inputs of the haskell package with the system package. Your override generation has no such logic and thus you get a loop. | 19:32:46 |
| maralorn | I am not sure if 3 is feasible to fix without pulling in cabal2nix as a dependency, because it contains a map for system dependency names from the cabal file to nixpkgs. (because they are often named differently.) | 19:34:32 |
