fix(ci): bump Linux release runner to ubuntu-24.04, fixing stale bundled WebKitGTK - #1007
Merged
Conversation
…led WebKitGTK (#961) The AppImage bundles whatever libwebkit2gtk-4.1-dev the build runner's apt repos resolve at build time (see the "Linux system deps" step) — AppRun's LD_LIBRARY_PATH then makes that bundled copy take priority over the host's system WebKitGTK at runtime. ubuntu-22.04's version was stale relative to what current distros (Ubuntu 24.04+, Fedora 44) ship, which is why a from-source build (linking straight against the host's healthy system library) worked fine on the exact machine where the shipped AppImage white-screened — the released binary was running an older, buggier WebKitGTK under the hood regardless of the host. Bumped the Linux release matrix entry to ubuntu-24.04, and ci.yml's Tauri shell-check job to match (its own comment already says "Mirror release.yml" — now it actually does, so a green PR check accurately predicts the release build will also succeed). Raises the AppImage's glibc floor from 2.35 to 2.39 (Ubuntu 24.04+) — README's system-requirements table corrected from the now-false "Ubuntu 20.04+" claim. No reports of anyone on a pre-2022 distro. This does not fix the AppRun launcher's separate, related bug (its WebKitGTK-version auto-detection reads the *system's* pkg-config version, not the version actually bundled and running) — that would need a reliable way to read the bundled .so's version from within the AppImage, which isn't straightforward (WebKitGTK's soname doesn't map 1:1 to its release version) and isn't verifiable without a real Linux build environment to test against. Left as a known, separate gap. Cannot be verified from here on a real Ubuntu 26.04 machine — shipped on the strength of the root-cause diagnosis, pending the reporter's confirmation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
📝 WalkthroughWalkthroughCI and release workflows update the Linux build matrix from ubuntu-22.04 to ubuntu-24.04. README and CHANGELOG are updated to document the new minimum OS/glibc requirement, an ASR integration alternative, and a shutdown-race fix. ChangesUbuntu 24.04 baseline update
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 5❌ Failed checks (1 warning, 4 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
|
| Filename | Overview |
|---|---|
| .github/workflows/ci.yml | The Linux Tauri check runner now mirrors Ubuntu 24.04; the workflow dependency surface remains consistent. |
| .github/workflows/release.yml | The Linux release runner moves to Ubuntu 24.04, but part of the rationale still references an older support floor. |
| README.md | The English system requirements table now reflects Ubuntu 24.04/glibc 2.39, while sibling install surfaces still need the same floor. |
| CHANGELOG.md | The unreleased notes describe the AppImage fix and remote ASR path, but the ASR note omits the backend activation step. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[Release build runner] -->|ubuntu-24.04| B[AppImage bundles newer WebKitGTK]
B --> C[Runtime needs glibc 2.39]
C --> D[Ubuntu 24.04+ hosts]
C --> E[Older glibc hosts fail to launch]
F[Updated README floor] --> C
G[Unsynced install docs] -. can still point older users .-> E
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart LR
A[Release build runner] -->|ubuntu-24.04| B[AppImage bundles newer WebKitGTK]
B --> C[Runtime needs glibc 2.39]
C --> D[Ubuntu 24.04+ hosts]
C --> E[Older glibc hosts fail to launch]
F[Updated README floor] --> C
G[Unsynced install docs] -. can still point older users .-> E
Reviews (1): Last reviewed commit: "fix(ci): bump Linux release runner to ub..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| ### Added | ||
|
|
||
| - **A path to Qwen3-ASR today: generic OpenAI-compatible transcription.** The direct integration is still blocked on `transformers>=5.13` stabilizing upstream, but a community member proposed splitting the work — add a backend that talks to any OpenAI-compatible transcription server right now. Point OmniVoice at a self-hosted Qwen3-ASR/FunASR/SenseVoice server, or OpenAI's own API, configured in Settings → Models. No install; audio does leave your machine to whichever server you configure, unlike every other ASR engine. (#877) |
Contributor
There was a problem hiding this comment.
This note says users can configure the OpenAI-compatible transcription backend in Settings → Models, but that panel only stores the server settings; activation still requires OMNIVOICE_ASR_BACKEND=openai-compat-asr. A user following this release note can enter a Qwen3/FunASR/OpenAI server and still transcribe with the default local backend, with no visible sign that the configured server is unused.
Context Used: Review as a panel of passionate senior domain expe... (source)
| | | **Minimum** | **Recommended** | | ||
| |---|---|---| | ||
| | **OS** | Windows 10, macOS 12+ (Apple Silicon), Ubuntu 20.04+ | Any modern 64-bit OS | | ||
| | **OS** | Windows 10, macOS 12+ (Apple Silicon), Ubuntu 24.04+ (glibc 2.39+) | Any modern 64-bit OS | |
Contributor
There was a problem hiding this comment.
This raises the English README to Ubuntu 24.04/glibc 2.39, but the parallel Linux install surfaces still do not carry the same AppImage floor. A user landing on the translated README or detailed Linux install page can still treat Ubuntu 20.04/22.04 as supported, download the new AppImage, and hit a glibc loader failure before the app starts.
Context Used: CLAUDE.md (source)
Comment on lines
+230
to
+232
| # (Ubuntu <22.04, Debian <12) lose support; no report of anyone on | ||
| # something that old has come in, and the project's own install | ||
| # docs already assume Debian 12 / Ubuntu 22.04+. |
Contributor
There was a problem hiding this comment.
This rationale still says the install docs assume Debian 12 / Ubuntu 22.04+, but the changed AppImage is built on Ubuntu 24.04 and requires glibc 2.39. A future maintainer can read this as evidence that those older distros remain within the official AppImage floor and undo the runner bump while trying to preserve support for them.
Context Used: CLAUDE.md (source)
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 229-232: Update the release workflow comment in the AppImage glibc
floor note so it matches the actual supported Ubuntu versions: the change to
glibc 2.39 excludes Ubuntu 22.04 as well as older releases, so replace the
parenthetical in the release note near the AppImage packaging logic with wording
consistent with the README (Ubuntu 24.04+ / glibc 2.39+). Keep the rest of the
explanation intact and make sure the comment no longer implies Ubuntu 22.04
remains supported.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: a00a4839-59ca-4c3a-ab3b-08c25f91661f
📒 Files selected for processing (4)
.github/workflows/ci.yml.github/workflows/release.ymlCHANGELOG.mdREADME.md
Comment on lines
+229
to
+232
| # the AppImage's glibc floor from 2.35 to 2.39 — pre-2022 distros | ||
| # (Ubuntu <22.04, Debian <12) lose support; no report of anyone on | ||
| # something that old has come in, and the project's own install | ||
| # docs already assume Debian 12 / Ubuntu 22.04+. |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Comment inaccurately describes which Ubuntu versions lose support.
The glibc floor rises from 2.35 to 2.39, but Ubuntu 22.04 ships glibc 2.35 — so 22.04 itself also falls below the new floor. The comment says "Ubuntu <22.04" loses support, implying 22.04 is still fine. The README correctly states "Ubuntu 24.04+ (glibc 2.39+)." Fix the parenthetical to match.
📝 Proposed fix for the comment
- # Bumped from ubuntu-22.04 → ubuntu-24.04 (`#961`): the AppImage
- # bundles whatever `libwebkit2gtk-4.1-dev` the build runner's apt
- # repos resolve (see the "Linux system deps" step below) — 22.04's
- # was meaningfully stale relative to what current Ubuntu/Fedora
- # ship, and AppRun's LD_LIBRARY_PATH makes that bundled, stale copy
- # take priority over a healthy system WebKitGTK at runtime. Raises
- # the AppImage's glibc floor from 2.35 to 2.39 — pre-2022 distros
- # (Ubuntu <22.04, Debian <12) lose support; no report of anyone on
- # something that old has come in, and the project's own install
- # docs already assume Debian 12 / Ubuntu 22.04+.
+ # Bumped from ubuntu-22.04 → ubuntu-24.04 (`#961`): the AppImage
+ # bundles whatever `libwebkit2gtk-4.1-dev` the build runner's apt
+ # repos resolve (see the "Linux system deps" step below) — 22.04's
+ # was meaningfully stale relative to what current Ubuntu/Fedora
+ # ship, and AppRun's LD_LIBRARY_PATH makes that bundled, stale copy
+ # take priority over a healthy system WebKitGTK at runtime. Raises
+ # the AppImage's glibc floor from 2.35 to 2.39 — Ubuntu <24.04
+ # and Debian <13 lose support; no report of anyone on an older
+ # distro has come in, and the project's own install docs already
+ # assume Ubuntu 24.04+.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| # the AppImage's glibc floor from 2.35 to 2.39 — pre-2022 distros | |
| # (Ubuntu <22.04, Debian <12) lose support; no report of anyone on | |
| # something that old has come in, and the project's own install | |
| # docs already assume Debian 12 / Ubuntu 22.04+. | |
| # the AppImage's glibc floor from 2.35 to 2.39 — Ubuntu <24.04 | |
| # and Debian <13 lose support; no report of anyone on | |
| # something that old has come in, and the project's own install | |
| # docs already assume Ubuntu 24.04+. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml around lines 229 - 232, Update the release
workflow comment in the AppImage glibc floor note so it matches the actual
supported Ubuntu versions: the change to glibc 2.39 excludes Ubuntu 22.04 as
well as older releases, so replace the parenthetical in the release note near
the AppImage packaging logic with wording consistent with the README (Ubuntu
24.04+ / glibc 2.39+). Keep the rest of the explanation intact and make sure the
comment no longer implies Ubuntu 22.04 remains supported.
debpalash
added a commit
that referenced
this pull request
Jul 8, 2026
…ersion, not the host's (#961 follow-up) (#1024) The launcher decided whether to export WEBKIT_DISABLE_COMPOSITING_MODE by asking the host's pkg-config — but LD_LIBRARY_PATH makes the BUNDLED libwebkit2gtk the one that actually runs, so on any machine where the two diverge the detection read the wrong number. This was the second bug identified during #961's investigation (the reporter built from source, so their dev packages answered pkg-config with a healthy version while the shipped bundle ran an older lib) and was explicitly deferred in #1007 as not-safely-fixable at runtime. The fix makes it knowable by construction instead: inject-apprun.sh runs at bundle time ON the build host whose libwebkit2gtk gets bundled, so it stamps that version into .bundled-webkitgtk-version inside the AppDir. AppRun reads the stamp first and only falls back to host pkg-config for bundles predating it. Empty/unreadable stamp fails safe (workaround on), same philosophy as the missing-pkg-config path. Tests: 3 new cases in AppRun.test.sh — marker-beats-host in both directions (broken-marker/healthy-host and the #961 inversion, healthy-marker/broken-host) plus empty-marker fail-safe. Also wires AppRun.test.sh into pytest (tests/test_apprun_launcher.py) — it was previously run by NO CI job, so the launcher could regress silently. Also documents Windows install-to-another-drive behavior in docs/install/windows.md (#938): local drives work via the wizard's directory picker, mapped network drives are a Windows Installer limitation, and the data directory moves independently of the app. Co-authored-by: mergetest <test@local> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root cause (#961)
The reporter's white-screening AppImage worked fine as a from-source build on the exact same Ubuntu 26.04 machine. That split was the tell: the AppImage bundles whatever
libwebkit2gtk-4.1-devthe build runner's apt repos resolve at build time, and AppRun'sLD_LIBRARY_PATHmakes that bundled copy take priority over the host's system WebKitGTK at runtime. The release build ran onubuntu-22.04, whose WebKitGTK was meaningfully stale relative to what current distros ship — so the shipped AppImage was running an older, buggier library under the hood regardless of the host machine's own healthy WebKitGTK.What changed
.github/workflows/release.yml— Linux release matrix entry:ubuntu-22.04→ubuntu-24.04..github/workflows/ci.yml— the Tauri shell-check job's Linux runner bumped to match. Its own comment already says "Mirror release.yml" — now it actually does, so a green PR check accurately predicts the release build will also succeed.README.md— system-requirements table corrected from the now-false "Ubuntu 20.04+" to "Ubuntu 24.04+ (glibc 2.39+)", matching the new floor.CHANGELOG.md—[Unreleased]entry.What this does NOT fix
There's a second, related bug in
frontend/src-tauri/appimage/AppRun: its WebKitGTK-version auto-detection reads the system'spkg-configversion to decide whether to apply a known-range compositing workaround — not the version actually bundled and running viaLD_LIBRARY_PATH. On a machine with dev packages installed (like the reporter's, since they build from source), this can read the wrong number entirely. Fixing that properly would need a reliable way to read the bundled.so's actual version from within the launcher script, which isn't straightforward — WebKitGTK's soname doesn't map 1:1 to its release version — and I have no real Linux build environment here to empirically verify a new heuristic. Left as a known, separate, still-open gap rather than shipping something unverified.Verification
Cannot be tested against a real Ubuntu 26.04 machine from here — this ships on the strength of the root-cause diagnosis (confirmed via the reporter's own from-source-vs-AppImage split), pending their confirmation on the next build.
🤖 Generated with Claude Code
Updated Linux release and CI runners from
ubuntu-22.04toubuntu-24.04so AppImage builds pick up newer bundled WebKitGTK, and kept the Tauri shell-check job aligned with release behavior.Also updated:
README.mdsystem requirements toUbuntu 24.04+/glibc 2.39+CHANGELOG.mdwith an unreleased note for the AppImage/WebKitGTK fixThe separate
AppRunWebKitGTK version-detection issue was left unchanged.