Skip to content

Tracking: Bump Lua dependencies #570322

Open

Description

@Skyb0rg007

Lua 5.2 was released in 2011, and had its last patch released in 2015. It was the default behind pkgs.lua before #569839.

#569839 has landed: lua and lua5 are now convenience aliases for lua5_5_compat, and luaPackages aliases lua55Packages. Existing package dependencies were made explicit as lua5_2_compat or lua52Packages, so changing the aliases did not migrate those consumers.

This tracker covers those remaining package migrations, unused-input removals, and Lua module compatibility fixes. Completion can also mean deliberately following another interpreter, or removing an obsolete package; it does not mean every package must use Lua 5.5. Check a box only when the corresponding Nixpkgs change has landed. An upstream fix or a prerequisite module fix alone does not complete a consumer migration.

The suggestions listed here (ex. "lua (5.2) → drop") were generated by AI; please do not blindly accept the written conclusions

It’s just meant to be a starting point for the package maintainers. Anyone making a PR must test the code and understand the changes made.

Status and remaining-work descriptions were reconciled on 2026-10-27 against Nixpkgs master 847a58f3686a, live PR states, upstream PRs and commits, and LuaRocks releases. These tracker updates were assisted by Codex (GPT-6.1) and Claude Code (Claude Opus 5.5); no package builds or runtime tests were rerun for the tracker edits.

Remove the Lua input

These are unused-input candidates, not automatic drops. The before/after output and dependency-history audit covers x86_64-linux only. Per-package verification is still needed, especially for optional features, system-versus-vendored Lua, and other platforms.

  • alephone (lua (5.2) → drop): Builds its vendored Lua 5.2. no maintainer alephone: drop unused lua input #571424
  • animeko (lua5_2 → drop (verify)): Only for autoPatchelf of VLC libs that get deleted; meta.broken. cc @pokon548
  • bam (lua5_3 → drop): Builds its vendored Lua 5.3. cc @7c6f434c
  • desmume (lua (5.2) → drop): Lua is disabled in the meson build. no maintainer
  • duckmarines (lua (5.2) → drop): LÖVE game; runs on LuaJIT. no maintainer
  • ete-unwrapped (lua5_4 → drop): No Lua in the source. cc @ashleyghooper @drupol fix in ete-unwrapped: 0-unstable-2025-08-17 -> 0-unstable-2026-06-21 #570416
  • freeciv (lua5_3 → lua5_4 + --enable-sys-lua=yes (lua5_5 with Freeciv 3.3)): 3.2 wants exactly 5.4, else silently builds its bundled copy. cc @nbp
  • fsuae (lua (5.2) → drop): Uses its own Lua 5.2; off by default. cc @c4patino
  • hawkthorne-journey (lua (5.2) → drop): LÖVE game; runs on LuaJIT. cc @liberodark {skyemu,hawkthorne-journey,pdns-recursor}: drop unused lua input #570799
  • libresprite (lua (5.2) → drop): No Lua in the source. cc @fgaz
  • lutris (lua (5.2) → investigate): Removing Lua changes the FHS runtime environment. The DeSmuME runner checked in the output-comparison audit has no Lua in DT_NEEDED, but runtime loading is unverified; test the runner before choosing a drop or another ABI. cc @Steinhagen
  • mrrescue (lua (5.2) → drop): LÖVE game; runs on LuaJIT. no maintainer
  • openscenegraph (lua (5.2) → drop or restore system Lua): luaSupport is off by default; even when enabled, OSG_USE_LOCAL_LUA_SOURCE selects bundled Lua 5.2.3. Decide whether to use system Lua, and preserve or explicitly migrate the override interface. cc @aanderse @7c6f434c
  • oxwm (lua5_4 → drop): Builds its vendored Lua 5.4.8. cc @tonybanters
  • pdns-recursor (lua (5.2) → drop lua): Uses LuaJIT, also in buildInputs. cc @rnhmjoj {skyemu,hawkthorne-journey,pdns-recursor}: drop unused lua input #570799
  • pktgen (lua5_3 → drop): enable_lua is off. cc @abuibrahim @stepbrobd pktgen: fix gcc16 build and drop unused inputs #570823
  • proxmark3 (lua (5.2) → lua5_4): Only finds lua5.4, else builds its bundled copy. cc @nyanotech @emilytrau
  • radare2 (lua (5.2) → drop unused input): radare2 6.x has no Lua bindings. Removing luaBindings/lua also changes the override and config.radare interfaces; preserve compatibility or document the migration. cc @NixOS/redis
  • skyemu (lua (5.2) → drop): Builds its vendored Lua 5.4.7. cc @liberodark {skyemu,hawkthorne-journey,pdns-recursor}: drop unused lua input #570799
  • swiften (lua (5.2) → drop): Only Sluift uses Lua, and it is not installed. The before/after installed outputs were equivalent apart from build nondeterminism; patching out Sluift is not required for this drop. cc @Twey
  • teeworlds (lua5_3 → drop): The CMake build doesn't use Lua. cc @Luflosi
  • the-powder-toy (lua5_2 (+ luajit) → drop lua5_2): Uses LuaJIT, also in buildInputs. cc @siraben
  • unvanquished (lua (5.2) → drop): Only the game logic uses Lua, and it isn't built. cc @NixOS/redis
  • widelands (lua (5.2) → drop): Builds its vendored Eris (a Lua 5.3 fork). cc @7c6f434c @jcumming
  • wordgrinder (lua52Packages → drop unused refs or restore system Lua): The current Makefile ignores LUA_INCLUDE/LUA_LIB and uses bundled Lua 5.1. Choose whether to drop those inputs or select system Lua through LUA_PACKAGE; the latter changes the output and needs testing. The LUA_CPATH wrapper is also unused. cc @matthiasbeyer

