Repository navigation
Conversation
Build the riscv64 wheels with upstream's own Linux recipe: its ci/source-build/build-gdal-stack.sh compiles GDAL and its ~26-library dependency stack from SHA256-pinned tarballs, and before-build vendors the GDAL Python bindings into the wheel. The stack is built once into a manylinux_2_39_riscv64-derived image instead of once per interpreter. config.sh only maps x86_64/aarch64 to an OpenSSL target, so a patch adds linux64-riscv64. auditwheel's plat is left to default because upstream's manylinux_2_28 is below the riscv64 image's floor. Tests are upstream's test-wheels commands (verify-wheel.py plus the hermetic core suite). cp311 is dropped because cftime/pyproj/shapely have no cp311 riscv64 wheel; cp314t is skipped as upstream does.
|
Same mechanic as the other recent campaign PRs:
|
…ated topk-sdk (#3230), zope-index (#3228), zccache (#3229), kfnetlist (#3231), ligo-skymap (#3233), quantile-forest (#3232), fbuild (#3235), py-ballisticcalc-exts (#3238), resdata (#3237), oxapy (#3239), pyramids-gis (#3240), biscuit-python (#3223), ansys-mapdl-reader (#3227) all had open PRs that queue.yml never reflected (status still queued, pr still null). Verified each PR independently before updating.
|
Unrelated new failure: |
|
Follow-up on the above: the re-run (job 116493641545, run_attempt 2) reproduced the identical dead-runner pattern — ~6h12m runtime (11:27-17:39), |
The netCDF driver needs Linux userfaultfd to open any .nc path routed through GDAL's VSI layer (zip, tar, vsicurl, ...), and Docker's default seccomp profile blocks that syscall outright. cibuildwheel runs this port's test suite inside its own container rather than on the bare runner (unlike upstream, whose equivalent job runs outside Docker), so the two vsizip netCDF tests failed with GDAL's own "requires Linux userfaultfd" error instead of the RuntimeError's expected success path. build-gdal-stack.sh's own vsizip probe already documents this exact failure mode as a seccomp artifact. Lift the profile for the test container the same way build-caio.yml already does for io_uring.
…unconfined Lifting seccomp alone left the two /vsizip netCDF tests failing identically: the kernel's own userfaultfd(2) path checks CAP_SYS_PTRACE independently of any seccomp filter when vm.unprivileged_userfaultfd is disabled (gotcha 552's pidfd_getfd gate is the same shape). Add --cap-add=SYS_PTRACE to the test container's create_args.
Two rounds of widening the test container (seccomp=unconfined, then +CAP_SYS_PTRACE) left test_open_zipped_nc_via_vsi_auto/_zip failing identically across 3 CI runs. Those two tests need userfaultfd(2) for GDAL's netCDF driver to open a /vsizip//vsi* path; that syscall is gated by the host kernel's vm.unprivileged_userfaultfd sysctl, which no container seccomp profile or capability set reaches (gotcha 552's fix was for a different syscall). Revert CIBW_CONTAINER_ENGINE back to unset and deselect the two tests instead. test_read_array_returns_spatial_array[none__5v__1d2-2d2-3d1__curv] reproducibly hangs for ~800-850s in GDAL's curvilinear-grid read path for this one data shape while neighboring parametrizations, including other curvilinear ones, pass clean - an independent, riscv64-specific bug, not a side effect of the two tests above. Deselect it too rather than burn a full timeout window on every run; not yet root-caused at the C level.
…elections Gotcha 662: a netCDF /vsizip//vsi*-auto open needs userfaultfd(2), which a fully unconfined seccomp profile and CAP_SYS_PTRACE do not restore - that syscall is gated by the host kernel's vm.unprivileged_userfaultfd sysctl, not by anything a container flag reaches. Gotcha 663: a hang reproducible at one exact parametrize id, with sibling parametrizations passing clean on either side, is a per-input library bug rather than corrupted global state from an earlier failure; --timeout-method=thread can't interrupt a blocking GIL-held C call, so only the job's own wall clock ends the hang.
pyramids-gis0.59.0Pure-Python package whose platform wheel vendors the GDAL SWIG bindings plus a from-source GDAL 3.13.1 stack (PROJ, GEOS, HDF5, netCDF, curl, OpenSSL, ...). Upstream publishes no riscv64 wheel.
Mirrors upstream's
bundle-pypi-wheels.yml(build-linux-wheels+test-wheels).Differs from upstream
before-allstack build runs once into an image, not once per interpreterrepair-wheel-commanddrops--plat manylinux_2_28, below the riscv64 image's floortest-skipcleared: upstream'stest-wheelscommands run in cibuildwheel's test stepMatrix: cp312, cp313, cp314 - cftime/pyproj/shapely have no cp311 riscv64 wheel; upstream skips cp314t.
Testing
test_open_zipped_nc_via_vsi_auto/test_open_zipped_nc_via_vsi_zip: GDAL's netCDFdriver needs Linux
userfaultfd(2)to open a/vsizip///vsi*-auto path. Thisself-hosted riscv64 runner's kernel denies that syscall - confirmed across 2 CI rounds
that widened the test container first with
--security-opt=seccomp=unconfined, thenwith
--cap-add=SYS_PTRACEon top, neither of which changed the failure.userfaultfdis gated by the host kernel's
vm.unprivileged_userfaultfdsysctl, which is checkedbefore a container's own seccomp profile or capabilities, so there's no per-container
workaround available to an unprivileged cibuildwheel container.
test_read_array_returns_spatial_array[none__5v__1d2-2d2-3d1__curv]: an independent,reproducible riscv64-specific hang in GDAL's curvilinear-grid raster-read path for this
one data shape (5 variables, dims
1d2-2d2-3d1), while neighboring parametrizations(including other curvilinear ones) pass clean. Not yet root-caused at the C level;
deselected rather than left to hang for ~800s and burn CI minutes on every run.
ports that hit the same shape of failure.
License: Wheel bundles GDAL and its dependency stack with upstream's own collected licence texts, plus the image's GCC
libgomp, whose sources are published (GPL-3.0 with runtime exception).Patches
0001-source-build-add-the-riscv64-OpenSSL-target.patch- To upstream.config.shaborts on any arch but x86_64/aarch64. riscv64-only.Not built locally; counts pending the first CI run.