The override lists every python3 package by name, so it has to change
whenever the package set does, and it cannot be used as is on branches
that build a different set, like libpython3-3.13 and python3-email on
openwrt-25.12.
Check the interpreter, python3-dev and libpython3-X.Y against the
version, and accept the standard library modules and -src packages by
pattern, since they ship no executables. python3-dev now gets a real
check through python3-config and patchlevel.h, because python3-config
prints no version.
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
libatomic is only needed where the compiler does not inline 64-bit
atomics, but the package depends on it on every target.
ATOMIC64_DEPENDS restricts the dependency to those targets.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Adds support for setuptools 84.
chardet-normalizer has been broken since setuptools 84 was merged in
6211fee354
Signed-off-by: Austin Lane <vidplace7@gmail.com>
Refresh PKG_HASH from the python.org release tarball, and bump
PYTHON3_PIP_VERSION to 26.2.1 to match the pip wheel bundled in 3.14.7's
ensurepip (it already matches the python-pip package version).
Refresh the patches against the new source; only the hunk offsets shift.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
d883c02a41 ("python3: pin host curses to the SDK's narrow ncurses",
2026-05-28) forced every curses header check Python's configure.ac
runs to "no", specifically to keep host ncurses's (then narrow-only)
build from being shadowed by whatever curses headers the build host's
own distro happened to ship under /usr/include.
That assumption broke when openwrt/openwrt@18725c45a3 ("ncurses:
bump to 6.6.20260801") switched host ncurses to track ncurses' git
snapshots rather than the old 6.4 tarball: ncurses 6.6+ defaults to
building wide-character support for ABI 6 (cf_dft_widec, gated on
cf_cv_abi_default which is just the major version - this is a policy
change accumulated in ncurses' own git history since 6.4 was tagged,
not something OpenWrt or ncurses deliberately changed for wide-char
specifically). Host ncurses now produces ncursesw.pc/panelw.pc, which
Python 3.14's configure.ac finds independently via its own
PKG_CHECK_MODULES(CURSES, ncursesw)-style pkg-config probe ("checking
for ncursesw... yes") - a check that was never gated by these ac_cv_*
overrides in the first place. That flips on the wide-character code
paths in Modules/_cursesmodule.c, while the ac_cv_header_ncursesw_*=no
overrides still force the *header* checks to fail, so the actual
#include falls through to the stale narrow ncurses/ncurses.h. The
result is a mismatch between what pkg-config says is available and
what header actually got included, producing:
./Modules/_cursesmodule.c: error: implicit declaration of function
'unget_wch'; did you mean 'ungetch'?
(and similarly for wget_wch, wins_nwstr, mvwins_nwstr - every
wide-character-only curses function).
Fix this at the python3/ncurses integration boundary rather than by
touching ncurses' own host build behaviour globally (see
openwrt/openwrt#24811, which tried --disable-widec on host ncurses
and had to be reverted: it also drops extended colors from host tic,
shrinking MAX_ENTRY_SIZE 32768->4096 so tic can no longer process the
xterm/xterm-256color terminfo entries needed to assemble the target
terminfo package). Since host ncurses's own -I.../include/ncursesw
already gets added via pkg-config's Cflags substitution regardless of
these overrides, stop forcing ac_cv_header_ncursesw_{ncurses,panel}_h
to "no" - configure now genuinely finds ncursesw/ncurses.h in
staging_dir/hostpkg, consistent with what its own pkg-config check
already reports, and both detection paths agree.
ac_cv_header_ncursesw_curses_h stays forced, along with the bare
(non-w) curses.h/ncurses.h/panel.h checks: host ncurses is configured
with --without-curses-h, so staging_dir/hostpkg/include/ncursesw/ has
no curses.h of its own to genuinely detect - a real "yes" here could
only ever come from the build host's own /usr/include/ncursesw/
curses.h (e.g. Fedora's ncurses-devel), the exact distro-shadowing
this override block exists to prevent.
Verified end to end: clean host python3 rebuild against unmodified
current ncurses compiles Modules/_cursesmodule.c and
Modules/_curses_panel.c without error, and the resulting
staging_dir/hostpkg python3.14 successfully `import curses` with
unget_wch present.
Fixes: d883c02a41 ("python3: pin host curses to the SDK's narrow ncurses")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
userpath adds to and removes from the user's PATH. Its only consumer in
the feed was pipx, which has just been removed, so python-userpath now
has no users. Remove it as well.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
pipx installs and runs Python applications in isolated virtual
environments. That workflow sees little use on OpenWrt's embedded
targets, and keeping the package current has become a recurring
maintenance burden as upstream keeps adding build- and run-time
dependencies to support it. Nothing in the feed depends on pipx, so
remove it.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
Refresh sha256 from PyPI sdist. Drop the macOS cross-compile patch;
2.1.1 already carries the sysconfig.get_platform() fix upstream.
Add test-version.sh: 2.1.1 ships the cffi-gen-src console tool, a
subcommand CLI with no version flag, so the generic per-executable
version probe fails the package ("No executables in the package
provided version"). test-version.sh skips that probe, and test.sh now
asserts cffi.__version__ against the packaged version.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
Refresh sha256 from the PyPI sdist and refresh 003 for the shifted line.
Retarget 002-pip-runner-pyc-fix.patch instead of dropping it: in 26.2.1
get_runnable_pip() moved from build_env.py (now a package) to
_internal/utils/misc.py. The function is otherwise unchanged and still
returns __pip-runner__.py, so the .pyc fallback is still required. We ship
pip byte-compiled only (the .py sources live in the -src package), so
without it build isolation cannot locate the runner and every PEP 517
install fails on target. This is a packaging workaround, not an upstream
bug, so upstream has no reason to carry it.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
Refresh sha256 from PyPI sdist. Upstream renamed the sdist to use an
underscore (pytest_forked-1.7.5.tar.gz), so set PYPI_SOURCE_NAME.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
Refresh sha256 from PyPI sdist. 1.6.0 switched its build backend from
setuptools to hatchling, so build-depend on python-hatchling/host.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
Pillow uses pybind11 only for pybind11.setup_helpers.ParallelCompile,
which parallelises the C extension build; it ships no runtime bindings.
Patch setup.py to remove that import and call and drop pybind11 from
build-system.requires, then remove python-pybind11/host from
PKG_BUILD_DEPENDS. The C extensions are compiled serially instead, with
no functional change to the package.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
flit-core 4.0.2 breaks the whole python feed. flit-core is a host-only
build backend, but nearly everything built with it caps flit_core<4 (the
host tools wheel/installer/pyproject-hooks/typing-extensions and dozens of
leaf packages like marshmallow, click, pip), so their host builds fail with
"Missing dependencies: flit_core<4" against 4.0.2. Nothing needs
flit_core>=4; 3.12.0 satisfies every cap and has no runtime impact. Revert
until the ecosystem's upper bounds catch up.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
installer caps flit_core<4 in its build-system, so its /host build fails
with "Missing dependencies: flit_core<4" against flit-core 4.0.2. flit_core
4 builds it unchanged; relax the upper bound.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
pyproject-hooks caps flit_core<4 in its build-system, so its /host build
fails with "Missing dependencies: flit_core<4" against flit-core 4.0.2.
flit_core 4 builds it unchanged; relax the upper bound.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
Like python-wheel, typing-extensions caps its build backend at
"flit_core >=3.11,<4", so python-typing-extensions/host fails with
"Missing dependencies: flit_core<4,>=3.11" now that the feed ships
flit-core 4.0.2. flit_core 4 builds it unchanged; relax the upper bound.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>