| 6 Feb 2025 |
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 (he/him) | 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 (he/him) | 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 (he/him) | 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 (he/him) | 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 (he/him) | 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 |
Tristan Ross | Plus we've been discussing this for like a year but haven't really done much. LLVM 12 has been EOL for 4 years as well. | 21:56:09 |
| 10 Feb 2025 |
linj | In reply to @rosscomputerguy:matrix.org We're the only distro with LLVM 12 guix has 12 and many older ones such as 3.5.2. Not saying that is better, though. https://packages.guix.gnu.org/search/?query=llvm | 01:51:41 |