| 13 Apr 2023 |
 Lily Foster | (I think massive rebuilds to master should be red regardless, but I do wish build failures were also more obvious to others with ofborg) | 15:31:07 |
 7c6f434c | Well, some large single-package updates that will timeout on their own are master-targeted because they are too often security updates.
(The list of transient failures to keep gray so that people stop caring about red is a complicated question; are ENOSPC rare enough?) | 15:53:11 |
 Artturin | In reply to @sandro:supersandro.de
Blocking merge to master if the rebuild amount is to high and bringing ofborg into the hot path might not be the best idea. Calculating the rebuild amount takes a good amount of time, if ofborg is overloaded potentially hours. Also there are not even a handful of people maintaining ofborg and the domain for it recently expired. we could comment if 10.rebuild-linux: 501+ and targetting master
https://docs.github.com/en/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added
| 17:50:13 |
 K900 | Oh that's probably easier than hacking this into ofborg | 17:52:49 |
| K900 | That's actually way easier, wow | 17:53:44 |
| 7c6f434c | (Oh, and of course red on build failures in OfBorg is pure negative without recognition of dep failures — marking stuff with currently-being-fixed deps as broken just because of them is absolutely pointless) | 18:29:15 |
| Lily Foster | In reply to @7c6f434c:nitro.chat
(Oh, and of course red on build failures in OfBorg is pure negative without recognition of dep failures — marking stuff with currently-being-fixed deps as broken just because of them is absolutely pointless) (Does that occur often? Marking something red does not prevent merging if it really needs) | 18:32:56 |
| 7c6f434c | I think it occurs quite often if you consider Darwin a platform, or if you consider staging a branch | 18:33:49 |
| 7c6f434c | And OfBorg design choice is extremely low tolerance to making pointless noise red. | 18:35:02 |
| Lily Foster | In reply to @7c6f434c:nitro.chat
I think it occurs quite often if you consider Darwin a platform, or if you consider staging a branch Problems that are transitive dep failures though, not timeouts or anything? | 18:35:14 |
| Lily Foster | In reply to @7c6f434c:nitro.chat
And OfBorg design choice is extremely low tolerance to making pointless noise red. Yes I really really would not like pointless red. That would make it useless | 18:35:33 |
| 7c6f434c | (think = I have impression of having seen it on a large share of failures there) | 18:35:41 |
| 7c6f434c | Memory is fallible, so any number I try to come up from memory with should not be trusted. But it takes some «training set» to get to the stage «ah, to the surprise of absolutely no one…» | 18:37:18 |
| 7c6f434c | * Memory is fallible, so any number I try to come up from memory with should not be trusted. But it takes some «training set» to get to the stage of «ah, to the surprise of absolutely no one…» reaction | 18:37:28 |
| 7c6f434c | * Memory is fallible, so any number I try to come up with from memory should not be trusted. But it takes some «training set» to get to the stage of «ah, to the surprise of absolutely no one…» reaction | 18:38:07 |
| Lily Foster | Yeah I sure don't have hard numbers. I know I see timeouts semi-often. I was just wondering if it could be differentiated since sometimes people don't notice when an ofborg build on, say, darwin for a new package is failing and they either need to fix it or mark it broken to avoid wasting resources | 18:40:49 |
| 7c6f434c | … and of course the structure of OfBorg job dispatching does not fit well the claims like «a freshly added package is failing» | 18:44:07 |
| Lily Foster | In reply to @cole-h:matrix.org
Gotcha. Sorry about that. If you remind me on Monday I can try to reproduce the issue on one of the boxes directly Are you still able to do this sometime? (Do you just want me to DM you an expression or a flake ref to build or anything?) The build started failing again in ofborg on x86_64-linux when I pushed a small update to the PR earlier and I cannot reproduce it on any other system I have access to | 19:14:42 |
| 14 Apr 2023 |
 raitobezarius | logs.nix.ci seems broken atm, but the other URL that hexa mentioned is working | 15:18:48 |
| Artturin | In reply to @raitobezarius:matrix.org
logs.nix.ci seems broken atm, but the other URL that hexa mentioned is working The domain expired | 15:29:28 |
 hexa | and was renewed in the meantime | 15:30:56 |
| hexa | Creation Date: 2018-02-06T08:48:27.153Z
Registry Expiry Date: 2024-02-06T08:48:27.258Z
| 15:30:56 |
|  figsoda joined the room. | 15:53:59 |
| 15 Apr 2023 |
 cole-h | In reply to @lily:lily.flowers
Are you still able to do this sometime? (Do you just want me to DM you an expression or a flake ref to build or anything?) The build started failing again in ofborg on x86_64-linux when I pushed a small update to the PR earlier and I cannot reproduce it on any other system I have access to Feel free to DM with instructions / Nix expression / flake reference / etc to build and I'll get back to you when I can! | 12:35:54 |
| cole-h | In reply to @hexa:lossy.network
and was renewed in the meantime Yep, we have the domain back, but I haven't had the time to point everything back at it. Will probably happen next week some time. | 12:36:54 |
| 20 Apr 2023 |
| hexa | why is aarch64-darwin always so much behind 😕 | 21:50:25 |
| cole-h | Because there are only 2 of them | 21:51:12 |
| hexa | 
Download image.png | 21:51:31 |
| hexa | and we have more of everything else? even x86_64-darwin? | 21:51:43 |
| cole-h | Yeah: https://ofborg.org/prometheus/graph?g0.expr=ofborg_queue_builder_consumers%7Barch!~%22.*-lowprior%22%7D&g0.tab=1&g0.stacked=0&g0.show_exemplars=0&g0.range_input=6h | 21:52:15 |
