@@ -11416,12 +11416,12 @@ packages:
   pr: null
   notes: 'Not feasible: closed-source proprietary BLPAPI SDK, same shape as azure-cognitiveservices-speech/ibm-db (gotcha 342, feasibility-and-triage.md). The xbbg PyPI name is NOT the old alpha-xone pure-Python Bloomberg wrapper: as of 1.x it is xbbg-org/xbbg, a ground-up rewrite -- a shared Rust engine (crates/xbbg-core, xbbg-async, xbbg-arrow, xbbg-ext, xbbg-recipes) exposed to Python via PyO3 (bindings/pyo3-xbbg, maturin), confirmed by cloning the real v1.4.11 tag. The 5-wheel cp310-cp314 matrix (no abi3) is therefore genuine per-interpreter compilation, not a packaging artifact as hypothesized. The blocker: crates/blpapi-sys (registry name xbbg-blpapi-sys) is an FFI crate whose build.rs runs bindgen against Bloomberg''s proprietary BLPAPI C SDK headers/libs, resolved from BLPAPI_ROOT/BLPAPI_INCLUDE_DIR/BLPAPI_LIB_DIR -- a real build-and-link-time dependency, not a runtime dlopen. It is gated behind xbbg-core''s "live" feature, but pyo3-xbbg''s own Cargo.toml defaults = ["live", "extension-module"], and upstream''s actual .github/workflows/pypi_upload.yml confirms every published wheel is built with that default (it fetches the BLPAPI SDK via its own sdk-version/BLPAPI_VERSION jobs and sets BLPAPI_ROOT before `cargo build`/maturin, for every platform leg) -- so the shipped PyPI wheel always links the real SDK, not an opt-out no-op. blpapi itself has no public PyPI project at all (pypi.org/pypi/blpapi/json 404); it is distributed solely from Bloomberg''s own private index (blpapi.bloomberg.com/repository/releases/python/simple/blpapi/), confirmed live: every release from 3.25.1 through the current 3.26.9.1 ships only manylinux2014_x86_64, macosx_11_0_arm64, win32 and win_amd64 -- no aarch64 Linux, no riscv64, at any version ever published. blpapi-sys''s own build.rs documents this explicitly (panics with a dedicated message on docs.rs for exactly this reason: "the BLPAPI C SDK is proprietary... neither bundled nor downloadable"; its crate README adds the SDK license permits distributing copies but not modifying/adapting them, so not even redistributing bindgen output is an option). No source is available at any layer and no sibling package could be ported first to unblock this -- it is a wait-on-Bloomberg case (same as azure-cognitiveservices-speech), not blocked-on-dependency. Confirmed read-only against the real v1.4.11 source tree and Bloomberg''s own live package index; no worktree/branch opened.'
 - pkg: pybammsolvers
