| 18 Oct 2025 |
 MangoIV | if you take your tools from one nixpkgs set, you're fine, since nixpkgs does ship the correct hie-bios, the issue is when you e.g. isntall hls locally and cabal-install globally (which did work until recently, but now doesn't work)
and most importantly, it only works in nixpkgs by accident, upstream is broken :D | 16:05:40 |
 maralorn | Oh, okay. But there's not really something we can do about this, right? And it's also only a one time issue and will phase out over time? | 16:08:04 |
 sterni | In reply to @eldritchcookie:matrix.org
do i need to rename the package if i pass it as another name like
gi-gtk-hs = pkgs.haskell.lib.markUnbroken (super.gi-gtk-hs.override {
gi-gtk = self.gi-gtk3;
gi-gdk = self.gi-gdk3;
});
no | 21:45:53 |
 dotlambda | In reply to @maralorn:maralorn.de
Alternatively you remove the stackage pinning from hledger. Which by the issue I linked has been requested multiple times. https://github.com/NixOS/nixpkgs/pull/453350 | 22:49:30 |
| 19 Oct 2025 |
|  raboof joined the room. | 13:51:52 |
| raboof | I'm very curious if ghc 9.12's -fobject-determinism will have an effect on haskell packages' reproduciblity (https://github.com/NixOS/nixpkgs/issues/151347). Is there anything I could help out with towards that? Would looking at the merge conflicts in https://github.com/NixOS/nixpkgs/pull/452254 help, or does that not make sense without deep haskell knowledge? | 14:38:51 |
 Wolfgang Walther |
Would looking at the merge conflicts in https://github.com/NixOS/nixpkgs/pull/452254 help
These merge conflicts are artifacts of how the haskell-updates branch is set up and nothing to worry about. The will be resolved once we merge this PR into staging.
| 16:20:32 |
| Wolfgang Walther | We are currently still on GHC 9.10 by default. I think it only really makes sense to look into this flag once we switch to GHC 9.12? | 16:21:38 |
| raboof | yup, that PR just looked like WIP work that might get us closer towards that :) | 16:33:53 |
| raboof | I noticed that we're packaging both .so and .a artifacts where Arch seems to only include the .so . Probably a naive question, but are we using those .a's? :) | 16:40:29 |
| raboof | with https://github.com/NixOS/nixpkgs/commit/fffebd7398360d241c3e34f01af4813ef199e488 haskell.packages.ghc912.these seems deterministic, so that's promising! | 17:03:16 |
| Wolfgang Walther | That PR is just the regular update of haskellPackages. We track Stackage. Stackage LTS is currently on GHC 9.10.3. So when we upgrade to GHC 9.12 is mostly dependent on when Stackage updates. We just updated to GHC 9.10 recently, so it will still take a while.
Ofc, we can enable this flag for GHC 9.12+ already - but we won't build the big majority of haskell packages with it, yet. And we won't have insights into whether it might cause build problems, because we don't build the full package set for GHC 9.12, yet. | 17:33:01 |
| raboof | Gotcha, makes sense | 17:56:09 |
| raboof | it might be interesting to enable it by default for 9.12 - cache.nixos.org does appear to contain a bunch of packages.ghc912 packages (though it's not quite clear to me where they're built), so it might allow us to see build problems early | 20:18:58 |
| 20 Oct 2025 |
 Peter Becich | Would someone take a look at hls-cabal-plugin on NixPkgs?
Breakage reproducible on both master and haskell-updates:
NIXPKGS_ALLOW_BROKEN=1 nix build nixpkgs#haskellPackages.hls-cabal-plugin --impure
NIXPKGS_ALLOW_BROKEN=1 nix build nixpkgs/haskell-updates#haskellPackages.hls-cabal-plugin --impure
I believe this is contributing to a breakage of Haskell Language Server
| 04:38:28 |
| maralorn | No, the standalone hls plugin packages are deprecated, they were moved into the hls package | 06:17:09 |
| Peter Becich | Thanks! | 06:19:50 |
| sterni | In reply to @raboof:matrix.org
with https://github.com/NixOS/nixpkgs/commit/fffebd7398360d241c3e34f01af4813ef199e488 haskell.packages.ghc912.these seems deterministic, so that's promising! did you measure performance impact | 06:59:59 |
| sterni | In reply to @raboof:matrix.org
I noticed that we're packaging both .so and .a artifacts where Arch seems to only include the .so . Probably a naive question, but are we using those .a's? :) yes | 07:00:18 |
| sterni | In reply to @raboof:matrix.org
with https://github.com/NixOS/nixpkgs/commit/fffebd7398360d241c3e34f01af4813ef199e488 haskell.packages.ghc912.these seems deterministic, so that's promising! * did you measure performance impact? | 07:00:28 |
| sterni | In reply to @raboof:matrix.org
I noticed that we're packaging both .so and .a artifacts where Arch seems to only include the .so . Probably a naive question, but are we using those .a's? :) * yes, dynamically linking executables means excessively large closure sizes | 07:01:25 |
 Alex | In reply to @sternenseemann:systemli.org
yes As usual, separate outputs would be nice but potentially require a lot of effort to implement. :s | 08:17:03 |
| 21 Oct 2025 |
|  50^2 changed their profile picture. | 04:51:49 |
|  @le:4d2.org left the room. | 10:36:16 |
 eldritchcookie | is cabal2nix not aware of build-tools-depends or do i need to blame flake-parts's haskell-flake? | 21:57:25 |
 Artem | eldritchcookie: the latter I think | 23:13:21 |
| Artem | * eldritchcookie: the former I think | 23:13:25 |
| Artem | * eldritchcookie: the former I think (not aware) | 23:13:33 |
| eldritchcookie | i did some digging and actually calling cabal2nix on my cabal package has an output which contains TestToolDepends = [tasty-discover]; so somebody is dropping that and it certainly isnt cabal2nix | 23:17:22 |
| 22 Oct 2025 |
| raboof | for 'these' it does seem slower, but in the order of 'tens of milliseconds' on an ~11-second build. I tried a more substantial package (hoogle), that was about 2 seconds slower for a 46-second build (averages across 4 builds each). So measurable impact (but promising to see it did seem to have the desired effect for hoogle as well)... | 10:39:44 |
