| 11 Jan 2024 |
 Lily Foster | In reply to @elvishjerricco:matrix.org
mainly that, but also the fact that it feels a need to build a kernel for a change like this: https://github.com/NixOS/nixpkgs/pull/280296/files it may not be cached on master rn 🤷🏻♀️ | 16:15:50 |
| Lily Foster | it always rebases on master and there's sometimes rebuilds of dependencies on master | 16:16:08 |
| Lily Foster | * it always applies patch against master and there's sometimes rebuilds of dependencies on master | 16:16:19 |
 ElvishJerricco | so I guess I just asked it to build too much at once and it ran out of space in /tmp? | 16:16:29 |
| ElvishJerricco | looks like kernels are not currently cached on master, and it was trying to build two of them at once to run the zfs tests | 16:18:36 |
| Lily Foster | In reply to @elvishjerricco:matrix.org
so I guess I just asked it to build too much at once and it ran out of space in /tmp? well there were kernel releases yesterday and those get merged straight to master, so i can believe that there would be kernel rebuilds on master right now and that ofborg ran out of space trying to build those so it could build the actual test | 16:18:54 |
| ElvishJerricco | I guess I'll build the tests myself then | 16:19:33 |
 ris_ | could ofborg be failing on https://github.com/NixOS/nixpkgs/pull/274089 because because it's trying to evaluate the packages in (the new) pkgsExtraHardening? | 20:09:55 |
| ris_ | * could ofborg be failing on https://github.com/NixOS/nixpkgs/pull/274089 because because it's trying to evaluate the packages in (the new) pkgsExtraHardening? | 20:10:12 |
| ris_ | * could ofborg be failing on https://github.com/NixOS/nixpkgs/pull/274089 because it's trying to evaluate the packages in (the new) pkgsExtraHardening? | 20:10:22 |
 cole-h | I doubt it. The eval failure is because the staging commit your PR is built off of was busted. If you rebase, it should work (or at least get further):
error: evaluation aborted with the following error message: 'lib.customisation.callPackageWith: Function called without required argument "filemagic" at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-1/pkgs/development/python-modules/jira/default.nix:5'
| 20:11:28 |
| Lily Foster | In reply to @r_i_s:matrix.org
could ofborg be failing on https://github.com/NixOS/nixpkgs/pull/274089 because because it's trying to evaluate the packages in (the new) pkgsExtraHardening? possibly. on a quick glance on mobile i see the ofborg-eval failure link which shows eval output says this though: Function called without required argument "filemagic"
| 20:11:36 |
| Lily Foster | yeah what cole said (i typed too slow 😅l | 20:11:57 |
| Lily Foster | * yeah what cole said (i typed too slow 😅) | 20:12:00 |
| Lily Foster | In reply to @cole-h:matrix.org
I doubt it. The eval failure is because the staging commit your PR is built off of was busted. If you rebase, it should work (or at least get further):
error: evaluation aborted with the following error message: 'lib.customisation.callPackageWith: Function called without required argument "filemagic" at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-1/pkgs/development/python-modules/jira/default.nix:5'
i mean it merged onto base branch before doing evals, so staging must have been busted at that anyway? they should just need to retrigger eval rather than rebasing | 20:12:58 |
| Lily Foster | * i mean it merges onto base branch before doing evals, so staging must have been busted at that anyway? they should just need to retrigger eval rather than rebasing | 20:13:04 |
| Lily Foster | * i mean it merges onto base branch before doing evals, so staging must have been busted at that time anyway? they should just need to retrigger eval rather than rebasing | 20:13:11 |
| 15 Jan 2024 |
 @adam:robins.wtf | how can we speed up eval and aarch64-darwin builders? can we throw money at these problems? | 13:45:02 |
| Lily Foster | In reply to @adam:robins.wtf
how can we speed up eval and aarch64-darwin builders? can we throw money at these problems? money can to an extent probably be thrown at the problem. really our eval shouldn't be so expensive, but if we had the money, we could still theoretically just get more evaluators/x86_64-linux builders (they are colocated) and more aarch64-darwin builders for short-term and have it be better (but our eval compute cost has been going up a lot the last year or so, and it's not helped by nix performance regressing in both eval time and memory pretty much every release iirc...) | 13:56:53 |
| @adam:robins.wtf | honestly i think the aarch64-darwin builders is the bigger problem. | 13:58:04 |
| @adam:robins.wtf | 12+ hours just to get time on an aarch64-darwin builder is absurd and can only hurt the support of this platform as people will merge without waiting | 14:00:00 |
| @adam:robins.wtf | especially given that x86_64-darwin, a dying platform, is competing in a much more reasonable amount of time | 14:01:21 |
| @adam:robins.wtf | * especially given that x86_64-darwin, a dying platform, is completing in a much more reasonable amount of time | 14:01:33 |
| Lily Foster | idk how much the macstadium aarch64-darwin builders are now, but tbh we could probably do what we did for hydra and switch our x86_64-darwin builders to aarch64-darwin and just use rosetta | 14:02:01 |
| Lily Foster | In reply to @lily:lily.flowers
idk how much the macstadium aarch64-darwin builders are now, but tbh we could probably do what we did for hydra and switch our x86_64-darwin builders to aarch64-darwin and just use rosetta thoughts on this @[cole-h]? | 14:02:38 |
| @adam:robins.wtf | i'd be willing to contribute some money directly towards better aarch64-darwin resources. maybe not enough to fully fund expansion, but i'm willing to try and raise funds from others too | 14:05:11 |
| Lily Foster | In reply to @adam:robins.wtf
i'd be willing to contribute some money directly towards better aarch64-darwin resources. maybe not enough to fully fund expansion, but i'm willing to try and raise funds from others too well tbh i'm thinking if the cost difference isn't that much, we can probably just have 6 aarch64-darwin/rosetta instead of 4 x86_64 + 2 aarch64. but depending on how the x86_64 builders are performing it could be a bit if a performance hit. however given they are mostly idle and the aarch64 queue is mostly behind, i think it may come out in our favor | 14:08:13 |
| Lily Foster | * well tbh i'm thinking if the cost difference isn't that much, we can probably just have 6 aarch64-darwin/rosetta instead of 4 x86_64 + 2 aarch64. but depending on how the x86_64 builders are performing it could be a bit of a performance hit. however given they are mostly idle and the aarch64 queue is mostly behind, i think it may come out in our favor | 14:08:26 |
| Lily Foster | if it's not enough, we can probably look at funding more builders from there | 14:08:47 |
| @adam:robins.wtf | i've found rosetta performance to be pretty good | 14:08:54 |
