Description:
After the latest update on the Testing branch (2026-04-08), AwesomeWM fails to start and immediately drops back to the display manager (LightDM). The issue seems to be a compatibility regression between the new glib2 / harfbuzz versions and lua54-lgi.
System Info:
Branch: Testing
WM: Awesome v4.3-1735-gfa805ab46 (git version)
Lua: 5.4.8
LGI:extra/lua54-lgi 0.9.2-13
Kernel: 6.18.21-1-MANJARO
Packages causing the issue:
glib2 (2.86.4-1 → 2.88.0-1)
harfbuzz (13.2.1-1 → 14.0.0-2)
Error Log (traceback from startx):
error: /usr/share/lua/5.4/lgi/ffi.lua:87: bad argument #1 to 'fromarray' (lgi.record expected, got table)
stack traceback:
[C]: in field 'fromarray'
/usr/share/lua/5.4/lgi/ffi.lua:87: in function 'lgi.ffi.load_enum'
/usr/share/lua/5.4/lgi/override/cairo.lua:55: in main chunk
...
error: /usr/share/awesome/lib/gears/color.lua:137: attempt to call a nil value (field 'create_rgba')
Temporary Workaround:
Downgrading the following packages and adding them to IgnorePkg resolves the issue: glib2 glib2-devel harfbuzz harfbuzz-icu
It appears that lua54-lgi needs a rebuild against the new glib2 headers, or there is a breaking change in how GObject Introspection handles records/tables in the new release.
Thanks for the suggestion, @jofi. I attempted a clean rebuild of the package (awesome54-git) in a GitHub Actions CI environment using the archlinux:base-devel image to ensure a pristine build state.
Even in this clean environment, the build fails during the configuration stage. This confirms the issue is a systemic incompatibility between the current repository packages and not related to local configuration.
Build log error (from clean Docker container):
[ 2%] Checking for LGI...
Building for Lua 5.4.
Found lgi 0.9.2.
Error: /usr/share/lua/5.4/lgi/ffi.lua:87: bad argument #1 to 'fromarray' (lgi.record expected, got table)
WARNING
=======
The lgi check failed.
Awesome needs lgi to run.
Add AWESOME_IGNORE_LGI=1 to your environment to continue.
make[2]: *** [CMakeFiles/lgi-check-run.dir/build.make:71: CMakeFiles/lgi-check-run] Error 1
Key takeaways:
The build fails even on a fresh Arch-based system with the latest updates.
The lgi-check utility (run by CMake) crashes immediately when trying to interface with the new glib2 (2.88) stack.
Since lua54-lgi is provided as a binary in the extra repository, it appears the package is effectively broken for any Lua 5.4 application relying on GObject Introspection on the current Testing branch.
Is there a plan to patch or rebuild lua54-lgi to handle the changes in GObject Introspection data structures?
I’ve confirmed this is an upstream Arch issue using a clean archlinux:base-devel Docker container on GitHub Actions. Since I don’t have an Arch GitLab account, could one of the Manjaro maintainers escalate this to the Arch packaging team? It’s a blocker for all AwesomeWM builds. When you try to build on lua54(im not sure what happens on when i try to build it on lua53, but i guess same result)
“escalate” sounds funny But seriously I can’t see there is anything wrong about packaging. AwesomeWM claims to build with Lua 5.1-5.4 and even refuses the latest one. But as it looks it doesn’t build with Lua 5.4. This is something for the AwesomeWM developers first. Do they have working gobject bindings for Lua 5.4? How about updating to the latest Lua version? Are you certain the problem is in the binding package and caused by the packager (rather than the upstream developers of the binding package)? I think they should figure out first what the issue is - “they” refers to the AwesomeWM developers.
Hi @jofi, thanks for the reply! No offense taken on the “escalate” wording — just trying to figure out where the chain broke so we can get things working again.
Just to clarify the technical side: this is not an AwesomeWM bug. AwesomeWM actually builds and runs perfectly fine with Lua 5.4.
The build is failing because CMake runs a pre-flight sanity check (lgi-check) to see if the system’s lua-lgi can communicate with GObject Introspection. Because lua-lgi crashes when trying to talk to the new glib2 2.88, the AwesomeWM build cleanly aborts. AwesomeWM is just the victim here.
You are completely right on your second point, though: the root cause is very likely an upstream issue in the lua-lgi binding package itself (inability to parse the new data structures in GLib 2.88).
Since lua-lgi upstream is updated very infrequently (0.9.2 is quite old), when core system libraries like glib2 break it, distributions (like Arch) usually have to apply a patch to the package in the repositories to keep the system functional.
My main goal was just to flag that extra/lua54-lgi is currently broken on the Testing branch for any application that uses it. If anyone happens to know if Arch is tracking a patch for lua-lgi to fix this GLib 2.88 breakage, that would be the actual solution here!
In my ISO which linked there is a LUA54 version of awesome.
Following up on my previous message, I have a technical question regarding my CI setup.
So far, I have been building my packages on GitHub Actions using the official archlinux:base-devel Docker image. It worked well for a while, but as we’ve seen with the current glib2 issue, it can be too “bleeding edge” for a stable workflow.
Since my goal is to target Manjaro Stable to ensure maximum reliability for the users, I am planning to switch my CI container to: image: manjarolinux/build-stable:latest (Am i on the correct image?)
In your opinion, is this the correct “official” way to mirror the Manjaro Stable environment in GitHub Actions, or is there another image/toolset the Manjaro team recommends for automated package building?
Thank you for your patience and for helping a “GitLab noob” find the right path!
One more quick technical follow-up: I was just checking Docker Hub to prepare my migration from archlinux:base-devel to a Manjaro-native environment.
I noticed that manjarolinux/build-stable hasn’t been updated in 5 years, so I assume it’s deprecated. However, the general manjarolinux/build image was updated 18 days ago.
Is manjarolinux/build the current standard for CI/CD? And if so, does it point to the Stable branch by default, or should I manually configure the mirrors within the container to ensure I’m building against Stable libraries (to avoid the current glib2 issues on Testing/Unstable)?
I’d love to hear what the official team’s workflow is for automated package builds.
Sorry, I really don’t know much about any of that. I build everything manually with chrootbuild. @philm and @boredland would know more about CI & Docker stuff.
@Yochanan thank you for your patiance, and mention who would know those things, what i ask you, i already know what i was think was true, couse manage to fix my github action yaml to use manjaro stable image.
Looks like Arch just rebuilt those things what mention in this topic and the Arch gitlab-forum or whatnot as well, couse today i run my builder with arch dev image and sucessfully built my custom awesome pckg without modifying anything in the PKGBUILD.
[07:19:00] INFO: ✅ Successfully built awesome54-git
[07:19:00] INFO: ARTIFACT_FROM_BUILT_FILES pkg=awesome54-git ver=4.3.1736.g994f9d6ed-1
[07:19:00] INFO: [VERSION_TRUTH] PKGBUILD: 4.3.1735.gfa805ab46-1, Artifact: 4.3.1736.g994f9d6ed-1
[07:19:00] INFO: [VERSION_TRUTH] Using artifact version for VCS package: 4.3.1736.g994f9d6ed-1
[07:19:00] INFO: 🔐 Signing ALL built packages for version 4.3.1736.g994f9d6ed-1...
[07:19:00] INFO: ✅ Builder user has access to GPG secret key for signing
[07:19:00] INFO: 🚀 Attempting to sign: awesome54-git-4.3.1736.g994f9d6ed-1-x86_64.pkg.tar.zst
[07:19:00] INFO: Using GPG key: ***
[07:19:00] INFO: Output signature: awesome54-git-4.3.1736.g994f9d6ed-1-x86_64.pkg.tar.zst.sig
Again thank you for the patience and try to show the way for both of you @Yochanan and @jofi
But seriously I can’t see there is anything wrong about packaging. AwesomeWM claims to build with Lua 5.1-5.4 and even refuses the latest one. But as it looks it doesn’t build with Lua 5.4. This is something for the AwesomeWM developers first. Do they have working gobject bindings for Lua 5.4? How about updating to the latest Lua version? Are you certain the problem is in the binding package and caused by the packager (rather than the upstream developers of the binding package)? I think they should figure out first what the issue is - “they” refers to the AwesomeWM developers.
