🐛fix: Tauri AppImage failing to render on wayland + mesa

[DistractionRectangle]

AppImages built with Tauri fail to render with EGL_BAD_PARAMETER on wayland + mesa. This is a side effect of binary stripping in older linuxdeploy builds. Tauri cli pulls in an outdated build of linuxdeploy. This can be fixed by opting out of binary stripping, or by upgrading linuxdeploy. Tauri cli is well behaved in that it doesn't fetch linuxdeploy if it already exists in the cache. This behavior allows us to pin linuxdeploy to any version of our choosing by prepopulating the toolsdirectory with a linuxdeploy binary before calling Tauri cli.

Describe Your Changes

• Pins linuxdeploy version to prevent @tauri-apps/cli-linux-x64-gnu from pulling in an outdated version

Fixes Issues

• Fixes #5305
• Fixes #5367

Self Checklist

• [X] Added relevant comments, esp in complex areas
• [ ] Updated docs (for bug fixes / features)
• [ ] Created issues for follow-up changes or refactoring needed

---

[!IMPORTANT] Pins linuxdeploy version in GitHub workflow to fix Tauri AppImage rendering issues on Wayland + Mesa.

• Behavior:
  • Pins linuxdeploy version in .github/workflows/template-tauri-build-linux-x64.yml to prevent outdated versions causing rendering issues on Wayland + Mesa.
  • Downloads specific linuxdeploy-x86_64.AppImage and sets executable permissions before Tauri CLI execution.
• Fixes:
  • Closes issues #5305 and #5367 related to rendering failures on Wayland + Mesa.

^{This description was created by for 1f1a6fb2e19eea1212e14b0f35ba9a69ae155acf. You can customize this summary. It will automatically update as commits are pushed.}

Edit: correct github keyword from closes to fixes, added some hyperlinks to issue desc for improved context.

[Minh141120]

Hi @DistractionRectangle,

I'm Minh from Menlo Research. First of all, thank you so much for your contribution and for flagging this issue with Tauri's linuxdeploy, as well as for digging into the root cause in issue #5367. We really appreciate the time and care you've put into this.

Following your suggestion, I downloaded the latest linuxdeploy-x86_64.AppImage from this release https://github.com/linuxdeploy/linuxdeploy/releases/download/1-alpha-20250213-2/linuxdeploy-x86_64.AppImage, set TAURI_TOOLKIT_PATH to ${XDG_CACHE_HOME:-$HOME/.cache}/tauri, and moved the binary into that location as linuxdeploy-x86_64.AppImage.

I've tried this setup on both a fresh Fedora Workstation 42 (GNOME desktop) and Ubuntu 22.04. However, I'm still encountering an error during make build-tauri (and make build as well), specifically:

failed to bundle project: failed to run linuxdeploy

We’re actively working on this and continuing to investigate what might be causing the failure. If there's anything else you think we should double-check, your input would be greatly appreciated.

I've attached a screenshot of the terminal output below for reference:

• On Ubuntu
• On Fedora

[DistractionRectangle]

Hi @Minh141120, that's to be expected. That's the other issue I touched upon in #5367, there's a bit of magic in the github release workflow that isn't reflected by the makefile. As I've come to understand it, linuxdeploy drills down the dependency tree of bundled resources and errors when dependencies are missing (as you've just run into). This is normally reasonable, expect when you want dependencies to be provided by the end users' systems. Tauri doesn't provide an escape hatch for this.

What it appears you guys are doing is this, you first remove the resources you intend to bundle from tauri.conf.json, proceed to call make build-tauri (necessary as the make build doesn't call yarn:copylib which is needed when building from a clean slate), throw out the appimage from that build (it's just used to create a skeleton appdir), then you manually copy the resources you intend to bundle to flesh out that app dir and then proceed to manually build the appimage with appimagetool (which doesn't drill down the dependency tree and just bundles the image) [0].

[0] https://github.com/menloresearch/jan/blob/e9b28c5a901c1954d7c4953761887ce991640e01/.github/workflows/template-tauri-build-linux-x64.yml#L174C1-L181C29

[Minh141120]

Hi @DistractionRectangle, thank you so much for the incredibly detailed explanation, your insight has been extremely helpful.

I'll try to get it working locally first, and once everything builds smoothly, I'll proceed with merging your changes. Your thorough breakdown really helped us understand the issue and saved us a lot of time!

By the way, we're planning to move toward a Flatpak distribution for Jan in the near future (issue #5416), which should help us avoid these kinds of packaging issues going forward.

Once again, we greatly appreciate your contribution. I’ll keep you posted here as soon as I make progress.

Thanks again for your support!

[Minh141120]

HI @DistractionRectangle,

Its working now on my fedora machine, the Wayland rendering issue is gone! 🎉🎉. Thanks to your contribution, everything is running smoothly:

We greatly appreciate your help! We’ll be including this in the upcoming v0.6.4 release. Once again, thank you for your contributions. I’ll go ahead and merge both of your PRs: the Tauri fix and the reproducible dev environment via .devcontainer.

[Minh141120]

Hi @DistractionRectangle,

Could you help us rebase your branch with the latest changes from release/v0.6.4 and push the updated commit? That’ll help us proceed with the merge.

[DistractionRectangle]

Rebased on release/v.0.6.4

[Minh141120]

Thank you @DistractionRectangle, I’ll go ahead and merge it once all the CI checks have passed.