@@ -8504,9 +8504,9 @@ packages:
   version: 5.4.0
   home: https://github.com/nabla-c0d3/nassl
   repo: https://github.com/nabla-c0d3/nassl
-  status: ci-running
-  pr: 2729
-  notes: '20 Linux wheels upstream (abi: cp310,cp311,cp312,cp313,cp314); no riscv64 on PyPI or pypi.riseproject.dev. nassl statically links its own from-source OpenSSL (legacy OpenSSL_1_0_2e and modern OpenSSL_1_1_1w builds) and zlib, selected per-platform in build_config.py, which had no riscv64 branch at all - its Linux detection only special-cased aarch64, so riscv64 silently fell through to the linux-x86_64 Configure target. Patched build_config.py to add a riscv64 platform: the modern build uses OpenSSL''s own "linux64-riscv64" Configure target (1.1.1w carries no riscv64 assembly at all - that landed only in the 3.x series - so this is a plain portable-C build, avoiding the large-shared-object asm relocation pitfalls a newer OpenSSL''s riscv64 asm can hit per CLAUDE.md gotcha 625); the legacy build''s pinned 1.0.2e predates riscv64 entirely and falls back to "linux-generic64", mirroring how it already special-cases OSX_ARM64 two lines above. Also added the new platform to all_linux_platforms() so the existing -Wl,--exclude-libs=ALL symbol-hiding step (and its test, test_internal_openssl_symbols_are_hidden) covers riscv64 too. Workflow mirrors upstream''s own build_wheels.yml/build_wheels_linux_aarch64.yml (cibuildwheel driving invoke''s build.deps/build.nassl tasks), narrowed to riscv64, with one extra CIBW_BEFORE_ALL_LINUX step installing the riscv64 manylinux image''s full perl package (its minimal perl-interpreter lacks FindBin/lib, which OpenSSL''s Configure needs; CLAUDE.md gotcha 46). Matrix is cp310..cp314 as separate per-interpreter jobs (mercurial/h5py convention), matching upstream''s own non-abi3 wheel set; no cp314t, which upstream does not build either. No gpl_sources job: OpenSSL/zlib are built from pristine upstream source exactly as upstream''s own wheels do, and nothing GPL-licensed from the build environment is linked in. PR #2729 opened as draft; CI running. First CI run (https://github.com/riseproject-dev/python-wheels/actions/runs/37336888859) was red on 3 of 5 interpreter legs, root-caused as two independent issues, neither riscv64-specific, both now patched and pushed: (1) cp313/cp314 both failed tests/cert_chain_verifier_test.py::test_valid_certificate_chain with OpenSSL error 20 ("unable to get local issuer certificate"). That test is not a static fixture: it fetches www.github.com''s live leaf cert via ssl.get_server_certificate() at test time and hardcodes a 2018-era "Sectigo ECC Domain Validation Secure Server CA" intermediate to chain it against the bundled tests/mozilla.pem trust store. Confirmed mozilla.pem loads fine (not a staging/packaging issue) and that nassl''s X509_STORE_CTX chain-building never touches the system/build OpenSSL CA-path defaults (not an OpenSSL_1_1_1w build-flag issue) - the only moving part is the live fetch. Confirmed via SSL Labs that www.github.com''s real current issuer is now "Sectigo Public Server Authentication CA DV E36"/"...DV R36", a newer Sectigo intermediate generation that replaced the hardcoded one, so the hardcoded intermediate''s subject no longer matches the live leaf''s issuer at all - exactly what error 20 means, on any platform, today, not just riscv64. No newer upstream release past the 5.4.0 tag fixes this, and nassl''s Kali Linux packaging has hit this same test break before from the same live-fetch-vs-hardcoded-cert design, there with error 10 ("certificate expired") instead of error 20 - a different symptom of the identical root cause. Pinning today''s correct intermediate would only move the next GitHub CA rotation''s break further out, so patched the test to skip instead (patches/nassl/5.4.0/0002-*, Upstream-Status: To upstream). (2) cp311''s invoke build.deps -> build_zlib -> fetch_source() timed out after ~1018s fetching https://www.zlib.net/fossils/zlib-1.2.13.tar.gz, while cp310/cp312 in the same run hung on the identical fetch with no timeout firing at all, cancelled only by the job''s own 90-minute ceiling - 3 of 5 interpreter legs stuck on the exact same URL within the same few seconds, while cp313/cp314 fetched it in seconds. That split reads as zlib.net''s CDN-less "fossils" path choking under the CI matrix''s simultaneous requests (thundering-herd/under-provisioned-server), not a one-off single-job flake or a general riscv64-runner reachability problem. Patched ZlibBuildConfig.src_tar_gz_url to GitHub''s tag archive for the identical v1.2.13 tree (patches/nassl/5.4.0/0003-*, Upstream-Status: Inappropriate), mirroring how this same file already fetches OpenSSL from a GitHub tag archive; src_path needs no change since GitHub''s vX.Y.Z-tag archive already extracts to "zlib-1.2.13" (same convention build-cvxopt.yml already relies on for SuiteSparse). Both patches verified to apply together, in sequence, against a clean 5.4.0 checkout; pushed as 330e0092fa8. Riscv64 CI re-run queued on push, not yet confirmed green; PR left in draft.'
+  status: ci-green
+  pr: https://github.com/riseproject-dev/python-wheels/pull/2729
+  notes: 'PR #2729 CI green (all 5 build legs cp310-cp314 + publish dry-run passed after the cert-chain-test-skip and zlib-GitHub-mirror fixes); undrafted. 20 Linux wheels upstream (abi: cp310,cp311,cp312,cp313,cp314); no riscv64 on PyPI or pypi.riseproject.dev. nassl statically links its own from-source OpenSSL (legacy OpenSSL_1_0_2e and modern OpenSSL_1_1_1w builds) and zlib, selected per-platform in build_config.py, which had no riscv64 branch at all - its Linux detection only special-cased aarch64, so riscv64 silently fell through to the linux-x86_64 Configure target. Patched build_config.py to add a riscv64 platform: the modern build uses OpenSSL''s own "linux64-riscv64" Configure target (1.1.1w carries no riscv64 assembly at all - that landed only in the 3.x series - so this is a plain portable-C build, avoiding the large-shared-object asm relocation pitfalls a newer OpenSSL''s riscv64 asm can hit per CLAUDE.md gotcha 625); the legacy build''s pinned 1.0.2e predates riscv64 entirely and falls back to "linux-generic64", mirroring how it already special-cases OSX_ARM64 two lines above. Also added the new platform to all_linux_platforms() so the existing -Wl,--exclude-libs=ALL symbol-hiding step (and its test, test_internal_openssl_symbols_are_hidden) covers riscv64 too. Workflow mirrors upstream''s own build_wheels.yml/build_wheels_linux_aarch64.yml (cibuildwheel driving invoke''s build.deps/build.nassl tasks), narrowed to riscv64, with one extra CIBW_BEFORE_ALL_LINUX step installing the riscv64 manylinux image''s full perl package (its minimal perl-interpreter lacks FindBin/lib, which OpenSSL''s Configure needs; CLAUDE.md gotcha 46). Matrix is cp310..cp314 as separate per-interpreter jobs (mercurial/h5py convention), matching upstream''s own non-abi3 wheel set; no cp314t, which upstream does not build either. No gpl_sources job: OpenSSL/zlib are built from pristine upstream source exactly as upstream''s own wheels do, and nothing GPL-licensed from the build environment is linked in. PR #2729 opened as draft; CI running. First CI run (https://github.com/riseproject-dev/python-wheels/actions/runs/37336888859) was red on 3 of 5 interpreter legs, root-caused as two independent issues, neither riscv64-specific, both now patched and pushed: (1) cp313/cp314 both failed tests/cert_chain_verifier_test.py::test_valid_certificate_chain with OpenSSL error 20 ("unable to get local issuer certificate"). That test is not a static fixture: it fetches www.github.com''s live leaf cert via ssl.get_server_certificate() at test time and hardcodes a 2018-era "Sectigo ECC Domain Validation Secure Server CA" intermediate to chain it against the bundled tests/mozilla.pem trust store. Confirmed mozilla.pem loads fine (not a staging/packaging issue) and that nassl''s X509_STORE_CTX chain-building never touches the system/build OpenSSL CA-path defaults (not an OpenSSL_1_1_1w build-flag issue) - the only moving part is the live fetch. Confirmed via SSL Labs that www.github.com''s real current issuer is now "Sectigo Public Server Authentication CA DV E36"/"...DV R36", a newer Sectigo intermediate generation that replaced the hardcoded one, so the hardcoded intermediate''s subject no longer matches the live leaf''s issuer at all - exactly what error 20 means, on any platform, today, not just riscv64. No newer upstream release past the 5.4.0 tag fixes this, and nassl''s Kali Linux packaging has hit this same test break before from the same live-fetch-vs-hardcoded-cert design, there with error 10 ("certificate expired") instead of error 20 - a different symptom of the identical root cause. Pinning today''s correct intermediate would only move the next GitHub CA rotation''s break further out, so patched the test to skip instead (patches/nassl/5.4.0/0002-*, Upstream-Status: To upstream). (2) cp311''s invoke build.deps -> build_zlib -> fetch_source() timed out after ~1018s fetching https://www.zlib.net/fossils/zlib-1.2.13.tar.gz, while cp310/cp312 in the same run hung on the identical fetch with no timeout firing at all, cancelled only by the job''s own 90-minute ceiling - 3 of 5 interpreter legs stuck on the exact same URL within the same few seconds, while cp313/cp314 fetched it in seconds. That split reads as zlib.net''s CDN-less "fossils" path choking under the CI matrix''s simultaneous requests (thundering-herd/under-provisioned-server), not a one-off single-job flake or a general riscv64-runner reachability problem. Patched ZlibBuildConfig.src_tar_gz_url to GitHub''s tag archive for the identical v1.2.13 tree (patches/nassl/5.4.0/0003-*, Upstream-Status: Inappropriate), mirroring how this same file already fetches OpenSSL from a GitHub tag archive; src_path needs no change since GitHub''s vX.Y.Z-tag archive already extracts to "zlib-1.2.13" (same convention build-cvxopt.yml already relies on for SuiteSparse). Both patches verified to apply together, in sequence, against a clean 5.4.0 checkout; pushed as 330e0092fa8. Riscv64 CI re-run queued on push, not yet confirmed green; PR left in draft.'
 - pkg: scikit-learn-extra
   version: 0.3.0
   home: https://github.com/scikit-learn-contrib/scikit-learn-extra
