| 2 Feb 2026 |
 alexfmpe | https://github.com/NixOS/nixpkgs/pull/445672#discussion_r2430214570 | 15:41:49 |
 teo (they/he) | 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 |
| teo (they/he) | iserv-proxy also used to be in the ghc tree but got moved out a while ago | 15:44:57 |
| teo (they/he) | Basically before 10.0, the way to get iserv was to have it bundled with GHC | 15:58:45 |
|  mag changed their display name from m to GOD EMPEROR MAYHEM - OVERSEER OF ENTROPY AND THE SECOND LAW. | 20:38:30 |
| 3 Feb 2026 |
 Alex | 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 |
 Jens Petersen | We have #haskell-distros:matrix.org now btw - just created today if anyone interested | 02:56:49 |
 sterni | In reply to @alex:tunstall.xyz
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. if all fails we can probably use NIX_CFLAGS_COMPILE | 06:37:31 |
| sterni | I wonder if unregistered builds are affected by this even on later versions | 06:37:59 |
| mag changed their display name from GOD EMPEROR MAYHEM - OVERSEER OF ENTROPY AND THE SECOND LAW to mag. | 13:35:14 |
| Alex | 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 |
| sterni | Alex: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.4/m4/fp_settings.m4 | 11:47:43 |
| Alex | Oh nice, so CONF_CC_OPTS_STAGE2 (or whatever it is derived from) might work. | 11:48:46 |
| Alex | Yep, that fixed it. PR soon. | 12:56:30 |
| Alex | sterni https://github.com/NixOS/nixpkgs/pull/487958
(Thanks for pinging me about this by the way.) | 13:06:06 |
 andromeda | I needed 9.12.1 for a language feature, now have to rebuild all my dependencies again :( | 19:18:11 |
| andromeda | my life is so hard /s | 19:18:18 |
| alexfmpe | is haskell.packages.ghc912.foobarpackage not cached in hydra? | 19:40:59 |
| andromeda | it rebuilt linear, opengl, glfw-b, and most/all of their dependencies, so I guess not | 19:44:29 |
| andromeda | new favourite language extension MultilineStrings | 19:48:36 |
| alexfmpe | $ nix-build -A haskell.packages.ghc912.haskell-language-server --dry-run 2>&1 | grep "will be"
these 472 paths will be fetched (354.11 MiB download, 4469.75 MiB unpacked):
| 19:49:52 |
| alexfmpe | seems cached for x86_64-linux at least | 19:49:59 |
| alexfmpe | $ nix-build -A haskell.packages.ghc912.linear --dry-run 2>&1 | head -n 10
these 2 derivations will be built:
/nix/store/k43nhxkm1wssqw6dcypgq911bjskchfd-bytes-0.17.5.drv
/nix/store/49f28h8fg1bbf8mdgf2wpnv84r2jhp1y-linear-1.23.3.drv
these 81 paths will be fetched (31.83 MiB download, 402.85 MiB unpacked):
| 19:51:52 |
| alexfmpe | maybe you happened to build something recently merged so hydra hadn't catched up yet | 19:52:28 |
| andromeda | 🤷♀️ | 19:53:49 |
| Alex | 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 |
| alexfmpe | ah fair, I was checking in haskell-updates | 20:17:53 |
| alexfmpe | seems pretty much the same in current master:
$ nix-build -A haskell.packages.ghc912.haskell-language-server --dry-run 2>&1 | grep "will be"
these 507 paths will be fetched (357.33 MiB download, 4501.69 MiB unpacked):
$ nix-build -A haskell.packages.ghc912.linear --dry-run 2>&1 | head -n 4
these 2 derivations will be built:
/nix/store/57bmq5jy0sraqqava0jr0swivma0xd0q-bytes-0.17.4.drv
/nix/store/pbghk5rsl6s077p32m655yvn8c8fc246-linear-1.23.2.drv
these 100 paths will be fetched (36.87 MiB download, 465.34 MiB unpacked):
| 20:18:59 |
| 8 Feb 2026 |
| sterni | we've removed 9.12.1, so must be an old revision | 11:52:55 |
 chreekat | 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:
Warning:
This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
package hackage-security (hackage-security-0.6.2.4-7CLHB9zPIN0FxCfhihIq1r) requires Cabal-syntax-3.10.3.0
package Cabal (Cabal-3.12.1.0-HdYCe711lcf3vEdSKCpUQK) requires Cabal-syntax-3.12.1.0-JlhyVgsDFbHIDMshThsYz
Is it because those packages are not overridable (boot packages or such)? Or could it be configure-time dependencies?
| 12:28:56 |
