 | OfBorg | 164 Members |
| Number of builds and evals in queue: <TBD> | 60 Servers |
| OfBorg | 164 Members |
| Number of builds and evals in queue: <TBD> | 60 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Jun 2023 | ||
 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 | 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 |
| 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:28 |
| Artturin | 2.3.16 and 2.4pre-rc1 have a difference of 3,902 commits https://github.com/NixOS/nix/compare/2.3.16...2.4pre-rc1 | 17:24:14 |
| Artturin | * fun fact 2.3.16 and 2.4pre-rc1 have a difference of 3,902 commits https://github.com/NixOS/nix/compare/2.3.16...2.4pre-rc1 | 17:26:46 |
| cole-h | 13:40 on the same commit using Nix 2.13 | 17:31:47 |
| cole-h | * 13m40s on the same commit using Nix 2.13 | 17:31:51 |
| cole-h | Err Nix 2.3 | 17:33:15 |
| cole-h | lol | 17:33:16 |
| cole-h | * 13m40s on the same commit using Nix 2.3 | 17:33:17 |
| cole-h | (coming back) using 2.15.1: | 20:59:25 |
| 8 Jul 2023 | ||
| vcunat | Hmm, so both CPU and RAM usage would be significantly worse. I thought of doing this for the tarball job instead, but the RAM requirements wouldn't most likely become a problem with the current infra. | 08:05:06 |
| vcunat | * Hmm, so both CPU and RAM usage would be significantly worse. I thought of doing this for the tarball job instead, but the RAM requirements would most likely become a problem with the current infra. | 08:05:18 |
| vcunat | The corresponding machines have only 64 GiB physical RAM. | 08:07:24 |
 sterni | In reply to @cole-h:matrix.orgWe already had path interpolation slip into master before: https://github.com/NixOS/ofborg/issues/612 | 08:55:27 |