-  version: 0.9.1
-  home: https://pypi.org/project/pybammsolvers/
-  repo: https://github.com/pybamm-team/pybamm
-  status: queued
-  pr: null
-  notes: 'Feasible but large; not attempted this session -- scoping only. Real source is NOT the standalone github.com/pybamm-team/pybammsolvers repo named in the old queue entry: that repo is archived ("code moved to PyBaMM monorepo", commit 0a957b1, PR #109) and frozen at v0.8.2. Versions 0.9.0+ are cut from github.com/pybamm-team/PyBaMM''s packages/pybammsolvers/ subdirectory, tagged pybammsolvers-v<ver> in that monorepo (confirmed: pybammsolvers-v0.9.1 = commit 79fb27f, pybammsolvers-v0.10.0/v0.11.0 also present) -- any port must clone PyBaMM and build from that subtree, using its reusable .github/workflows/_build_solver_wheels.yml as the template (not the archived repo''s dead CI). Real build: scikit-build-core + pybind11 C++ extension (idaklu.cpp -> pybind11_add_module). SUNDIALS (LLNL/sundials, git submodule, ENABLE_KLU/ENABLE_OPENMP/ENABLE_LAPACK) and SuiteSparse KLU+AMD+COLAMD+BTF (DrTimothyAldenDavis/SuiteSparse, git submodule) are both built from source at wheel-build time by install_KLU_Sundials.py -- not vcpkg on Linux (vcpkg is Windows-only per CMakeLists.txt''s own WIN32 guard) and not a separate dependency to port first; both are portable, architecture-generic CMake/Make C projects with no x86-only paths found. Upstream''s own manylinux job (build_manylinux_wheels in _build_solver_wheels.yml) needs only openblas-devel/lapack-devel (dnf, from CRB on the aarch64 leg) plus the submodule build -- openblas-devel/lapack-devel are already proven present in our manylinux_riscv64 image per casadi.yaml''s own port notes, so this specific prerequisite is not a new blocker. The real blocker for *this exact version* is CasADi version pinning: pyproject.toml pins casadi==3.7.2 exactly (both build-system.requires and project.dependencies, non-Windows path resolves libcasadi.so/headers from the installed Python casadi wheel), and CIBW_REPAIR_WHEEL_COMMAND_LINUX hardcodes `--exclude libcasadi.so.3.7`. Our registry only publishes casadi 3.8.0/3.8.1 (docs/packages/casadi.yaml) -- not 3.7.2 -- so a literal 0.9.1 port needs casadi==3.7.2 added as a riscv64 wheel first (a real but small sibling port: same upstream, same build recipe already proven, just an older tag). The cleaner path: pybammsolvers-v0.10.0 and v0.11.0 (same monorepo, confirmed via their pyproject.toml) pin casadi==3.8.1 -- exactly the version we already publish -- so porting 0.10.0/0.11.0 instead of the queue-assigned 0.9.1 avoids the casadi mismatch entirely and should be preferred unless 0.9.1 specifically is required downstream. Either way this is a substantial native build (two from-source C libraries plus a pinned-ABI compiled dependency, with the project''s own CMakeLists already doing GNU libstdc++ ABI probing via `nm` against libcasadi to match _GLIBCXX_USE_CXX11_ABI) comparable in scope to this repo''s own casadi.yaml port, which took multiple multi-hour CI cycles (PIC flags, wget-vs-curl, SWIG fork deviations) to land -- not attempted in this session per the task''s explicit scope-check instruction. Concrete next steps for whoever picks this up: (1) decide 0.9.1 (needs a casadi==3.7.2 sibling port first) vs 0.10.0/0.11.0 (reuses published casadi 3.8.1, recommended); (2) worktree from pybamm-team/PyBaMM at the chosen pybammsolvers-v<ver> tag, build-from-checkout (not the archived standalone repo, not the PyPI sdist -- scikit-build-core''s sdist excludes the submodule trees entirely per its own pyproject.toml comment); (3) mirror build_manylinux_wheels'' matrix, adding a riscv64 leg alongside its existing x86_64/aarch64 legs (CIBW_BEFORE_ALL_LINUX: dnf/yum openblas-devel+lapack-devel, then `python install_KLU_Sundials.py`), with CIBW_REPAIR_WHEEL_COMMAND_LINUX excluding the matching libcasadi.so.<major.minor> for whichever casadi version is targeted; (4) confirm the pytest suite under tests/ (test_integration.py, test_module.py, test_standalone_newton_solver.py, test_observe.py) needs only pybammsolvers + its dev extras, not a full PyBaMM install, before wiring CIBW_TEST_COMMAND. No worktree/branch opened yet -- this is read-only scoping (PyPI JSON for 0.9.1/0.9.0/0.10.0/0.11.0, the real sdist, the archived standalone repo, and a shallow clone of the pybamm-team/PyBaMM monorepo at the pybammsolvers-v0.9.1/v0.10.0/v0.11.0 tags).'
+  version: 0.11.0
+  home: https://github.com/pybamm-team/PyBaMM
+  repo: https://github.com/pybamm-team/PyBaMM
+  status: ci-running
+  pr: https://github.com/riseproject-dev/python-wheels/pull/3267
+  notes: 'Feasible, ported: targeted v0.11.0 instead of the queue-assigned v0.9.1, per the prior scoping note''s own recommendation - confirmed pyproject.toml at v0.11.0 pins casadi==3.8.1, exactly our published casadi.yaml version (0.9.1 pins casadi==3.7.2, which we don''t publish). PR #3267 open. Built from pybamm-team/PyBaMM (the monorepo, not the archived pre-0.9 standalone pybammsolvers repo) at tag pybammsolvers-v0.11.0, packages/pybammsolvers subtree. Confirmed our published riscv64 casadi-3.8.1 wheel''s actual on-disk soname is libcasadi.so.3.7 - matches upstream''s own CIBW_REPAIR_WHEEL_COMMAND_LINUX --exclude libcasadi.so.3.7 verbatim, no change needed. Read install_KLU_Sundials.py/CMakeLists.txt/FindSUNDIALS.cmake/FindSuiteSparse.cmake in full: no x86/aarch64-only branches; SUNDIALS (pinned ddf5daba) and SuiteSparse (pinned 31572b33) are generic CMake/Make C builds; the one ABI-reconciliation hack (nm-probing libcasadi.so for _GLIBCXX_USE_CXX11_ABI) is dynamic/arch-agnostic. openblas-devel/lapack-devel confirmed installable via plain dnf on manylinux_2_39_riscv64 (CRB already enabled) per build-casadi.yml precedent; cmake/ninja/pybind11 provisioned by scikit-build-core itself from riscv64 PyPI wheels. Read every test file: test_integration/test_module/test_observe/test_standalone_newton_solver import only pybammsolvers/casadi/numpy/pytest (dev extras); the two files doing `import pybamm` guard it with pytest.importorskip, so upstream''s own `pytest {project}/tests` just works without a full PyBaMM install. CIBW_ENVIRONMENT points PIP_EXTRA_INDEX_URL at pypi.riseproject.dev so casadi/numpy resolve at build+test time (gotcha 12) - the one real deviation from upstream, which gets both from public PyPI. Matrix cp312/cp313/cp314, no cp314t (matches upstream''s own CIBW_SKIP - casadi ships no cp314t wheel anywhere). Real licensing gap found (pre-existing upstream, not riscv64-specific): idaklu links SUNDIALS (BSD-3) and SuiteSparse''s BTF/KLU (LGPL-2.1-or-later) + AMD/COLAMD/SuiteSparse_config (BSD-3) from pinned submodules, verified by reading their actual LICENSE files at the pinned SHAs, but upstream''s own pyproject.toml only declares license-files = [LICENSE] - every platform''s upstream wheel omits these texts. Added patches/pybammsolvers/0.11.0/0001-license-files.patch (Upstream-Status: To upstream, no write access to pybamm-team/PyBaMM from this session) extending license-files to also ship sundials/LICENSE and SuiteSparse/LICENSE.txt; applies cleanly, passes check_patch.py. timeout-minutes 180 by analogy to build-cvxopt.yml (same image, also compiles SuiteSparse from source). CI status at handback: pr-checks.yml all green on the post-edit run (the first check_commit_messages run correctly failed on the pre-footer-strip body snapshot - explained in a PR comment, self-resolved on the edited-triggered rerun, no real bug); the three real build jobs (cp312/cp313/cp314-manylinux_riscv64) were still queued behind the shared riscv64 runner backlog at handback, so the actual SUNDIALS/SuiteSparse/idaklu compile + pytest run has not yet been observed on real hardware - watch closely once a runner frees up.'
 - pkg: dwave-samplers
   version: 1.8.0
   home: https://docs.dwavequantum.com