| 21 May 2024 |
 cole-h | In reply to @7c6f434c:nitro.chat
Not sure if it is a useful report, but a PR I review got ENOSPC on x86_64-linux ofborg. https://logs.ofborg.org/?key=nixos/nixpkgs.312998&attempt_id=36815c47-62d8-4fce-862b-497ff60ccafe Yeah, there were Issues yesterday, but should be resolved AFAICS? | 13:25:01 |
| 22 May 2024 |
 7c6f434c | Probably! K900 was fighting local flakiness of tests that passed on ofborg more often than not (by short-circuiting the tests) by that time, so the merge did not need all-platform ofborg run for the latest revision. | 08:17:10 |
| 7c6f434c | Thanks! | 08:17:13 |
 K900 | I wasn't even looking at ofborg tbh | 08:17:33 |
| K900 | I was just rebuilding everything locally because I have more compute than an average ofborg job | 08:17:48 |
| K900 | And that thing already takes forever to build | 08:17:59 |
| 7c6f434c | I did look at ofBorg to check that the platform-by-platform situation is as expected. | 08:19:03 |
 Alyssa Ross | A while a go there was a discussion in this room about raising the timeout on Darwin. On staging PRs it never gets past LLVM, which is part of stdenv, so it's essentially useless — but also, that means that every staging PR is going to take at least an hour of OfBorg time, so I and others suspect that raising the timeout to allow it to finish might actually free up capacity, because it will be able to share LLVM builds. | 12:32:05 |
|  NixOS Moderation Botchanged room power levels. | 15:25:58 |
| NixOS Moderation Botchanged room power levels. | 15:28:12 |
| cole-h | In reply to @qyliss:fairydust.space
A while a go there was a discussion in this room about raising the timeout on Darwin. On staging PRs it never gets past LLVM, which is part of stdenv, so it's essentially useless — but also, that means that every staging PR is going to take at least an hour of OfBorg time, so I and others suspect that raising the timeout to allow it to finish might actually free up capacity, because it will be able to share LLVM builds. Right, I remember now... the only problem I have with that is the Darwin queue frequently grows to the hundreds, and I'm afraid that if given e.g. 2 hours (or more) that means the build queue will become even more unmanageable... I dunno, I suppose I'm willing to give it a shot, just let me what you think we should start with (2? 3? 6 hours before timeout?) | 22:45:13 |
| 23 May 2024 |
| Alyssa Ross | shouldn't need to be more than 3 | 06:42:05 |
| Alyssa Ross | not sure if 2 would be enough | 06:42:08 |
 hexa | are the builders sharing a cache of any kind? | 13:01:10 |
| hexa | or would every individual builder have to build their own llvm | 13:01:23 |
| K900 | Even if they share a cache they don't share locks | 13:01:43 |
| K900 | So they'll attempt to race | 13:01:47 |
| hexa | yes, but you can't have it all 🙂 | 13:04:12 |
| cole-h | ofborg has a queue, so if one builder picks up the only LLVM build, nobody else can pick it up | 14:38:40 |
| cole-h | In reply to @qyliss:fairydust.space
shouldn't need to be more than 3 I'll give it a shot later today and we'll see how it goes. | 14:39:29 |
| 7c6f434c | It's not an LLVM build, it's an LLVM-dependent build though | 14:40:49 |
| cole-h | Gotcha, I misunderstood the concern | 14:41:15 |
| hexa | and caching? | 18:10:57 |
| hexa | if one builder has the result, can others reuse it? 😛 | 18:11:03 |
| cole-h | No, no caching between machines at this moment | 18:11:34 |
| Alyssa Ross | ah, I assumed there would be | 18:12:48 |
| Alyssa Ross | that makes me less confident it would save time | 18:12:57 |
| hexa | wondering, does haumea run on darwin? | 18:13:49 |
| hexa | that would allow sharing directly from the /nix/store | 18:14:05 |
| cole-h | No clue what haumea is, so can't comment | 18:14:38 |
