Add Linux x64 Build Support to Release Pipeline (Ubuntu 24.04/26.04)

[AliRezaTaleghani]

quick way to extend current workflow with Linux friendly ( Ubuntu desktop ) artifacts

Attachments Included:

✅ build_linux.sh - Complete build script for AppImage + .deb
✅ LINUX_BUILD.md - User-facing documentation
✅ make_update_manifest.py - Reference file with changes
Issue Body Contains:

Problem statement (no Linux builds currently)
Solution overview (AppImage + .deb)
Direct download links to all three implementation files
🎯 What's Next
Anyone can now:

Download the three attachment files from the issue
Apply the workflow changes to .github/workflows/release.yml
Update the manifest script with Linux artifact mapping
Test locally on Ubuntu 24.04/26.04
Submit a PR referencing issue #171

build_linux.sh
LINUX_BUILD.md
make_update_manifest.py

[coderdailyone]

Would you take a PR that adds an artifact-only Linux x64 build? Scope: one CI job (PyInstaller onedir + tauri build for AppImage/deb) uploading unsigned artifacts — no updater-manifest entry, no release-page changes, no support commitment implied.

The code side looks ready: state_dir() is XDG-aware, keep-awake is an explicit no-op on Linux, and nothing in the sidecar launch path is macOS/Windows-specific. If Linux is deliberately on hold for support-load reasons, feel free to say so — I didn't want to send an unwanted PR.

[bruce-forte]

Note that not everybody uses Ubuntu. We need a solution that works on any linux. Omarchy comes into mind (Arch).

[coderdailyone]

@bruce-forte Agreed — that's why the artifact-only scope I proposed above centers on AppImage, which is distro-agnostic and runs on Arch (incl. Omarchy) as long as FUSE is available. The .deb would just be a convenience for Debian/Ubuntu users, not the only path.

@rohitprasad15 Given #19 / #173 / #470 / #551 all overlap here — would you take an artifact-only Linux CI job (unsigned AppImage artifacts, no updater-manifest entry, no support commitment implied)? Happy to send a minimal PR, or to help consolidate the existing ones instead.

[luislobo]

@rohitprasad15 — I'm the author of #551, one of the four PRs @coderdailyone listed. I've just tested my own work against the alternatives and concluded mine shouldn't be the base, so let me put the evidence here and consolidate rather than add to the pile.

#551's AppImage is broken, and I only found out by building it. My sidecar fix resolves the absolute path /usr/lib/OpenWorker/sidecar, which is right for an installed .deb and wrong inside an AppImage, where the payload lives at $APPDIR/usr/lib/... under a /tmp/.mount_XXXXXX prefix. I built the AppImage today and checked every candidate the resolver tries:

1. $APPDIR/usr/bin/sidecar/openworker-server      MISS
2. $APPDIR/usr/Resources/sidecar/...              MISS
3. /usr/lib/OpenWorker/sidecar/...   (absolute)   MISS
4. $APPDIR/usr/bin/openworker-server              MISS
   actual: $APPDIR/usr/lib/OpenWorker/sidecar/openworker-server   EXISTS, never checked

It then falls through to the dev fallback, which env!("CARGO_MANIFEST_DIR") bakes into the shipped binary at compile time — on my artifact that is literally a path inside my home directory. On any other machine it doesn't exist, so the app stalls at "Starting coworker…". That's the same symptom @rmanicardi documented in #19. Worth noting it would have passed a naive local test: on the build machine that baked path does exist, so the AppImage appears to work and tells you nothing.

@Nikish-codes's #470 gets this right. Resolving through Tauri's resource_dir() is correct across deb/rpm/AppImage instead of hardcoding one layout. #470 is also the only one of the four with a distro-aware dependency installer — which is the direct answer to @bruce-forte's point above, since it covers Debian/Ubuntu/Mint/Pop, Fedora/RHEL/Rocky/Alma and Arch/Manjaro rather than assuming apt-get. And it has independent cross-distro validation: @marbetschar built and ran it on Fedora 44 (Nikish-codes#1). On #173, @niutech commented that it was superseded by #470 — that was a reader's view rather than its author standing down, and @AliRezaTaleghani hasn't weighed in either way, so I shouldn't have described it as a concession.

So my recommendation is #470 as the base, and I've closed #551.

