Lua stopped shipping a pkg-config file after 5.1; the 5.2, 5.3 and 5.4
release tarballs contain none. Distributions add one to their Lua
packages instead: Debian's liblua5.4-dev ships lua5.4.pc, lua-5.4.pc
and lua54.pc, Alpine's lua5.4-dev ships lua5.4.pc and lua-5.4.pc. Build
systems of Lua consumers look Lua 5.4 up under these names. The package
stages no pkg-config file so far, so such builds cannot find
liblua5.4; the only Lua pkg-config file in the staging directory is
lua.pc of the lua package (5.1.5).
Stage lua5.4.pc, generated from a template with the package version,
and lua-5.4.pc and lua54.pc as links to it. It points to the headers in
/usr/include/lua5.4 and to liblua5.4, and lists libm and libdl as
private libraries for static linking, as the upstream Makefile links
them on Linux.
Of the packages that look up one of these names through pkg-config,
libinput disables its Lua plugin support explicitly in the previous
commit. tio looks up lua-5.4 before lua but depends on lua (5.1), so it
links liblua5.4 without depending on it until the next commit moves it
to Lua 5.4. The others select their Lua version explicitly, look up lua
(5.1) first, build without the feature using Lua, or depend on lua5.4
already.
Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Mirko Vogt <mirko-openwrt@nanl.de>
luaconf.h builds the module search paths out of LUA_ROOT, which upstream
hardcodes to /usr/local, where nothing installs on OpenWrt. LUA_ROOT is
defined unconditionally, but the two macros it feeds, LUA_PATH_DEFAULT
and LUA_CPATH_DEFAULT, are both guarded with #if !defined and are the
only users of it, so set them in TARGET_CFLAGS and drop the patch.
The resulting paths are the ones the patch produced, so the interpreter
behaves exactly as before.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
The three Lua variants of each package install the same files, differing
only in the destination directory, so define LUA_INSTALL_DIR next to the
other per-variant settings and share a single install recipe. Same idiom
as luafilesystem, luasec and luaexpat. No packaged path changes.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
Commit 3fe92e63f5 moved the default Lua 5.4 module search paths
from /usr/local to /usr. luaossl still staged and packaged its Lua 5.4
modules under /usr/local/lib/lua/5.4, outside the default search paths.
Set lua54path and lua54cpath to /usr/lib/lua/5.4 and update the package
install rules to match. Bump PKG_RELEASE to 3 so the corrected package
is offered as an upgrade. Keep Lua 5.1 and Lua 5.3 paths unchanged.
Fixes: 3fe92e63f5 ("lua: look for lua5.4 modules under /usr instead of /usr/local")
Signed-off-by: Jianhui Zhao <zhaojh329@gmail.com>
Commit 3fe92e63f5 moved the default Lua 5.4 module search paths
from /usr/local to /usr. cqueues still staged and packaged its Lua 5.4
modules under /usr/local/lib/lua/5.4, outside the default search paths.
Set lua54path and lua54cpath to /usr/lib/lua/5.4 and update the package
install rules to match. Bump PKG_RELEASE to 3 so the corrected package
is offered as an upgrade. Keep Lua 5.1 and Lua 5.3 paths unchanged.
Fixes: 3fe92e63f5 ("lua: look for lua5.4 modules under /usr instead of /usr/local")
Signed-off-by: Jianhui Zhao <zhaojh329@gmail.com>
Commit 3fe92e63f5 ("lua: look for lua5.4 modules under /usr instead of
/usr/local") changed LUA_ROOT to /usr/, moving the default Lua 5.4
module search paths out of /usr/local. The Lua 5.4 variant of lua-ffi
still installed ffi.so under /usr/local/lib/lua/5.4, so require("ffi")
could no longer find it with the default search paths.
Install ffi.so under /usr/lib/lua/5.4 to match the new default search
path. Bump PKG_RELEASE to 2 so the corrected package is offered as an
upgrade. Keep the Lua 5.1 and Lua 5.3 installation paths unchanged.
Fixes: 3fe92e63f5 ("lua: look for lua5.4 modules under /usr instead of /usr/local")
Signed-off-by: Jianhui Zhao <zhaojh329@gmail.com>
Commit 3fe92e63f5 ("lua: look for lua5.4 modules under /usr instead of
/usr/local") changed LUA_ROOT to /usr/, moving the default Lua 5.4
module search paths out of /usr/local. The Lua 5.4 variant of lua-cjson
still installed cjson.so under /usr/local/lib/lua/5.4, so require("cjson")
could no longer find it with the default search paths.
Install cjson.so under /usr/lib/lua/5.4 to match the new default search
path. Bump PKG_RELEASE to 6 so the corrected package is offered as an
upgrade. Keep the Lua 5.1 and Lua 5.3 installation paths unchanged.
Fixes: 3fe92e63f5 ("lua: look for lua5.4 modules under /usr instead of /usr/local")
Signed-off-by: Jianhui Zhao <zhaojh329@gmail.com>
Commit 3fe92e63f5 ("lua: look for lua5.4 modules under /usr instead of
/usr/local") changed LUA_ROOT to /usr/, moving the default Lua 5.4
module search paths out of /usr/local. lua-eco still installed its Lua
and native modules under /usr/local/lib/lua/5.4, so require() could no
longer find them with the default search paths.
Install modules from the main package and all subpackages under
/usr/lib/lua/5.4, which is searched for both .lua and .so files.
Define LUA_INSTALL_DIR once and use it throughout the install rules so
future directory changes only need one update. Bump PKG_RELEASE to 2
so the corrected packages are offered as upgrades.
Fixes: 3fe92e63f5 ("lua: look for lua5.4 modules under /usr instead of /usr/local")
Signed-off-by: Jianhui Zhao <zhaojh329@gmail.com>
Refresh sha256 from the PyPI sdist.
26.4.0 drops OpenSSL.crypto.X509Req and dump_certificate_request, so
test.sh can no longer import them; remove them and the CSR block. CSR
handling now lives in cryptography.x509, which is not this package.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
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>
Config parameters grabbed from standard libraries and existing Perl
build tree. Tested good on both glibc and musl with simple scripts.
Signed-off-by: Xinhui Yang <cyan@cyano.uk>
curl 8.22.0 removes TLS-SRP support. Explicitly set
PECL_cv_LIBCURL_TLSAUTH_SRP=no to prevent configure from
running a test that fails when cross-compiling.
Signed-off-by: Peter Polonec <polonec.devel@pm.me>
The open-coded architecture list pulls libatomic onto ARMv6K and ARMv7
targets although they inline 64-bit atomics, and still names the
removed arc architecture. ATOMIC64_DEPENDS covers exactly the targets
that need it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
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>
PHP's configure script probes __atomic_exchange_1 as an external
function on riscv64, which only resolves against libatomic, and so
links the library although no binary references an atomic symbol.
The riscv64-only dependency and linker flag paper over that. Link
with --as-needed so the unused library is dropped and remove both;
mips and riscv64 builds import no atomic symbols.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Refresh PKG_HASH from the tag tarball. Upstream moved from
keplerproject to lunarmodules and the 2.7.0 tag has no leading v;
point PKG_SOURCE_URL and the homepage URL at lunarmodules.
Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
Support configuring major version series as host-only (i.e. no target
packages) to reduce strain on buildbots in release branches. The goal is to
have one major target series and multiple host-only ones. E.g. 25.12 uses
1.26 as the default host/target series and 1.27 and beyond as host-only for
packages that require these.
Signed-off-by: George Sapkin <george@sapk.in>
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>
Mirko Vogt
Alexandru Ardelean
Jianhui Zhao
Josef Schlehofer
Xinhui Yang
Peter Polonec
Austin Lane
Daniel Golle
Wei-Ting Yang
George Sapkin
Josef Schlehofer