+ notes: '10 Linux wheels upstream (abi: cp310,cp311,cp312,cp313,cp314); no riscv64 on PyPI or pypi.riseproject.dev. Python client wraps the aerospike-client-c C SDK (Apache-2.0, https://github.com/aerospike/aerospike-client-c), bundled as a git submodule, not vendored as a prebuilt binary. Only riscv64-hostile spot found: as_arch.h''s as_arch_pause() spin hint is `#if defined __x86_64__ / #elif __aarch64__` with no fallback, and is used unconditionally from always-compiled spinlock/rwlock inline functions in as_atomic_gcc.h, so riscv64 hits an implicit-declaration -Werror failure; fixed with a one-line portable no-op patch (patches/aerospike/19.2.2/). The patch lands inside a nested submodule (aerospike-client-c/modules/common) whose own .gitmodules already sets `ignore = dirty` on that path, so it does not poison the versioningit-computed wheel version (verified empirically with a throwaway nested-submodule repo: `git describe --dirty` stays clean after the same kind of edit). libyaml-devel (CRB) and openssl-devel (AppStream) both resolve on the riscv64 manylinux image via plain `dnf install`, matching upstream''s own yum install line; no custom OpenSSL-baked image needed. Verified locally on x86_64: sdist->wheel build succeeds cleanly (no cibuildwheel), the compiled .so imports, and `aerospike.client()` against a closed port raises the expected exception.ConnectionError, exercising the same C cluster-init path the patch touches. No live Aerospike server in CI; build-aerospike.yml''s CIBW_TEST_COMMAND is a smoke test instead of upstream''s server-backed integration suite. Default cp312/cp313/cp314/cp314t matrix (upstream is unpinned per-interpreter, no abi3). PR #2310 opened, initial CI (setup/check_patches/check_packages_yaml/check_commit_messages) green, riscv64 build matrix running.'
0 commit comments