docs: record Windows installer fix verified, Linux still open #173
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -36,16 +36,30 @@ Rule 12 / Rule 11. This register survives the session. Future agents resume from | |
| binaries run on both older and newer driver installs, while dropping v12 | ||
| instead would have saved more space (~1.1GB vs. ~630MB) at the cost of | ||
| silently losing GPU acceleration for anyone without the newest driver. | ||
| **Verified 2026-08-22 via a real CI run** (manually dispatched against the | ||
| fix branch with `gh workflow run ci.yml --ref ...`, since these jobs only | ||
| trigger on push-to-main/workflow_dispatch, not on `pull_request`): **Windows | ||
| `Tauri Desktop Build` now succeeds** — `makensis` completed in ~9 minutes | ||
| and produced a real `Alphonso_2.6.2_x64-setup.exe` artifact (~957MB, | ||
| confirmed via `gh api .../artifacts`), no more datablock error. Merged to | ||
| `main` at `96354f9` (PR #172). | ||
| **Linux `Tauri Desktop Build (Linux)` still fails** — same | ||
| `failed to run linuxdeploy` error, now in ~20 seconds (vs. ~2 minutes for | ||
| the last known-good run on 2026-08-16), with zero diagnostic output between | ||
| "Bundling ... .AppImage" and the failure — Tauri swallows linuxdeploy's own | ||
| stderr. The near-instant failure time suggests this may NOT be the same | ||
| size-driven root cause as Windows's NSIS bug (a real size problem would | ||
| likely fail partway through processing ~1GB+ of payload, not in 20s flat) — | ||
| worth investigating as a possibly distinct issue (FUSE/AppImage execution | ||
| environment on the runner, a linuxdeploy/plugin version regression, disk | ||
| space) rather than assuming the same CUDA-trim fix will resolve it. | ||
| **This is not currently blocking anything**: `desktop-linux` has | ||
| `continue-on-error: true` in `ci.yml` (same as macOS), so it was never a | ||
| required check — Windows was the only gating job, and it's fixed. Resume | ||
| hint if picked up: get real stderr out of linuxdeploy directly (run | ||
| `linuxdeploy-x86_64.AppImage` by hand against the built `app` binary | ||
| outside of Tauri's bundler, or add `RUST_LOG=debug`/`--verbose` to | ||
| `tauri build` if supported) before assuming it's the same size issue. | ||
|
Comment on lines
+59
to
+62
There was a problem hiding this comment. 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- tracked files related to Tauri/linuxdeploy ---'
git ls-files | rg '(^|/)(tauri|Cargo|package|pnpm|yarn|npm|ci|workflow|DEFERRED_WORK)|linuxdeploy' | head -200
printf '%s\n' '--- deferred work context ---'
nl -ba docs/governance/DEFERRED_WORK.md | sed -n '35,70p'
printf '%s\n' '--- workflow build context ---'
nl -ba .github/workflows/ci.yml | sed -n '260,325p'
printf '%s\n' '--- linuxdeploy references ---'
rg -n -i -C 3 'linuxdeploy|appdir|AppDir|AppImage|tauri build|bundle' .github docs src app package.json Cargo.toml tauri.conf.json 2>/dev/null || trueRepository: obsidian-media/AlphonsoEcosystem Length of output: 50389 🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- deferred work context ---'
sed -n '35,70p' docs/governance/DEFERRED_WORK.md
printf '%s\n' '--- Linux workflow context ---'
sed -n '270,315p' .github/workflows/ci.yml
printf '%s\n' '--- Tauri configuration ---'
sed -n '1,120p' src-tauri/tauri.conf.json
printf '%s\n' '--- Linux Tauri configuration ---'
sed -n '1,120p' src-tauri/tauri.linux.conf.json
printf '%s\n' '--- all workflow linuxdeploy/AppDir references ---'
rg -n -i -C 2 'linuxdeploy|appdir|AppDir|tauri build|appimage' \
.github/workflows src-tauri docs/governance/DEFERRED_WORK.mdRepository: obsidian-media/AlphonsoEcosystem Length of output: 14947 🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- Tauri CLI versions ---'
rg -n -C 2 '"`@tauri-apps/cli`"|"tauri-cli"|tauri-cli' package.json package-lock.json src-tauri/Cargo.toml src-tauri/Cargo.lock
printf '%s\n' '--- Tauri build scripts and target paths ---'
rg -n -i -C 3 'target/release|bundle/appimage|appdir|linuxdeploy|appimage' \
package.json package-lock.json src-tauri .github/workflows \
--glob '!src-tauri/Cargo.lock'
printf '%s\n' '--- repository history summary for relevant files ---'
git log --oneline -8 -- docs/governance/DEFERRED_WORK.md src-tauri/tauri.conf.json .github/workflows/ci.ymlRepository: obsidian-media/AlphonsoEcosystem Length of output: 6408 🌐 Web query:
💡 Result: In Tauri v2, the AppImage bundling process utilizes linuxdeploy to create the final distribution file [1][2]. Linuxdeploy Invocation: The Tauri bundler executes linuxdeploy by invoking it as a command with specific arguments, including the path to the AppDir and plugins [2][3]. A typical invocation, as seen in the build process, follows this pattern [2][3]: linuxdeploy-.AppImage --appimage-extract-and-run --verbosity --appdir <AppDir_Path> --plugin gtk --output appimage [2][3] AppDir Staging Path: Tauri creates an AppDir—a directory structure that mimics the desired filesystem layout of the installed application—within the project's build directory [4][3]. The path typically follows this structure: <project_root>/src-tauri/target//bundle/appimage/<app_name>.AppDir [3] Does linuxdeploy receive the built executable or an AppDir? Linuxdeploy receives the AppDir [2][3]. Tauri first populates this AppDir with the built application executable, necessary libraries, metadata files (such as.desktop files and icons), and any additional resources [1][4][5]. Once this directory is fully staged, linuxdeploy scans the contents of the AppDir to resolve dependencies and packages the entire directory into a single, executable AppImage file [1][2][5]. [1][2][3] Citations:
🌐 Web query:
💡 Result: In Tauri v2 (including version 2.11.2), the tauri-bundler uses the linuxdeploy tool to create AppImage files [1][2]. The specific reference to linuxdeploy --appdir in the codebase refers to the command-line invocation of the linuxdeploy AppImage binary, which takes the --appdir argument to specify the directory containing the application's structure to be bundled [3][4][5]. Key details regarding this process include: 1. Invocation Pattern: The bundler dynamically downloads or uses a cached linuxdeploy AppImage binary [3]. It executes this binary with arguments such as --appdir , often alongside plugin flags (e.g., --plugin gtk) and output specifications [4][5][6]. 2. Plugin Usage: Custom plugins, such as those for GTK or GStreamer, are integrated into the bundling process [3][4][5]. These scripts are designed to be triggered by linuxdeploy and also accept the --appdir argument to identify the target directory for bundling resources [4][5]. 3. Environment Requirements: The LINUXDEPLOY environment variable must typically be set or provided by the bundler logic to point to the correct linuxdeploy executable [3][4][5]. 4. Troubleshooting: Errors related to "failed to run linuxdeploy" are common in various environments (like CI or specific Linux distributions) [7][8][6]. These are often addressed by: - Ensuring dependencies (e.g., FUSE, specific glib/GTK versions) are satisfied [7]. - Running with the --verbose flag to identify specific failures (e.g., issues with binary stripping or section parsing) [7][8][6]. - Setting the NO_STRIP=true environment variable if linuxdeploy encounters issues with modern ELF relocation formats during the stripping process [7][8]. Tauri is also exploring more modern, portable AppImage bundling approaches as alternatives to the traditional linuxdeploy-based method to improve stability and compatibility [9]. Citations:
Pass the generated AppDir to Tauri stages the application under 🤖 Prompt for AI Agents |
||
|
|
||
| - [2026-08-18] Hermes agent-backend delegation (per-agent Ollama/NVIDIA/Gemini/Hermes | ||
| provider picker, wiring 9 in-app agents to a separate live Hermes Agent | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
Limit “not currently blocking anything” to the required CI gate.
continue-on-error: trueprevents the Linux job from blocking the workflow result. It does not make the Linux package available. In.github/workflows/ci.ymlLines 299-302, the AppImage upload followsnpm run tauri buildand has noif: always(), so this failure can leave the artifact missing. State that Linux is not blocking the required check or merge, while keeping the artifact gap explicit.🤖 Prompt for AI Agents