| 23 Jul 2025 |
 Katalin 🔪 | In reply to @raitobezarius:matrix.org
Katalin 🔪 a while ago, you sent us cl/3081 (thank you for that!), sterni just sent us https://gerrit.lix.systems/c/lix/+/3731, the change are very similar ; for now, I assume that we won't need an approach that perform explicit compilation detection, so I'm leaning on proceeding with sterni's change, do you have any opinion on this? yeah, version check should be fine in practice, I personally prefer compile checks where possible because they’re technically more accurate but it doesn’t really matter. go ahead! | 15:20:54 |
 raitobezarius (DECT: 7248) | thank you so much! | 15:21:03 |
| raitobezarius (DECT: 7248) | yeah, we should revisit this as soon as compile checks are necessary | 15:21:12 |
 just1602 | raitobezarius: https://github.com/NixOS/nixpkgs/pull/427807
I don't know if there's anything else to do. After doing those change I ran
cd pkgs/tools/package-management/lix
nix-build --impure -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'
There might be better way to test that to make sure the build is working properly, tho
| 17:12:29 |
| raitobezarius (DECT: 7248) | there's like nixosTests.misc.lix iirc | 17:12:44 |
| raitobezarius (DECT: 7248) | you can run a test on that | 17:12:47 |
| raitobezarius (DECT: 7248) | In reply to @just1602:systemli.org
raitobezarius: https://github.com/NixOS/nixpkgs/pull/427807
I don't know if there's anything else to do. After doing those change I ran
cd pkgs/tools/package-management/lix
nix-build --impure -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'
There might be better way to test that to make sure the build is working properly, tho
also if you can take a look in the git history | 17:20:43 |
| raitobezarius (DECT: 7248) | you will find the commit syntax we use for these bumps | 17:20:50 |
| 24 Jul 2025 |
|  Janne Heß joined the room. | 12:05:56 |
 hexa | https://github.com/NixOS/nixpkgs/pull/428076 | 14:49:31 |
| just1602 | How incompatible is lix with nix 2.24? | 15:13:22 |
 K900 | Not really? | 15:14:28 |
| K900 | Why? | 15:14:31 |
| just1602 | Just to understand how this nixpkgs minver change is gonna be a mess.: D | 15:16:03 |
| just1602 | * Just to understand how this nixpkgs minver change is gonna be a mess. :D | 15:16:23 |
 emily | the PR title is inaccurate | 15:16:26 |
| emily | it bumps to 2.18, which Lix forked from | 15:16:30 |
| emily | and runs the checks that were done against 2.3 against Lix instead | 15:16:45 |
| emily | so it should be no problem for Lix (or slightly better even) | 15:17:01 |
| emily | however I believe Tvix/Snix are still targeting 2.3 so who knows what will happen | 15:17:27 |
| just1602 | In reply to @emilazy:matrix.org
however I believe Tvix/Snix are still targeting 2.3 so who knows what will happen I'm wondering if they could start to target lix 😅 | 16:22:11 |
 John Ericson | https://github.com/NixOS/nix/issues/13544 do you all do this yet by any chance? | 19:12:25 |
| emily | it's technically a compat break | 19:46:01 |
| emily | since it changes hashes | 19:46:04 |
| emily | what is SHA-1 even used for at this point? seems like it'd be better to try phasing it out? I assume nothing in Nixpkgs is pinned by SHA-1 | 19:46:20 |
| emily | well, actually, for Git they just run it in checking mode and abort if a potentially-colliding input is detected | 19:46:47 |
| emily | which is still a compat break, but at least not silent hash changing | 19:46:52 |
| emily | if it's for Git revs then you want to be doing that but I assume libgit2/git(1) will already handle the hashing there | 19:47:08 |
| emily | pkgs/servers/mx-puppet-discord/node-packages.nix
111: sha1 = "532e01241dbcb0f2769f1b9a7cde313d30101173";
120: sha1 = "68018cab4f59834b3fef2e59fbfd52938403e001";
129: sha1 = "52b0e8bb808a1202602899af67939b049dd42402";
138: sha1 = "0a37a3f9430ff7c29512d29882e25ae738a31283";
🫣
| 19:49:51 |
| emily | apparently these are the only SHA-1 pins left in Nixpkgs | 19:49:55 |
