| 15 Mar 2025 |
 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:matrix.org joined the room. | 16:42:42 |
| @Las:matrix.org | 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 |
| emily | the nixops-aws build was broken and also relied on packages that were removed (after it was already broken) | 11:02:39 |
| emily | see the warning on https://github.com/NixOS/nixops?tab=readme-ov-file#nixops | 11:02:49 |
| emily | I think the rewrite is not really production-ready either, you'd probably want to look at deploy-rs or colmena | 11:03:09 |
| emily | but those do not have deep provider integration, you might have to supplement with something like Terraform or Pulumi | 11:03:50 |
|  Domen Kožar changed their profile picture. | 11:39:36 |
| @dmjio:matrix.org | Yea true, but it's been that way for a while... its still so good because its all Nix (imo). I will try the NixOS channel. Might just pin to an old hash in the meantime. Thank you for context. | 15:06:56 |
| 22 Mar 2025 |
| @mombaby:matrix.org left the room. | 05:40:43 |
|  thomie joined the room. | 18:48:24 |
