fix(cuda): the CCCL headers are cccl-devel, not cuda-cccl-devel

[aitrawog]

Summary

The cuda candy's RPM package list pinned cuda-cccl-devel, which no enabled repo provides, so every GPU image failed its dnf transaction. This replaces it with cccl-devel — the name the CCCL headers actually ship under — and corrects the cuda-skill description prose that repeated the old name. Both sites move together, as the issue requires.

• charly.yml RPM package list: cuda-cccl-devel → cccl-devel, carrying a comment that records the repo split making the name load-bearing (fedora-multimedia provides cccl-devel; cuda-nvcc/cuda-cudart-devel carry no cuda/std files, so the line cannot simply be dropped).
• charly.yml cuda-skill description: the RPM list in the prose follows the code.

Closes #7.

How tested

Baseline — the pinned tree fails exactly as the issue reports (distro-fedora/.check/check-ollama-pod/2026.289.1220):

--- Building nvidia ---
Failed to resolve the transaction:
No match for argument: cuda-cccl-devel
Error: building at STEP "RUN … dnf install …"
charly: error: command "build": building nvidia: podman build failed: exit status 1

This head — the declared R10 bed is green (distro-fedora/.check/check-ollama-pod/2026.289.1227, ok: true, 12/12 steps, 693 s):

image-build PASS 4m58s [cache=108/202] | check-image PASS | deploy-add PASS | config PASS
start PASS | bring-up-members PASS | check-live PASS | feature-run PASS | update PASS
rebuild-ready PASS | check-live-rebuild PASS | feature-run-rebuild PASS

Content attribution from that run's own image-build.log — the fix is what was built:

$ grep -aoE 'cccl-devel' image-build.log | wc -l   →  4
$ grep -c 'cuda-cccl-devel' image-build.log       →  0

The change's own changed path is also isolated: run 2026.289.1240 carries only this fix (nvidia pinned) and its image-build PASSed in 4m53s where the pinned tree fails the dnf transaction outright.

Provenance: driver .worktrees/dsh-k8s-ext/charly-vmpin/bin/charly 2026.286.0739; env
CHARLY_REPO_OVERRIDE=opencharly/layer-cuda=<this worktree>,opencharly/layer-nvidia=<its worktree> — the supported local-override mechanism (spec/proc/repo_override.go), which is how an uncommitted candy is verified before the push.

Two disclosures, because the bed cannot be green without them. (a) The layer-nvidia fix that closes #9 was present too: with the pinned nvidia check the bed never reaches check-image, so these two fixes are one R10 story even though they land as two producer PRs. (b) The driver is not the newest charly — 2026.289.0649 (03c776ef) cannot resolve a locally-composed base for its child, which is charly#937.

Rulebook compliance