@@ -8589,7 +8589,7 @@ packages:
   repo: https://github.com/dmlc/treelite
   status: ci-green
   pr: https://github.com/riseproject-dev/python-wheels/pull/2732
-  notes: '1 Linux wheels upstream (abi: py3); no riscv64 on PyPI or pypi.riseproject.dev. Last release of this distribution: treelite 4.0.0 dropped runtime/python and reborn it as tl2cgen_runtime in dmlc/tl2cgen (verified: no runtime/ dir and no Predictor class anywhere in the 4.0.0 tree), so 3.9.1 is a closed, pinned build, same shape as the tflite-runtime (PR #2154) precedent. Both python/ and runtime/python/ build from one root CMakeLists.txt (cmake --build with no target builds both treelite and treelite_runtime); the runtime wheel bundles a ctypes-loaded libtreelite_runtime.so with no extension module (xgboost/decord shape), retagged py3-none via `wheel tags` after cibuildwheel''s cp312 build since cibuildwheel''s pip frontend ignores setup.py bdist_wheel --universal. Two build-time fixes needed on the manylinux_riscv64 image: CMAKE_POLICY_VERSION_MINIMUM=3.5 for vendored fmtlib''s old cmake_minimum_required, and a patch pinning vendored RapidJSON past v1.1.0 (GIT_TAG 862c39b) because v1.1.0''s GenericStringRef declares a copy-assignment that assigns to its own const length member, which GCC 14 rejects outright - fixed upstream 3 commits later by deleting the operator, reproduces on any platform. test_basic.py itself is not run as the test: every check there builds its DMatrix from a SciPy CSR matrix via np.array(..., copy=False, dtype=cast), which numpy 2 (the only line with a riscv64 wheel) refuses outright on any platform since treelite-runtime predates numpy 2 - a real upstream gap, not a riscv64 one. Tested instead by installing the companion treelite package from the same checkout, compiling a real xgboost model with the gcc toolchain, loading it through treelite_runtime.Predictor and predicting on a dense DMatrix (which takes no such cast). PR #2732 open as a draft, fully green: build_wheels, gpl_sources and the publish dry run (which correctly resolves treelite_runtime-3.9.1-py3-none-manylinux_2_39_riscv64.whl) all passed.'
+  notes: 'PR #2732 undrafted after independent CI re-verification (lint checks had gotten stuck "cancelled" twice on GitHub''s shared ubuntu-latest runners; a fresh run came back fully green). 1 Linux wheels upstream (abi: py3); no riscv64 on PyPI or pypi.riseproject.dev. Last release of this distribution: treelite 4.0.0 dropped runtime/python and reborn it as tl2cgen_runtime in dmlc/tl2cgen (verified: no runtime/ dir and no Predictor class anywhere in the 4.0.0 tree), so 3.9.1 is a closed, pinned build, same shape as the tflite-runtime (PR #2154) precedent. Both python/ and runtime/python/ build from one root CMakeLists.txt (cmake --build with no target builds both treelite and treelite_runtime); the runtime wheel bundles a ctypes-loaded libtreelite_runtime.so with no extension module (xgboost/decord shape), retagged py3-none via `wheel tags` after cibuildwheel''s cp312 build since cibuildwheel''s pip frontend ignores setup.py bdist_wheel --universal. Two build-time fixes needed on the manylinux_riscv64 image: CMAKE_POLICY_VERSION_MINIMUM=3.5 for vendored fmtlib''s old cmake_minimum_required, and a patch pinning vendored RapidJSON past v1.1.0 (GIT_TAG 862c39b) because v1.1.0''s GenericStringRef declares a copy-assignment that assigns to its own const length member, which GCC 14 rejects outright - fixed upstream 3 commits later by deleting the operator, reproduces on any platform. test_basic.py itself is not run as the test: every check there builds its DMatrix from a SciPy CSR matrix via np.array(..., copy=False, dtype=cast), which numpy 2 (the only line with a riscv64 wheel) refuses outright on any platform since treelite-runtime predates numpy 2 - a real upstream gap, not a riscv64 one. Tested instead by installing the companion treelite package from the same checkout, compiling a real xgboost model with the gcc toolchain, loading it through treelite_runtime.Predictor and predicting on a dense DMatrix (which takes no such cast). PR #2732 open as a draft, fully green: build_wheels, gpl_sources and the publish dry run (which correctly resolves treelite_runtime-3.9.1-py3-none-manylinux_2_39_riscv64.whl) all passed.'
 - pkg: deno
   version: 2.9.6
   home: https://deno.com
