| 2 Apr 2025 |
 Grimmauld (migrated to @grimmauld:m.grimmauld.de) | thats exactly why i am building all those packages on aarch64-linux, it just is the fastest builder | 20:56:13 |
 Gaétan Lepage | In reply to @emilazy:matrix.org
and sorry again to Gaétan Lepage for the dodgy grep :) Fair enough, I have been the culprit quite a few times in the past ! | 20:56:30 |
 Ihar Hrachyshka | yeah I was thinking it's weird that we have to pick numbers for whole nixpkgs-review run when it really depends on whether others need the machine... | 20:56:49 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | (i also hjonstly didn't expect to be able to overload the darwin machine just feeding single build jobs by hand...) | 20:56:57 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | * (i also honstly didn't expect to be able to overload the darwin machine just feeding single build jobs by hand...) | 20:57:02 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | * (i also honstly didn't expect to be able to overload the aarch64-linux machine just feeding single build jobs by hand...) | 20:57:10 |
 emily | the default is jobs = cores = nproc | 20:57:20 |
| emily | so as soon as two builds with >80 parallelizable C compiles happen it blows up | 20:57:40 |
| emily | (and it'll try to do 80 builds if it can, so very easy to go over) | 20:57:51 |
| Gaétan Lepage | The current SotA for this kind of use is ver sub-optimal | 20:57:59 |
| emily | https://github.com/NixOS/nix/pull/11143 would make this a lot less painful | 20:58:05 |
