| 15 May 2026 |
John Ericson | that reminds me we should actually test no local nix store in the presigning case | 20:16:39 |
John Ericson | ideally we can do some/all of the tests both ways | 20:16:55 |
John Ericson | rather than write new tests from scratch | 20:17:00 |
John Ericson | I do have a NixOS test for presigning and it would be fun to disable the host nix store on that | 20:17:18 |
John Ericson | I suppose it might be a problem for evaluations though | 20:17:34 |
John Ericson | maybe after those are distributed | 20:17:37 |
Janne | Why is the clock ticking? I am not aware of a release cycle to catch in hydra? | 21:04:53 |
hexa | The primary work should be enabling whomever can fix the scheduling in the queue-runner, because all other work is basically pointless if nobody wants to deploy the queue-runner in the state it is right now. | 21:05:42 |
hexa | nixos/infra is pinned and so is my private hydra | 21:06:05 |
Janne | * Why is the clock ticking? I am not aware of a release cycle to catch in hydra? The answer to that would probably also explain the insane velocity the repo currently has (for no apparent reason from my perspective) | 21:06:13 |
Janne | Which may give me additional headache (not sure if there will be conflicts) to have to rebase the upcoming security patches for h.n.o | 21:06:53 |
John Ericson | the click is ticking is my own client work that allows me to work 100% of the time on hydra | 21:07:04 |
John Ericson | the actual feature work is all basically all done hydra side | 21:07:29 |
John Ericson | but that is equally pointless if the thing is broken and cannot be deployed | 21:07:41 |
Janne | I'm a bit too tired to come up with the proper words for what I think so I think I will have to postpone that to tomorrow (from my perspective) | 21:10:12 |
John Ericson | ideally, the new queue runner was going to be finsished and deployed jan/feb, before I even started | 21:10:16 |
John Ericson | sure, have a good friday evening | 21:10:45 |
John Ericson | OK yay the daemon protocol refactor is now passing the test suite locally | 22:31:08 |
John Ericson | that's net -2000 lines of code :) | 22:31:20 |
| 16 May 2026 |
Janne | Sorry, I honestly don't have anything worthwile to say today either | 18:02:13 |
Mic92 | In reply to @hexa:lossy.network nixos/infra is pinned and so is my private hydra What issue did you face in your private instance? I could start stabilizing things a bit. | 18:11:02 |
hexa | can't deploy the queue-builder on the builders for reasons | 18:51:21 |
tomberek | I'm keen to try things out... but only been lurking as I'm not quite sure when/if it is in a good state to test (mainly interested in a centralized scheduler with a de-centralized/binary-cache store as the source of truth). What would be helpful here? Docs? Users playing with it? Code? Review? | 20:28:55 |
| 17 May 2026 |
Mic92 | tomberek: users playing with would be good | 04:55:44 |
Mic92 | in theory could you not have the queue-builder running on your hydra as well and use nix remote build protocol? Also this sounds a bit like an insane setup. | 04:56:37 |
Mic92 | https://github.com/NixOS/hydra/pull/1747 <- Ever since I saw this code the interpolation for flakes scared me. | 04:57:05 |
Mic92 | Simon Hauser: Janne I would like to merge the ofborg infra into the nixos infra repo: https://github.com/NixOS/infra/pull/1009 reason is that this makes it easier to keep staging hydra in sync with the ofborg builder's queue-builder agent. Also shipping security updates on a more regular base is easier this way. I think you should still be able to deploy machines. Potentially we could also give our merge access to the infra repo? | 05:50:47 |
Mic92 | Janne: in case simon, doesn't read my message, please let him know about the pull request | 05:51:18 |
hexa | sgtm | 12:13:36 |
| 18 May 2026 |
Janne | I tried to keep it similar to make such a migration easier in the future. So I am fully on board with that. The merge access is something that may be helpful and I would take it if given to me but it's not something I will explicitly require or that I think is strictly necessary | 16:42:46 |