| 11 Jan 2025 |
 alexfmpe | hmm I saw witherable-0.5 getting downloaded/built by cabal, and haskellPackages.witherable comes out as 0.5 as well | 19:52:34 |
| alexfmpe | notably, it's the nixpkgs version that's doing the unexpected thing and including those imports | 19:53:13 |
| alexfmpe | how can it fail the (0,3,2) check? | 19:53:33 |
| alexfmpe | it's acting as if witherable < 0.3.2 | 19:53:59 |
| alexfmpe | even weirder, the .cabal has witherable > 0.4 in there | 19:54:53 |
| alexfmpe | so this should be dead code in the first place | 19:55:03 |
| alexfmpe | related question: I submitted a PR removing it, but over on nixpkgs keep failing to apply the other hackage->master patches so this one doesn't get conflicts
do we overrideSrc or wait for a release? | 19:56:38 |
| alexfmpe | * even weirder, the .cabal has witherable >= 0.4 in there | 20:04:00 |
| alexfmpe | actually nevermind, managed to workaround with a simple postPatch sed, good enough until the release | 20:33:02 |
 sterni (he/him) | alexfmpe: ig you could generate a cabal freeze file to verify?! | 21:46:00 |
| alexfmpe | on the non-nixpkgs build? | 21:46:31 |
| sterni (he/him) | yes | 21:48:19 |
| 12 Jan 2025 |
|  Rayane Nakib (ريّان نقيب) joined the room. | 12:40:13 |
| 13 Jan 2025 |
 m1-s | Hi, i am working on a project where I just updated from nix 22.11 to 24.11. this project uses a haskell library that does ffi stuff. since the update I am getting the following error when trying to compile something that uses the ffi haskell library:
> <no location info>: error:
> /nix/store/ig69mqspa9a7gmkib1p05rndsfmp5qjl-mypackage-0.1.0/lib/ghc-9.6.6/lib/x86_64-linux-ghc-9.6.6/mypackage-0.1.0-GG7CxsqkGDRPE7u83aSVw-ghc9.6.6.so: undefined symbol: my_function
Anyone has a clue what broke or how to debug this? Did anything change in the way nix/ghc handles ffi things since nix 22.11?
| 08:05:19 |
| m1-s | it builds in the dev shell with cabal. just not in nix. so i must be missing some flags in my nix build. dont know which though. | 08:17:12 |
|  KSP Atlas joined the room. | 09:55:20 |
 Collin Arnett | Redacted or Malformed Event | 11:11:03 |
| alexfmpe | I had something similar looking once but for a symbol from a dependency. Whatever the cause was, it got fixed by overriding that dep to use cabal 3.6+ | 15:47:50 |
| alexfmpe | But I was using an older nixpkgs, it wasn't happening on newer ones | 15:48:15 |
| alexfmpe | hmm do you maybe have some conditionals in .cabal that look relevant?
cabal2nix isn't great at handling them | 15:49:14 |
| alexfmpe | huuh how is it that nix-build -A haskell.packages.ghc910.aeson-gadt-th works even though https://hackage.haskell.org/package/aeson-gadt-th has base <4.20 ? | 23:21:08 |
 maralorn | Normally jailbreak | 23:21:39 |
| maralorn | I guess you know that 😃 | 23:22:14 |
| alexfmpe | ah derp it was hidden on configuration.nix-nix | 23:22:14 |
| alexfmpe | * ah derp it was hidden on configuration-nix.nix | 23:22:22 |
| 14 Jan 2025 |
| sterni (he/him) | Cabal 3.14.1.1 breaks GHC 9.12 bootstrap and it's kind of interesting how this happened
- So to begin with GHC 9.12 arbitrarily requests Cabal 3.14 for hadrian because they need it for some feature. Since no previous GHC actually ships this version of Cabal, you can't use the core package.
- Cabal 3.14.1.1 newly introduces a constraint on unix that is supposed to prevent building it with a buggy version of unix (a bug that apparently only affects 32bit platforms). I must say that these is a questionable decision and seems like abusing the constraint system. It's also strange that even though the bug only affects certain platforms, the constraint isn't conditional. (https://github.com/haskell/unix/pull/318)
- Since GHC 9.10 which we use for bootstrapping ships an affected version of Unix we get a violated constraint.
Which goes to show that making your bootstrapping process more complex, things will go wrong as soon as someone steps just a tiny bit away from the CI tested bootstrap plans that pin every dependency.
| 13:13:17 |
| maralorn | Phew | 13:15:20 |
| maralorn | sterni: Can we override Cabal and unix? | 13:17:13 |
| sterni (he/him) | yes, but it's a massive headache becasue unix is also used by other libraries | 13:17:32 |
| sterni (he/him) | The patch for unix is trivial we can probably just pick it onto every GHC we ship. | 13:17:55 |
