| 8 Apr 2023 |
 cole-h | OK, ofborg.org is the domain for the moment. Webhook has been updated and appears to be working, now I'm deploying the evaluators themselves to pick up this new domain and hopefully we should be back up and running again soon. | 15:46:12 |
| cole-h | I'll try to collect a list of PRs that happened between ofborg's untimely demise and get them re-eval'd, but if I miss any, don't hesitate to @ofborg eval!
This does mean that old PRs' logs.nix.ci links will likely remain dead, but they might work if you change the URL to use logs.ofborg.org. | 15:48:12 |
| cole-h | OK, I think I've commented on all the (new) PRs that were missed. | 16:05:03 |
 hexa | ofborg.org.org.org.org.org | 16:05:21 |
| cole-h | This does mean there's a large-ish eval queue (and likely build queue after that), so please be patient :) | 16:05:30 |
| hexa | good luck on keeping nix.ci 🙂 | 16:05:36 |
| hexa | queue at 25 | 16:06:14 |
| cole-h | yep | 16:06:38 |
| cole-h changed the room topic to "Number of builds and evals in queue: https://ofborg.org/prometheus/graph?g0.expr=ofborg_queue_evaluator_waiting&g0.tab=1&g0.stacked=0&g0.show_exemplars=0&g0.range_input=2h&g1.expr=ofborg_queue_builder_waiting%7Barch!~%22.*-lowprior%22%7D&g1.tab=1&g1.stacked=0&g1.show_exemplars=0&g1.range_input=2h" from "Number of builds and evals in queue: https://nix.ci/prometheus/graph?g0.expr=ofborg_queue_evaluator_waiting&g0.tab=1&g0.stacked=0&g0.show_exemplars=0&g0.range_input=2h&g1.expr=ofborg_queue_builder_waiting%7Barch!~%22.*-lowprior%22%7D&g1.tab=1&g1.stacked=0&g1.show_exemplars=0&g1.range_input=1w". | 16:07:19 |
| cole-h | Updated topic with new URL for the moment. | 16:07:38 |
 K900 | Too bad you can't get ofb.org | 16:13:39 |
| hexa | because it already hosts this very important other website | 16:14:14 |
 VladimÃr ÄŒunát | I thought exactly about that when ofborg.org appeared here. | 16:14:57 |
| hexa | In reply to @hexa:lossy.network
ofborg.org.org.org.org.org cough | 16:15:15 |
| VladimÃr ÄŒunát | org.org is already taken, apparently. No idea if deeper layers are "available". | 16:16:42 |
 Lily Foster | In reply to @cole-h:matrix.org
I'll try to collect a list of PRs that happened between ofborg's untimely demise and get them re-eval'd, but if I miss any, don't hesitate to @ofborg eval!
This does mean that old PRs' logs.nix.ci links will likely remain dead, but they might work if you change the URL to use logs.ofborg.org. I can confirm real quick that just changing the URL from nix.ci to ofborg.org did not work (at least not for the one I tried). Which is a tad unfortunate because I linked a log in an upstream issue report yesterday (https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/337), but it's not that big of a deal really (since I saved a copy regardless and can produce it if really needed) | 16:35:58 |
| cole-h | Can you send me the link?
(Also, those links are extremely ephemeral, please don't rely on them to stick around for any length of time.) | 16:36:43 |
| Lily Foster | In reply to @cole-h:matrix.org
Can you send me the link?
(Also, those links are extremely ephemeral, please don't rely on them to stick around for any length of time.) I knew they were ephemeral. I only expected it up to be long enough for upstream to look at if they cared enough (which is also why I saved a copy)
Link was https://logs.nix.ci/?key=nixos/nixpkgs.225143&attempt_id=e780960b-b5a3-4abf-aad9-adab9b8a28cf
| 16:38:15 |
| Lily Foster | And the only reason I'm testing this with ofborg is because I can't reproduce it locally on any machines anymore... (I did one time and have been unable to since, but it's reliably reproduce in ofborg but only on x86_64-linux... it's weird) | 16:38:58 |
| Lily Foster | * And the only reason I'm testing this with ofborg is because I can't reproduce it locally on any machines anymore... (I did one time and have been unable to since, but it's reliably reproduced in ofborg but only on x86_64-linux... it's weird) | 16:39:02 |
| Lily Foster | (really though don't bother spending time on resurrecting that link -- it's not that important and they asked for a new log anyway) | 16:40:24 |
| cole-h | Gotcha. Sorry about that. If you remind me on Monday I can try to reproduce the issue on one of the boxes directly | 16:45:40 |
| 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 Will let you know! I'm currently just pushing an update to the PR while it's marked draft that print out the log they need and letting it run on x86_64-linux (then nabbing the log from the /logfile API and trimming)
Is there actually any way to avoid the ofborg eval step when doing that? (so that I'm not putting spurious stuff in the eval queue that I really just want a quick build for?)
| 16:51:37 |
 Artturin | no afaik, we have https://github.com/NixOS/ofborg/blob/released/ofborg/src/tasks/evaluate.rs#L576 but that only affects builds | 17:00:52 |
| Lily Foster | Oh great the build succeeded this time in ofborg on x86_64-linux. Heisenbug I guess 🫠| 17:04:02 |
| cole-h | In reply to @lily:lily.flowers
Will let you know! I'm currently just pushing an update to the PR while it's marked draft that print out the log they need and letting it run on x86_64-linux (then nabbing the log from the /logfile API and trimming)
Is there actually any way to avoid the ofborg eval step when doing that? (so that I'm not putting spurious stuff in the eval queue that I really just want a quick build for?)
You can't prevent the eval, but you can tell ofborg to manually build the attr(s) you want and that should happen independently of the eval step. | 17:34:17 |
| cole-h | e.g. @ofborg build asdf will build asdf even if there's an eval happening at the same time | 17:35:03 |
| cole-h | In reply to @lily:lily.flowers
Will let you know! I'm currently just pushing an update to the PR while it's marked draft that print out the log they need and letting it run on x86_64-linux (then nabbing the log from the /logfile API and trimming)
Is there actually any way to avoid the ofborg eval step when doing that? (so that I'm not putting spurious stuff in the eval queue that I really just want a quick build for?)
* You can't prevent the eval, but you can tell ofborg to manually build the attr(s) you want and that will happen independently of the eval step. | 17:35:08 |
| Lily Foster | In reply to @cole-h:matrix.org
e.g. @ofborg build asdf will build asdf even if there's an eval happening at the same time Yeah I did actually do that. Just didn't want clog up the eval queue (especially since it was backing up a bit the last few days -- seems better today though) | 17:36:06 |
| cole-h | Eval queue should get eaten through fairly fast. The evals themselves may be slow but the machines are fast enough that it shouldn't ever grow to an unmanageable number (unlike the Darwin build queues lol) | 17:37:05 |
