| 23 Jun 2026 |
raitobezarius | https://lix.systems/blog/2025-06-27-lix-critical-bug/ | 11:34:28 |
raitobezarius |  Download clipboard.png | 11:34:33 |
raitobezarius | no it's not your HW | 11:34:35 |
raitobezarius | you are just on a corrupting version of Lix | 11:34:40 |
raitobezarius | but this version should not be accessible in any non-EOL meaningful channels | 11:34:50 |
raitobezarius | so it seems like you have very old nixpkgs or? | 11:34:54 |
jyrama | A couple of weeks old flake.lock update with lix from lixPackageSets.stable.lix hmm | 12:09:28 |
jyrama | Well, I will try figuring out a newer version. Thx. | 12:10:09 |
jyrama | (Currently 26.05 nixos branch ) | 12:10:41 |
raitobezarius | 25.11's stable is 2.93.4 | 12:12:36 |
raitobezarius | (what can I tell is that 25.05's stable is 2.91) | 12:14:50 |
raitobezarius | * (what can I tell is that 25.05's stable is 2.91.3) | 12:15:05 |
raitobezarius | so something very weird is happening to you | 12:15:22 |
jyrama | That makes it even weirder. Maybe my machine is just bonkers. But also confirms what I was thinking about having tried to update away from the .1 or .2 when the news about corruption came out. | 12:16:34 |
teutat3s | Is there a workaround to get lix 2.95.2 to build on latest 26.05? It seems to get stuck in checkPhase after the latest staging-next-26.05 merge. I saw some mention of an issue with curl, is that the same thing? | 13:44:01 |
teutat3s | https://hydra.nixos.org/build/332131086 | 13:44:17 |
jyrama | I have both 2.94.2 and 2.95.2 timing out on the functional 2 tests on my machine. | 14:40:52 |
Maximilian Marx | I'm seeing the same issue with current main and latest 26.05 | 15:00:55 |
raitobezarius | correct, it's tracked in https://zulip.lix.systems/#narrow/channel/9-Store/topic/Plan.20for.20curl.20brokenness/with/11836 | 15:43:13 |
raitobezarius | but no one has been able to tackle it unfortunately | 15:43:19 |
raitobezarius | the solution could be to downgrade curl just for lix and introduce a curl-lix attr | 15:43:30 |
zoë (@blokyk) | if we can find out which curl commit broke things, could it be enough to use a patch that reverts it? | 15:46:39 |
raitobezarius | we already know which curl commit breaks it | 15:46:51 |
raitobezarius | what is the difference between reverting that commit and downgrading curl? | 15:47:08 |
zoë (@blokyk) | that way if the curl packaging evolved because of upstream changes, lix doesn't have to keep up the old packaging because of the old version | 15:48:06 |
raitobezarius | right but it may expose you to way more breakage because reverting one commit has no guarantee that you have fixed all the bugs | 15:48:43 |
zoë (@blokyk) | similarly, it would benefit from other improvements (like security fixes), though that's both a pro and a con since it also means it's possible for it to break again instead of lix using a known-good version | 15:49:05 |
raitobezarius | given what we know of curl | 15:49:39 |
raitobezarius | i would rather take a stupid approach which is downgrading | 15:49:47 |
raitobezarius | than trying to be subtle | 15:49:52 |