| 6 Feb 2025 |
 lambdatheultimatealias | Speaking of which, I raised a PR on haskell-updates with the result of running regenerate-hackage-packages.sh for my package only. Was this necessary and right? It stops the package breaking and has the advantage that there is no cleanup after the next hackage pull. | 13:41:13 |
 maralorn | In reply to @lambdatheultimatealias:matrix.org
Speaking of which, I raised a PR on haskell-updates with the result of running regenerate-hackage-packages.sh for my package only. Was this necessary and right? It stops the package breaking and has the advantage that there is no cleanup after the next hackage pull. That's good, if it is the only thing you touched. | 13:52:30 |
| lambdatheultimatealias | I ran the above and update-hackage.sh. It worked committing only my package version and sha256 in hackage-packages.nix so I think I'm ok. Thanks for confirming | 13:59:20 |
 sterni | A nice the 9.12.1 arithmetic unsoundness breaks the crypton test suite so it's that bad | 14:45:21 |
| maralorn | In reply to @lambdatheultimatealias:matrix.org
I ran the above and update-hackage.sh. It worked committing only my package version and sha256 in hackage-packages.nix so I think I'm ok. Thanks for confirming Ah, no. You can't partially run update-hackage. That's an all packages or none thing | 16:16:29 |
| lambdatheultimatealias | maralorn: Hmm. It appears to work if I simply don't commit the output from update-hackage.sh. Let me know please if I'm misunderstanding. https://github.com/NixOS/nixpkgs/pull/378565 | 17:38:05 |
| maralorn | In reply to @lambdatheultimatealias:matrix.org
maralorn: Hmm. It appears to work if I simply don't commit the output from update-hackage.sh. Let me know please if I'm misunderstanding. https://github.com/NixOS/nixpkgs/pull/378565 That will be reverted the next time someone runs regenerate-hackage-packages. | 17:55:11 |
 bdesham | In nixpkgs’ configuration-common.nix, I see lines like hnix-store-remote = super.hnix-store-remote.override { hnix-store-core = self.hnix-store-core_0_6_1_0; }; to use an older version of a dependency package. I think I need to do the same thing for my application. How does hnix-store-core_0_6_1_0 get defined in the first place?
I tried to run regenerate-hackage-packages.sh but I got an error, possibly because I’m on macOS.
| 17:56:57 |
| maralorn | bdesham: That certainly depends on the error. macOS somedoes creates problems, yeah. Generally which attributes are generated is documented in the Haskell section of the nixpkgs manual. | 19:22:19 |
| lambdatheultimatealias | Got it. Thanks. Would it be acceptable to jailbreak the package and then remove jailbreak after the next Hackage pull? | 20:20:49 |
 alexfmpe | In reply to @sternenseemann:systemli.org
A nice the 9.12.1 arithmetic unsoundness breaks the crypton test suite so it's that bad Oh I was wondering what was up with that. | 22:59:18 |
|  @rizary:matrix.org left the room. | 23:02:05 |
| 7 Feb 2025 |
|  @sleepymonad:matrix.org left the room. | 08:46:12 |
| sterni | alexfmpe: I can't be sure, but the PSA on Haskell-cafe made it sound pretty bad, and the test is not failing with any other GHC version | 13:24:26 |
 chreekat | Yeah (`mod` 8) was broken by a faulty optimization implementation, and (more interesting imo) the tests apparently should have caught it but didn't | 16:33:12 |
|  terrorjack joined the room. | 22:29:59 |
| 8 Feb 2025 |
| sterni | Got my haskell-packages.nix refactor done and also documented https://github.com/NixOS/nixpkgs/pull/378063 | 19:06:26 |
| 7 Feb 2025 |
|  terrorjack left the room. | 22:31:16 |
| 8 Feb 2025 |
| terrorjack set a profile picture. | 02:24:30 |
| terrorjack removed their profile picture. | 02:25:05 |
| 9 Feb 2025 |
 Tristan Ross | Is there a way we can get GHC to bootstrap without LLVM 12 on aarch64-darwin? Or is it strictly LLVM 12. (This was from a convo in !kxOJEqURGkuOHTRRQB:matrix.org) | 20:54:50 |
| maralorn | I think that depends on the GHC version. Newer versions have a native backend for aarch64-darwin I think. (And would also be compatible with a newer LLVM.) | 21:42:51 |
| Tristan Ross | In reply to @maralorn:maralorn.de
I think that depends on the GHC version. Newer versions have a native backend for aarch64-darwin I think. (And would also be compatible with a newer LLVM.) Ok because we need to figure something out since LLVM 12 is going away in 25.05. | 21:45:05 |
| maralorn | Well my opinion would be that we drop support for combinations which we can’t support. But that is for sterni to decide. | 21:50:17 |
| sterni | Why? | 21:50:54 |
| Tristan Ross | In reply to @sternenseemann:systemli.org
Why? Because we have 8 versions and LLVM 20 is releasing soon. | 21:51:34 |
| sterni | It seems to me that removing LLVM 13 and 14 are more interesting immediate goals since it's easier by comparison (though cling does seem to have a hard dependency on LLVM 13). | 21:54:07 |
| Tristan Ross | We're the only distro with LLVM 12 | 21:51:57 |
| Tristan Ross | Not even Debian has LLVM 12 | 21:52:13 |
| Tristan Ross | In reply to @sternenseemann:systemli.org
It seems to me that removing LLVM 13 and 14 are more interesting immediate goals since it's easier by comparison (though cling does seem to have a hard dependency on LLVM 13). Afaict, there's more things depending on more newer versions. | 21:54:54 |