One thing from #551 worth keeping, which none of #19/#173/#470 have — I've sent it to #470 as Nikish-codes#2. build_linux.sh lets ggml tune whisper.cpp for the build host. A clean Ubuntu 24.04 VM advertised avx2 but not fma; ggml took its AVX2 path anyway and the build failed on _mm256_fmadd_ps: target specific option mismatch. Defaulting the GGML_* flags OFF fixes it. This is a CI-specific hazard: a runner whose CPU flags differ from the target host will either fail to build or emit artifacts that SIGILL on user machines, and that is genuinely painful to diagnose from a CI log. Whichever base you pick, it should carry this.

On @coderdailyone's actual question — artifact-only, unsigned, no updater-manifest entry, no support commitment — that scope seems right to me, and it's mostly a subtraction from #470 rather than new work: drop its make_update_manifest.py changes and keep the CI job emitting unsigned AppImage (plus .deb as a convenience). AppImage is the distro-agnostic piece, so it answers the "not everybody uses Ubuntu" concern without implying you support every distro.

And a process note, offered helpfully: #19 has been open since 23 July, #173 since 26 July, #470 since 7 August, mine since 25 August, and none has had a maintainer comment. That's four people independently solving the same problem and three of us finding out about each other only by accident. Even a one-line "use #470, artifact-only, no manifest" would let this converge immediately — and if Linux is deliberately on hold for support-load reasons, saying so plainly would also be useful. Nobody here would rather keep guessing.

For completeness, voice input and keep-awake are handled in #19 (runtime cpal probe, systemd-inhibit), so between #470 and #19 the Linux story is close to complete.

[luislobo]

Follow-up on my comment above — I've now run the AppImage rather than just reading the resolver, and the runtime evidence is stronger than the path-enumeration I posted.

I instrumented the dev-venv fallback and launched the AppImage from /tmp. The shipped binary exec'd this:

argv: /home/luis/dev/luislobo/openworker/surfaces/gui/src-tauri/../../../.venv/bin/openworker-server --host 127.0.0.1 --port 39445
PWD:  /tmp/.mount_OpenWoLFGAeK/usr

That is the env!("CARGO_MANIFEST_DIR") fallback in server_bin() — my own build machine's home directory, baked into the artifact at compile time and executed at runtime. ps showed the child as [openworker-serv] <defunct> while the WebKit processes stayed up: window renders, no backend.

So for an AppImage built from #551 the resolver doesn't merely prefer the wrong path — every packaged candidate misses and it falls through to a path that exists only on the machine that built it. Nothing about that is specific to my setup; it's what CARGO_MANIFEST_DIR does in any release build.

Two things worth drawing out for whoever's PR becomes the base:

1. This is invisible to local testing. On the build machine that baked path exists, so the AppImage appears to work. It only fails on someone else's machine. Any "works for me" AppImage report — including one I might have given you — should be treated as unverified unless it came from a machine that never built the thing.
2. AppImage's runtime rewrites the child environment. The spawned process inherited PYTHONHOME=/tmp/.mount_*/usr/, PYTHONPATH=/tmp/.mount_*/usr/share/pyshared/ and an LD_LIBRARY_PATH pointing into the mount. I could not isolate whether that contributed to the child dying here, so I'm flagging it as worth checking rather than claiming it as a defect — a PyInstaller-frozen sidecar may well neutralise it. It seems worth a deliberate test in whichever PR lands, since a sidecar that inherits a hijacked PYTHONHOME fails in a way that's hard to read from a stack trace.

None of this changes my recommendation — it sharpens it. Resolving via resource_dir() as #470 does is correct precisely because it never reaches a compile-time path. I'd just suggest that whatever lands gets smoke-tested on a machine that didn't build it, since that's the only configuration where this class of bug shows up.

[luislobo]

Correction to my first comment, which I've also edited above: I wrote that #173 had "stood down in favour of" #470. That was wrong and I shouldn't have put it that way.

The "superseded by #470" remark on #173 came from @niutech, a commenter — not from @AliRezaTaleghani, who authored it and hasn't commented since July. #173 is still open. I read someone else's assessment and restated it as the author's position, which isn't fair to them and made the consensus behind #470 sound firmer than it is.

My recommendation is unchanged, but it rests on #470's technical merits — resource_dir() resolution, the distro-aware installer, and @marbetschar's Fedora 44 result — not on anyone having withdrawn.