queue: squawk-cli 2.63.0 - CI green on PR #2180 (47 min riscv64 build, 4 test legs, publish dry-run clean)

Author: luhenry

.queue.yml

@@ -4744,16 +4744,16 @@ packages:
   version: 2.63.0
   home: https://squawkhq.com
   repo: https://github.com/sbdchd/squawk
-  status: in-review
+  status: ci-green
   pr: https://github.com/riseproject-dev/python-wheels/pull/2180
-  notes: '2 Linux wheels upstream (abi: py3); no riscv64 on PyPI or pypi.riseproject.dev. FEASIBLE and ported - PR https://github.com/riseproject-dev/python-wheels/pull/2180 open (draft, branch squawk-cli). Not a vendored-prebuilt-binary case (gotcha 35/524/529): this is gotcha 117''s third shape, a maturin `bindings = "bin"` project compiled from source. The released manylinux_2_28_x86_64 wheel holds exactly four entries - METADATA, WHEEL (Generator: maturin (1.7.1)), RECORD and a 21.6 MB squawk_cli-2.63.0.data/scripts/squawk - no .so, no importable module, so the py3-none-<platform> tag is real and there is no interpreter matrix on the build job. Upstream publishes a complete sdist (1,105 files, root Cargo.toml + Cargo.lock + 13 workspace crates), and in the git checkout the pyproject.toml lives at crates/squawk/pyproject.toml (maturin sdist hoists it to the root and adds manifest-path), so the build uses maturin-action''s working-directory: crates/squawk rather than taplo''s write-a-pyproject step. Feasibility evidence on this x86_64 host: `cargo metadata --filter-platform riscv64gc-unknown-linux-gnu --locked` resolves 306 packages; only 34 have build scripts and openssl-sys is the single one with a `links` key - no bindgen, no clang-sys, no ring/aws-lc, and no build.rs anywhere in the squawk workspace itself; `cargo check --locked --target riscv64gc-unknown-linux-gnu` over squawk-parser/-syntax/-linter/-ide/-fmt/-lexer/-line-index/-thread/-server (everything except the reqwest-using squawk-github) is clean in 24 s. The one native piece is the vendored OpenSSL that reqwest''s native-tls-vendored feature pulls in: openssl-src 300.5.2+3.5.2 maps riscv64gc-unknown-linux-gnu to linux64-riscv64 in its own target table, and a cross attempt got as far as ''Configuring OpenSSL version 3.5.2 for target linux64-riscv64'' before dying only on this host''s missing riscv64-linux-gnu-gcc, which the native riscv64 runner supplies. Rust side is fine too: rust-toolchain.toml pins stable 1.94 (not nightly, so gotcha 238 does not bite) and rust-1.94.0-riscv64gc-unknown-linux-gnu.tar.gz exists. Workflow mirrors the `linux` job of upstream''s python.yml with three deliberate deviations. (1) maturin-version deliberately left unset: upstream pins v1.7.1 and maturin-riscv64gc-unknown-linux-gnu.tar.gz 404s for that tag (1.9.5 is 200), i.e. exactly gotcha 344''s gzip: stdin: not in gzip format failure; the pyproject''s own requires is the range maturin>=1.7,<2.0, which findReleaseFromManifest resolves against the live release list, so no explicit override is needed. (2) before-script-linux installs perl-core instead of upstream''s yum perl-IPC-Cmd, per gotcha 46 - Rocky 10 also lacks FindBin, which OpenSSL''s Configure needs - alongside the usual git safe.directory line. (3) upstream''s clang/llvm/llvm-devel and `python3 -m ensurepip` are dropped, since nothing in the riscv64 graph binds C headers and a bin wheel needs no pip in the container. timeout-minutes 1440 per gotcha 365 (tokio + hyper + h2 + vendored OpenSSL + an LSP server is the exact shape that stalled there). No patches; license is Apache-2.0 OR MIT with LICENSE-APACHE/LICENSE-MIT at the upstream root and nothing third-party vendored into the binary beyond statically-linked OpenSSL. Testing: upstream packages no wheel-level suite (its Rust/insta tests are not in the wheel) and the wheel carries no importable module, so there is no `python -m squawk` (gotchas 187/224); the test job drives the installed console script instead - --version, --help, upload-to-github --help (the subcommand behind the OpenSSL dependency), an ELF check, a clean file exiting 0, an ALTER TABLE ... ADD COLUMN ... NOT NULL migration exiting 1 with 5 rules, and --exclude removing exactly prefer-bigint-over-int from the JSON reporter. Worth knowing: squawk exits 1 on violations under EVERY reporter including --reporter json, so each lint call needs `|| rc=$?` under set -e. That whole test step was extracted from the YAML and run byte-for-byte against upstream''s own published 2.63.0 x86_64 binary on this host before pushing (exit 0). No docker daemon in this session, so no QEMU rehearsal of the riscv64 build itself - the real runner is the first end-to-end proof. CI: not yet concluded at the time of this note.'
+  notes: '2 Linux wheels upstream (abi: py3); no riscv64 on PyPI or pypi.riseproject.dev. FEASIBLE and ported - PR https://github.com/riseproject-dev/python-wheels/pull/2180 open (draft, branch squawk-cli). Not a vendored-prebuilt-binary case (gotcha 35/524/529): this is gotcha 117''s third shape, a maturin `bindings = "bin"` project compiled from source. The released manylinux_2_28_x86_64 wheel holds exactly four entries - METADATA, WHEEL (Generator: maturin (1.7.1)), RECORD and a 21.6 MB squawk_cli-2.63.0.data/scripts/squawk - no .so, no importable module, so the py3-none-<platform> tag is real and there is no interpreter matrix on the build job. Upstream publishes a complete sdist (1,105 files, root Cargo.toml + Cargo.lock + 13 workspace crates), and in the git checkout the pyproject.toml lives at crates/squawk/pyproject.toml (maturin sdist hoists it to the root and adds manifest-path), so the build uses maturin-action''s working-directory: crates/squawk rather than taplo''s write-a-pyproject step. Feasibility evidence on this x86_64 host: `cargo metadata --filter-platform riscv64gc-unknown-linux-gnu --locked` resolves 306 packages; only 34 have build scripts and openssl-sys is the single one with a `links` key - no bindgen, no clang-sys, no ring/aws-lc, and no build.rs anywhere in the squawk workspace itself; `cargo check --locked --target riscv64gc-unknown-linux-gnu` over squawk-parser/-syntax/-linter/-ide/-fmt/-lexer/-line-index/-thread/-server (everything except the reqwest-using squawk-github) is clean in 24 s. The one native piece is the vendored OpenSSL that reqwest''s native-tls-vendored feature pulls in: openssl-src 300.5.2+3.5.2 maps riscv64gc-unknown-linux-gnu to linux64-riscv64 in its own target table, and a cross attempt got as far as ''Configuring OpenSSL version 3.5.2 for target linux64-riscv64'' before dying only on this host''s missing riscv64-linux-gnu-gcc, which the native riscv64 runner supplies. Rust side is fine too: rust-toolchain.toml pins stable 1.94 (not nightly, so gotcha 238 does not bite) and rust-1.94.0-riscv64gc-unknown-linux-gnu.tar.gz exists. Workflow mirrors the `linux` job of upstream''s python.yml with three deliberate deviations. (1) maturin-version deliberately left unset: upstream pins v1.7.1 and maturin-riscv64gc-unknown-linux-gnu.tar.gz 404s for that tag (1.9.5 is 200), i.e. exactly gotcha 344''s gzip: stdin: not in gzip format failure; the pyproject''s own requires is the range maturin>=1.7,<2.0, which findReleaseFromManifest resolves against the live release list, so no explicit override is needed. (2) before-script-linux installs perl-core instead of upstream''s yum perl-IPC-Cmd, per gotcha 46 - Rocky 10 also lacks FindBin, which OpenSSL''s Configure needs - alongside the usual git safe.directory line. (3) upstream''s clang/llvm/llvm-devel and `python3 -m ensurepip` are dropped, since nothing in the riscv64 graph binds C headers and a bin wheel needs no pip in the container. timeout-minutes 1440 per gotcha 365 (tokio + hyper + h2 + vendored OpenSSL + an LSP server is the exact shape that stalled there). No patches; license is Apache-2.0 OR MIT with LICENSE-APACHE/LICENSE-MIT at the upstream root and nothing third-party vendored into the binary beyond statically-linked OpenSSL. Testing: upstream packages no wheel-level suite (its Rust/insta tests are not in the wheel) and the wheel carries no importable module, so there is no `python -m squawk` (gotchas 187/224); the test job drives the installed console script instead - --version, --help, upload-to-github --help (the subcommand behind the OpenSSL dependency), an ELF check, a clean file exiting 0, an ALTER TABLE ... ADD COLUMN ... NOT NULL migration exiting 1 with 5 rules, and --exclude removing exactly prefer-bigint-over-int from the JSON reporter. Worth knowing: squawk exits 1 on violations under EVERY reporter including --reporter json, so each lint call needs `|| rc=$?` under set -e. That whole test step was extracted from the YAML and run byte-for-byte against upstream''s own published 2.63.0 x86_64 binary on this host before pushing (exit 0). No docker daemon in this session, so no QEMU rehearsal of the riscv64 build itself - the real runner is the first end-to-end proof. CI fully green on run 35635450968: the riscv64 build step ran 18:00:35 -> 18:47:42 UTC (47 min, of which the vendored OpenSSL is ~4 min, 18:08:57 -> 18:12:59) and produced squawk_cli-2.63.0-py3-none-manylinux_2_39_riscv64.whl (sha256 81e360801eabdfddb84e98fd828dd9e5f8536ed5ab9600f32d648353c63eeead); all four test legs (3.12/3.13/3.14/3.14t) green in about a minute each, with the real riscv64 binary reporting the expected 5 issues on the fixture migration; publish dry-ran clean (would tag squawk-cli-v2.63.0-20260921185000, add squawk-cli to packages.txt and open the docs PR). The dropped maturin-version pin resolved as predicted - the log reads `Found maturin release from manifest: v1.15.0`, i.e. the >=1.7,<2.0 range picked a release that does ship riscv64 assets - and perl-core pulled in the full el10 perl distribution. maturin also notes the wheel is eligible for manylinux_2_38, which is informational only. Left as a draft for the maintainer; not yet published.'
 - pkg: spacy-pkuseg
   version: 1.0.1
   home: https://github.com/explosion/spacy-pkuseg
   repo: https://github.com/explosion/spacy-pkuseg
   status: in-review
   pr: https://github.com/riseproject-dev/python-wheels/pull/2183
