| 29 Sep 2023 |
 7c6f434c | I don't think ofBorg and normal impure eval are distinguishable, and we don't want to mark the package broken for normal use. | 14:07:11 |
 Lily Foster | In reply to @7c6f434c:nitro.chat
I don't think ofBorg and normal impure eval are distinguishable, and we don't want to mark the package broken for normal use. Well if it's impure, you could use builtins.readFile and detect hostnames or the ofborg runner executable and such 😉 | 14:30:18 |
| 7c6f434c | I wonder if this will be an error-out during pure eval, though | 14:33:22 |
| Lily Foster | (But again please never do that, everything about it is so cursed and frail ðŸ˜) | 14:33:25 |
| Lily Foster | In reply to @7c6f434c:nitro.chat
I wonder if this will be an error-out during pure eval, though lib.isPureEval | 14:33:37 |
| Lily Foster | * `lib.inPureEvalMode` | 14:34:49 |
| 7c6f434c | Fortunately existence of stable branches would make tying to details of ofBorg deployments just too painful and impractical… | 14:38:34 |
| Lily Foster | Stables branches or not, it's a bad and frail idea | 14:41:41 |
| Lily Foster | Please don't seriously consider this in any capacity.... | 14:42:19 |
 cole-h | My problem with increasing the ofborg timeout on darwin is that the darwin builders are pretty slow as it is. I worry that that would cause the darwin queue to blow up (as has happened in the past even without a longer timeout).
It would be interesting to explore an "ofborgWillTimeoutOnTheseSystems" predicate, though. | 15:40:09 |
 @infinisil:matrix.org | cole-h: What about a dynamic approach: When the queue is too long, time out the longest-running job until it's short enough again | 15:58:15 |
 @asymmetric:matrix.dapp.org.uk | could we add a command to ofborg, so that one could do @ofborg set timeout 2h or something, on a case by case basis, as a github comment? this would at least be a stopgap, and would mean we don't have to "pollute" meta with ofborg-specific attributes | 15:59:46 |
| @asymmetric:matrix.dapp.org.uk | * could we add another command to ofborg, so that one could do @ofborg set timeout 2h or something, on a case by case basis, as a github comment? this would at least be a stopgap, and would mean we don't have to "pollute" meta with ofborg-specific attributes | 15:59:54 |
| @asymmetric:matrix.dapp.org.uk | * could we add another command to ofborg, so that one could do @ofborg set timeout 2h aarch64-darwin or something, on a case by case basis, as a github comment? this would at least be a stopgap, and would mean we don't have to "pollute" meta with ofborg-specific attributes | 16:00:06 |
| @asymmetric:matrix.dapp.org.uk | * could we add another command to ofborg, so that one could do @ofborg set timeout 2h aarch64-darwin or something, on a case by case basis, as a github comment on the pr of a specific package? this would at least be a stopgap, and would mean we don't have to "pollute" meta with ofborg-specific attributes | 16:00:24 |
| @asymmetric:matrix.dapp.org.uk | * could we add another command to ofborg, so that one could do @ofborg set timeout 2h polkadot aarch64-darwin or something, on a case by case basis, as a github comment on the pr of a specific package? this would at least be a stopgap, and would mean we don't have to "pollute" meta with ofborg-specific attributes | 16:00:31 |
| cole-h | In reply to @infinisil:matrix.org
cole-h: What about a dynamic approach: When the queue is too long, time out the longest-running job until it's short enough again As far as I know, RabbitMQ (what ofborg uses) is a "dumb" queue system. I don't know if we get information about the queue aside from the fact that there's a job we can take, and then communicating that we succeeded a job...
(I'm not all that familiar with RabbitMQ, however) | 16:01:32 |
| cole-h | In reply to @asymmetric:matrix.dapp.org.uk
could we add another command to ofborg, so that one could do @ofborg set timeout 2h polkadot aarch64-darwin or something, on a case by case basis, as a github comment on the pr of a specific package? this would at least be a stopgap, and would mean we don't have to "pollute" meta with ofborg-specific attributes An interesting idea, but I think the problem with that is that 1) the timeout is set in the nix-build command (so there's no way to change it once the build has started running); and 2) the machine that processes comment commands is separate from the machines that run those commands (builds, evals, etc)... | 16:03:22 |
