| 22 Apr 2026 |
 raitobezarius | Meh I'm sure we will fall in the pointer tagging change and this won't help me understanding what is going on | 12:31:03 |
| raitobezarius | I will try analyzing the forcing logic just by reading the frames | 12:31:31 |
| raitobezarius | and if I fail, I will think about something else | 12:31:35 |
| raitobezarius | found a nicer reproducer | 12:49:45 |
| raitobezarius | nix-instantiate --eval -E 'import ./. { system = "x86_64-darwin"; allowAliases = false; overlays = [ (self: super: { stdenv = super.stdenv.override {}; }) ]; }' | 12:49:50 |
| raitobezarius | CppNix explodes immediately, Lix produces a result | 12:49:57 |
 emily | (nothing better than a language without semantics) | 12:51:55 |
| raitobezarius | let's be even more precise | 12:52:06 |
| raitobezarius | nix-instantiate --eval -E 'import ./. { system = "x86_64-darwin"; allowAliases = false; overlays = [ (self: super: { stdenv = super.stdenv // { __bootPackages = throw "bye"; }; }) ]; }' also differs in evaluation | 12:52:10 |
| raitobezarius | it feels like what trips up the __bootPackages is the series of asserts inside the darwin/default.nix entrypoint | 12:52:40 |
| raitobezarius | but I don't know if this needs to be forced to know the list of package names | 12:52:58 |
| raitobezarius | On a conceptual level, no package name depends on the actual state of stdenv | 12:53:48 |
| raitobezarius | There's no true evaluation bug because CppNix and Lix agrees that pkgs.pkgsExtraHardening.stdenv is cooked | 12:54:11 |
| raitobezarius | I don't have time to go deeper right now to pinpoint why the potential assert are thunked somehow in the eval machinery in Lix | 12:54:44 |
| raitobezarius | I will open an issue on the Lix side and pass it to the rest of the core team | 12:54:53 |
| raitobezarius | I suggest that override is repaired and is tested wrt to presence of __bootPackages or that AvailabilityVersions do not assume its existence in stdenv because overridden stdenv exist | 12:55:16 |
| raitobezarius | This unblocks the current failure in Hydra | 12:55:32 |
| raitobezarius | release-checks should add something about .stdenv to the package set being evaluated | 12:55:48 |
| raitobezarius | This will make Lix flag this also unless we deem it to be a bug on our side and will converge to CppNix's evaluation behaviors | 12:56:04 |
| raitobezarius | but if I read https://edolstra.github.io/pubs/laziness-ldta2008-final.pdf | 12:56:46 |
| raitobezarius | I read "maximal laziness" | 12:56:48 |
| raitobezarius | if Lix can produce a result here out of maximal laziness… :P | 12:56:55 |
| raitobezarius | * if Lix can produce a (correct) result here out of maximal laziness… :P | 12:57:13 |
| raitobezarius | you can follow our discussions in https://zulip.lix.systems/#narrow/channel/6-Eval/topic/Laziness.20difference.20in.20Lix.202.2E94.2B.20vs.2E.20Lix.202.2E93/near/9924 | 12:59:34 |
| * raitobezarius goes away | 13:00:24 |
 Randy Eckenrode | I added a test for __bootPackages in my attempted fix PR. Once we get a fix in, then this can all go away on staging where I tear out this stuff that was only there to avoid rebuilds on master. | 13:07:29 |
| raitobezarius | Awesome, tysm! | 13:07:39 |
| emily | it would be nice to have a more minimal reproducer so it can be analysed as a language semantics question rather than a Nixpkgs constructs one | 13:16:44 |
| emily | (ofc not saying anyone is obligated to produce that) | 13:16:52 |
 Vladimír Čunát | Merged staging-next. While the release-checks` on master suffers from multiple non-linux issues, it seems unrelated. | 13:23:47 |