-  notes: '20 Linux wheels upstream (abi: cp310,cp311,cp312,cp313,cp39); no riscv64 on PyPI or pypi.riseproject.dev. FEASIBLE and ported - PR https://github.com/riseproject-dev/python-wheels/pull/2183 open (draft, branch spacy-pkuseg). An ordinary setuptools+Cython port, and the cheapest of the explosion.ai family this repo has already done (cymem/murmurhash/preshed/srsly/thinc/spacy): setup.py declares three Extensions - spacy_pkuseg.inference (language="c++"), spacy_pkuseg.feature_extractor and spacy_pkuseg.postag.feature_extractor - all cythonized from .pyx with numpy''s include dir, no CMake, no vendored C/C++ library, no submodule. Grepped the whole tree for sse/avx/neon/__x86/aarch64/-march/-mtune: zero hits, so nothing arch-specific to port. Dependency closure is clear: build-system.requires is setuptools + numpy>=2.0.0,<3.0.0 + cython>=0.25 and install_requires is numpy>=1.19.0,<3.0.0 + srsly>=2.3.0,<3.0.0; pypi.riseproject.dev serves numpy 2.5.3 (cp312/cp313/cp314/cp314t), srsly 2.5.3 (same four) and cython 3.3.0 (cp312/cp313/cp314), so a plain isolated build frontend with PIP_EXTRA_INDEX_URL resolves everything - no CIBW_BEFORE_BUILD, no --no-build-isolation, no constraints file. PyPI''s newest numpy and srsly are both 2.5.3 today, i.e. exactly what the registry has, so pip will not prefer a newer sdist. cp314t has no riscv64 cython wheel on the registry; verified on x86 that `pip install --no-binary :all: cython==3.3.0` on a free-threaded 3.14 builds in seconds and yields a py3-none-any wheel (Cython skips compiling its own extensions under free-threading), so the cp314t build env is fine. Two things worth knowing. (1) Upstream''s pyproject carries `free-threaded-support = false`, an option cibuildwheel removed in 3.0; cibuildwheel 4.2.0 refuses the whole [tool.cibuildwheel] table with "Option ''free-threaded-support'' not supported in a config file" before any build starts. Reproduced locally with cibuildwheel 4.2.0 --print-build-identifiers against the release-v1.0.1 checkout. Same failure and same fix as patches/thinc/9.1.1/0001-Comment-out-the-removed-cibuildwheel-free-threaded-support-option.patch; unlike thinc there is no upstream commit to backport (explosion fixed it in thinc as 6f3a08b1 but spacy-pkuseg master, three commits past the tag, still has the line), so the patch is Upstream-Status: To upstream. (2) The three extensions declare no free-threading support, so importing them on cp314t re-enables the GIL with a RuntimeWarning that upstream''s `-Werror` pytest line turns fatal - the same wall build-srsly.yml hit, and the same fix: CIBW_TEST_ENVIRONMENT: PYTHON_GIL=1, which keeps cp314t in the matrix instead of dropping it the way build-spacy.yml had to. Full default matrix cp312/cp313/cp314/cp314t. Testing mirrors tests.yml (`python -m pytest --pyargs spacy_pkuseg -Werror`), but that suite is one test_import case, so the test command first exercises the compiled code directly: inference.run_viterbi on a 3x2 lattice must return states [1,0,1] and exp(11.5), and feature_extractor.get_slice_str(''abcdef'',1,3,6) must be ''bcd''. A post-build step asserts the wheel holds exactly the three expected .so files. No numpy/cython pin was needed: the Cython 3.3.0 regression that forced `cython<3.3.0` in build-preshed.yml/build-spacy.yml is a typed __setitem__ routed through Py_ssize_t, and nothing here uses PreshMap or uint64 keys - built and tested green against Cython 3.3.0 on all four interpreters. x86_64 pre-flight before pushing: built the wheel from the release-v1.0.1 checkout on cp312, cp313, cp314 and cp314t (all four produce the three .so files and a dist-info/licenses/LICENSE), and ran the workflow''s exact CIBW_TEST_COMMAND string byte-for-byte in each of the four venvs - 1 passed each time, cp314t with PYTHON_GIL=1. Also verified the patch applies cleanly to a fresh tag checkout and that cibuildwheel 4.2.0 then accepts all four -manylinux_riscv64 identifiers. License MIT, LICENSE at the upstream root and already in the wheel''s dist-info/licenses/; nothing third-party is vendored. CI: not yet concluded at the time of this note.'
+  notes: '20 Linux wheels upstream (abi: cp310,cp311,cp312,cp313,cp39); no riscv64 on PyPI or pypi.riseproject.dev. FEASIBLE and ported - PR https://github.com/riseproject-dev/python-wheels/pull/2183 open (draft, branch spacy-pkuseg). An ordinary setuptools+Cython port, and the cheapest of the explosion.ai family this repo has already done (cymem/murmurhash/preshed/srsly/thinc/spacy): setup.py declares three Extensions - spacy_pkuseg.inference (language="c++"), spacy_pkuseg.feature_extractor and spacy_pkuseg.postag.feature_extractor - all cythonized from .pyx with numpy''s include dir, no CMake, no vendored C/C++ library, no submodule. Grepped the whole tree for sse/avx/neon/__x86/aarch64/-march/-mtune: zero hits, so nothing arch-specific to port. Dependency closure is clear: build-system.requires is setuptools + numpy>=2.0.0,<3.0.0 + cython>=0.25 and install_requires is numpy>=1.19.0,<3.0.0 + srsly>=2.3.0,<3.0.0; pypi.riseproject.dev serves numpy 2.5.3 (cp312/cp313/cp314/cp314t), srsly 2.5.3 (same four) and cython 3.3.0 (cp312/cp313/cp314), so a plain isolated build frontend with PIP_EXTRA_INDEX_URL resolves everything - no CIBW_BEFORE_BUILD, no --no-build-isolation, no constraints file. PyPI''s newest numpy and srsly are both 2.5.3 today, i.e. exactly what the registry has, so pip will not prefer a newer sdist. cp314t has no riscv64 cython wheel on the registry; verified on x86 that `pip install --no-binary :all: cython==3.3.0` on a free-threaded 3.14 builds in seconds and yields a py3-none-any wheel (Cython skips compiling its own extensions under free-threading), so the cp314t build env is fine. Two things worth knowing. (1) Upstream''s pyproject carries `free-threaded-support = false`, an option cibuildwheel removed in 3.0; cibuildwheel 4.2.0 refuses the whole [tool.cibuildwheel] table with "Option ''free-threaded-support'' not supported in a config file" before any build starts. Reproduced locally with cibuildwheel 4.2.0 --print-build-identifiers against the release-v1.0.1 checkout. Same failure and same fix as patches/thinc/9.1.1/0001-Comment-out-the-removed-cibuildwheel-free-threaded-support-option.patch; unlike thinc there is no upstream commit to backport (explosion fixed it in thinc as 6f3a08b1 but spacy-pkuseg master, three commits past the tag, still has the line), so the patch is Upstream-Status: To upstream. (2) The three extensions declare no free-threading support, so importing them on cp314t re-enables the GIL with a RuntimeWarning that upstream''s `-Werror` pytest line turns fatal - the same wall build-srsly.yml hit, and the same fix: CIBW_TEST_ENVIRONMENT: PYTHON_GIL=1, which keeps cp314t in the matrix instead of dropping it the way build-spacy.yml had to. Full default matrix cp312/cp313/cp314/cp314t. Testing mirrors tests.yml (`python -m pytest --pyargs spacy_pkuseg -Werror`), but that suite is one test_import case, so the test command first exercises the compiled code directly: inference.run_viterbi on a 3x2 lattice must return states [1,0,1] and exp(11.5), and feature_extractor.get_slice_str(''abcdef'',1,3,6) must be ''bcd''. A post-build step asserts the wheel holds exactly the three expected .so files. No numpy/cython pin was needed: the Cython 3.3.0 regression that forced `cython<3.3.0` in build-preshed.yml/build-spacy.yml is a typed __setitem__ routed through Py_ssize_t, and nothing here uses PreshMap or uint64 keys - built and tested green against Cython 3.3.0 on all four interpreters. x86_64 pre-flight before pushing: built the wheel from the release-v1.0.1 checkout on cp312, cp313, cp314 and cp314t (all four produce the three .so files and a dist-info/licenses/LICENSE), and ran the workflow''s exact CIBW_TEST_COMMAND string byte-for-byte in each of the four venvs - 1 passed each time, cp314t with PYTHON_GIL=1. Also verified the patch applies cleanly to a fresh tag checkout and that cibuildwheel 4.2.0 then accepts all four -manylinux_riscv64 identifiers. License MIT, LICENSE at the upstream root and already in the wheel''s dist-info/licenses/; nothing third-party is vendored. CI fully green on run 35635450968: the riscv64 build step ran 18:00:35 -> 18:47:42 UTC (47 min, of which the vendored OpenSSL is ~4 min, 18:08:57 -> 18:12:59) and produced squawk_cli-2.63.0-py3-none-manylinux_2_39_riscv64.whl (sha256 81e360801eabdfddb84e98fd828dd9e5f8536ed5ab9600f32d648353c63eeead); all four test legs (3.12/3.13/3.14/3.14t) green in about a minute each, with the real riscv64 binary reporting the expected 5 issues on the fixture migration; publish dry-ran clean (would tag squawk-cli-v2.63.0-20260921185000, add squawk-cli to packages.txt and open the docs PR). The dropped maturin-version pin resolved as predicted - the log reads `Found maturin release from manifest: v1.15.0`, i.e. the >=1.7,<2.0 range picked a release that does ship riscv64 assets - and perl-core pulled in the full el10 perl distribution. maturin also notes the wheel is eligible for manylinux_2_38, which is informational only. Left as a draft for the maintainer; not yet published.'
 - pkg: mosek
   version: 11.2.3
   home: https://www.mosek.com