@@ -8601,9 +8601,9 @@ packages:
   version: 10.4.2
   home: https://github.com/pacman82/arrow-odbc-py
   repo: https://github.com/pacman82/arrow-odbc-py
-  status: queued
-  pr: null
-  notes: '2 Linux wheels upstream (abi: py3); no riscv64 on PyPI or pypi.riseproject.dev.'
+  status: ci-green
+  pr: https://github.com/riseproject-dev/python-wheels/pull/2731
+  notes: 'PR #2731 CI green (build + publish dry-run passed, 4/4 smoke tests on every reused leg); undrafted. maturin crate with bindings = "cffi" (not PyO3/abi3), hence the py3-none-<platform> tag (gotcha 479 shape, precedented by build-cmsis-pack-manager.yml). Links unixODBC at build+runtime; confirmed present in Rocky 10''s own riscv64 repodata (unixODBC/unixODBC-devel in AppStream/CRB, no from-source build needed) - build-pyodbc.yml already proves the same link path works on this image. Upstream''s own test suite needs a Microsoft SQL Server service unavailable on riscv64; replaced with a riscv64-only smoke test against PostgreSQL + postgresql-odbc, mirroring build-pyodbc.yml''s own driver setup.'
 - pkg: faiss-gpu
   version: 1.15.0
   home: https://github.com/facebookresearch/faiss