| 25 Sep 2025 |
 Lun | Can someone please update #ROCm:nixos.org 's title to be NixOS ROCm to match #cuda:nixos.org ? | 23:23:58 |
 hexa (signing key rotation when) | not ours, moderation managesthat | 23:35:18 |
| hexa (signing key rotation when) | * not ours, moderation manages that | 23:35:20 |
| hexa (signing key rotation when) | #matrix-suggestions:nixos.org | 23:36:02 |
| 26 Sep 2025 |
 Mic92 | https://github.com/NixOS/nixos-wiki-infra/pull/310 Hacked some wikimedia extension together that should allow us to put the wiki behind fastly | 15:49:59 |
 dgrig | https://github.com/NixOS/nixpkgs/pull/446387 if anyone wants to review the package and module for https://github.com/NixOS/infra/issues/853 | 16:08:26 |
 dish [Fox/It/She] | looks good to me, added to merge queue | 19:10:58 |
| 27 Sep 2025 |
|  @7c6f434c:nitro.chat joined the room. | 08:48:00 |
| 28 Sep 2025 |
|  Vuks joined the room. | 12:26:30 |
| hexa (signing key rotation when) | was talking with Lun yesterday about building rocm flavored packages on h.n.o | 14:22:41 |
| hexa (signing key rotation when) | 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 (signing key rotation when) | 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 (signing key rotation when) | 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 (signing key rotation when) | * 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 (signing key rotation when) | * 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 (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 |
| vcunat | Also visibility in regressions tackled during staging-next. | 15:03:47 |
| Lun | pkgsRocm is an entire nixpkgs | 15:03:54 |
| vcunat | 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 |
| vcunat | * 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 |
| vcunat | 🤔 anyway, that was just a quick thought. Maybe someone will have a better suggestion. | 15:06:51 |
