Repository navigation
Build Linux Wheels (x86): rocm10.1 leg fails — "No matching distribution found for torch" (nightly ROCm 10.1 wheels missing from index) #5003
Description
Commits affected: b4dcda49cb54ed9bf14de14df61bac684ca7a787
Run: https://github.com/pytorch/ao/actions/runs/38818567230
Summary
The rocm10.1 wheel-build leg fails because PyTorch's nightly ROCm 10.1 index serves no torch wheels, so pip install torch cannot resolve a candidate. This is a dependency-availability problem in the upstream nightly channel, not a code regression in the triggering commit.
Failure details
- Failed job(s) (one root cause, two cascading jobs):
build / build-manywheel-py3_10-rocm10_1— step Install torch dependency (exit code 1).build / upload / upload-manywheel-py3_10-rocm10_1— step Download the artifact (cascade: no wheel was produced).
- Representative error (build job):
+ conda run --no-capture-output -p /__w/_temp/conda_environment_38818567230 \ pip install torch --pre --index-url https://download.pytorch.org/whl/nightly/rocm10.1 ERROR: Could not find a version that satisfies the requirement torch (from versions: none) ERROR: No matching distribution found for torch Looking in indexes: https://download.pytorch.org/whl/nightly/rocm10.1 - Cascade error (upload job):
##[error]Unable to download artifact(s): Artifact not found for name: pytorch_ao__3.10_rocm10.1_x86_64 - Contrast: the sibling
rocm10.0leg installedtorch-2.15.0.dev20260923+rocm10.0from.../whl/nightly/rocm10.0without issue. All CPU, CUDA 13.0/13.2/13.4, and XPU legs passed.
Root cause
The build matrix includes a rocm10.1 entry whose install command points at https://download.pytorch.org/whl/nightly/rocm10.1. pip reads that index but finds zero torch candidates (from versions: none), i.e. no nightly torch wheels have been published for ROCm 10.1 yet (the rocm10.0 index, by contrast, is populated). The build therefore cannot install its torch dependency, and the downstream upload job fails only because the build produced no artifact to download.
The triggering commit b4dcda4 ("[pat] Add opt-in global group-count score correction", #4983) is a pure quantization-code change and does not touch the build matrix, ROCm configuration, or the torch install logic. The failure is driven entirely by the state of the external nightly package index.
Note: the runner emitted a generic line stating "This is a script/workflow error, not an infrastructure issue." That is a canned runner message and is contradicted by the actual evidence — the empty upstream rocm10.1 index is an environment/dependency-availability condition, not a defect in this repo's code or the triggering commit.
Classification
infra failure — a missing/unpublished upstream dependency (no nightly torch wheels on the ROCm 10.1 index) external to the repository and unrelated to the triggering commit. It is deterministic (so not a per-run flaky test) and not a code regression (the changed commit does not touch build/ROCm logic, and the parallel ROCm 10.0 leg succeeds).
Suggested fix
- Short term: re-run once PyTorch nightly publishes ROCm 10.1
torchwheels, or temporarily drop/disable therocm10.1matrix entry until upstream wheels exist (mirroring howrocm10.0is handled). - Medium term: gate ROCm matrix versions on wheel availability so a newly-added ROCm version is only enabled after the corresponding nightly index is populated, to avoid redundant red builds on
main. - The upload-leg failure needs no separate action — it resolves automatically once the build leg can install torch and produce the artifact.
Activity
github-actions commentedon Oct 15, 2026
b4dcda49cb54ed9bf14de14df61bac684ca7a787) — https://github.com/pytorch/ao/actions/runs/38818566659github-actions commentedon Oct 15, 2026
Recurs on commit
7b0382e13cb0184010c9395fed6f0218741c627b— Run: https://github.com/pytorch/ao/actions/runs/38819718512Matches the existing diagnosis exactly. The
build / build-manywheel-py3_10-rocm10_1leg fails at the Install torch dependency step:and
build / upload / upload-manywheel-py3_10-rocm10_1cascades withArtifact not found for name: pytorch_ao__3.10_rocm10.1_x86_64. All other legs (CPU, CUDA 13.0/13.2/13.4, ROCm 10.0, XPU) are unaffected.Still an infra/upstream dependency-availability issue: no nightly
torchwheels published on the ROCm 10.1 index. The triggering commit ([pat] Add direct projected-weight optimization mode, #4984) is a quantization-code change and does not touch the build matrix or ROCm config. No new diagnosis needed; this confirms the failure is persistent onmainuntil upstream ROCm 10.1 nightlies are published (or the matrix entry is gated/disabled).Note: the runner's canned line "This is a script/workflow error, not an infrastructure issue." is contradicted by the evidence — the empty upstream index is an environment condition, not a repo code defect.
github-actions commentedon Oct 15, 2026
7b0382e13cb0184010c9395fed6f0218741c627b) — https://github.com/pytorch/ao/actions/runs/38819718595github-actions commentedon Oct 15, 2026
7b0382e13cb0184010c9395fed6f0218741c627b) — https://github.com/pytorch/ao/actions/runs/38819718193github-actions commentedon Oct 15, 2026
Recurred on
mainat commitaa2521284b3beb7d35c1154b145eba694f390220("[pat] Add coupled shared-axis pruning", #4985).Run: https://github.com/pytorch/ao/actions/runs/38821023471
Same root cause as this issue's diagnosis — matches exactly:
build / build-manywheel-py3_10-rocm10_1fails at the torch-install step:build / upload / upload-manywheel-py3_10-rocm10_1cascades:Unable to download artifact(s): Artifact not found for name: pytorch_ao__3.10_rocm10.1_x86_64.The nightly ROCm 10.1 index still serves no
torchwheels, so the build cannot resolve its dependency. The triggering commit touches only quantization code (shared-axis pruning) and does not modify the build matrix, ROCm config, or torch-install logic — consistent with an unpopulated upstream index rather than a code regression. (The runner's canned "script/workflow error, not an infrastructure issue" line is contradicted by the empty upstream index.)Still an infra failure; no new action beyond the existing suggestions (re-run once the rocm10.1 nightly index is populated, or gate the rocm10.1 matrix entry on wheel availability).
github-actions commentedon Oct 15, 2026
7b0382e13cb0184010c9395fed6f0218741c627b) — https://github.com/pytorch/ao/actions/runs/38819718595github-actions commentedon Oct 15, 2026
aa2521284b3beb7d35c1154b145eba694f390220) — https://github.com/pytorch/ao/actions/runs/38821023076github-actions commentedon Oct 15, 2026
Recurrence on commit
5d763d6e0d07a97d164295431d8dfa64208caa1b("[pat] Accelerate coupled pruning for sharded DTensors", #4986).Run: https://github.com/pytorch/ao/actions/runs/38822682369
Same root cause as this issue, matching the existing diagnosis exactly:
build / build-manywheel-py3_10-rocm10_1fails at the Install torch dependency step:build / upload / upload-manywheel-py3_10-rocm10_1cascades:Unable to download artifact(s): Artifact not found for name: pytorch_ao__3.10_rocm10.1_x86_64.As before, the runner prints the canned line "This is a script/workflow error, not an infrastructure issue" — contradicted by the evidence: the upstream nightly ROCm 10.1 index still has zero
torchwheels. The triggering commit is a quantization/pruning change (torchao/) and does not touch the build matrix, ROCm config, or torch-install logic. Still an infra failure (missing upstream dependency), not a regression in this commit. The ROCm 10.1 nightly index remains unpopulated days after this was first filed.github-actions commentedon Oct 15, 2026
5d763d6e0d07a97d164295431d8dfa64208caa1b) — https://github.com/pytorch/ao/actions/runs/38822682048github-actions commentedon Oct 16, 2026
Recurs on
mainat commit861156873fdc084c03be6e99512312a6e3cb0909(run https://github.com/pytorch/ao/actions/runs/38945305724).The
build / build-manywheel-py3_10-rocm10_1leg fails identically to the diagnosis in this issue —pip install torch --pre --index-url https://download.pytorch.org/whl/nightly/rocm10.1returnsERROR: Could not find a version that satisfies the requirement torch (from versions: none)/No matching distribution found for torch, i.e. the upstream nightly ROCm 10.1 index still has notorchwheels. Theupload-manywheel-py3_10-rocm10_1job fails only as a cascade (artifact not produced). Still infra/dependency-availability, unrelated to the triggering commit (a qnn_test numerics backout that touches no build/ROCm logic).Additional note for this run (NOT the same root cause): the
build / build-manywheel-py3_10-xpuleg also failed, but with a transient SIGBUS (exit 128) duringpip install torchwhile downloadingintel-openmp, withupload-manywheel-py3_10-xpucascading. This was leg-specific (the rocm leg kept running and hit its own error ~2 min later, so it was not a run-level cancel) and looks like a one-off infra/bus-error blip rather than a reproducible failure — likely clears on re-run. Flagging it here rather than opening a separate issue; worth a re-run to confirm it's transient.github-actions commentedon Oct 16, 2026
861156873fdc084c03be6e99512312a6e3cb0909) — https://github.com/pytorch/ao/actions/runs/38945305156