| 11 May 2026 |
 John Ericson | oh nevermind I do see it | 20:35:24 |
| John Ericson | that is in subprojects/crates/nix-utils/src/realise.rs | 20:37:02 |
| John Ericson | git log missed it becasue it was there since the initial commit (?) | 20:37:17 |
| John Ericson | oh because I was git loging the specific file | 20:39:10 |
| John Ericson | Frooastside: the instent is that the new builder and new queue runner will cooporate to get the inputs in place separately | 20:40:09 |
| John Ericson | so nix shouldn't need to download anything | 20:40:16 |
| John Ericson | but clearly that is not working right yet | 20:40:20 |
 Frooastside | Ok, thank you | 20:41:05 |
| 12 May 2026 |
 Morgan (@numinit) | FYI https://nixos.org/hydra/manual/ seems broken due to CORS rules | 03:51:51 |
| Morgan (@numinit) | Any sense where they're coming from? Took a quick look in https://github.com/NixOS/infra/blob/main/build/hydra-proxy.nix to fix it but didn't see anything | 03:53:31 |
| Frooastside | I tried getting the old queue-runner working but i face a weird issue where it just gets stuck on "sending inputs..." it tries to copy things from the s3 store but never finishes im not even sure whats the problem there. the only option is to manually kill the nix-daemon processes, systemctl restart nix-daemon doesnt touch the stuck processes. after doing that i can manually copy the nix store paths though im not sure if it works manually because its only one at a time or something else | 09:10:28 |
|  Harinn joined the room. | 18:14:22 |
 tomberek | Can the new queue-runner serve as only a coordinator/scheduler, but not perform any build/signing actions on it's own (eg: without even having a functioning Nix store locally?). Use-case: CI with ephemeral builders needing a centralized coordinator. | 20:49:03 |
 hexa | yes, it can | 20:49:24 |
| hexa | using pki for onboarding new nodes and the presigned urls feature to decentralize uploading | 20:49:59 |
| Frooastside | I think the problem might have been nix.settings.auto-optimise-store = true it seems to work now (for at least 2 minutes and it stopped every 10 seconds or so) | 22:31:22 |
| 15 May 2026 |
 Janne | Took me some time. I will only respond in one message to all of your messages so I don't have to use the shitty matrix quote feature too much.
I usually read my Matrix many times a day, the reason I seem so unresponsive is the dreadful feeling of opening this group or interacting with the repo in general that has taken over. Thank you for all the responses, but it still didn't address stuff like the short-time self-merges (~1h for the most recent one) and the overall overly high velocity on refactorings that don't seem to be really critical at all to take the new runner into production. About both the LLM thing and the toml-formatter thing: These are technical issues and that's not what is draining all motivation and energy to do any Hydra work. It's only a human issue (to me, at least). I have gotten to the point where I just delete mails for the Hydra repo without even reading the title because it doesn't even feel like it still matters to take a look | 17:46:12 |
| John Ericson | Janne: we can find a compromise, but I want to be clear that lots and lots of refactoring is something that brings me joy, and is also how I get to know the code that was written last year | 19:58:33 |
| John Ericson | there is a a bit of an inherient trade-off in here in that if I do less, you might feel better, and might help me figure out what is going wrong with prod, but I will be doing less (quite literally) and I will be learning the code less | 19:59:21 |
| John Ericson | IMO the state of this repo being unable to be deployed is not good a high risk state, but consider also I can stop refeactoring --- my prefered way of finding the problem --- and then I hope you are less burnt out? but we're gambling on psycology here. Say you still feel burnt out, and meanwhile the clock is ticking for me to get this stuff done | 20:00:45 |
| John Ericson | your welcome to look at any older commit and try to debug that, and if you get it working, I will have no problem deploying that older commit | 20:01:19 |
| John Ericson | and we can re-review what is on master since then | 20:01:25 |
| John Ericson | Janne: if roadmap would make this all more scrutable, the refactors I've done the last few days are all in prep for trying to only send resolved derivations to the builder in order to make the building dependnecies by mistake isssue impossible | 20:12:46 |
| John Ericson | well I should say almost all. In conjunction with that I am looking to replace the FFI with the daemon protocol because of the SQLIte errors we saw, and trying to be less tied to an exact nix version (since itis C++ FFI ATM) | 20:14:05 |
| John Ericson | The FFI was my idea I requested of Simon Hauser but I regret doing so because I didn't realize on macOS especially the daemon would be used anyways, so it would be FFI just to do the daemon protocol anyways | 20:15:38 |
| 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 |
