| 24 Sep 2025 |
 @wolfgangwalther:matrix.org | And, can we get notifications directly via freescout, too? Or do we essentially need to add all of us as forwarders as well? | 18:27:34 |
 hexa | No idea. | 18:27:52 |
 Winter | you can get notifs | 18:27:54 |
| Winter | no forwarding needed | 18:28:01 |
| 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 | not ours, moderation managesthat | 23:35:18 |
| hexa | * not ours, moderation manages that | 23:35:20 |
| hexa | #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 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 |
