!RROtHmAaQIkiJzJZZE:nixos.org

NixOS Infrastructure

386 Members
Next Infra call: 2024-07-11, 18:00 CEST (UTC+2) | Infra operational issues backlog: https://github.com/orgs/NixOS/projects/52 | See #infra-alerts:nixos.org for real time alerts from Prometheus.120 Servers

Load older messages


SenderMessageTime
26 Sep 2025
@pyrox:pyrox.devdish [Fox/It/She]looks good to me, added to merge queue19:10:58
27 Sep 2025
@7c6f434c:nitro.chat7c6f434c joined the room.08:48:00
28 Sep 2025
@vuks:matrix.orgVuks joined the room.12:26:30
@hexa:lossy.networkhexa was talking with Lun yesterday about building rocm flavored packages on h.n.o 14:22:41
@hexa:lossy.networkhexaand 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 it14:23:28
@hexa:lossy.networkhexathat list is too expensive to generate on every eval, but that is also not really required, it can gradually be adapted to what is needed14:24:02
@hexa:lossy.networkhexathe implication is that -rocm flavored package attributes can be removed in favor of config.rocmSupport or foobar.override { rocmSupport = true; }14:24:35
@hexa:lossy.networkhexa* 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:lossy.networkhexa * 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:lossy.networkhexa so the idea is unstable-rocm, release-25.11-rocm 14:25:09
@vcunat:matrix.orgVladimír ČunátWhy will these be split away? Less build shares and/or frequency of evals?14:28:07
@hexa:lossy.networkhexawe can also integrate them in the main jobset 🤔14:46:37
@hexa:lossy.networkhexa* we can also integrate them in the main jobset 🤔 i was just not sure how to accomplish that14:46:45
@hexa:lossy.networkhexabecause we currently eval nixpkgs once with rocmSupport = false14:46:52
@hexa:lossy.networkhexaand they only have pkgsRocm and aliases with overrides that enable it14:47:25
@hexa:lossy.networkhexahttps://github.com/LunNova/nixpkgs/blob/push-kuknstozqsvo/pkgs/top-level/release-rocm.nix14:48:37
@vcunat:matrix.orgVladimír Čunát Plug in pkgsRocm attribute-subtree? Probably by adding the reference in our pkgs/top-level/release.nix 14:58:22
@vcunat:matrix.orgVladimír Čunát * Plug in this pkgsRocm attribute-subtree? Probably by adding the reference in our pkgs/top-level/release.nix 14:58:29
@vcunat:matrix.orgVladimí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
@vcunat:matrix.orgVladimír ČunátAlso visibility in regressions tackled during staging-next.15:03:47
@lt1379:matrix.orgLunpkgsRocm is an entire nixpkgs15:03:54
@vcunat:matrix.orgVladimí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
@vcunat:matrix.orgVladimí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
@vcunat:matrix.orgVladimír Čunát🤔 anyway, that was just a quick thought. Maybe someone will have a better suggestion.15:06:51
@hexa:lossy.networkhexarecursing into pkgsRocm would duplicate eval time15:07:42
@hexa:lossy.networkhexa* recursing into pkgsRocm would double eval time15:08:04
@vcunat:matrix.orgVladimír ČunátI suspect we did have a tool for evaluating just a particular subset of attributes, but I'm not sure about efficiency.15:08:22
@vcunat:matrix.orgVladimír ČunátEssentially, 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:nitro.chat7c6f434cAsk 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
@lt1379:matrix.orgLunIf 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 openmpi15:29:48

Show newer messages


Back to Room ListRoom Version: 6