| 7 Jul 2022 |
 Winter (she/her) | How so, in what way? Obviously it depends on the test, but what are you thinking of? | 05:56:19 |
 7c6f434c | Using a package that has hand-optimised assembly in it and finally gets marked broken on aarch64 when someone gets fed up with build failures | 05:57:14 |
| 7c6f434c | ofBorg is and should be conservative with the red marks | 05:58:16 |
| Winter (she/her) | Ah, yeah, in the case of broken packages, that won't stop manual triggers from trying to eval aarch64 (although we could gate passthru.tests based on broken for the automatic triggers) | 05:58:54 |
| Winter (she/her) | Yeah that makes sense | 05:58:59 |
| Winter (she/her) | Apologies for going in circles | 05:59:04 |
| 7c6f434c | Realistically GitHub is just too restricted to have good high-resolution status reporting | 06:00:11 |
| 7c6f434c | So ofBorg reports as red just the things that can be defined without finely carved logic | 06:00:37 |
| Winter (she/her) | What are those things, if it's so conservative on tests for example? Eval errors on the packages themselves? I guess those could also be affected by the issues discussed so hm | 06:01:33 |
| 7c6f434c | Well, there is evaluator for package set where marked-broken and some other evaluation failures are treated as expected failures | 06:02:52 |
| 7c6f434c | Like, Hydra auto-builds new packages without them being added to special lists, but of course there are limits to how broken things can be before this enumeration breaks down | 06:03:33 |
| 7c6f434c | That would be a red failure | 06:03:42 |
| 7c6f434c | (happens from time to time!) | 06:03:49 |
| Winter (she/her) | So anything that's on a release list/channel/whatever that list is called failing would be a failure from OfBorg? | 06:10:36 |
| 7c6f434c | No | 06:10:52 |
| 7c6f434c | Enumerating things that are even available for Hydra to build failing, that would be a failure | 06:11:18 |
| Winter (she/her) | What do you mean by enumerating, evaluating the list? | 06:13:18 |
| 7c6f434c | Yes, and it has eval failure catching that is fine with many things | 06:13:56 |
| Winter (she/her) | Right.
Okay, I somewhat understand these design choices now, thanks (and sorry, again)! | 06:16:54 |
| 12 Jul 2022 |
 Artturin | In reply to @sandro:supersandro.de
How did it happen that we lose aarch64-darwin? this is still happening | 19:53:08 |
 cole-h | I can take a look tomorrow. | 19:54:19 |
|  siraben joined the room. | 20:09:48 |
| 13 Jul 2022 |
| cole-h | In reply to @cole-h:matrix.org
I can take a look tomorrow. I took a look earlier and it should be fixed now. | 17:59:20 |
| 14 Jul 2022 |
|  pennae left the room. | 02:53:58 |
| Artturin | not fixed | 16:31:00 |
| cole-h | In reply to @artturin:matrix.org
not fixed Could you give some more information? All the Darwin machines are up | 18:48:14 |
| Artturin | for example https://github.com/NixOS/nixpkgs/pull/181458 | 18:48:47 |
| Artturin | no on aarch64-darwin | 18:48:53 |
| cole-h | In reply to @artturin:matrix.org
no on aarch64-darwin Spent some time looking into this -- no idea why it happened, but it seems restarting ofborg on those machines fixed it (there's one building now). Probably won't apply retroactively, unfortunately, but should be fine for the moment | 20:50:33 |
| 15 Jul 2022 |
 Sandro | How about those get restarted periodically? | 01:30:19 |
