| 20 Jan 2022 |
| andi- left the room. | 00:10:17 |
nf | Redacted or Malformed Event | 12:37:49 |
| 24 Jan 2022 |
piegames | My PR managed to get labeled "ofborg-internal-error": https://github.com/NixOS/nixpkgs/pull/155061 | 11:08:36 |
hexa | staging-next achieved the same last night | 11:46:04 |
| 25 Jan 2022 |
hexa | eval is slow | 18:15:05 |
hexa | like "3 hours to review request"-slow | 18:15:17 |
cole-h | By eval, do you mean "ofborg seeing this PR and starting its eval" or "ofborg running its eval on this PR"? | 19:03:06 |
hexa | the evaluator seems busy, takes a long time to visit PRs | 19:04:57 |
cole-h | Any specific PRs, or is it generally slow for all PRs? (I can query the logs for specific PRs, is why I ask) | 19:07:24 |
hexa | https://github.com/NixOS/nixpkgs/pull/156702 | 19:09:05 |
hexa | for example | 19:09:08 |
| 27 Jan 2022 |
Andreas Schrägle | https://github.com/NixOS/nixpkgs/runs/4972851468?check_suite_focus=true
what's happening here? | 21:47:30 |
hexa | saw something similiar yesterday and linked it somewhere 😀 | 22:42:25 |
piegames | Redacted or Malformed Event | 22:44:44 |
piegames | In reply to @hexa:lossy.network saw something similiar yesterday and linked it somewhere 😀 https://github.com/NixOS/nixpkgs/pull/155061#issuecomment-1022208823 | 22:45:46 |
piegames | The error there was that the commit dropped the package without removing it from all-packages.nix (probably thanks to a rebase conflict fuckup). I don't know if this was the actual error or how the eval for the other platforms managed to even get so far | 22:46:54 |
Andreas Schrägle | hm. My PR removes every mention of neon_0_29 though. | 23:15:33 |
| 28 Jan 2022 |
piegames | In reply to @andreas.schraegle:helsinki-systems.de hm. My PR removes every mention of neon_0_29 though. If you're too stuck on the issue, ping @Nixos/Darwin-Maintainers I guess🤷 | 00:06:02 |
| 30 Jan 2022 |
Winter (she/her) | if I got ofborg-internal-error added to a PR, but then after pushing some more commits, ofborg was fine, can i remove the label? | 03:09:13 |
Winter (she/her) | or should i keep it there | 03:09:20 |
Sandro | Please keep it. Normal users can ignore it. It only is a sign that @ofborg eval or a push needs to be done. | 03:40:25 |
Winter (she/her) | In reply to @sandro:supersandro.de Please keep it. Normal users can ignore it. It only is a sign that @ofborg eval or a push needs to be done. As I said, I pushed new commits and OfBorg eval'd fine. | 04:57:10 |
Winter (she/her) | Sandro: so is it fine if I remove it in this case? | 06:40:02 |
Sandro | In reply to @winterqt:nixos.dev Sandro: so is it fine if I remove it in this case? just ignore the label. You don't need to do anything with it. | 06:40:27 |
Winter (she/her) | In reply to @sandro:supersandro.de just ignore the label. You don't need to do anything with it. will do, but why? if it's evaling fine now, why keep it? | 15:02:13 |
Winter (she/her) | just seems useless to me idk | 15:03:02 |
Sandro | Because it is an indicator which PRs failed and only people with access to ofborg can figure out why it failed. | 15:07:31 |
Sandro | Most of the time those errors have nothing to do with the PR. If so you get a red eval result. More often some GitHub API things have problems. | 15:08:23 |
hexa | red eval means you broke eval, that's most often the commiters fault, not ofborgs 😀 | 15:25:20 |
Winter (she/her) | In reply to @sandro:supersandro.de Because it is an indicator which PRs failed and only people with access to ofborg can figure out why it failed. yes but i never got a red eval, just that label added and an eval didn't start until i pushed again and then everything was fine
so am i keeping it there just because the fact that it failed at one point could be useful to see | 15:41:25 |