| 30 Jun 2026 |
 emily | the per-test 300s timeout was what I ran into | 13:11:52 |
| emily | I'd imagine users on slower hardware might get hit by it more often | 13:12:02 |
 Rutile | adding a pass-throgh flag for per-test timeout would fix this tho (aka having a setting in nixpkgs which defaults to 300) | 13:12:47 |
| Rutile | unless that breaks caching | 13:13:06 |
 Grimmauld (any/all) | if that changes the drv being built, yes that breaks caching | 13:13:36 |
 raitobezarius | That breaks caching because the values change in the drv? | 13:13:49 |
| Grimmauld (any/all) | you could do it as impure env var, but please don't | 13:13:54 |
| Grimmauld (any/all) | yes | 13:14:01 |
| raitobezarius | The best thing is what emilazy said which is to let Nix deal with the timeout | 13:14:03 |
| Rutile | yay, even more env vars :D | 13:14:04 |
| raitobezarius | Anyway, what I will do is I will try to make issues out of this discussion, I think this is mostly Nixpkgs problems so that should be doable to fix in reasonable amount of time | 13:14:53 |
| raitobezarius | In reply to @grimmauld:m.grimmauld.de
certain year range of hardware
And apparently 2024 is too old? ... wtf?
I understand curl is being weird. But forcing people to run downstream patches to make your software work, patches they attempted to upstream but got told "your hardware is too old, we'd rather keep the flaky tests", that is certainly a take... Please less of this tone, I apologize if I trigger you or something, but I am not trying to be unreasonable | 13:16:31 |
| emily | on the Nixpkgs side the policy is already set, the Meson hooks deliberately set the timeout to 0 | 13:17:25 |
| emily | the Lix package is just structured in a way that doesn't pick that up, "accidentally" | 13:17:46 |
| 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 |