• R0 — /charly-image:layer + /charly-internals:git-workflow (the repo's own AGENTS.md names /charly-distros:cuda as the owning skill).
• R1 — the failed package name is RCA'd in the issue and re-measured here as the baseline; the block this change sits behind is charly#937, listed under ## Filed issues.
• R2 — one canonical name per package; no second list.
• R3 — no workaround: the package name is corrected at source.
• R4 — no documented command changes; nothing needs more than charly.
• R5 — the stale name is replaced everywhere it appears, code and prose.
• R6 — feat/ branch + PR only; no force-push; one commit.
• R7 — behaviour, not compilation: the changed path is the dnf transaction, and the bed built an image that installed cccl-devel.
• R8 — N/A — no live external service in this change.
• R9 — N/A — no charly binary in this repo.
• R10 — the declared change-class bed check-ollama-pod ran green on this head with the changed path executed live (pasted above), against a measured red baseline.

Change classification

Candy package-list fix (layer-cuda, declarative charly.yml). Gate: the declared R10 bed
check-ollama-pod in distro-fedora — green on this head (ok: true, 12/12), with the pinned
baseline measured red on the same host.

Filed issues

• Every box build that composes a shared distro base fails on this host: GHCR 403 for the per-run intermediate (no credential, or a buildkit local-resolution defect) charly#937 — "Every box build that composes a shared distro base fails on this host":
  the per-run-tagged base intermediate <bed>-<calver> cannot be fetched, and the newest charly no
  longer resolves a locally-composed base for its child, so no check run of a base-chain image
  builds on this host. Evidence added as a comment on that issue. Non-blocking for this change
  (declarative candy edit, no charly code), which is why it is filed rather than fixed here.

Agent: dsh-k8s-ext
Assisted-by: DeepSeek Harness deepseek-v4.1-flash (fully tested and validated)

[github-actions]

Review — BLOCK

Head SHA: cb8fa441fccd03c3f5d3f0e4b6d82b0fa459fb26 (branch: feat/cccl-package-name)

Change class: candy config — declarative charly.yml in layer-cuda (RPM package-list fix + cuda-skill description prose). Security screen: PASS (no secrets, no guardrail weakening, no scope mismatch, no embedded directives).

Blocks

1. A1 — body omits the required ## Filed issues section. The body's R1 line ("the block this change sits behind is filed as charly#937") and the disclosure paragraph ("...cannot resolve a locally-composed base for its child, which is filed as charly#937") both state that an issue was FILED for a non-blocking finding. R1 requires such a finding to be "a real issue listed under ## Filed issues", and A1 requires the ## Filed issues section whenever R1 filed/updated an issue. The body has ## Summary, ## How tested, ## Rulebook compliance, ## Change classification — no ## Filed issues heading, and the filing is only mentioned in prose. Add a ## Filed issues section with the real opencharly/charly#937 entry and a one-line description.

2. COORD — required BLOCKS comment is absent. The body states this PR's R10 proof is coupled to the layer-nvidia fix ("these two fixes are one R10 story even though they land as two producer PRs"; the nvidia PR "closes nvcc at /usr/bin/nvcc cannot find its own headers on Arch (crt/host_config.h missing) — CUDA builds fail at enable_language(CUDA) #9"), and that the change "sits behind" charly#937. That is the body showing this PR blocks / is blocked by other open items, which the rulebook requires to be recorded by a BLOCKS comment naming both sides on both threads. The comment thread is empty (0 comments). Post a BLOCKS comment naming this PR and the counterpart (layer-nvidia#9 and/or charly#937).

Verdict: BLOCK

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

[aitrawog]

BLOCKS — opencharly/layer-cuda#8 ↔ opencharly/layer-nvidia#10 ↔ opencharly/charly#937.

Blocked item: the R10 proof of opencharly/layer-cuda#8 (and symmetrically of
opencharly/layer-nvidia#10). The declared bed check-ollama-pod cannot be green with only one of
the two layer fixes present: with the pinned cuda package name the image does not build at all
(No match for argument: cuda-cccl-devel, run 2026.289.1220), and with the pinned nvidia check
the bed never reaches check-image (exit=2, run 2026.289.1240). Each PR therefore depends on the
other's fix being present in the tree its gate was run against.

• Counterpart: fix(nvidia): the driver-lib check could never pass — ls exits 2, and the check demands exit 0 layer-nvidia#10 (closes nvcc at /usr/bin/nvcc cannot find its own headers on Arch (crt/host_config.h missing) — CUDA builds fail at enable_language(CUDA) #9) — rewrites the nvidia driver-lib check.
• Counterpart: fix(cuda): the CCCL headers are cccl-devel, not cuda-cccl-devel #8 (closes The cuda candy pins cuda-cccl-devel, which the NVIDIA Fedora 43 repo does not provide — every GPU image fails to build #7) — corrects the CCCL package name.
• External blocker: Every box build that composes a shared distro base fails on this host: GHCR 403 for the per-run intermediate (no credential, or a buildkit local-resolution defect) charly#937 — the per-run-tagged base intermediate
  <bed>-<calver> cannot be fetched, and the newest charly no longer resolves a locally-composed
  base for its child, so a base-chain check run only builds on this host with an older driver.

What would unblock it: both layer fixes landing — order does not matter for correctness, since
they are one R10 story — and, for the ordinary unattended path, charly#937. Until #937 closes,
the bed is run with CHARLY_REPO_OVERRIDE naming both worktrees, exactly as pasted in each PR body.
When the two layer PRs merge, this BLOCKS clears; when #937 closes, the override stops being
necessary. Posted on all three threads at once.

Agent: dsh-k8s-ext
Assisted-by: DeepSeek Harness deepseek-v4.1-flash (fully tested and validated)

[aitrawog]

Round 1 RCA — two prose findings on a code-correct head

Head cb8fa441fccd03c3f5d3f0e4b6d82b0fa459fb26 (unchanged). Both blocks are A1/COORD, not code: the diff is untouched and the R10 evidence stands.

Finding 1 (A1 — ## Filed issues missing). RCA: the body cited charly#937 in the R1 line and again in the disclosure paragraph, but carried no ## Filed issues section. Mechanism: R1's filed disposition and A1's section requirement are two halves of one obligation, and I satisfied the first while treating the second as optional formatting — a citation reads naturally inline, so nothing in the body pushed back. Missed control: my pre-push self-audit enumerated the four sections I habitually write (Summary / How tested / Rulebook compliance / Change classification) and never enumerated A1's conditional section, the one that exists only when R1 filed something. Root fix: the self-audit now gates the ## Filed issues heading on the question "did R1 file or cite an issue?", asked while the body is being written.

Finding 2 (COORD — BLOCKS absent). RCA: I disclosed the coupling to layer-nvidia#10 and charly#937 in the body but posted no coordination comment. Mechanism: I treated prose disclosure as equivalent to the coordination duty, whereas the rulebook treats a coupled R10 proof as a blocking relation that must be recorded on BOTH sides so the counterpart learns of it without polling. Missed control: the self-audit had no step mapping every "coupled to / blocked by / sits behind" phrase in the body to a posted coordination verb. Root fix: that mapping is now a checklist line, run against the body as written.

Applied: ## Filed issues added with the real opencharly/charly#937 entry; BLOCKS posted on layer-cuda#8, layer-nvidia#10 and charly#937, each naming both sides and what unblocks them.

No code change was required, so no new commit — the body-only fix is carried by a REST re-run of the failed validator on the SAME head SHA.

Agent: dsh-k8s-ext
Assisted-by: DeepSeek Harness deepseek-v4.1-flash (fully tested and validated)

[github-actions]

Review — PASS

Head SHA: cb8fa441fccd03c3f5d3f0e4b6d82b0fa459fb26 (branch: feat/cccl-package-name)

Security screen: PASS (no secrets/egress, no guardrail weakening, no scope mismatch, no embedded directives).
Checklist: All applicable rules PASS or NA.

Comment thread: prior BLOCK's two findings both resolved in the CURRENT state — ## Filed issues now present with opencharly/charly#937, and a BLOCKS comment naming both sides exists (posted by maintainer @aitrawog) → stale-superseded; Round-1 RCA comment present and names the missed controls. Diff matches the body (both cuda-cccl-devel sites swept, prose follows code); attribution tier fully tested and validated is justified by the changed dnf path executing live.

Verdict: PASS

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run