| 23 Aug 2025 |
 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 |
| emily | (by need I mean: the old one will cause problems with CMake 4) | 23:15:41 |
| raitobezarius | In reply to @emilazy:matrix.org
so most users will be using their actual Nixpkgs if they set the follow i'm a non flake user :D | 23:18:14 |
| emily | actually it is not even about the flake input, I was wrong | 23:18:51 |
| emily | it sets an overlay | 23:18:53 |
| raitobezarius | yeah | 23:18:57 |
| emily | so it will be using the NixOS system's package set, regardless | 23:18:59 |
| raitobezarius | hm yep | 23:19:10 |
| 24 Aug 2025 |
| Lunaphied | Uhhhh | 00:28:08 |
| Lunaphied | hm something about that seems off | 00:28:13 |
| Lunaphied | In reply to @raitobezarius:matrix.org
i'm a non flake user :D I really need to get around to that change with supporting overrides in flake-compat | 00:28:36 |
| raitobezarius | just give me https://git.afnix.fr/sprinkles/sprinkles | 00:29:20 |
| Lunaphied | o.o what's this exactly? | 00:34:46 |
| raitobezarius | Charles attempts to bring a flake structure to the non-flake world | 00:35:05 |
| raitobezarius | i personally like it, it's growing on me certainly | 00:35:16 |
