| 9 Mar 2025 |
 maralorn | e.g.: What’s this: https://github.com/NixOS/nixpkgs/pull/387911/checks?check_run_id=38382570966 ? | 15:41:08 |
| maralorn | emily: Ah, thank you. Is the eval check enforced for merge? | 15:41:55 |
 emily | of course not 🙃 | 15:42:08 |
| maralorn | Why of course?^^ | 15:42:24 |
| emily | looks weird. maybe a timeout? | 15:42:44 |
| emily | that would make too much sense. | 15:42:47 |
 alexfmpe | Conveying sarcasm over the internet is hard | 17:29:41 |
| emily | I did put an upside down face in there :P | 17:30:19 |
| 10 Mar 2025 |
|  Mr Mayhem changed their display name from 𒀱Lord Mayhem of the Magnolias to Magnolia Mayhem. | 01:49:04 |
| 11 Mar 2025 |
|  blackglasses changed their profile picture. | 07:58:35 |
|  dyniec changed their profile picture. | 13:40:03 |
| 12 Mar 2025 |
|  @jellyterra:matrix.org changed their profile picture. | 02:44:37 |
| @jellyterra:matrix.org changed their profile picture. | 02:45:55 |
| 14 Mar 2025 |
 Profpatsch | Why is generateOptparseApplicativeCompletions not just an input to haskellPackages.makeDerivation? | 13:32:54 |
| 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 |
