| 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 (he/him) | 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 (he/him) | 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 (he/him) | 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 (he/him) | 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 |
| chreekat | 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 |
| sterni (he/him) | This is true, but the core packages bundled on GHC still depend on other core packages. So if you want to globally override Cabal, you also need to globally override all core packages that (indirectly) depend on Cabal, so they get rebuilt. | 12:32:18 |
| sterni (he/him) | Then you also need to convince the cabal solver to pick those packages over the core packages which can sometimes be tricky (but usually just works). | 12:32:44 |
| sterni (he/him) | in this case the latter seems to be happening, i.e. hackage-security is still built against the core package | 12:33:37 |
| chreekat | Ok, so my memory/intuition was fairly correct. How can I do a "null" override for hackage-security and any other packages, so they get rebuilt? certainly not just hackage-security = old.hackage-security, ... | 12:36:19 |
