Skip to content

Commit f15d95c

Browse files
committed
queue: executorch queued -> ci-running, PR #2434
1 parent 2ca1d6c commit f15d95c

1 file changed

Lines changed: 3 additions & 3 deletions

File tree

‎.queue.yml‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -6935,9 +6935,9 @@ packages:
69356935
version: 1.4.1
69366936
home: https://pytorch.org/executorch/
69376937
repo: https://github.com/pytorch/executorch
6938-
status: queued
6939-
pr: null
6940-
notes: '10 Linux wheels upstream (abi: cp310,cp311,cp312,cp313,cp314); no riscv64 on PyPI or pypi.riseproject.dev.'
6938+
status: ci-running
6939+
pr: 2434
6940+
notes: '10 Linux wheels upstream (abi: cp310,cp311,cp312,cp313,cp314); no riscv64 on PyPI or pypi.riseproject.dev. Triaged as feasible despite the size (large CMake C++ world: XNNPACK, cpuinfo, pthreadpool, flatbuffers/flatcc, Eigen, pocketfft, CoreML''s portable pieces, pybind11) -- mirrors upstream''s own default `--preset pybind` setup.py+CMake build (XNNPACK CPU delegate, portable/optimized/quantized kernels, OpenVINO backend; QNN/CUDA/Vulkan all opt-in and stay off, same as upstream''s own CI off-x86_64). The apparent hard dependency wall (torch>=2.13.0a0, torchao>=0.18.0, pytorch-tokenizers>=1.4.1, coremltools==9.0 on Linux, all unconditional install_requires) is not a blocker: torch (2.13.0+cpu/2.14.0+cpu) and pytorch-tokenizers (1.4.1/1.5.0) are already published for riscv64 cp312/cp313/cp314; coremltools 9.0 is already published for riscv64 cp312/cp313 (its `python_version < "3.14"` marker means cp314 never needs it); torchao has no riscv64 wheel on PyPI but does publish a `py3-none-any` fallback wheel (confirmed via `pip download torchao==0.18.0 --platform manylinux_2_39_riscv64 --python-version 312 --only-binary=:all:`), and its own x86_64 abi3 wheel never matches riscv64 anyway, so pip always resolves the pure-Python one. cp310/cp311 dropped (torch/pytorch-tokenizers ship neither for riscv64); cp314t dropped (upstream itself ships no free-threaded wheel). XNNPACK''s CMake build (not Bazel, so gotcha 442''s Bazel-omission risk does not apply) already builds and ships cleanly on this exact manylinux_2_39_riscv64 image/runner inside our own published torch wheel (PyTorch''s default CPU build also vendors XNNPACK-via-CMake), which is strong precedent against the zvfh/RVV gotchas (420/442) actually firing here -- worth re-checking gotcha 442''s runtime-dispatch-safety question directly if XNNPACK-related SIGILLs ever show up in CI. CoreML backend on Linux only compiles its portable pieces (coreml_util/coreml_inmemoryfs/executorchcoreml pybind module); the Apple-only delegate/.mm sources and protobuf SDK sources stay gated (`if(APPLE)` / `EXECUTORCH_BUILD_DEVTOOLS`, both false here), so no Xcode/Apple-framework dependency. Smoke test keeps upstream''s own registered-backend assertions but replaces its torchvision-based MobileNetV3 example (torchvision has no riscv64 wheel) with a small hand-built model run through both the portable (non-delegated) and a real XNNPACK-delegated export+execute path. One patch (0001, Inappropriate) widens `license-files` to bundle the licences of the third-party libraries statically linked in (XNNPACK, cpuinfo, pthreadpool, FP16, FXdiv, flatbuffers, flatcc, Eigen, pocketfft, nlohmann/json, pybind11) -- upstream''s own wheel ships only its own LICENSE. PR #2434 (draft) opened, CI kicked off; not yet watched to green -- this is a large from-source C++ build (XNNPACK+cpuinfo+pthreadpool+Eigen+pocketfft+CoreML pieces), expect long per-leg build times, in the same cost class as openvino/lalsuite rather than a quick pybind11 wrapper. Worktree .claude/worktrees/executorch, branch executorch.'
69416941
- pkg: fatfs-ng
69426942
version: 0.1.15
69436943
home: https://github.com/Jason2866/pyfatfs

0 commit comments

Comments
 (0)