wai-quantum: the members certified on the Mac Studio run on the Studio #537
2026-10-29
wai-quantum: the members certified on the Mac Studio run on the Studio
All checks were successful
wai-quantum matrix-extension member / does this change touch it (pull_request) Successful in 8s
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 11s
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
wai-quantum Metal member / does this change touch it (pull_request) Successful in 11s
wai-quantum matrix-extension member / member · matrix extension, emulated (aarch64 Linux) (pull_request) Successful in 25s
wai-quantum Metal member / member · Metal absent (linux) (pull_request) Successful in 52s
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 2m44s
wai-quantum Metal member / member · Metal (macos) (pull_request) Successful in 7m34s
wai-quantum matrix-extension member / member · matrix extension absent (macos) (pull_request) Successful in 10m11s
Three new runners joined `macos` and `linux` on 2026-10-29: an M5 Max and an M4 Max (both with the matrix extension, and other GPUs), and the iMac's Linux VM. #533's run put two Studio-certified members on them: - `member · Metal (macos)`, pinned to the Studio's gpu-msl-1009, ran on the M5 Max: every c0-c5 test failed, the device undeclared. - `member · matrix extension absent (macos)` ran on an M4 Max: "this runner has SME". Both now ask for `macos-m3-ultra`, a label the Studio's runner carries beside `macos`. The fleet's other macOS jobs stay on `macos`. Members for the laptops' GPUs and their matrix extension are for a run on them to declare. (The third failure, the riscv64 vector member on the iMac's VM, was the VM lacking a riscv64 binfmt handler. That is fixed on the host: qemu-user 8.2.2's handlers are installed there, as on jetson-hub.) Co-Authored-By: Claude Opus 5.5 <[email protected]>