| 26 Sep 2025 |
dish [Fox/It/She] | looks good to me, added to merge queue | 19:10:58 |
| 27 Sep 2025 |
| 7c6f434c joined the room. | 08:48:00 |
| 28 Sep 2025 |
| Vuks joined the room. | 12:26:30 |
hexa | was talking with Lun yesterday about building rocm flavored packages on h.n.o | 14:22:41 |
hexa | and the best idea we could come up with is a dedicated jobset release-rocm.nix with a list like release-cuda.nix, that is generated from comparing an eval with rocmSupport and one without it | 14:23:28 |
hexa | that list is too expensive to generate on every eval, but that is also not really required, it can gradually be adapted to what is needed | 14:24:02 |
hexa | the implication is that -rocm flavored package attributes can be removed in favor of config.rocmSupport or foobar.override { rocmSupport = true; } | 14:24:35 |
hexa | * the implication is that -rocm flavored package attributes can be removed in favor of just toggling config.rocmSupport or foobar.override { rocmSupport = true; } | 14:24:44 |
hexa | * the implication is that -rocm flavored package attributes can be removed in favor of just toggling config.rocmSupport or foobar.override { rocmSupport = true; } | 14:24:53 |
hexa | so the idea is unstable-rocm, release-25.11-rocm | 14:25:09 |
Vladimír Čunát | Why will these be split away? Less build shares and/or frequency of evals? | 14:28:07 |
hexa | we can also integrate them in the main jobset 🤔 | 14:46:37 |
hexa | * we can also integrate them in the main jobset 🤔 i was just not sure how to accomplish that | 14:46:45 |
hexa | because we currently eval nixpkgs once with rocmSupport = false | 14:46:52 |
hexa | and they only have pkgsRocm and aliases with overrides that enable it | 14:47:25 |
hexa | https://github.com/LunNova/nixpkgs/blob/push-kuknstozqsvo/pkgs/top-level/release-rocm.nix | 14:48:37 |
Vladimír Čunát | Plug in pkgsRocm attribute-subtree? Probably by adding the reference in our pkgs/top-level/release.nix | 14:58:22 |
Vladimír Čunát | * Plug in this pkgsRocm attribute-subtree? Probably by adding the reference in our pkgs/top-level/release.nix | 14:58:29 |
Vladimír Čunát | 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 |
Vladimír Čunát | Also visibility in regressions tackled during staging-next. | 15:03:47 |
Lun | pkgsRocm is an entire nixpkgs | 15:03:54 |
Vladimír Čunát | OK, I assumed this pkgsRocm would be just the diff mentioned in
that list is too expensive to generate on every eval, but that is also not really required, it can gradually be adapted to what is needed
Because we don't want huge amount of duplicate jobs on Hydra (even if the hashes are the same in them).
| 15:05:29 |
Vladimír Čunát | * OK, I assumed this pkgsRocm would be just that diff mentioned in
that list is too expensive to generate on every eval, but that is also not really required, it can gradually be adapted to what is needed
Because we don't want huge amount of duplicate jobs on Hydra (even if the hashes are the same in them).
| 15:05:41 |
Vladimír Čunát | 🤔 anyway, that was just a quick thought. Maybe someone will have a better suggestion. | 15:06:51 |
hexa | recursing into pkgsRocm would duplicate eval time | 15:07:42 |
hexa | * recursing into pkgsRocm would double eval time | 15:08:04 |
Vladimír Čunát | I suspect we did have a tool for evaluating just a particular subset of attributes, but I'm not sure about efficiency. | 15:08:22 |
Vladimír Čunát | Essentially, I meant to take whatever you propose for a separate jobset and plug it in. The cost shouldn't differ significantly. | 15:09:16 |
7c6f434c | Ask ROCm-interested people to maintain release-rocm.nix with things they care about (which can be sometimes linted locally, but no need to check completeness on every eval), then import it in the main release? | 15:12:56 |
Lun | If I import release-rocm's jobs into release do I need to make sure all the names end up unique or it'll break? So if release-rocm.nix is making an "openmpi" job that needs to be something else to be valid to add in release.nix and not conflict with the default openmpi | 15:29:48 |