| 7 Aug 2023 |
|  nf changed their profile picture. | 09:41:23 |
 @antifuchs:asf.computer | with the github status check reporter, is there a way to set a "summary" status with a consistent name? I would like to make the "all hydra builds have passed" status a requirement to merge pull requests (via branch protection rules), but there's no way to identify them in the rule - they all have the jobset name on them, which varies by PR | 17:06:14 |
| @antifuchs:asf.computer | huh, it seems that https://github.com/NixOS/hydra/blob/master/src/lib/Hydra/Plugin/GithubStatus.pm#L46 should prevent the PR ID from going onto the job name in the status already? But then, my statuses are named like ci/hydra:home:pr-307:nixos.flynn (to just pr-, not -pr-...) | 17:09:35 |
| @antifuchs:asf.computer | oh dang, yeah it's exactly the fault of my jobsets calculator; reworking it to add a little prefix (I picked the base ref name so it looks like main-pr-8882) should work fine! | 17:23:03 |
| @antifuchs:asf.computer | hooray, and with https://gist.github.com/antifuchs/464fcf5c110d1a1b0b8d161d32dafbb5 it works perfectly! | 17:25:26 |
| 9 Aug 2023 |
|  Benedikt joined the room. | 17:44:43 |
|  @c:catgirl.cloud joined the room. | 21:22:54 |
| 10 Aug 2023 |
|  pbsds changed their display name from pbsds (UTC+1) to pbsds. | 14:54:57 |
| 11 Aug 2023 |
|  @rimuru:gentoo.chat changed their profile picture. | 15:39:12 |
| 12 Aug 2023 |
 hacker1024 | For some reason my NixOS ISO jobs (from system.build.isoImage) are timing out after two hours. I cannot find any reference to this limit in the Nix documentation or Nixpkgs, and I have not got anything resembling a value for two hours in my Nix or Hydra configuration. Does anyone know what is causing this? None of my other jobs that last longer than two hours time out. | 08:51:53 |
| hacker1024 | * For some reason my NixOS ISO jobs (from system.build.isoImage) are timing out after two hours. I cannot find any reference to this limit in the Nix documentation or Nixpkgs, and I have not got anything resembling a value for two hours in my Nix or Hydra configurations. Does anyone know what is causing this? None of my other jobs that last longer than two hours time out. | 08:52:20 |
 K900 (deprecated) | It's probably in meta.timeout on the derivation itself | 08:53:41 |
| hacker1024 | In reply to @k900:conduit.0upti.me
It's probably in meta.timeout on the derivation itself I checked in the REPL and in Nixpkgs, that doesn't seem to be the case | 09:02:54 |
| 13 Aug 2023 |
|  @10leej:matrix.org joined the room. | 01:26:30 |
 vcunat | IIRC there are two kinds of timeout. The other one is for max. silent time (no new logs). | 06:28:23 |
| vcunat | .meta.timeout is just an override, for some value configured I think. | 06:30:10 |
| vcunat | * .meta.timeout is just an override, for some value configured in Hydra or Nix I think. | 06:30:17 |
| vcunat | Yeah, man nix.conf shows even a few more kinds of timeouts | 06:31:26 |
| hacker1024 | Yep, the problem is that both my timeout and my max-silent-time is set to zero in nix show-config, and there's no mention of a timeout in hydra.conf. | 06:31:59 |
| hacker1024 | https://github.com/NixOS/hydra/blob/60e2c377d305b72cee39c51b5892d215e4238278/src/hydra-eval-jobs/hydra-eval-jobs.cc#L196 🤦
Thanks for the tip | 06:33:16 |
| hacker1024 | Oh, that default is actually in the manual. My bad. | 06:34:20 |
| hacker1024 | I suppose it makes sense to set it in Hydra (nix.conf doesn't really make sense across multiple build machines), but that default is pretty low. | 06:35:20 |
| vcunat | Two hours without any log line seems pretty suspicious to me. Could be e.g. thrashing due to low RAM. | 07:54:17 |
| hacker1024 | In reply to @vcunat:matrix.org
Two hours without any log line seems pretty suspicious to me. Could be e.g. thrashing due to low RAM. The SquashFS compression takes a long time, and there's nothing to be outputted while that's happening. I'm only using a free-tier Oracle Cloud VM with 4 ARM cores, so it can take a little longer than normal when other derivations are building at the same time. | 07:57:50 |
| hacker1024 | In reply to @vcunat:matrix.org
Two hours without any log line seems pretty suspicious to me. Could be e.g. thrashing due to low RAM. * The SquashFS compression takes a long time (CPU-bound), and there's nothing to be outputted while that's happening. I'm only using a free-tier Oracle Cloud VM with 4 ARM cores, so it can take a little longer than normal when other derivations are building at the same time. | 07:58:05 |
| 14 Aug 2023 |
|  K900 changed their display name from K900 (Old) to K900 ⚡️. | 16:09:24 |
| K900 changed their display name from K900 ⚡️ to K900 (⚡️ migration pending). | 16:23:32 |
| 15 Aug 2023 |
| K900 changed their display name from K900 (⚡️ migration pending) to K900 ⚡️. | 08:48:57 |
| K900 (deprecated) changed their display name from K900 to K900 (deprecated). | 08:49:12 |
| @10leej:matrix.org left the room. | 19:33:53 |
