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>
Fix stripping when using previous version as a bootstrap.
Fixes: 5657eb0e2 ("golang: split src into separate packages")
Signed-off-by: George Sapkin <george@sapk.in>
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>
RUSTC_TARGET_ARCH comes from the GNU triple, so every 32-bit PowerPC
subtarget gets powerpc-unknown-linux-musl. That triple is hard-float and
mpc85xx is not: its e500v2 has no floating-point unit, and the toolchain
reports _SOFT_FLOAT and calls __divdf3 for a division.
So rustc emits lfd, stfd and fdiv for a core with no floating-point
registers, and passes doubles in a way nothing else in the image does. It
does not fail outright — a speed test reported negative throughput, and
formatting one of those values tripped an assertion inside core.
Pass -Ctarget-feature=-hard-float where CONFIG_SOFT_FLOAT says so. The same
flag has to reach the std that rust/host builds, or std and the packages
linked against it disagree about how a double is passed.
Signed-off-by: Josef Schlehofer <pepe@bloodkings.eu>
LLVM places the release fence of a cmpxchg between the load-linked and the
store-conditional. On e500v2 that clears the reservation, so the
store-conditional always fails. The strong form retries and re-reserves; the
weak form has no retry and can never succeed.
fetch_update in core is a weak retry loop, so it spins forever and anything
using it hangs. A tokio reactor livelocks on its first I/O event, burning
CPU without issuing a syscall, which makes async Rust unusable on the
subtarget.
Carry the fix as a patch until it reaches a rustc release. It adds a
TargetLowering hook, defaulting to false, so only PowerPC changes.
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Also refresh 020-riscv64-support.patch from the current state of
openresty/luajit2#236. The previous snapshot defined
asm_tail_prep(ASMState *as), but since openresty/luajit2 commit
68354f44 the callers pass a second TraceNo argument, so the riscv64
build failed with:
lj_asm.c:2559:5: error: too many arguments to function 'asm_tail_prep'
The refreshed patch carries the upstream adaptation and restores the
build. The other four patches apply unchanged.
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
luajit2 currently fails to link for powerpc: lj_vm.o emits PLT calls
that force BSS-PLT, which the inline-PLT relocations emitted by GCC 12
and newer do not support. Add the same GOT-based fix that
lang/lua/luajit has carried as 060-ppc-musl.patch since 2019.
With that in place the package builds, but ipairs() and pairs() turn
out to be broken on 32-bit big-endian soft-float targets. Both are
regressions in luajit2's PPC64 patch and do not affect upstream
LuaJIT. To be submitted to openresty/luajit2 as well.
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
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>
Austin Lane
Alexandru Ardelean
George Sapkin
Daniel Golle
Josef Schlehofer
Josef Schlehofer
Wei-Ting Yang