Haskell in Nixpkgs/NixOS | 712 Members | |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 140 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 Feb 2026 | ||
| It lives here https://gitlab.haskell.org/ghc/ghc/-/tree/ghc-9.10/utils/iserv?ref_type=heads but doesn't exist on master since we now use the on demand stuff | 15:44:33 | |
| iserv-proxy also used to be in the ghc tree but got moved out a while ago | 15:44:57 | |
| Basically before 10.0, the way to get iserv was to have it bundled with GHC | 15:58:45 | |
| 20:38:30 | ||
| 3 Feb 2026 | ||
| This seems to be caused by the unregisterised backend. I haven't tried an unregisterised native build, but disabling unregisterised "fixed" the build, at the cost of producing segfaulting binaries. I tried adding -std=gnu17 and even -std=gnu99 to EXTRA_CC_ARGS but I'm still getting errors related to the -std=gnu23 default, so I'm not sure what I'm missing here. | 01:12:03 | |
| 4 Feb 2026 | ||
| We have #haskell-distros:matrix.org now btw - just created today if anyone interested | 02:56:49 | |
In reply to @alex:tunstall.xyzif all fails we can probably use NIX_CFLAGS_COMPILE | 06:37:31 | |
| I wonder if unregistered builds are affected by this even on later versions | 06:37:59 | |
| 13:35:14 | ||
I saw that it gets passed as -optc-std=gnu17. My hypothesis is that -optc options are ignored by the C backend and only used for C source files.One potential problem with NIX_CFLAGS_COMPILE is that I suspect it would need to be propagated to all dependants.There might be some other way of configuring C flags, such that they always get used. I saw for example that --info includes a "CC args" entry, though I'm not sure how the build system sets that. | 17:42:16 | |
| 7 Feb 2026 | ||
| Alex: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.4/m4/fp_settings.m4 | 11:47:43 | |
Oh nice, so CONF_CC_OPTS_STAGE2 (or whatever it is derived from) might work. | 11:48:46 | |
| Yep, that fixed it. PR soon. | 12:56:30 | |
| sterni https://github.com/NixOS/nixpkgs/pull/487958 (Thanks for pinging me about this by the way.) | 13:06:06 | |
| I needed 9.12.1 for a language feature, now have to rebuild all my dependencies again :( | 19:18:11 | |
| my life is so hard /s | 19:18:18 | |
is haskell.packages.ghc912.foobarpackage not cached in hydra? | 19:40:59 | |
| it rebuilt linear, opengl, glfw-b, and most/all of their dependencies, so I guess not | 19:44:29 | |
| new favourite language extension MultilineStrings | 19:48:36 | |
| 19:49:52 | |
| seems cached for x86_64-linux at least | 19:49:59 | |
| 19:51:52 | |
| maybe you happened to build something recently merged so hydra hadn't catched up yet | 19:52:28 | |
| 🤷♀️ | 19:53:49 | |
It's inconsistent because haskell-updates gets all non-broken packages for its default GHC cached, but sometimes master (and thus nixpkgs-unstable) deviates slightly from it. | 20:15:47 | |
ah fair, I was checking in haskell-updates | 20:17:53 | |
| seems pretty much the same in current master:
| 20:18:59 | |
| 8 Feb 2026 | ||
| we've removed 9.12.1, so must be an old revision | 11:52:55 | |
| If I try to override Cabal and Cabal-syntax in a package set, why do I end up with multiple versions of Cabal? In particular I get this serious warning:
Is it because those packages are not overridable (boot packages or such)? Or could it be configure-time dependencies? | 12:28:56 | |
| Am I right in assuming that usually if you override a package in a package set (examples from the file I'm modifying: https://github.com/commercialhaskell/stackage-server/blob/master/package.nix), the override you specify becomes the only version of that package available, regardless of where it lives in the dependency tree of other packages in the set? | 12:31:10 | |