[ElliotGarbus]

Motivation: Kivy 2.3.2 is a low-risk maintenance release whose main goal is Python 3.14 support. Kivy uses ffpyplayer as its video and audio provider, so it needs ffpyplayer wheels for Python 3.14. Maintainer @AndreMiras is leading the effort.

Adds Python 3.14 wheels and testing on Windows, Linux (x86_64, aarch64) and macOS (x86_64, arm64, universal2). Support for existing Python versions is unchanged, and the change is kept deliberately low risk; dropping old Pythons and adding 3.15 are left for a later release alongside Kivy 2.4.

Python 3.14 support

• Add 3.14 to the Windows, manylinux and macOS build matrices and to the setup.py classifiers.
• Cython: Python 3.14 builds with cython~=3.1.8, the first series that supports 3.14. All other Python versions keep cython~=3.0.11, so their builds are unchanged. This uses environment markers in pyproject.toml, the matching setup_requires in setup.py, and the Windows CI install. No .pyx changes were needed; Cython 3.1 emits the same warnings as 3.0.
• cibuildwheel ~=2.23.3 → ~=3.4.1, since 2.x can't build cp314. Two cibuildwheel 3 default changes are reverted to keep builds as before: CIBW_BUILD_FRONTEND: pip, and the manylinux2014 image on both architectures (instead of the new manylinux_2_28 default).
• CI jobs that used python-version: 3.x now use '3.14'. 3.x now resolves to 3.15, which has no wheels and isn't supported by Cython 3.1.
• macOS: cibuildwheel raises the Intel deployment target to 10.15 for CPython 3.14 (the python.org minimum), so merge_osx_deps.sh also fuses macosx_10_15_x86_64 wheels, so 3.14 gets a universal2 wheel too. Wheels for other versions are unaffected (still 10.13).

CI repairs (pre-existing breakages, unrelated to 3.14)

A fresh CI build of master currently fails. These are the minimum fixes needed to get it green:

• macos-13 runners are retired → use macos-15-intel for both macOS jobs. Its Xcode 16 SDK needs:
  • zlib 1.2.13 → 1.3.1 (1.2.13's fdopen macro breaks against the new SDK headers)
  • libpng 1.6.39 → 1.6.41 (drops the <fp.h> include; same fix Kivy made in 💚 Repair maintenance macOS dependency CI kivy/kivy#9461)
  • libvpx 1.14.1's configure doesn't recognize darwin24 and falls back to a generic ELF target. The x86_64 build now passes --target=x86_64-darwin20-gcc explicitly, as the arm64 build already does. That gives the same flags macos-13 auto-detected.
  • dep_versions.sh is now part of the macOS FFmpeg cache key, so version bumps actually rebuild.
• Linux: git over HTTPS fails inside the manylinux2014 container (fatal: remote helper 'https' aborted session, for code.videolan.org and GitHub alike). x264, fdk-aac and libvpx are now cloned on the runner and copied into the container. build-wheels.sh still clones directly when run standalone.
• Linux: LD_LIBRARY_PATH is now only set for auditwheel repair. The newer manylinux2014 image builds Python 3.10+ against a newer OpenSSL 3. With ffmpeg_build/lib (which contains OpenSSL 3.0.8) on LD_LIBRARY_PATH for the whole build, those Pythons lost their ssl module and pip couldn't install build dependencies.

Testing

• Full CI run on the fork, all jobs green: https://github.com/ElliotGarbus/ffpyplayer/actions/runs/40808667451
  • Windows wheels and tests, 3.9–3.14
  • manylinux x86_64/aarch64 wheels cp39–cp314, tested on 3.14
  • sdist built and tested on 3.14 on Linux
  • macOS wheels cp39–cp314 fused to universal2, tested on 3.14
  • docs
• Locally on Windows: built and tested wheels for 3.14 (Cython 3.1.8) and 3.13 (Cython 3.0.12), 9 passed each. Also built the sdist on 3.14 through pip's isolated build, which correctly picked cython~=3.1.8.

Notes

• Python 3.14 free-threaded (cp314t) wheels are not built.
• Earlier attempts this supersedes or builds on: GitHub Actions: Test on Python 3.14 #185, Upgrade from deprecated macos-13 to macos-15-intel in CI #190, Move nogil to end of function signatures #193, Tentative support/test for Python 3.14 #197.

[matham]

Thank you!

[AndreMiras]

Thanks that was quick!
The v4.5.4 Linux x86_64 release job failed downloading FFmpeg 6.0 with curl exit 35 (TLS/SSL connection error). The aarch64 job was then cancelled, so Linux wheel creation and publication were skipped on both architectures.
The master run at the same release commit successfully built the 4.5.4 manylinux wheels for CPython 3.9–3.14 on both architectures, and those are available as Actions artifacts.

Could you rerun the two linux_wheels jobs (x86_64 and aarch64) in the v4.5.4 release run?
A Linux-only retry would avoid re-uploading the existing Windows/macOS files, since the Twine commands don't use --skip-existing.
The macOS job also failed after publishing, so the generic "Re-run failed jobs" option would try to repeat that upload and likely fail.

Cross ref the current kivy workaround kivy/kivy#9473 for context.

[matham]

Should be fixed, I think!?

[AndreMiras]

Yes that did it and I could close my workaround PR, thank you 🙏