| 13 Apr 2023 |
 Sandro 🐧 | So? Would that be a bad thing? | 12:11:42 |
| Sandro 🐧 | If things time out we probably want to restart them anyway | 12:11:53 |
 K900 | Staging times out all the time | 12:14:22 |
| K900 | So probably not the best idea | 12:14:27 |
| Sandro 🐧 | so exclude PRs targeting staging? I really want to push for that because most new people think grey can be ignored which it usually cannot especially for new packages. | 13:59:08 |
| Sandro 🐧 | * so exclude PRs targeting staging? I really want to push for that because many new people think grey can be ignored which it usually cannot especially for new packages. | 13:59:20 |
 7c6f434c | Chromium update will timeout on its own | 15:26:08 |
 Lily Foster | I also occasionally get ofborg timeouts for larger packages or if some big rebuilds (e.g. nodejs) are on master (generally just for darwin builders though -- usually linux builders don't suffer from build timeouts unless it's to staging or something is wrong). Could ofborg differentiate between timeout/failure and set timeout to neutral and propagate the failure red? | 15:30:01 |
| 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 |
