Update (2026-08-06): the root cause is not the S3/zypper encoding behaviour described below.
rocm-libraries' therock-multi-arch-ci.yml never passes rocm_rpm_package_version, so the ||
fallback in multi_arch_ci_linux.yml puts the wheel version (10.1.0.dev0+<sha>) into the RPM
filenames instead of the intended 10.1.0~<date>g<sha>. TheRock's own CI passes all four install
lanes. See the discussion below; the original text is kept for the reproduction details.
Summary
Linux::release / Test RPM Install - sles16 fails on every PR and has done so since at least
2026-06-20. All 367 RPMs return HTTP 404 under zypper, while rhel8 / rhel10 / ubuntu2404 pass on
the same run. This makes Multi-Arch CI Summary red repo-wide and forces manual overrides
(most recently ROCm/rocm-libraries#10180, which is blocking SGLang).
Root cause
RPM filenames embed a + from the dev version 10.1.0.dev0+<sha>. The S3 REST endpoint decodes a
literal + in the URL path as a space, so the object is only reachable when it is sent as %2B.
B=https://therock-ci-artifacts-external.s3.amazonaws.com/ROCm-rocm-libraries/31063962255-linux/packages/rpm/x86_64
F='amdrocm-10.1.0.dev0+84be6e7935adc8647edbc2f74fdd71bd1a9730c9-31063962255.x86_64.rpm'
curl -o /dev/null -w '%{http_code}\n' "$B/$F" # 404 literal '+'
curl -o /dev/null -w '%{http_code}\n' "$B/${F//+/%2B}" # 200 '%2B'
curl -o /dev/null -w '%{http_code}\n' "$B/${F//+/%20}" # 404 space
The stored key does contain a literal +, so the upload itself is fine:
<Key>.../packages/rpm/x86_64/amdrocm-10.1.0.dev0+84be6e79...-31063962255.x86_64.rpm</Key>
dnf and apt percent-encode + and succeed; zypper sends the literal + and 404s on every
package. Repo metadata (repomd.xml, primary.xml.gz) downloads fine, which is why zypper gets as
far as resolving package names before failing.
Failing log excerpt:
Preloading: amdrocm-ck10.1-...x86_64.rpm [The requested URL returned error: 404]
Installation has completed with error.
[FAIL] Failed to install RPM packages (exit code: 4)
[FAIL] Step 1 (repo setup and install) failed.
Evidence
Reproduced identically against a second run's artifacts (31099145995), so it is not a one-off
upload problem. sles16 is red on every unrelated run sampled, while the other three OS lanes pass:
| Run |
rhel8 |
rhel10 |
ubuntu2404 |
sles16 |
| 31099145995 |
pass |
pass |
pass |
fail |
| 31096739996 |
pass |
pass |
pass |
fail |
| 31094598762 |
pass |
pass |
pass |
fail |
| 31092050233 |
pass |
pass |
pass |
fail |
| 31058200317 (Aug 5) |
pass |
pass |
pass |
fail |
| 30179912967 (Jul 25) |
pass |
pass |
pass |
fail |
| 27865212542 (Jun 20) |
pass |
— |
pass |
fail |
Example failing job:
https://github.com/ROCm/rocm-libraries/actions/runs/31063962255/job/92660497427
Impact
- Every rocm-libraries PR needs a manual override to merge.
- Likely also affects real SLES users installing from any S3-backed ROCm repo, not just CI.
Possible fixes
- Drop
+ from the package version (e.g. 10.1.0.dev0.<sha> or ~<sha>). No client needs to
encode anything. Changes package NEVRA, so it needs packaging-owner sign-off.
- Percent-encode
+ as %2B in the repodata <location href> after createrepo_c
(build_tools/packaging/linux/upload_package_repo.py). Needs validation that libzypp does not
unescape it back to a literal +.
- Make the sles16 test download RPMs locally then
zypper install ./*.rpm. Fixes CI only, not
end users.
I could not validate options 2 and 3 locally — pulling registry.suse.com/bci/bci-base:16.0 is
blocked by a TLS-intercepting proxy on my network.
Summary
Linux::release / Test RPM Install - sles16fails on every PR and has done so since at least2026-06-20. All 367 RPMs return HTTP 404 under zypper, while rhel8 / rhel10 / ubuntu2404 pass on
the same run. This makes
Multi-Arch CI Summaryred repo-wide and forces manual overrides(most recently ROCm/rocm-libraries#10180, which is blocking SGLang).
Root cause
RPM filenames embed a
+from the dev version10.1.0.dev0+<sha>. The S3 REST endpoint decodes aliteral
+in the URL path as a space, so the object is only reachable when it is sent as%2B.The stored key does contain a literal
+, so the upload itself is fine:dnfandaptpercent-encode+and succeed;zyppersends the literal+and 404s on everypackage. Repo metadata (
repomd.xml,primary.xml.gz) downloads fine, which is why zypper gets asfar as resolving package names before failing.
Failing log excerpt:
Evidence
Reproduced identically against a second run's artifacts (31099145995), so it is not a one-off
upload problem. sles16 is red on every unrelated run sampled, while the other three OS lanes pass:
Example failing job:
https://github.com/ROCm/rocm-libraries/actions/runs/31063962255/job/92660497427
Impact
Possible fixes
+from the package version (e.g.10.1.0.dev0.<sha>or~<sha>). No client needs toencode anything. Changes package NEVRA, so it needs packaging-owner sign-off.
+as%2Bin the repodata<location href>aftercreaterepo_c(
build_tools/packaging/linux/upload_package_repo.py). Needs validation that libzypp does notunescape it back to a literal
+.zypper install ./*.rpm. Fixes CI only, notend users.
I could not validate options 2 and 3 locally — pulling
registry.suse.com/bci/bci-base:16.0isblocked by a TLS-intercepting proxy on my network.