| 11 Oct 2022 |
 ncfavier | yeah i glanced over the API docs already but there's only completed | 15:03:04 |
 cole-h | If there's no other easy way to look at when ofborg first pushes a status, then I think changing the wording would be fine :) | 15:13:47 |
| 12 Oct 2022 |
 K900 | Where do I poke ofborg to make it recalculate the labels? | 11:35:38 |
| K900 | It's not doing that on https://github.com/NixOS/nixpkgs/pull/191357 | 11:35:43 |
 hexa | eval should to that imo | 11:42:56 |
| K900 | That's what I thought too | 12:06:18 |
| K900 | But it doesn't match my nixpkgs-review numbers | 12:06:30 |
| K900 | Unless it's also counting broken packages? | 12:06:39 |
| cole-h | You can see which packages it thinks has changed, and for which architecture, by clicking the "Details" link next to the ofborg-eval — ^.^! status. That'll tell you what ofborg thinks changed. | 16:28:41 |
| K900 | Oh | 16:29:42 |
| K900 | It does count broken packages | 16:29:52 |
| K900 | Is that intentional? | 16:29:57 |
| cole-h | Probably | 16:30:21 |
| K900 | It just misfires hard on KDE stuff because we have three different attrsets for Qt 5.12, 5.14 and 5.15 | 16:30:57 |
| K900 | And the KDE stuff is included in all three, but marked broken on <5.15 | 16:31:09 |
| K900 | So ofborg counts 1.5k rebuilds when there's really about 500 | 16:32:37 |
| 13 Oct 2022 |
| hexa | disk full https://github.com/NixOS/nixpkgs/pull/191123 | 18:25:16 |
| hexa | nvm, olde | 18:25:47 |
| hexa | * nvm, old | 18:25:47 |
| 14 Oct 2022 |
| ncfavier | In reply to @ncfavier:matrix.org
can we talk about the "pending status [that] will be cleared when ofborg starts eval" that's only cleared when ofborg finishes eval? proposed a fix https://github.com/NixOS/nixpkgs/pull/195984 | 14:10:40 |
| 15 Oct 2022 |
|  underpantsgnome changed their display name from underpantsgnome to underpantsgnome!. | 00:30:21 |
| 17 Oct 2022 |
 Artturin | https://github.com/NixOS/ofborg/pull/618 | 18:03:20 |
| Artturin | ci passed | 18:03:23 |
| 22 Oct 2022 |
 zseri | huh, why does https://github.com/NixOS/nixpkgs/pull/190730/checks?check_run_id=9036063946 get marked as "neutral" instead of "failure/error" (one of the modified packages itself failed to compile)? | 11:47:03 |
 7c6f434c | Build failures are always reported as neutral outcomes, because failures are for things that are even more unambiguous (you'd need to check for disk full, transient network issues etc. to be sure about build failures) | 11:48:23 |
 Sandro 🐧 | No, it is stupid. GitHub treats it as being ignorable which it often isn't and broken packages should be marked as such. | 13:05:34 |
| zseri | In reply to @7c6f434c:nitro.chat
Build failures are always reported as neutral outcomes, because failures are for things that are even more unambiguous (you'd need to check for disk full, transient network issues etc. to be sure about build failures) like, you need to check for that anyways on failures, and failures just say "well, it failed (probably to compile)", but you can ignore it if it is a false-positive... | 13:37:53 |
| 7c6f434c | ofBorg is tuned carefully to minimise false-positive red-failures | 13:38:44 |
| zseri | uhm but when does it report red-failures then? | 13:41:00 |
| zseri | * uhm but when does it report red-failures then? only syntax-errors? | 13:41:18 |
