Upstream replaced its Makefile with build-aux/luke, which the 3-1
rockspec runs through the command build type. The override that ran
`make all` to generate version.lua now fails, and luke generates that
file from version.lua.in itself, so drop the override.
The new rockspec also drops std._debug, which std.normalize now loads
optionally through pcall, and ldoc, since releases ship prebuilt
documentation.
Upstream replaced its Makefile with build-aux/luke, which the 1.2
rockspec runs through the command build type. The override that ran
`make all` to generate version.lua now fails, and luke generates that
file from version.lua.in itself, so drop the override.
The generated rockspec may target the generator interpreter rather than the package interpreter. Rewriting only the build target leaves installation compiling a different target, which omits compatibility symbols on Lua 5.1, Lua 5.2 and LuaJIT when the selected rockspec targets Lua 5.5.
Normalize the install target and path variables alongside the existing build rewrite, and align disabled with the supported Lua range. Builds and scheduler/module-loading checks pass on Lua 5.1 through 5.5 and LuaJIT with both the current and Lua 5.5 rockspecs on x86_64-linux.
Assisted-by: Codex (GPT-6.1 Sol)
The rockspec only depends on bit32 on Lua 5.1: 5.2 ships it, and 5.3+
use luaposix's native bitwise module. bit32 is capped below 5.5, so
propagating it everywhere would keep luaposix broken on 5.5 even after
luaposix/luaposix#402 is released.
Assisted-by: Claude (Opus 5.5)
The 0.7.5-1 rockspec on LuaRocks caps Lua below 5.5, but the code works
on 5.5 unchanged. Add a helper that raises the bound, for use until
LuaRocks has rockspecs that allow 5.5.
Assisted-by: Claude (Opus 5.5)
The marker allowed Lua 5.1 to 5.3 and blocked 5.5, but it is the other
way around: before 5.5, Lua aligns userdata to 8 bytes on x86_64 while
luaffi's cdata needs 16, so freeing any cdata segfaults. On aarch64,
call.c falls back to the 32-bit x86 call generator, so C calls fault on
every Lua version.
Assisted-by: Claude (Opus 5.5)
luacheck 1.2.0 built fine on Lua 5.5 but failed at startup, so the
breakage only showed up for users. Run `luacheck --version` as an
install check for every Lua package set.
The check matches the "Luacheck: <version>" banner rather than the bare
version: a startup traceback prints the store path, which contains the
version too, so a bare match would pass on a crash. Building without
the Lua 5.5 patch now fails in this check.
Assisted-by: Claude Code (GPT-6.1-sol)
Assisted-by: Claude (Opus 5.5)
lgi 0.9.2 is still the latest release. It does not compile against Lua
5.4, where lua_resume() gained an argument, and on Lua 5.5 its Lua code
assigns to for-loop control variables, which are now read-only. Both
are fixed upstream but unreleased.
Backport the two fixes and stop marking Lua 5.4 and newer as broken.
The patches can be dropped with the next lgi release.
https://github.com/lgi-devs/lgi/pull/249https://github.com/lgi-devs/lgi/pull/359
Assisted-by: Claude (Opus 5.5)
cqueues 20261006 builds against Lua 5.5. Widen the Lua range the
override writes into the rockspec, and drop the matching broken marker.
Assisted-by: Claude (Opus 5.5)
Lua 5.5 makes for-loop control variables read-only. luacheck 1.2.0
assigns to one while loading its standards, so every run under Lua 5.5
fails with "attempt to assign to const variable 'field_name'".
Backport the upstream fix. It is on master but not in a release yet;
the patch can be dropped with the next luacheck release.
https://github.com/lunarmodules/luacheck/issues/147eea104d82f
Assisted-by: Claude (Opus 5.5)
The marker was added with lua-zlib 1.2 in 2019, when the upstream
rockspec capped Lua below 5.4. Upstream has since removed that cap and
added Lua 5.5 support, and the packaged 1.4 builds and works on both.
The generated package already rejects Lua older than 5.1, so the
override no longer needs its own meta.
https://github.com/brimworks/lua-zlib/issues/49
Assisted-by: Claude (Opus 5.5)