Fix the Lua version used today

These are already wrong, independent of Lua 5.5.

  • dit (lua (5.2) → lua5_3): Only uses a system Lua ≤ 5.3, else builds its bundled copy. cc @davidak
  • ibus-engines.pinyin (lua (5.2) → patch lua/base.lua, then lua5_5): Already broken on 5.3+; ibus-libpinyin has the fix. cc @azuwis ibus-engines.pinyin: use lua 5.5 #571975
  • icesl (lua (5.2) → update to 2.5.3 and switch to lua5_1): Tested. Current hashes fail; the binary needs the 5.1 ABI. cc @mgttlinger

Ready for Lua 5.5

Upstream supports 5.5 in the packaged version, or it was tested working.

Supported upstream in a newer version

Some entries need a package update or backport before switching to Lua 5.5; see each entry for the remaining work.

Likely works: test-build with Lua 5.5

These were candidates from source review. Builds and checks of the actual Lua integration are still required; package-specific blockers and upstream fixes are noted below.

  • apacheHttpd (lua (5.2) → lua5_5): Any Lua ≥ 5.1; off by default. cc @arcayr
  • apk-tools (lua5_3 → lua5_5 + -Dlua_version=5.5): lua-zlib now supports newer Lua; retain the optional Lua integration and verify it with the matching module set. no maintainer (lua-zlib fixed in luaPackages.lua-zlib: unmark broken on Lua 5.4 and newer #571063)
  • asc (lua (5.2) → lua5_5): No upper bound; scripts pass luac -p. cc @7c6f434c
  • asterisk (all variants) (lua (5.2) → lua5_5): No upper bound. cc @auntieNeo @DerTim1 @yorickvP
  • bozohttpd (lua (5.2) → lua5_5): NetBSD builds it with 5.4. cc @liclac
  • cadzinho (lua5_4 → lua5_5): Installed scripts pass luac -p. cc @sikmir
  • celestia (lua (5.2) → lua5_5 (or lua5_4)): Unversioned find_package(Lua). cc @returntoreality @pancaek
  • collectd (lua (5.2) → lua5_5): Any Lua ≥ 5.1. cc @bjornfor
  • devilspie2 (lua (5.2) → lua5_5): Falls back to the generic lua. no maintainer devilspie2: use lua5_5 #571430
  • dnsdist (lua (5.2) → lua5_5): Any Lua ≥ 5.1. cc @jojosch
  • domino-chain (lua (5.2) → lua5_5): Themes pass luac -p. cc @fgaz
  • domoticz (lua5_3 → lua5_4 (5.5 plausible)): 5.3 is a minimum. cc @nuxeh @LennyPenny
  • eiskaltdcpp (lua (5.2) → lua5_5): Unversioned find_package(Lua). no maintainer
  • elinks (lua (5.2) → lua5_5): No version restriction. cc @iblech
  • emacsPackages.lua (lua (5.2) → lua5_5): Follows lua.luaversion. cc @nagy
  • flycast (lua (5.2) → lua5_5): 5.2 is a minimum. cc @tallesCoelho
  • freeswitch (lua (5.2) → lua5_5): Falls back to the generic lua. cc @MikaelFangel
  • frr (lua53Packages.lua → lua5_4 (then 5.5)): Any Lua ≥ 5.3; docs say 5.3. cc @woffs @thillux
  • geeqie (lua5_3 → lua5_5): Any Lua ≥ 5.3. cc @pSub @markus1189
  • gittyup (lua5_4 → lua5_5): Unversioned find_package(Lua). cc @FliegendeWurst @phijor
  • gnuplot (lua (5.2) → lua5_5): Tries lua.pc first; off by default. no maintainer
  • gpick (lua (5.2) → lua5_5): Any Lua ≥ 5.2. cc @VergeDX
  • grafx2 (lua (5.2) → lua5_5 + upstream fixes): The Lua discovery and installed sample-script fixes are upstream; a Nixpkgs backport/update and runtime verification are still pending. no maintainer; upstream https://gitlab.com/GrafX2/grafX2/-/merge_requests/396
  • gravit: Removed rather than migrated to Lua 5.5. no maintainer gravit: drop #571717
  • grilo-plugins (lua5_4 → lua5_5): Any Lua ≥ 5.3. cc @NixOS/gnome grilo-plugins: use lua 5.5 #583191
  • gswatcher (lua5_4 → lua5_5): Any Lua ≥ 5.4. cc @pluiedev
  • highlight (lua (5.2) → lua5_5): All files pass luac -p; big rebuild. no maintainer
  • librime-lua (lua (5.2) → lua5_4 (or 5.5)): User scripts make 5.4 safer. cc @jian-lin @xddxdd
  • libtas (lua5_4 → lua5_5): Falls back to the generic lua. cc @skyrina
  • libucl (lua (5.2) → lua5_5): No upper bound; off by default. cc @jpotier
  • luabind (lua5_1 → test-build): Move with soi and icesl. no maintainer
  • lunarml (lua5_3 → lua5_4 (then 5.5)): Check phase only. cc @toastal @ratsclub
  • lutok (lua (5.2) → update to 0.6.3 + lua5_4): 0.4 is stale; gates atf and kyua. cc @reckenrode
  • lxi-tools (lua (5.2) → lua5_5): Any Lua ≥ 5.1. cc @vq
  • megaglest (lua (5.2) → test-build): CMake already lists 5.5. cc @matejc
  • mgba (lua (5.2) → lua5_5): CMake's FindLua knows 5.5. cc @Gliczy
  • midimonster (lua5_4 → lua5_5): Falls back to the generic lua. cc @keldu
  • mmex (lua (5.2) → lua5_5): 5.5.0 reported working. no maintainer
  • monotone (lua (5.2) → lua5_5 + test patch): A test assigns to a for variable. cc @7c6f434c
  • mympd (lua5_4 → lua5_5): 5.4 is a minimum. cc @doronbehar mympd: use Lua 5.5 #572508 mympd: 26.0.0 -> 26.1.0 #572884; upstream Lua dump callback fix: Fix: Handle the empty final Lua dump callback jcorporation/myMPD#1573
  • nbfc-linux (lua5_4 → lua5_5): Falls back to the generic lua. cc @Celibistrial @bohanubis
  • neomutt (lua (5.2) → lua5_5): Tries the generic lua first; off by default. cc @erikryb @RaitoBezarius @ethancedwards8
  • onscripter (lua5_1 → test-build / keep): Games target 5.1. cc @midchildan
  • orthanc (lua (5.2) → lua5_4 (or 5.5)): Upstream uses 5.4. no maintainer
  • osm2pgsql (lua (5.2) → lua5_5): Unversioned find_package(Lua). cc @NixOS/geospatial osm2pgsql,tilemaker: use lua5_5 #571454
  • owntracks-recorder (lua (5.2) → lua5_5): Uses pkg-config lua. cc @aionescu
  • pdns (lua (5.2) → lua5_5): Any Lua ≥ 5.1. cc @Mic92 @NickCao
  • pinsel (lua (5.2) → lua5_5): Uses pkg-config lua. no maintainer
  • roccat-tools (lua (5.2) → lua5_5): Any Lua ≥ 5.1. no maintainer
  • rocqPackages.mathcomp (lua (5.2) → lua5_5): Only for a doc script. cc @vbgl @jwiegley @CohenCyril
  • rpm (lua5_4 → lua5_5): 5.2 is a minimum. no maintainer
  • rtorrent (lua5_4_compat → lua5_5): No upper bound; off by default. cc @thiagokokada
  • slurm (lua (5.2) → lua5_5): Any Lua ≥ 5.1. cc @markuskowa @edwtjo
  • snis-unwrapped (lua5_2 → lua5_5 (or lua5_4)): Falls back to the generic lua. cc @cyclic-pentane
  • texworks (lua (5.2) → lua5_5): CMake's FindLua knows 5.5. cc @dotlambda
  • tilemaker (lua (5.2) → lua5_5): Upstream already builds against 5.5 headers. cc @NixOS/geospatial osm2pgsql,tilemaker: use lua5_5 #571454
  • tio (lua (5.2) → lua5_5): Falls back to the generic lua. no maintainer tio: use Lua 5.5 #572513
  • tym (lua5_3 → lua5_5 (or lua5_4)): Tries the generic lua first. cc @wesleyjrz @kashw2
  • uhttpd (lua5_1 → test-build / keep): LuCI scripts need 5.1. cc @haylinmoore
  • weechat (lua5_3 → lua5_4 safe, lua5_5 likely): Verify scripting with the selected interpreter; weechat-matrix-bridge was removed in weechatScripts.weechat-matrix-bridge: drop #570683 and no longer needs a coordinated migration. cc @wahjava
  • weston (lua5_4_compat → lua5_5): 5.4 is a minimum; _compat is unneeded. cc @alyssais
  • xmoto (lua (5.2) → lua5_5): Bundled levels pass luac -p. cc @7c6f434c @pSub

Move up to Lua 5.4

The packaged versions have Lua 5.5 blockers. Some now have upstream fixes linked below; a Nixpkgs update or backport and verification are still needed.

Still on Lua 5.2, with no newer Lua upstream

These packages use Lua 5.2 today, and their packaged versions support only Lua 5.2 or older, or LuaJIT, so none of them can move to Lua 5.5 without patching. Completion means a deliberate choice: keep Lua 5.2, switch to LuaJIT where upstream accepts it, or patch the package. Together with VLC 3.0.x, these decide whether Lua 5.2 can be removed from Nixpkgs; mpv-unwrapped is likely the most widely used. Neovim is not listed: it uses LuaJIT, or Lua 5.1 where LuaJIT is unavailable, so it does not depend on Lua 5.2. These entries were checked against the packaged sources at Nixpkgs master 0657ebd01dc3; no packages were built.

  • cardpeek (lua5_2 → keep, or lua5_3_compat (untested)): 0.8.4 (2015), the latest release, calls luaL_checkint, which Lua 5.3 keeps only in compatibility mode, and its EMV script calls bit32, which Lua 5.4 removed. Unreleased upstream master ports the C calls to Lua 5.3 (L1L1/cardpeek@d0653e73af) but still uses bit32. cc @liclac
  • enlightenment.efl (lua5_2_compat → keep, or luajit): 1.28.1's lua-interpreter option is luajit or lua, and the lua path accepts only Lua 5.1 or 5.2. Nixpkgs enables elua and the Lua bindings. cc @matejc @romildo @NixOS/enlightenment
  • lite (lua52Packages.lua → keep, or patch for newer Lua): Nixpkgs replaces the vendored Lua 5.2 with system Lua. On Lua 5.3 and newer, data/core/statusview.lua passes a float to string.format("%d%%", …), which raises an error whenever the file-position percentage is not a whole number. This was found by reading the source; lite itself was not run on newer Lua. 1.11 (2020) is the latest release, with no upstream commits since 2021; the maintained fork lite-xl already uses lua5_4. no maintainer
  • mpv-unwrapped (lua5_2_compat → keep, or luajit): 0.41.0 accepts the generic lua.pc only at >=5.1.0, <5.3.0, the lua52/lua51 names, or LuaJIT; Lua 5.3 and newer are not accepted. LuaJIT follows Lua 5.1 semantics with some 5.2 extensions, so user scripts and mpvScripts need testing before a switch. cc @uninsane @fpletz @SchweGELBin
  • pioneer (lua5_2 → keep): Upstream master still requires exactly Lua 5.2 for system Lua (find_package(Lua 5.2 EXACT)) and otherwise builds its bundled Lua 5.2.2. Building the bundled copy would remove the Nixpkgs dependency, not Lua 5.2 itself. no maintainer

Consumer migrations after Lua module fixes

Lua ecosystem

Activity

  1. added
    5.scope: trackingLong-lived issue tracking long-term fixes or multiple sub-problems
    6.topic: luaLua is a powerful, efficient, lightweight, embeddable scripting language.
    on Oct 5, 2026
  2. doronbehar commented on Oct 5, 2026

    @doronbehar
    Contributor

    If so many of these packages support lua5.5 without any further changes, why not switch the default lua for everyone to 5.5, and let stuff break and fix only if needed?

  3. added
    llm-assistedContributions that include code generation with LLMs
    on Oct 5, 2026
  4. Skyb0rg007 commented on Oct 5, 2026

    @Skyb0rg007
    ContributorAuthor

    If so many of these packages support lua5.5 without any further changes

    The summaries here are entirely AI generated (as I noted at the top). I don’t think it’s a good idea to merge a treewide update without some human testing and confirmation.

    Edit: the other reason is that I’m changing pkgs.lua into an alias, not just changing the assignment. So I can’t just “make pkgs.lua 5.5 and see what breaks” because nixpkgs derivations can’t depend on aliases.

  5. added a commit that references this issue on Oct 5, 2026
  6. lucc commented on Oct 5, 2026

    @lucc
    Contributor

    For nvimpager:

    Yes, busted is a test only dependency but my reasoning is that it loads and tests the lua code that should be executed by lua 5.1 at runtime (inside neovim). It seems that neovim will not change their lua version (see :help lua-compat).

    For that reason I would argue not to switch.

    Should I annotate the nix code to explain this?

  7. khaneliman commented on Oct 5, 2026

    @khaneliman
    Contributor

    For nvimpager:

    Yes, busted is a test only dependency but my reasoning is that it loads and tests the lua code that should be executed by lua 5.1 at runtime (inside neovim). It seems that neovim will not change their lua version (see :help lua-compat).

    For that reason I would argue not to switch.

    Should I annotate the nix code to explain this?

    That makes sense. Keeping the tests compatible with Neovim’s Lua 5.1 interface seems preferable to switching them to 5.5.

    Could we use neovim-unwrapped.lua.pkgs.busted instead? Neovim recommends LuaJIT on supported platforms, and this would follow the interpreter selected by our Neovim package, including its plain Lua 5.1 fallback.

  8. Skyb0rg007 commented on Oct 5, 2026

    @Skyb0rg007
    ContributorAuthor

    For that reason I would argue not to switch.

    Makes sense to me, though I think neovim uses luajit (at least on Linux).

    Should I annotate the nix code to explain this?

    That would be very helpful to make sure no one tries to bump it to lua5_6 in a few years.

  9. pbsds commented on Oct 5, 2026

    @pbsds
    Member

    Disclaimer: My only insight into the current lua status is what i learned from this post on lobse.rs: https://hisham.hm/2026/08/04/the-lua-community-needs-to-learn-to-move-on/

    If so many of these packages support lua5.5 without any further changes, why not switch the default lua for everyone to 5.5, and let stuff break and fix only if needed?

    I'm inclined to just try and do this, and then later convert the lua attribute to an alias maybe. However we are in the process of stabilizing a new release, perhaps we should hold of on this until after branch-off?

    In the meanwhile, package-wise migrations i think is the way to go. 👍

  10. added a commit that references this issue on Oct 5, 2026
  11. Skyb0rg007 commented on Oct 5, 2026

    @Skyb0rg007
    ContributorAuthor

    I'm inclined to just try and do this, and then later convert the lua attribute to an alias maybe. However we are in the process of stabilizing a new release, perhaps we should hold of on this until after branch-off?

    This was actually triggered due to #569726, so I don't think trying to complete this before the release is a terrible idea.
    Though that thread (and #323083) goes over a lot of the issues in doing so.

    In the meanwhile, package-wise migrations i think is the way to go. 👍

    Yep, and I think per-package migrations is the right move even in the future.

    The issue with nixpkgs and that blog post is that lua51Packages and lua55Packages are constructed from the same sources, so we can't support older Lua versions in the same way.

  12. whispersofthedawn commented on Oct 6, 2026

    @whispersofthedawn
    Contributor

    i've just merged #570699, which unchecks some of the boxes up at the top by reverting #570393. someone other than an LLM needs to do the verification that this mass removal doesn't cause issues. for anyone who wants to reland this change, i'll say the same thing i said in that revert pr:

    for whoever wants to reland this: i highly recommend looking at diffoscope for these sorts of changes (unused dependency removals). the easiest way to ensure a dependency is actually unused is to compare the outputs before and after, which diffoscope is great for. if you can do this and see that for each of these, removing lua makes no change to the output (besides self-referencing store paths), you've demonstrated an extremely strong property and there is very little risk of regressions from this change. (there are also removals that might be correct that do cause a difference in output, but of course you still need to be able to explain why they're correct.)

    also, if you want to remove an unused dependency, please aim to understand why it was present in the first place. for example, even if you can show there is no difference in diffoscope output, it might be the case that someone added the lua dependency to avoid using a vendored lua, and that's no longer working. the correct course of action might be to switch from a vendored lua to a nixpkgs lua. we don't want to go breaking down Chesterton's fence without knowing why it was put there in the first place.

  13. 11 remaining items

  14. added a commit that references this issue on Oct 12, 2026
  15. added a commit that references this issue on Oct 12, 2026
  16. lucc commented on Nov 3, 2026

    @lucc
    Contributor

    About markdown:

    It seems that the upstream repo is inactive. There are lingering issues and PRs discussing lua compatibility. We could include patches from there.

    But our only consumer of the lua markdown package seems to be ldoc (I checked pkgs/development/lua-modules/generated-packages.nix and pkgs/development/lua-modules/overrides.nix; ldoc itself is only used by awesome WM and the sile typesetter). And the ldoc project also noticed the stale and incompatible upstream: lunarmodules/ldoc#437
    So we could also wait for the ldoc people to finish their fork and switch to it. (Hopefully that happens soon enough for the NixOS release)

    Or we could mark the consumers as "broken on lua 5.5" to make it easier or clearer for users how to steer clear of the build failure.

    What would be the best solution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.skill: sprintableA larger issue which is split into distinct actionable tasks5.scope: trackingLong-lived issue tracking long-term fixes or multiple sub-problems6.topic: luaLua is a powerful, efficient, lightweight, embeddable scripting language.llm-assistedContributions that include code generation with LLMs

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions