queue: rebrowser-playwright -> parked (same Node driver blocker as playwright), tetgen -> ci-running (PR #3081)

Author: luhenry

.queue.yml

@@ -11454,16 +11454,16 @@ packages:
   version: 1.52.0
   home: https://github.com/rebrowser/rebrowser-playwright-python
   repo: https://github.com/rebrowser/rebrowser-playwright-python
-  status: queued
+  status: parked
   pr: null
-  notes: '2 Linux wheels upstream (abi: py3); no riscv64 on PyPI or pypi.riseproject.dev.'
+  notes: 'Not feasible: same blocker as the already-parked plain playwright entry (gotcha 35/183), verified independently against this fork''s real v1.52.0-era sources rather than assumed from the name. rebrowser-playwright-python is a thin repackaging of Microsoft''s playwright-python: setup.py''s PlaywrightBDistWheelCommand downloads a per-platform driver zip from playwright.azureedge.net/builds/driver/ (driver_version pinned to "1.49.0-beta-1732210972000") and extracts it straight into the wheel as rebrowser_playwright/driver/{node,package/cli.js,...} - a prebuilt Node.js binary plus the playwright-core npm bundle, not a compiled Python extension; playwright/_impl/_driver.py launches it by shelling out to that bundled node binary. base_wheel_bundles (setup.py''s exhaustive list of wheel/zip targets) has exactly two Linux entries - manylinux1_x86_64 and manylinux_2_17_aarch64.manylinux2014_aarch64 - matching the queue''s "2 Linux wheels upstream"; there is no riscv64 zip_name anywhere in the list, because this pins to Microsoft''s own driver-build pipeline (not a rebrowser-built one), which has never produced a linux-riscv64 driver zip. Checked the fork''s own JS-side patch set directly (github.com/rebrowser/rebrowser-patches, republished to npm as rebrowser-playwright-core and downloaded by this same setup.py at build time): patches/playwright-core/{lib,src}.patch only touch CDP Runtime.Enable/execution-context handling (the anti-bot-detection fix), with zero mentions of hostPlatform, registry or any driver-download/architecture-detection code. So this fork inherits, unmodified, the exact silent-degrade-to-unknown-platform behavior on non-x64/arm64 Linux that the plain playwright 1.62.0 park note already documented, and Microsoft ships no riscv64 Chromium/Firefox/WebKit either way regardless of the Node driver. Same outcome as upstream playwright: the wheel would be installable (it is just a glue/driver-extraction layer) but non-functional for its entire purpose on riscv64, with no patch available since the blocker is Microsoft''s own unpublished driver and browser binaries, not anything in this fork''s own patch set. No worktree/branch/PR created.'
 - pkg: tetgen
   version: 0.8.4
   home: https://github.com/pyvista/tetgen
   repo: https://github.com/pyvista/tetgen
-  status: queued
-  pr: null
-  notes: '6 Linux wheels upstream (abi: cp310,cp311,cp312); no riscv64 on PyPI or pypi.riseproject.dev.'
+  status: ci-running
+  pr: https://github.com/riseproject-dev/python-wheels/pull/3081
+  notes: 'PR #3081 open. 6 Linux wheels upstream (abi: cp310,cp311,cp312); no riscv64 on PyPI or pypi.riseproject.dev. Verified real upstream (github.com/pyvista/tetgen, MIT wrapper): scikit-build-core + nanobind binding (STABLE_ABI for cp312+) over a direct, portable C++17 vendoring of Hang Si''s TetGen core (src/tetgen.cxx, src/tetgen.h) plus Shewchuk''s public-domain predicates.cxx; CMakeLists.txt has OpenMP commented out (not linked) and no GMP/other native deps, so there is nothing riscv64-specific to patch or build in-image - same shape and same PyVista ecosystem as the already-published pymeshfix port, which this mirrors almost line for line. Upstream''s own [tool.cibuildwheel] build matrix (cp310, cp311, cp312-abi3 covering 3.12-3.14) is left untouched, explaining the 3-abi-tag/6-wheel upstream count. Licensing checked carefully per the task''s own flag on TetGen''s history: the wrapper''s LICENSE is MIT (matches pyproject.toml''s license = "MIT"), but the vendored TetGen core itself is dual-licensed AGPL-3.0-or-later (GNU Affero, not the older pre-1.5 non-commercial-only TetGen license) with a commercial alternative sold by WIAS, captured verbatim in src/tetgen-license; pyproject.toml''s PEP 639 license-files already lists both LICENSE and src/tetgen-license, so both land in the wheel''s dist-info/licenses/ unmodified from upstream (checked for in the build step) - no patch needed, no gpl_sources job needed (nothing here links the manylinux_riscv64 image''s own gcc/libgomp/libgmp). No local build check: no docker daemon available in this sandbox.'
 - pkg: xbbg
   version: 1.4.11
   home: https://xbbg.org/