[Bug] Linux Settings → Compute: "mesh-llm feature not enabled" (mesh omitted from Linux builds)

[soydantaylor]

Describe the bug

On Linux, Settings → Compute fails with:

Couldn't check shared compute; mesh-llm feature not enabled

Share compute / Buzz Mesh cannot be used on stock Linux desktop builds (AppImage or .deb). The same surface works on macOS arm64 builds, where release CI compiles with --features mesh-llm.

This is the Linux counterpart of #2836 (Windows). Same root cause, different platform job: release-linux omits the mesh-llm Cargo feature, so the app ships mesh_llm_stubs whose commands unconditionally return that error string. Filing separately because the open PR for #2836 (#3223) only touches the Windows job — Linux stays stubbed after it lands.

To Reproduce:
Steps to reproduce the behavior:

1. Download the official Buzz Desktop Linux AppImage (tested: Buzz_0.4.22_amd64.AppImage) and run it.
2. Click on Settings.
3. Click on Compute.
4. See error: Couldn't check shared compute; mesh-llm feature not enabled.

Expected behavior

Linux builds:

• ship with mesh-llm enabled and a working host backend (CUDA / ROCm / Vulkan / CPU),

so that a Linux GPU host can share compute with agents on other members (e.g. macOS) in the same relay community.

Failing that, the Compute surface should be hidden or clearly disabled on builds without the feature, rather than rendering and then surfacing a stub error.

Supporting Material

Error string from Settings → Compute: Couldn't check shared compute; mesh-llm feature not enabled (frontend prefix + backend Err string).

Installed Linux AppImage usr/bin/buzz-desktop.bin contains stub indicators and no real mesh implementation:

$ grep -ao "mesh_llm_stubs\.\.[a-z_]*" usr/bin/buzz-desktop.bin | sort -u
mesh_llm_stubs..mesh_start_node
mesh_llm_stubs..mesh_stop_node

$ grep -ao "mesh_llm\.\.[a-z_]*" usr/bin/buzz-desktop.bin | sort -u
(no output — no non-stub mesh_llm symbols)

Also present as literals: mesh-llm feature not enabled, Buzz shared compute is not available in this build, shared compute model is required.

The bundled buzz CLI (usr/bin/buzz) contains no mesh code at all, so there is no CLI fallback for headless serving on Linux.

Code gate:

• desktop/src-tauri/Cargo.toml — mesh-llm optional, not in default:

  default = ["system-keyring"]
  mesh-llm = ["dep:iroh", "dep:mesh-llm-sdk", "dep:mesh-llm-host-runtime", "dep:mesh-llm-client", "dep:mesh-llm-node", "dep:mesh-llm-system", "dep:mesh-llm-events"]

• desktop/src-tauri/src/lib.rs:15-18 — mesh_llm vs mesh_llm_stubs behind feature = "mesh-llm"
• desktop/src-tauri/src/lib.rs:62-63 — #[cfg(not(feature = "mesh-llm"))] use mesh_llm_stubs::*;
• desktop/src-tauri/src/lib.rs:64-65 — #[cfg(all(feature = "mesh-llm", target_os = "macos"))] use shutdown::{hard_exit_after_mesh_shutdown, relaunch_after_mesh_shutdown}; — the mesh shutdown/relaunch path is macOS-only even when the feature is on
• desktop/src-tauri/src/mesh_llm_stubs.rs — every command (mesh_start_node, mesh_stop_node, mesh_node_status, mesh_serving_usage, mesh_installed_models, …) returns Err("mesh-llm feature not enabled")

CI:

• .github/workflows/release.yml — release (macOS arm64) builds with --features mesh-llm plus Metal llama steps; release-linux (ubuntu-latest) builds with:

  run: cd desktop && pnpm tauri build --verbose --ci --bundles deb,appimage --config src-tauri/tauri.release.conf.json

  — no --features mesh-llm, no mesh native backend steps.
• .github/workflows/linux-canary.yml — same omission.

Verified identical at tags v0.4.22, v0.5.2, and main, so this is not fixed by upgrading.

Backend availability is not the blocker on Linux, unlike Metal being macOS-only. Upstream Mesh-LLM/mesh-llm publishes prebuilt Linux CPU, Linux CUDA, Linux CUDA Blackwell, Linux ROCm, and Linux Vulkan runtime bundles for the same pinned release line Buzz depends on (v0.74.0), and scripts/build-linux.sh / scripts/build-linux-rocm.sh exist in that repo alongside the build-mac.sh that the macOS job's Metal steps mirror.

Related (not duplicates):

• [Bug] Windows Settings → Compute: "mesh-llm feature not enabled" (mesh omitted from Windows builds) #2836 — Windows twin of this bug (same root cause, different job)
• fix(desktop): enable Windows mesh-llm builds and address Compute Share startup/MeshLLM debug logging/non-image models trying to parse image input #3223 — open PR enabling mesh-llm for Windows; adds --features mesh-llm to the NSIS build and a bundle-windows-mesh-runtime-deps.ps1 step. Does not touch release-linux.
• [Field report] Cross-platform release failures: relay-mesh capability mismatch, WSLg WebKit crashes, AppImage ABI error, Windows Defender quarantine #3612 §1 — field report: Linux 0.5.0 .deb exposed provider = relay-mesh while the packaged binary lacked the capability; 24 workers spawned and all failed. Same root cause surfacing through agent config rather than the Compute panel.
• fix(desktop): hide relay mesh option when mesh-llm feature is absent #1719 — merged "hide relay mesh option when mesh-llm feature is absent"; evidently does not cover the Settings → Compute surface, which still renders and errors.
• refactor(desktop): feature-gate mesh-llm-sdk behind optional Cargo feature #823 / build: make mesh-llm opt-in for dev/staging to speed up iteration #1183 / fix(desktop): enable mesh llm for release builds #1221 — feature-gating and release-build history

Environment (please complete the following information):

• OS: Zorin OS 18.1 (Ubuntu 24.04 base), kernel 7.0.0-28-generic, Wayland session
• Version: Buzz Desktop 0.4.22 (Linux x86_64 AppImage)
• GPU (context): NVIDIA GeForce RTX 4080 SUPER 16GB, driver 580.173.02

Additional context

Proposed direction for a fix (not required to accept the bug), mirroring the shape of #3223:

1. Enable --features mesh-llm on release-linux and linux-canary.
2. Add a Linux mesh native backend build/cache step analogous to the macOS Metal steps — CUDA and/or Vulkan for broad coverage, ROCm where the pinned mesh-llm ABI supports it. Upstream's scripts/build-linux.sh and scripts/build-linux-rocm.sh are the counterparts to the prepare-llama.sh / build-llama.sh pair the macOS job already calls.
3. Implement the non-macOS mesh shutdown/relaunch paths currently gated all(feature = "mesh-llm", target_os = "macos") in desktop/src-tauri/src/lib.rs (this overlaps with [Bug] Windows Settings → Compute: "mesh-llm feature not enabled" (mesh omitted from Windows builds) #2836 item 3 — one fix serves both platforms).
4. Keep feature-off UX consistent: hide or clearly disable Compute rather than only showing the stub error, and validate release capability before offering relay-mesh as a provider (see [Field report] Cross-platform release failures: relay-mesh capability mismatch, WSLg WebKit crashes, AppImage ABI error, Windows Defender quarantine #3612 §1).