| 23 Aug 2025 |
 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 |
| emily | aloisw: btw, one of the problems with keeping the old toml11 is that we need the new one for the CMake 4 bump | 23:14:46 |
| emily | so I would strongly prefer to just fix this | 23:14:57 |
