| 9 Oct 2025 |
 raitobezarius | not pre-merge failed tests | 16:27:56 |
 Rutile (Commentator2.0) feel free to ping | hmm | 16:28:07 |
| raitobezarius | I retried your tests | 16:28:46 |
| raitobezarius | If they don't pass deterministically (timed out again) | 16:28:51 |
| raitobezarius | We can analyze | 16:28:52 |
| raitobezarius | But I honestly think it's high CPU steal on the macOS VM | 16:28:59 |
| raitobezarius | We don't have monitoring there alas | 16:29:03 |
| Rutile (Commentator2.0) feel free to ping | raitobezarius: exact same bug: it has +1 despite tests still running and / or having failed https://gerrit.lix.systems/c/lix/+/4209?tab=checks | 17:53:45 |
| Rutile (Commentator2.0) feel free to ping | https://buildkite.com/lix-project/lix/builds/5091#0199c9c9-d727-4e77-9646-27621f5ed12e | 17:54:20 |
 Philip Taron (UTC-8) | On [builtins.warn](https://git.lix.systems/lix-project/lix/issues/579): I see the CL from 10 months ago stalled out. Is there anything new in the Lix team thinking since then other than:
Make a new exception type Don't use an environment variable What the hell is going on with cached eval failures
That's what I surmised from reading the CL and issue. | 18:57:48 |
|  somasis joined the room. | 19:00:19 |
| raitobezarius | can you try to order a revert of the suspected commit and rerun the CI for you? | 19:45:15 |
| raitobezarius | There's unaddressed comments on the CL, hence why it stalled | 19:45:46 |
| raitobezarius | Ah, I understood | 19:46:33 |
| raitobezarius | That's terrifying :( | 19:46:36 |
| raitobezarius | I will try to prioritize looking into that | 19:46:42 |
| Philip Taron (UTC-8) | Yeah, I saw that -- I'm asking if my summary of the feedback, the bullet points, still represents the thinking of the team. | 20:22:28 |
 jade_ | nixpkgs really needs to stop using those environment variables and do it with the arg instead, and that's going to be a compat hazard in the migration period between now and later. it's a shame we didn't get to fixing this in nixpkgs 10 months ago e.g. with feature detection, but alas. | 20:36:50 |
| jade_ | in fact, nixpkgs should just set the NIX_CONFIG debug-on-warn thing assuming it is matched between cppnix and lix, imo | 20:37:30 |
| jade_ | * in fact, nixpkgs should just set the NIX_CONFIG abort-on-warn thing assuming it is matched between cppnix and lix, imo | 20:37:56 |
| jade_ | I would appreciate this being fixed in nixpkgs' test suite before we can release this feature into GA | 20:38:24 |
| jade_ | * I would appreciate this being fixed in nixpkgs' test suite before we can release this feature into GA, because it means that it avoids a period of nixpkgs CI not working properly. | 20:38:47 |
| Philip Taron (UTC-8) | I'm in the channel in part because I was grossed out by the code in Nixpkgs. | 21:02:24 |
| Philip Taron (UTC-8) | The code we're talking about is this function, right? | 21:08:07 |
| Philip Taron (UTC-8) | That codepath is only lit up for Lix, since every supported cppnix has builtins.warn. | 21:08:45 |
|  tavinator joined the room. | 22:24:02 |
| jade_ | right, but the stuff that uses it is relying on NIX_ABORT_ON_WARN=true doing something at all, which it will not do if we implement the lix side well | 23:26:52 |
| jade_ | * right, but the stuff that uses it is relying on NIX_ABORT_ON_WARN=true doing something at all, which it will not do if we implement the lix side the way we want | 23:27:01 |
| jade_ | thus the users of builtins.warn inside nixpkgs test driver code need to start setting NIX_CONFIG so that they don't require us to implement the legacy environment variable | 23:27:31 |
| jade_ | * right, but the stuff that uses it is relying on NIX_ABORT_ON_WARN=true doing something at all, which it will not do if we implement the lix side the way we want. cppnix reads NIX_ABORT_ON_WARN like the nixpkgs polyfill | 23:27:55 |
