| 23 Aug 2025 |
 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 |
| emily | in any case any new changes to a Lix release branch will never hit EOL Nixpkgs versions and I'm assuming that using Lix from the repo with EOL Nixpkgs versions is also not supported, so testing EOL versions in CI makes little sense for any branch | 23:14:16 |
