| 1 Mar 2025 |
 hexa (signing key rotation when) | where is the default limit set? | 06:59:30 |
| hexa (signing key rotation when) | a meta default? | 06:59:49 |
| hexa (signing key rotation when) | I think we only configure a max-silent-time on the builders | 07:00:17 |
| hexa (signing key rotation when) | and a max-unsupported-time on the queue-runner | 07:00:23 |
| hexa (signing key rotation when) | Redacted or Malformed Event | 07:00:28 |
 vcunat | .meta.timeout | 07:01:05 |
| hexa (signing key rotation when) | pkgs/applications/networking/browsers/chromium/browser.nix
121: timeout = 172800; # 48 hours (increased from the Hydra default of 10h)
| 07:01:34 |
| hexa (signing key rotation when) | 🤡 | 07:01:36 |
| hexa (signing key rotation when) | * pkgs/applications/networking/browsers/chromium/browser.nix
121: timeout = 172800; # 48 hours (increased from the Hydra default of 10h)
pkgs/development/tools/electron/common.nix
287: timeout = 172800; # 48 hours (increased from the Hydra default of 10h)
| 07:01:49 |
| hexa (signing key rotation when) | meta.timeout is not set by default, so … where is the default? 😄 | 07:02:35 |
| vcunat | I think it's in Hydra config. | 07:02:50 |
| hexa (signing key rotation when) | 
Download image.png | 07:03:04 |
| hexa (signing key rotation when) | , timeout => getMeta($buildInfo->{meta}->{timeout}, 36000)
| 07:03:33 |
| hexa (signing key rotation when) | indeed, here we are | 07:03:35 |
| hexa (signing key rotation when) | lun: I'm a bit afraid to ask, but there is supposed to be a migraphx python package, and one of the packages I maintain would want that to support rocm 🙈 | 07:09:15 |
| hexa (signing key rotation when) | supposedly this https://github.com/ROCm/AMDMIGraphX/blob/develop/src/py/migraphx_py.cpp | 07:13:00 |
 Lun | Mention it on the big ROCm tracking issue | 16:04:24 |
| Lun | definitely worse: https://gist.githubusercontent.com/LunNova/b1cf007f1af52b4dc353fd9925857b97/raw/63ea9ec1a500d5ef6ad4f2f0eac7a59b6db6e310/huge%2520composable_kernel%2520template%2520instantiation.txt | 16:07:29 |
| Lun | The ~4h builds are nix cores config set to 128 on a 64c/128t epyc milan eng sample that's clocking down to <3GHz due to power limits, not sure what the relative speedup per core will be but probably not enough to overcome dropping to 24 build threads.
Does bumping meta.timeout to 20h to start with sound reasonable? | 16:13:51 |
 emily | might make sense to do 48 and then scale down based on the actual time | 16:19:08 |
| emily | to avoid spending 20 hours on a build that times out and gets thrown away | 16:19:16 |
| emily | (I am not on the infra team, don't trust anything I say) | 16:19:34 |
| vcunat | I believe it's fine to put an unnecessarily big value in there. It's just a single package. I see the main purpose to limit some accidents where resources would be spent continually without bringing value. | 16:23:17 |
| vcunat | But honestly, doing so much work in a single derivation is rather risky. Generally it's better to split it up. | 16:24:19 |
| vcunat | For example, sometimes we need to restart the queue runner, i.e. all builds in progress get scrapped. | 16:24:57 |
| vcunat | We even had periods where it crashed often (same effect). | 16:25:16 |
| Lun | Haven't figured out a way to split it up yet that'll be easy to maintain | 16:26:25 |
| vcunat | And I have some concerns about increasing latency of channels, but maybe that will turn out negligible. | 16:27:38 |
| vcunat | * And I have some concerns about increasing latency of channel updates, but maybe that will turn out negligible. | 16:27:48 |
| vcunat | As it is now, everyone will be waiting for this huge thing to finish. | 16:28:23 |
