queue: wsaccel/suitesparse-graphblas -> ci-running (PR #3365, #3368); python-iptables/pyseccomp/landlock -> no-gap; robyn -> parked

Author: luhenry

.queue.yml

@@ -14863,3 +14863,45 @@ packages:
   status: ci-running
   pr: https://github.com/riseproject-dev/python-wheels/pull/3367
   notes: 'PR #3367 open. Barcode/QR-code native-accelerator candidate (PyO3 binding over the real zxing-cpp C++ core via the Rust zxing-cpp crate''s bundled feature, through a pure-Rust reader_core crate) considered under the barcode/QR-code native-accelerator sweep, distinct from already-published zxing-cpp (which pyrxing itself advertises musl/Alpine wheels as an improvement over) and from the unverifiable "rxing" PyPI package (single 2025-05 release whose README still contains a template "github.com/your-username/rxing-python" placeholder instead of a real source link - not pursued, no real upstream could be confirmed). Verified real upstream (tanagumo/pyrxing, Apache-2.0, LICENSE present in both the repo and the published wheel''s dist-info). The bundled zxing-cpp crate compiles the exact v3.1.1 C++ sources already proven on this registry''s riscv64 runners by the zxing-cpp package itself. PyPI 0.8.0 ships manylinux_2_39/musllinux_1_2 (x86_64/aarch64), macOS and Windows wheels for cp311-cp314, no riscv64. Mirrors the linux job of upstream''s own build.yml (PyO3/maturin-action, CXXFLAGS=-std=c++20), narrowed to riscv64gc, adding a before-script-linux `yum install -y cmake` since the manylinux riscv64 image lacks it and the bundled C++ build needs it. Smoke-tests the wheel by decoding upstream''s own assets/test_qr_code.png. No local build check: time-boxed per-candidate budget.'
+- pkg: wsaccel
+  version: 0.6.7
+  home: https://github.com/methane/wsaccel
+  repo: https://github.com/methane/wsaccel
+  status: ci-running
+  pr: https://github.com/riseproject-dev/python-wheels/pull/3365
+  notes: 'PR #3365 open. Web-server/ASGI native-accelerator candidate (Cython UTF-8 frame validation and XOR masking for ws4py/AutobahnPython-family websocket implementations) considered under the web-server/ASGI native-accelerator sweep, distinct from already-published/queued uvloop/httptools/websockets/granian/aiohttp entries (confirmed each of those is already covered via docs/packages before pursuing this one). Verified real upstream (methane/wsaccel, Apache-2.0, LICENSE present), two tiny Cython extensions (wsaccel/utf8validator.pyx, wsaccel/xormask.pyx), no architecture-specific code. PyPI 0.6.7 ships manylinux2014/musllinux x86_64/aarch64/i686 wheels for cp310-cp313, no riscv64. Mirrors upstream''s own build.yaml (cibuildwheel), narrowed to riscv64. Validated locally end to end on x86_64: pip wheel from the checkout builds cleanly with no special toolchain (gotcha 9), confirming portability before the riscv64 CI run. No patches.'
+- pkg: suitesparse-graphblas
+  version: 10.5.1.0
+  home: https://github.com/GraphBLAS/python-suitesparse-graphblas
+  repo: https://github.com/GraphBLAS/python-suitesparse-graphblas
+  status: ci-running
+  pr: https://github.com/riseproject-dev/python-wheels/pull/3368
+  notes: 'PR #3368 open. Linear-algebra/numerical-solver candidate (cffi bindings over the SuiteSparse:GraphBLAS C library - sparse linear algebra over semirings, used for graph algorithms) considered under the linear-algebra/numerical-solver sweep, distinct from already-published/queued scipy/numpy/openblas/cvxopt/osqp/ecos/scs/pyamg/highspy/clarabel/daqp/proxsuite and from the already-parked scikit-sparse/scikit-umfpack/cyipopt entries (all of those bind a *system* SuiteSparse with no bundled source, the actual no-gap reason there; this package instead builds GraphBLAS itself from a pinned upstream tag, same shape as build-cvxopt.yml''s from-source SuiteSparse AMD/UMFPACK/CHOLMOD build). Verified real upstream (GraphBLAS/python-suitesparse-graphblas, Apache-2.0, LICENSE present); the C library it builds (DrTimothyAldenDavis/GraphBLAS) is also Apache-2.0, vendoring only permissively-licensed lz4/zstd/xxHash/cpu_features (the last of which already recognizes riscv64 explicitly in its own CMakeLists.txt) - no GPL anywhere, no gpl_sources job needed. PyPI 10.5.1.0 ships manylinux_2_27/2_28 x86_64/aarch64 (+macOS/Windows/pyodide) wheels for cp311-cp314/cp314t, no riscv64. Mirrors upstream''s own wheels.yml Linux x86_64 job (cibuildwheel, CIBW_BEFORE_ALL running its suitesparse.sh to build GraphBLAS from source), narrowed to riscv64; GraphBLAS is built once per version (via a container: job) and shared across the interpreter matrix via an artifact instead of once per wheel, since the C library does not depend on the Python version. One patch widens license-files (PEP 639 explicit list, no glob fallback) so an added LICENSE.graphblas is picked up, the same gap-filling shape already used for ssh2-python/iminuit. Validated locally end to end on x86_64 (GRAPHBLAS_COMPACT=ON for speed, not the production flags CI uses): cmake configure, build (2 min on 4 cores), install, then pip wheel the Python package against it, install, import, and call a real GraphBLAS symbol successfully. The real riscv64 CI run uses the full (non-compact) build upstream''s own releases use, which is unproven here and could run long on 4-core runners - watch closely; timeout-minutes is set generously (480) for that job.'
+- pkg: python-iptables
+  version: 1.2.0
+  home: https://github.com/ldx/python-iptables
+  repo: https://github.com/ldx/python-iptables
+  status: no-gap
+  pr: null
+  notes: 'No-gap (novas shape). Containerization/sandboxing-adjacent native-tooling candidate (ctypes/CPython binding over libiptc for iptables firewall rules, used by container network-policy tooling) considered under the containerization/sandboxing native-tooling sweep, distinct from already-published/queued pyroute2/python-prctl entries. Verified real upstream (ldx/python-iptables, Apache-2.0, LICENSE present), genuine C extension (iptc/_ipt/iptc/*.c wrapping libiptc) - not pure Python. Checked the full PyPI release history (18 releases, 0.1.1 through 1.2.0): every single one ships only an sdist, zero wheels for any platform or architecture, ever, including x86_64. No upstream CI wheel-building workflow exists to narrow to riscv64 (goal 2 has nothing to mirror) - every Linux user, x86_64 included, already builds this from source against the host''s libiptc-dev today; riscv64 is in the identical position. No worktree/branch/PR created.'
+- pkg: pyseccomp
+  version: 0.1.2
+  home: https://github.com/cptpcrd/pyseccomp
+  repo: https://github.com/cptpcrd/pyseccomp
+  status: no-gap
+  pr: null
+  notes: 'No-gap (gotcha 27/50/126 shape). Containerization/sandboxing native-tooling candidate (libseccomp/BPF syscall-filtering bindings, used by container sandboxing tooling) considered under the containerization/sandboxing native-tooling sweep. Verified real upstream (cptpcrd/pyseccomp, MIT). PyPI 0.1.2 ships exactly one pyseccomp-0.1.2-py3-none-any.whl plus sdist - pure Python, no ext_modules; it binds libseccomp.so at runtime via ctypes rather than compiling an extension (same shape as the already-parked landlock candidate below). riscv64 already gets the identical pure wheel every other platform/arch gets from PyPI today; nothing for this registry to build. No worktree/branch/PR created.'
+- pkg: landlock
+  version: 1.0.0.dev5
+  home: https://github.com/Edward-Knight/landlock
+  repo: https://github.com/Edward-Knight/landlock
+  status: no-gap
+  pr: null
+  notes: 'No-gap (gotcha 27/50/126 shape). Containerization/sandboxing native-tooling candidate (Linux Landlock LSM sandboxing, used for process confinement similar to seccomp) considered under the containerization/sandboxing native-tooling sweep, alongside the separately-evaluated pyseccomp and the already-parked nono-py entry (a different, Rust/PyO3-based Landlock+seccomp binding blocked by missing riscv64 syscall-number constants upstream). Verified real upstream (Edward-Knight/landlock, no PyPI classifier license found but MIT per repo). PyPI 1.0.0.dev5 ships exactly one landlock-1.0.0.dev5-py3-none-any.whl plus sdist - pure Python, calls the landlock syscalls directly via ctypes, no ext_modules. riscv64 already gets the identical pure wheel every other platform/arch gets from PyPI today; nothing for this registry to build. No worktree/branch/PR created.'
+- pkg: robyn
+  version: 0.88.0
+  home: https://github.com/sparckles/robyn
+  repo: https://github.com/sparckles/robyn
+  status: parked
+  pr: null
+  notes: 'Parked, not no-gap - left for a future session with more time, not ruled infeasible. Web-server/ASGI native-accelerator candidate (its own Rust runtime - actix-web/actix/tokio via PyO3 - rather than an ASGI protocol accelerator) considered under the web-server/ASGI native-accelerator sweep, distinct from already-published/queued granian/oxapy/httpr/pyqwest/pyreqwest/restate-sdk/mitmproxy-rs (all proven PyO3+tokio builds on this registry''s riscv64 runners already) and from already-published uvloop/httptools/websockets. Verified real upstream (sparckles/Robyn, BSD-2-Clause, LICENSE present). Checked Cargo.lock directly: no ring/rustls/openssl/aws-lc-sys anywhere (actix-web is pulled with no TLS feature enabled) - the most common riscv64 Rust-crate blocker in this repo''s history is absent here. Remaining dependencies (dashmap, matchit, socket2, parking_lot, crossbeam-channel, pythonize, pyo3-async-runtimes) are all portable pure-Rust crates with no arch-gated code found. No architectural blocker identified, but not attempted this round: actix-web''s dependency closure is noticeably larger than the already-proven granian/oxapy builds (actix, actix-web-actors, actix-multipart, actix-files pull in a sizeable actor-framework graph on top of tokio), and the Python-side runtime deps (inquirerpy, multiprocess, orjson, rustimport, watchdog, uvloop) need a fresh per-interpreter dependency-resolution check against this registry before a workflow is authored. Revisit with a dedicated session to author build-robyn.yml from upstream''s own maturin-based CI and validate the actix-web dependency closure compiles on riscv64. No worktree/branch/PR created.'