| 29 Dec 2025 |
 Alex | In reply to @mangoiv.:matrix.org
I'm going nutz - I do doJailbreak hsuper.integer-logarithms as usual and it's build-type Simple and it fails with missing or private dependencies ghc-bignum <bla> installed <blup>
Is that something that happens only with ghc-bignum? Or does somebody know what's going on there?
Most likely it's because it's a conditional dependency. IIRC jailbreak does not work with those, so you'll need to patch the Cabal description with more primitive methods or find another way around the issue instead. | 12:51:44 |
 MangoIV | right; i guess calling it again with callCabal2nix would have also worked with the right ghc version - I decided to just patch it upstream ^^ | 12:53:31 |
| 30 Dec 2025 |
 sterni | Wolfgang Walther: so what is actually the state of __structuredAttrs itself? How widely supported is it nowadays and how many issues remain with it? I remember that in the past there were always various problems or bugs with certain Nix versions. | 12:30:18 |
| sterni | I think writing code that simultaneously supports __structuredAttrs true and false is somewhat nonsensical especially when code is written in a way that it has an extra API to work around regular argument splitting limitations. | 12:31:10 |
| sterni | If __structuredAttrs is truly the way to go and there are no potentially showstopping issues, I'd rather redesign the GHC expression and generic builder in a breaking way and always use structured attrs. | 12:32:09 |
| sterni | it'd help mkDerivation, actually, in some ways. | 12:32:21 |
| sterni | I must say that I personally find __structuredAttrs a bit icky since it's not exactly simple nor has clean separation of concerns, but oh well… | 12:33:43 |
 Wolfgang Walther | From the interpreter side, all (known) issues with structuredAttrs should be solved since we bumped min version for Nixpkgs - we are not concerned anymore with any Nix versions that had problems there. structuredAttrs is certainly the way to go in the future, it's just a matter of time (and effort) to get the migration done.
The reason to support both with/without structuredAttrs is purely the transition period while not every expression supports them. This is mostly relevant for generic builders / setup hooks and such, which might not be able to tell in advance whether their downstream consumers will be using structuredAttrs or not.
The GHC expressions can certainly all be rewritten to consistently use structuredAttrs, no problem with that. Forcing the haskell generic builder to always use structuredAttrs would have an impact of out-of-tree users using that builder. If we're OK with a breaking change in that way, then yes, the best way is to consistently use structuredAttrs here, too. | 12:37:55 |
 maralorn | Is there some ressource about what structuredAttrs does and what it solves? | 12:53:28 |
| sterni | Nix manual I assume | 12:54:05 |
| Wolfgang Walther | https://nix.dev/manual/nix/2.19/language/advanced-attributes#adv-attr-structuredAttrs | 12:55:05 |
|  amadaluzia[tde] changed their profile picture. | 12:59:17 |
 linj | I find this blog very helpful https://nixos.mayflower.consulting/blog/2020/01/20/structured-attrs/ | 13:52:51 |
| sterni | We probably (also) have some new Haskell failures on master now with gcc15, so that may be worth checking up on in the coming days. | 18:32:11 |
|  Lenny. changed their display name from Lenny. ☎️5665 to Lenny.. | 23:09:43 |
| 31 Dec 2025 |
|  das-g changed their display name from das-g (DECT 7881) to das-g. | 22:18:05 |
| 1 Jan 2026 |
|  @deb776:tedomum.net | 02:52:05 |
| @deb776:tedomum.net left the room. | 02:53:10 |
| 4 Jan 2026 |
|  Find me at aleksana:qaq.li changed their display name from aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) to aleksana 🏳️⚧️ (deprecated). | 17:12:55 |
| Find me at aleksana:qaq.li changed their display name from aleksana 🏳️⚧️ (deprecated) to Find me at aleksana:qaq.li. | 17:14:40 |
| 5 Jan 2026 |
|  connor (burnt/out) (UTC-8) joined the room. | 17:56:26 |
| 6 Jan 2026 |
| maralorn | So … What is the 2026 way of running doctests as part of my nix-build? | 12:36:15 |
 Pierre Thierry | I'm trying to work on monoidal-functors, but although nix build succeeds, doing cabal build either from nix develop or my shell with direnv and use flake fails with
unknown package: these (dependency of monoidal-functors)
| 14:44:48 |
 toonn | Might Cabal be picking up a different GHC? | 14:46:14 |
| Pierre Thierry | It doesn't look like it, cabal --verbose build says
Running: /nix/store/a8h81f4wc2nc8qgrfsxvgfd8has0xh3r-ghc-9.6.3/bin/ghc --print-global-package-db
and the flake says ghc963 | 14:48:51 |
| maralorn | Apparently cabal-doctest works. Couldn’t get doctest-discover to run. | 17:19:16 |
| maralorn | But I still very much have no idea what I am doing … | 17:19:33 |
| 7 Jan 2026 |
|  Sigmanificient joined the room. | 00:25:15 |
| Sigmanificient | Hello there, while having a conversation with my coincidentally named counterpart (i remember that), I discovered that haskell packages set has a at least a few packages that we should really not ship, as they has been removed after a report on the [https://github.com/haskell-infra/hackage-trustees/issues/132](hackage-trustees ' Spam/fraudulent issue)
While both examples sigmaSquadron gave me are marked as broken, this is due to dependency mismatch, not that the source is gone, because we have it cached. | 00:30:52 |
 SigmaSquadron | Yeah, it's probably not ideal that the channels just randomly have sources for known fraudulent software. | 00:35:11 |
