| 30 Jun 2026 |
 Rutile | This should get documented in the issue tracker tho '^^ | 12:34:16 |
 Puna | considering the above, should i add ARM (prolly in general) to the condition for the raised timeout in the pull request? | 12:43:17 |
| Puna | * considering the above, should i add ARM (prolly in general) to the condition for the raised timeout in the pull request? or drop the condition entirely? | 12:45:27 |
 Grimmauld (any/all) | i'm not sure conditionalizing makes any sense here | 12:45:36 |
| Puna | likewise, but i got asked to make it conditional | 12:46:08 |
 emily | https://git.lix.systems/lix-project/lix/issues/890 | 12:46:18 |
| Grimmauld (any/all) | but also, consider a setup where you do aarch64 -> x86_64 cross while having an emulator available. In that case, check phase will still execute, but you'd want to check build platform, not host platform | 12:46:27 |
| emily | there is no good reason to have timeouts inside a Nix build | 12:46:30 |
| emily | and Nixpkgs specifically disables it across the board for Meson, Lix's derivation just happens to be structured in a way that doesn't pick that up | 12:47:13 |
| emily | it should really be disabled unconditionally | 12:47:22 |
| emily | in Nixpkgs at least | 12:47:35 |
 raitobezarius | In reply to @emilazy:matrix.org
there is no good reason to have timeouts inside a Nix build I disagree, for users, it does make a difference? | 12:49:27 |
| Grimmauld (any/all) | test timeout is only relevant if it locks up. Assuming tests actually work reliably, it should be a non-issue. For users that pull from hydra, it is a non-issue. No timeout is only ever an issue during developing, while having to expect states in which it does lock up. A short timeout however is an issue if it causes build failures. | 12:52:26 |
| Grimmauld (any/all) | * test timeout is only relevant if it locks up. Assuming tests actually work reliably, it should be a non-issue. For users that pull from hydra, it is a non-issue. Lack of timeout is only ever an issue during developing, while having to expect states in which it does lock up. A short timeout however is an issue if it causes build failures. | 12:52:41 |
| raitobezarius | Yes, Lix has totally not been locking up for the past weeks | 12:53:30 |
| raitobezarius | (and therefore users were totally able to pull from Hydra) | 12:53:55 |
| Grimmauld (any/all) | If it locks up, i understand having aggressive timeouts for Lix' own CI system. I don't see why you'd want the timeouts in nixpkgs ever. | 12:54:51 |
| raitobezarius | Because if it locks up in Hydra and doesn't get cached, users will have to build and have their build hang as well? | 12:55:22 |
| emily | I don't understand - Hydra has timeouts already | 12:56:15 |
| raitobezarius | My take is that until the current abnormal state of our curl dependency is solved, timeouts are useful to waste less time for users across the board | 12:56:29 |
| raitobezarius | In reply to @emilazy:matrix.org
I don't understand - Hydra has timeouts already Yes, Hydra does, end users doesn't | 12:56:37 |
| emily | ok, I see what you mean, though was that failure even stochastic? | 12:57:23 |
| raitobezarius | It was not stochastic, it was deterministic | 12:57:36 |
| emily | then a timeout doesn't really help, no? the time to get a Lix build is infinite either way | 12:58:11 |
| raitobezarius | In reply to @emilazy:matrix.org
then a timeout doesn't really help, no? the time to get a Lix build is infinite either way The timeout gives you a fail fast signal | 12:58:41 |
| Grimmauld (any/all) | if you fail both on a somewhat overloaded system and if it is actually broken, the signal to noise ratio is questionable at best though | 12:59:30 |
| emily | it's not super fast... but there could be a timeout specifically for the curl tests that can hang, say? | 12:59:51 |
| raitobezarius | In reply to @emilazy:matrix.org
it's not super fast... but there could be a timeout specifically for the curl tests that can hang, say? Deal but I think this problem could really occur in say kj | 13:00:18 |
| raitobezarius | Or capnp | 13:00:21 |
| emily | in any case the current timeout has been too low for even common platforms for a long time, let alone anaemic ppc64 | 13:00:39 |
