| 28 Sep 2025 |
 hexa (signing key rotation when) | so the idea is unstable-rocm, release-25.11-rocm | 14:25:09 |
 vcunat | Why will these be split away? Less build shares and/or frequency of evals? | 14:28:07 |
| hexa (signing key rotation when) | we can also integrate them in the main jobset 🤔 | 14:46:37 |
| hexa (signing key rotation when) | * we can also integrate them in the main jobset 🤔 i was just not sure how to accomplish that | 14:46:45 |
| hexa (signing key rotation when) | because we currently eval nixpkgs once with rocmSupport = false | 14:46:52 |
| hexa (signing key rotation when) | and they only have pkgsRocm and aliases with overrides that enable it | 14:47:25 |
| hexa (signing key rotation when) | https://github.com/LunNova/nixpkgs/blob/push-kuknstozqsvo/pkgs/top-level/release-rocm.nix | 14:48:37 |
| vcunat | Plug in pkgsRocm attribute-subtree? Probably by adding the reference in our pkgs/top-level/release.nix | 14:58:22 |
| vcunat | * Plug in this pkgsRocm attribute-subtree? Probably by adding the reference in our pkgs/top-level/release.nix | 14:58:29 |
| vcunat | I mean, if we don't plan to save build resources significantly compared to inclusion, I think it's better to keep the advantages of inclusion:
- eval and channel sync. (i.e. you'll only need to wait for channels and not also coordinate with an additional jobset)
- accounting this in rebuild estimates on GitHub PRs
| 15:03:12 |
