[luhenry]

• Package: renkin
• Version: 1.0.0
• Source: https://github.com/kent-tokyo/renkin
• Docs: https://github.com/kent-tokyo/renkin

Compiles a Rust retrosynthesis route auditor/planner with PyO3 Python bindings. Upstream publishes no riscv64 wheel.

Mirrors upstream's release.yml build-wheels job (maturin, --features python), narrowed to Linux manylinux.

Differs from upstream

• Rust toolchain installed in-container via rustup - upstream's GitHub runners ship one already.

Testing

• python -c smoke test mirrors upstream's own python-smoke CI job: imports renkin, calls find_routes/capabilities and checks the returned version.

License: OK, MIT, nothing vendored.

Built on cp312; dependency tree (chematic, pyo3, rayon, flate2, serde) is pure Rust with no -sys/C bindings, verified with cargo metadata --filter-platform riscv64gc-unknown-linux-gnu.

[luhenry]

CI triage for this PR: not a code/config defect in build-renkin.yml.

What happened: the latest run (38382123320, head ff7a03c) shows all four Build renkin 1.0.0 cp3xx-manylinux_riscv64 jobs with conclusion cancelled, publish skipped, and the three non-build checks (check_commit_messages/check_packages_yaml/check_patches) green. Each build job's created_at/started_at/completed_at span exactly 24h00m00s (2026-10-13T10:15:46Z -> 2026-10-14T10:15:46Z), and the job objects carry no runner_id/runner_name/steps at all (log fetch 404s). That's the signature of a job that sat queued the whole time and never got assigned an ubuntu-24.04-riscv runner - GitHub auto-cancels a job queued >24h, distinct from a hung/failed build or a maintainer-initiated cancel.

Root cause: shared self-hosted riscv64 runner-pool contention, not anything specific to renkin. The earlier run (38381036830) was cancelled normally within 9 minutes by the concurrency group when the Merge branch 'main' into renkin commit was pushed - that's expected. The second run then queued for the full 24h with zero pickup; right now there are 10+ other build-*.yml riscv64 runs in_progress across the open-PR backlog competing for the same handful of runners, matching the documented pattern in skills/python-project-porting/references/gotchas/pytest-config-servers-and-selection.md ("the handful of ubuntu-24.04-riscv runners every other open port is queued on").

What I checked and ruled out:

• runs-on: ubuntu-24.04-riscv label matches exactly what every other build-*.yml in the repo uses - no typo.
• setup job (runs on ubuntu-latest) completed successfully in seconds, so the workflow's own YAML, matrix selection, and the reusable _setup.yml call are fine.
• No patches/renkin/ dir exists or is needed yet - the build never got far enough to need one, and the Rust/pyo3 dependency tree here is pure-Rust per the PR description.

Proposed next step: no source or workflow change to make here. Once runner-pool pressure from the backlog eases, re-dispatching this workflow (or a maintainer rerun-failed-jobs / workflow_dispatch) should let the build actually execute; I'm intentionally not pushing a rerun myself right now since the pool is visibly saturated and that would just re-queue behind the same contention. Flagging for a maintainer call rather than guessing at a fix for a problem that isn't in this PR's code.