| 30 Jun 2026 |
 emily | (as in, the way its check phase is written happens to not get these defaults applied, but I don't think that was an intentional decision when it was originally written but just a structural accident) | 13:18:52 |
 Qyriad | Specifically Nixpkgs adds --timeout-multiplier=0 to the Meson check flags | 13:19:13 |
| Qyriad | Most of Lix's tests run in installCheckPhase though, which isn't mesonCheckPhase where that timeout multiplier is added, yep | 13:20:25 |
 raitobezarius | @qyriad:katesiria.org: can I let you take care of @emilazy:matrix.org: remarks on macOS wrt timeouts? | 13:26:32 |
| Qyriad | Which ones? | 13:26:51 |
 Grimmauld (any/all) | fair, sorry. I am of the strong opinion upstream should make building as painless as possible, but i went a little far. | 13:27:44 |
| emily | fwiw I think potentially the single biggest UX improvement anyone could make to the ecosystem would be narinfo cache entries for failed builds. (I realize this isn't something Lix has the ability to make happen on the cache where it'd matter most though) | 13:30:26 |
| emily | (but even running into the question of whether timeouts help users running redundant builds that will certainly deterministically fail is a silly state of affairs to end up in) | 13:31:10 |
| raitobezarius | In reply to @emilazy:matrix.org
I agree slow tests are bad but punishing users for the tests being slow for a year+ when "we should just fix it instead" was the response then too doesn't seem to be actually helping the thing get fixed ^ | 13:32:15 |
| raitobezarius | I think we concur on the outcome we want to provide to everyone, it's just that we come from different PoVs on how to achieve that | 13:36:00 |
| raitobezarius | (not saying my PoV is universally right neither) | 13:36:12 |
| Grimmauld (any/all) | Imo the important question is what role tests are supposed to fulfil | 13:37:07 |
| Grimmauld (any/all) | From a user pov, tests are a sort of "stability guarantee". I want to run tests so i can be reasonably certain i don't run into unexpected regressions or other problems | 13:37:42 |
| Grimmauld (any/all) | From a dev pov, tests are more like, a mechanism to catch stupid mistakes early | 13:37:58 |
| raitobezarius | More than once in a time, any tool is destined to be used in unexpected ways, I won't mind using a tool that was not intended for a certain usecase for a new usecase if it seems to provide good value in a given period of time | 13:38:31 |
| raitobezarius | Right now, I care mostly about people knowing that Lix is not usable with some curl variants out there | 13:38:56 |
| Grimmauld (any/all) | for catching mistakes early, i understand wanting tests to fail fast. But if all i care about is correctness, not how long it takes to tell me that, i am willing to wait hours for a test to succeed/fail | 13:39:11 |
| raitobezarius | And it seems to surface in a timeoutted build that people can come to report to us and we can steer them to the ongoing mitigation work | 13:39:13 |
| raitobezarius | And this has happened more than 2-3 times OTOH | 13:39:23 |
| raitobezarius | Yes, in that case, it means that you are willing to wait forever if you had the broken curl variant until you took your own decision, but you have the knowledge to do this, not all our users do | 13:40:05 |
| Qyriad | Adding a new impure environment variable was rejected, but what about scaling --timeout-multiplier on $NIX_BUILD_JOBS? | 13:40:16 |
| Qyriad | That way machines building with lower parallelism transparently get higher timeouts | 13:40:33 |
| Grimmauld (any/all) | that sounds dangerous | 13:41:12 |
| raitobezarius | it won't fix the overloadness because job servers are not a thing alas | 13:41:31 |
| raitobezarius | for nixpkgs, i think we could even consider removing the timeout and aligning with a zero timeout and experiment how it goes | 13:41:52 |
| raitobezarius | most fixes for curl were done, mechanically, we won't see curl brokenness for a while | 13:42:05 |
| raitobezarius | if we see a bunch of users confused about forever builds and angry, we can revisit | 13:42:12 |
| Grimmauld (any/all) | because suddenly overcommit makes it worse by the square. You expect to run with 8x parallelism (thus make test timeout 8x shorter), but the linux kernel build already has 8x parallelism making it in reality WAY slower | 13:42:22 |
| Grimmauld (any/all) | * because suddenly overcommit makes it worse by the square. You expect to run with 8x parallelism (thus make test timeout 8x shorter), but the linux kernel build on the same box already has 8x parallelism making it in reality WAY slower | 13:42:57 |
| Grimmauld (any/all) | of course that is a scheduling mistake, sure | 13:43:40 |
