| 23 Aug 2025 |
 emily | I think if someone handles the backports for the backportable part of the stack then the deadlock will be broken. | 17:49:14 |
| emily | it was only reverted on the Nix end because of the cursed Nixpkgs behaviour but I got that fixed in Nixpkgs | 17:49:26 |
| emily | and then we can just cherry-pick stuff | 17:49:33 |
| emily | I just got demotivated after firing off a bunch of cherry-picks and seeing the builds fail | 17:49:51 |
 aloisw | On 2.91 this seems to be recursive lambda not being supported due to it not being C++23 yet. But yeah the Clang ICE on 2.92 does not look fun. | 17:59:14 |
| aloisw | Actually it fails on Darwin as well due to recursive lambda so maybe it's the same. | 18:01:27 |
| aloisw | That still doesn't explain why it fails properly on Darwin and ICEs on Linux though. | 18:02:01 |
| aloisw | nix-repl> (import ./. { system = "x86_64-linux"; }).clangStdenv.cc.version
"18.1.8"
nix-repl> (import ./. { system = "aarch64-darwin"; }).clangStdenv.cc.version
"16.0.6"
That might do it I guess? | 18:04:16 |
| emily | uh, how old is that Nixpkgs pin? | 18:24:41 |
| emily | we switched to LLVM 19 on all platforms in 25.05 | 18:24:49 |
| emily | I guess CI is just running against EOL Nixpkgs releases? | 18:25:08 |
| aloisw | 2.91 and 2.92 are on 24.11. | 18:37:00 |
| aloisw | Which is also what was evaluated in the pasted nix-repl output. | 18:37:35 |
| aloisw | So either nixpkgs needs to be bumped in these old branches, the recursive lambda removed, or polyfilled with y combinator. | 18:38:26 |
| emily | I don't see why not bump Nixpkgs | 19:05:51 |
| emily | that also means that people using the NixOS module are getting a Lix built from EOL Nixpkgs…? | 19:06:05 |
| emily | ok, no, because the NixOS module uses a different Nixpkgs | 19:06:44 |
| emily | but then corollary: the CI is already not testing what actually gets deployed | 19:06:55 |
 raitobezarius | Yeah I am not super happy with that | 21:43:54 |
| raitobezarius | We should lockfile maintain release branches as well | 21:44:05 |
| raitobezarius | I recently obtained the technology for it | 21:44:10 |
| raitobezarius | There needs to be wiring up for Gerrit and then happiness may ensue | 21:44:42 |
 Lunaphied | You want to automate lockfile updates on release branches? I don't see how that fits with tags | 22:06:15 |
| raitobezarius | Ideally, if the nixos-module work land, people will use lixFromNixpkgs or lix from nixpkgs, therefore, tags or not tags, people will stop have a point-in-time set of unmaintained dependencies | 22:53:48 |
| raitobezarius | Nonetheless, the lix repo CI should use up-to-date dependencies for testing things as it's the closest to what actual users are running (or should be running) | 22:54:10 |
| raitobezarius | Therefore, even if this doesn't lead to a release, release branches should have lockfile maintenance | 22:54:20 |
| raitobezarius | Because any backport work will benefit from a CI that tests uptodate nixpkgs | 22:54:38 |
| emily | the NixOS module calls the package with its own Nixpkgs input anyway | 23:13:16 |
| emily | in the flake | 23:13:28 |
| emily | so most users will be using their actual Nixpkgs if they set the follow | 23:13:30 |
