| 21 Jun 2023 |
 hexa | nope, it was that quick | 23:57:50 |
| 24 Jun 2023 |
|  kadawee joined the room. | 15:59:36 |
| 25 Jun 2023 |
|  @rasmus:rend.al left the room. | 13:56:35 |
| 26 Jun 2023 |
 trofi | ofborg started failing with internal errors somewhat frequently: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+label%3Aofborg-internal-error | 08:49:00 |
 K900 (deprecated) | Github is having a moment again I think | 08:52:01 |
| K900 (deprecated) | Some pages are barely loading form e | 08:52:08 |
| K900 (deprecated) | * Some pages are barely loading for me | 08:52:10 |
| 28 Jun 2023 |
| trofi | In https://github.com/NixOS/nixpkgs/pull/239881 running @ofborg eval was enough to get rid of ofborg-internal-error. Is it intentional that internal error label does not get removed automatically? | 07:02:31 |
| trofi | * In https://github.com/NixOS/nixpkgs/pull/239881 running @ofborg eval was enough to get rid of ofborg-internal-error condition (but not label). Is it intentional that internal error label does not get removed automatically? | 07:02:47 |
 Artturin | In reply to @trofi:matrix.org
In https://github.com/NixOS/nixpkgs/pull/239881 running @ofborg eval was enough to get rid of ofborg-internal-error condition (but not label). Is it intentional that internal error label does not get removed automatically? Yes, so a ofborg maintainer can check it | 07:04:54 |
 cole-h | (Which, to be fair, I've been bad about recently... but also to be fair, usually it's GH's API and not ofborg) | 13:33:00 |
 figsoda | tbh I've just been removing the label, should I keep the label and not remove it? | 13:37:28 |
| cole-h | It doesn't affect anything (other than telling you you'll want to @ofborg eval again), so if you wouldn't mind, please leave it :) | 13:38:01 |
| cole-h | While I don't do it often, I do check the logs every once in a while to make sure they didn't change the API out from under us (hasn't happened yet, but) | 13:38:27 |
| 7 Jul 2023 |
 vcunat | A quick question, in case you know easily: do we control what version+features of Nix are used in the evals? | 16:20:07 |
| cole-h | I think so? | 16:20:32 |
| cole-h | goes to check | 16:20:42 |
| vcunat | I expect we want to use 2.3.x with just default features? (nixpkgs/lib/minver.nix) | 16:21:13 |
| vcunat | It's nothing urgent. It just came up in NixOS release-managing discussion. | 16:23:03 |
| cole-h | Maybe... | 16:23:10 |
| cole-h | Is there a case that would have been caught with 2.3 that wasn't? | 16:23:56 |
| vcunat | I'm not aware of any, but I expect it won't be hard to create some artificial one. | 16:24:41 |
| Artturin | remember that 2.3 may have worse performance than 2.4+ | 17:08:41 |
| Artturin | likely has | 17:08:53 |
| cole-h | Which is especially important when evals take 10 minutes on recent masters... | 17:09:08 |
| cole-h | So I'd be hesitant to even entertain the idea of pinning to 2.3 until I see an actual, non-contrived / non-forced issue caused by not using the Nixpkgs minver | 17:09:59 |
| vcunat | We should probably measure the difference in performance on the particular expensive eval ofBorg is doing. Otherwise I don't trust it really. | 17:12:05 |
| cole-h | I'll do so. On 5dd0190da9b5aecb5238c1bea1ebaa77f15c6a45, here are the time stats:
822.67user 14.59system 10:02.16elapsed 139%CPU (0avgtext+0avgdata 58247012maxresident)k
72088inputs+0outputs (0major+14564664minor)pagefaults 0swaps
| 17:13:06 |
| cole-h | Running 2.4pre20210810_a6ba313 (not an ofborg machine, but same type) | 17:14:08 |
| cole-h | (I already bisected the largest increase in eval time to 4af22aab8e239b1ca28da851755c6da1a35fc91b, which made the leap from ~4-5m to like 7m, but not yet the remaining increase to 10m) | 17:17:20 |
