| 14 Mar 2025 |
 Profpatsch | I’m getting an error like | 13:38:28 |
| Profpatsch | at /nix/store/a396z42saqql55cp5n1vrb2j0siq86k1-nixpkgs-src/pkgs/development/haskell-modules/generic-builder.nix:32:1: | 13:38:30 |
| Profpatsch | error: function 'anonymous lambda' called with unexpected argument 'mkDerivation' | 13:38:30 |
| Profpatsch | passing hself.generateOptparseApplicativeCompletions ["foo"] (hself.mkDerivation { pname = … }) | 13:39:49 |
| Profpatsch | Ah uh do I need to pass it to callPackage as well … | 13:43:26 |
| Profpatsch | brrrr | 13:43:42 |
| 15 Mar 2025 |
 alexfmpe | 9.12.2 just got released, should we squeeze it into current haskell-updates? | 19:09:06 |
| alexfmpe | it supposedly fixes the codegen bug in 9.12.1 | 19:09:33 |
| alexfmpe | cargoculted my way into a PR, currently checking it's not horribly broken https://github.com/NixOS/nixpkgs/pull/390207 | 19:43:28 |
| 16 Mar 2025 |
 Tristan Ross | Does that mean we could squeeze in the LLVM bump stuff? (https://github.com/NixOS/nixpkgs/pull/379039). I really would like to get LLVM 12 out of nixpkgs for 25.05. I noticed that the patch recommended does not work in the bootstrap part because cannot patch a prebuilt binary with it. But I remember some discussions around other solutions. I think this is a best effort PR we can get to be able to get LLVM 12 dropped. | 05:39:59 |
 maralorn | Tristan Ross: I don’t think that has anything to do with the LLVM bump stuff, which seems relatively independent anyway. I can’t judge that PR, but the problem with it is figuring out whether it works. If it does work we can basically merge it at any time, independently of the following:
I want to highlight a different possibility: sterni and I settled on the deprecation policy, which I will announce (with a request for feedback) shortly. With that settled we are free to remove multiple old ghc versions once all in-tree consumers have been resolved. I guess the only point of contention is that we didn’t announce those deprecations in the last release notes after all, so if we want to stay true to that policy we probably should aim to drop them directly after 25.05 and announce the deprecation in 25.05. I know this is slower than you wanted this. But at least it is a solution. Would that be okay? | 09:31:45 |
| maralorn | cc emily | 09:31:59 |
| maralorn | (I know I promised stuff before, but this time I will keep it.) | 09:36:28 |
 emily | cool to hear, is it the "same versions as HLS" policy or some other one? have the bootstrapping concerns been worked out? | 14:12:53 |
| Tristan Ross | In reply to @maralorn:maralorn.de
Tristan Ross: I don’t think that has anything to do with the LLVM bump stuff, which seems relatively independent anyway. I can’t judge that PR, but the problem with it is figuring out whether it works. If it does work we can basically merge it at any time, independently of the following:
I want to highlight a different possibility: sterni and I settled on the deprecation policy, which I will announce (with a request for feedback) shortly. With that settled we are free to remove multiple old ghc versions once all in-tree consumers have been resolved. I guess the only point of contention is that we didn’t announce those deprecations in the last release notes after all, so if we want to stay true to that policy we probably should aim to drop them directly after 25.05 and announce the deprecation in 25.05. I know this is slower than you wanted this. But at least it is a solution. Would that be okay?
the problem with it is figuring out whether it works. If it does work we can basically merge it at any time
If I spin up a build of it on my ARM hardware and it passes, is that good for it to merge? The PR simply moves LLVM 12 to 13 and 15.
I want to highlight a different possibility: sterni and I settled on the deprecation policy, which I will announce (with a request for feedback) shortly.
That'd be great
we probably should aim to drop them directly after 25.05 and announce the deprecation in 25.05. I know this is slower than you wanted this. But at least it is a solution. Would that be okay?
If we can at least try and get my PR in, I think it'll be a good compromise. 24.11 has fully working GHC, 25.05 would have the few on 12, 25.11 would drop the old ones from the sound of it. | 14:55:00 |
| maralorn | I can’t say anything about the bootstrapping. The purpose of the policy is to signal to everyone that resolving the bootstrapping concerns is worth it because it can be removed after that. | 19:37:10 |
| maralorn | Yeah, the policy is roughly same versions as HLS. | 19:38:47 |
| emily | gotcha | 19:43:21 |
| emily | I haven't had too much time for Nixpkgs stuff recently but I will see if I can allocate some if stuff like that becomes the remaining blocker | 19:43:48 |
| 20 Mar 2025 |
|  Las joined the room. | 16:42:42 |
| Las | I heard alexfmpehas experience cross compiling to windows without haskell.nix? | 16:43:25 |
| alexfmpe | eh well, I gave it a go and fixed some low hanging fruit, that's about it | 18:12:44 |
| alexfmpe | https://github.com/NixOS/nixpkgs/pull/357744 | 18:12:48 |
| 21 Mar 2025 |
 @dmjio:matrix.org | Was AWS support totally removed from nixops ? | 01:21:25 |
| @dmjio:matrix.org | … while evaluating the attribute 'nixops_unstablePlugins.nixops-aws'
at /nix/store/zkpypzhg52sqw7jc70l7hgfys002rbgc-source/pkgs/applications/networking/cluster/nixops/default.nix:38:9:
37|
38| nixops-aws = throw "nixops-aws was broken and was removed from nixpkgs";
| 01:21:45 |
| @dmjio:matrix.org | is there an alternative | 01:21:49 |
| @dmjio:matrix.org | * is there an alternative, or a patch | 01:21:56 |
| @dmjio:matrix.org | I rely on this pkg | 01:22:54 |
|  @mombaby:matrix.org joined the room. | 04:12:37 |
| emily | wrong channel? but nixops is basically unmaintained | 11:02:22 |
