Conversation
mediapipe publishes no sdist and tags no release; PyPI's 1.0.1 wheels come from commit 02d83cb8, where mediapipe/version.bzl reads 1.0.1. The build mirrors upstream's Dockerfile.manylinux_2_28_x86_64 recipe: a static core+imgproc OpenCV 4.10, then setup.py bdist_wheel driving bazel to build //mediapipe/tasks/c:libmediapipe.so with the GPU disabled. bazel publishes no riscv64 binary, so it is bootstrapped from the dist archive in a cached job, and the wheel is retagged py3-none to match the interpreter-agnostic artifact upstream publishes.
luhenry
added a commit
that referenced
this pull request
Sep 19, 2026
Restores skills/python-project-porting/references/{gotchas-index.md,
gotchas/compiled-vs-pure-detection.md} to main's current content. The
gotcha this PR had added (381, the py3-none-<platform> explicit retag
case) collided with a gotcha number another agent had already taken on
main in the meantime - it'll be re-added on main directly with a fresh
number.
…is branch no longer touches
luhenry
added a commit
that referenced
this pull request
Sep 19, 2026
Originally added inside PR #2104 (mediapipe), which is not allowed to touch skills/ - removed from that branch and landed here instead, renumbered from its original 381 (already taken by other concurrent work by the time this was caught).
Contributor
|
luhenry
added a commit
that referenced
this pull request
Sep 19, 2026
… from PR #2110 json-tools-rs (#2107), fastecdsa (#2109), cvxopt (#2110), opencv-contrib-python-headless (#2111), nvtx (#2113) and bitsandbytes (#2094) were all merged by the maintainer while in-flight; .queue.yml still read in-review. Also found and stripped a leftover 'Generated by Claude Code' footer from #2110's description via the GitHub API - same issue already fixed on #2094/#2104/#2116.
XNNPACK builds its rvvfp16arith microkernels with -march=rv64gc_zvfh. The manylinux_2_39_riscv64 image is Rocky 10, whose binutils is 2.41, and zvfh only landed in 2.42 - the assembler rejects the whole ISA string rather than the one unknown extension, so all 71 translation units of @@XNNPACK//:rvvfp16arith_prod_microkernels failed with "unknown prefixed ISA extension `zvfh'" and took //mediapipe/tasks/c:libmediapipe.so down with them. GCC 14.3.1 itself accepts the flag, which is what makes it read like a compiler bug. --define=xnn_enable_riscv_fp16_vector=false is XNNPACK's own switch for this microkernel family, the same one it uses for Android, and it also sets XNN_ENABLE_RISCV_FP16_VECTOR=0 so the dispatch code stops referencing them. The plain rvv kernels keep building: -march=rv64gcv assembles fine on 2.41, so this gives up only fp16 arithmetic vector kernels, not RVV.
luhenry
added a commit
that referenced
this pull request
Sep 20, 2026
…; skills: add gotcha 426 tensorflow-cpu 2.21.0 is the same upstream tree as the already-parked tensorflow, selected by --repo_env=WHEEL_NAME. It has never published a non-x86_64 Linux wheel, and on aarch64 upstream already ships the CPU-only build under the plain tensorflow name, so riscv64 has no gap to close under the -cpu name and the variant is no cheaper than the base. Also records the measured scope (4 per-interpreter Bazel builds, calibrated against mediapipe PR #2104) and, explicitly, that this is NOT the jaxlib XLA blocker at this revision. Backfills a park reason on the tensorflow entry, which had none recorded.
luhenry
marked this pull request as ready for review
September 20, 2026 06:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mediapipe1.0.1Bazel builds
//mediapipe/tasks/c:libmediapipe.so, the CPU-only C API library the Python package loads throughctypes, over TFLite/LiteRT, XNNPACK and a static OpenCV. Upstream publishes no riscv64 wheel.Mirrors upstream's
Dockerfile.manylinux_2_28_x86_64andbuild_manylinux_wheel.sh.Differs from upstream
--java_runtime_version=local_jdk,--jobs=HOST_CPUS- no riscv64 remote JDK, and 128 jobs exhausts the runner.--define=xnn_enable_riscv_fp16_vector=false- XNNPACK'srvvfp16arithmicrokernels build with-march=rv64gc_zvfh, and the image's binutils 2.41 assembler rejects the whole ISA string (zvfhlanded in 2.42). This is XNNPACK's own switch for that kernel family, the one it already uses for Android; it also setsXNN_ENABLE_RISCV_FP16_VECTOR=0so the dispatch code stops referencing them.-march=rv64gcvassembles fine on 2.41, so the plain RVV kernels are kept.py3-none- the tag upstream publishes for this ctypes payload.02d83cb8- upstream tags no release and ships no sdist;mediapipe/version.bzlreads 1.0.1 there.Matrix: one interpreter-agnostic wheel, as upstream, so no
python:matrix.Testing: loads
libmediapipe.soand round-trips anmp.Imagethrough the C API; upstream's own suite needs model assets the wheel does not ship.License: OK
The build does fit the job timeout: run 4 ran to completion in 4h45m of Bazel time (5h23m wall) against a 720-minute limit and failed on the
zvfhgap above, not on time or memory.@@XNNPACK//:rvvfp16arith_prod_microkernelswas the only failing target in the run - 71 translation units, one distinct assembler error - and--keep_goingis what let the rest of the build continue for hours afterwards, so the summary reported a bareTarget //mediapipe/tasks/c:libmediapipe.so failed to buildat the very end. Rebuilding with the flag.