fix(cuda): add Linux x86_64 CUDA backend build and platform-aware download#561
fix(cuda): add Linux x86_64 CUDA backend build and platform-aware download#561smendola wants to merge 2 commits intojamiepine:mainfrom
Conversation
…nload The CUDA backend download previously used a single archive name (voicebox-server-cuda.tar.gz) for all platforms. Only a Windows binary was published in releases, so Linux users silently downloaded and extracted a Windows .exe, which was unusable. Changes: - backend/services/cuda.py: derive archive names from sys.platform so Linux downloads voicebox-server-cuda-linux-x86_64.tar.gz and Windows downloads voicebox-server-cuda-windows-x86_64.tar.gz (same for cuda-libs archives) - scripts/package_cuda.py: add required --platform argument that stamps the platform identifier into all output archive and checksum filenames - .github/workflows/release.yml: pass --platform windows-x86_64 to the existing Windows job; add build-cuda-linux job on ubuntu-latest that installs torch cu128, builds with PyInstaller, packages with --platform linux-x86_64, and uploads the Linux archives to the release No GPU is required in CI — PyInstaller bundles the CUDA .so libraries from the pip-installed nvidia-* packages at build time.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughAdds platform-specific CUDA packaging and artifact naming; introduces a Linux CUDA build job in the release workflow; and makes the runtime CUDA download select platform-suffixed release artifacts. Changes
Sequence Diagram(s)sequenceDiagram
participant CI as GitHub Actions (build-cuda-linux / release)
participant Pkg as scripts/package_cuda.py
participant GH as GitHub Releases (assets)
participant Runtime as App backend (`backend/services/cuda.py`)
CI->>Pkg: run packaging with `--platform linux-x86_64`
Pkg->>GH: upload `server-core-{platform}.tar.gz`, `cuda-libs-{platform}.tar.gz` and `.sha256`
CI->>GH: attach workflow artifact (onedir)
Runtime->>GH: query latest release assets
Runtime->>Runtime: derive platform from `sys.platform`
Runtime->>GH: download platform-suffixed assets
Note right of GH: Assets named with `-{platform}` suffix
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
scripts/package_cuda.py (1)
218-223:⚠️ Potential issue | 🟡 Minor
--torch-compathelp text disagrees with the actual default.
default=">=2.7.0,<2.11.0"buthelp="...(default: >=2.6.0,<2.11.0)". Update the help string (or the default) so--helpdoesn’t mislead.🩹 Suggested fix
parser.add_argument( "--torch-compat", type=str, default=">=2.7.0,<2.11.0", - help="Torch version compatibility range (default: >=2.6.0,<2.11.0)", + help="Torch version compatibility range (default: >=2.7.0,<2.11.0)", )🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/package_cuda.py` around lines 218 - 223, The help text for the "--torch-compat" argument is inconsistent with its default: parser.add_argument sets default=">=2.7.0,<2.11.0" but help says default is ">=2.6.0,<2.11.0"; update one to match the other — either set default to ">=2.6.0,<2.11.0" or change the help string to say "(default: >=2.7.0,<2.11.0)" — edit the parser.add_argument call for "--torch-compat" to make the default and help message consistent.
🧹 Nitpick comments (5)
backend/services/cuda.py (2)
343-346: Localcuda-libs.jsonmanifest no longer matches what the packaging script writes.
scripts/package_cuda.pynow writes a manifest withversion,platform,torch_compat,archive, andsha256, but this local write keeps just{"version": ...}. Not a functional bug today (onlyversionis read back viaget_installed_cuda_libs_version), but it makes the on-disk manifest diverge from the release artifact and forecloses easy platform/sha checks later (e.g., detecting that a user’s cached libs were extracted on a different OS after a re-image or shared profile).♻️ Optional: persist platform alongside version
- # Write local cuda-libs.json manifest - manifest = {"version": CUDA_LIBS_VERSION} + # Write local cuda-libs.json manifest + manifest = {"version": CUDA_LIBS_VERSION, "platform": _plat} get_cuda_libs_manifest_path().write_text(json.dumps(manifest, indent=2) + "\n")🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@backend/services/cuda.py` around lines 343 - 346, The local manifest write only emits {"version": ...}; change the write in the block that calls get_cuda_libs_manifest_path() so it emits the same manifest shape that scripts/package_cuda.py produces (keys: version, platform, torch_compat, archive, sha256) — populate platform with the runtime platform (e.g., platform.system()/platform.platform()), copy or compute torch_compat from the same source used elsewhere (or set to None/"" if unknown), and set archive and sha256 to the appropriate values or empty strings; keep the same json.dumps(..., indent=2) + "\n" formatting and ensure get_installed_cuda_libs_version still reads version as before.
4-12: Module docstring is now stale.The header still names
voicebox-server-cuda.tar.gzandcuda-libs-{version}.tar.gz; both archive names now carry a-{platform}suffix. Worth a one-line update so future readers don’t look for the old names on Releases.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@backend/services/cuda.py` around lines 4 - 12, Update the stale module-level docstring in the cuda module to reflect the new archive naming: change references to voicebox-server-cuda.tar.gz and cuda-libs-{version}.tar.gz to include the platform suffix (e.g., voicebox-server-cuda-{platform}.tar.gz and cuda-libs-{version}-{platform}.tar.gz) so the docstring at the top of backend.services.cuda (module-level docstring) accurately describes the downloaded archive names..github/workflows/release.yml (2)
392-403:cuda-libs.jsonis uploaded by Windows only.
scripts/package_cuda.pynow writes aplatformfield into the manifest, so per-platform manifests are inherently per-platform. The Windows job still uploadscuda-libs.json(line 330) but the Linux job does not — meaning the release will only ever expose the Windows manifest, and if you later addcuda-libs.jsonto the Linux upload list both jobs will race on the same release-asset filename. Either drop it from the Windows job (the downloader writes its own manifest locally and never fetches this file) or upload it under platform-suffixed names from both jobs.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 392 - 403, The Windows release job is uploading a platform-specific manifest (cuda-libs.json) which is written per-platform by scripts/package_cuda.py, causing the release to only expose the Windows manifest and creating a race if Linux also uploads the same filename; update the "Upload archives to GitHub Release" step in the Windows job to stop uploading cuda-libs.json (or alternatively change both Windows and Linux upload steps to upload platform-suffixed manifest filenames) so each platform either omits the manifest from the release or uses unique names, and ensure references to cuda-libs.json in that step are removed or renamed accordingly.
364-368: Optional: align torch pin between Windows and Linux jobs.Linux pins
torch==2.7.0+cu128 torchaudio==2.7.0+cu128, while Windows (lines 293–294) installs unpinnedtorch/torchaudiofrom the cu128 index. Both archives end up under the samecuda-libs-cu128-v1-{platform}.tar.gzversion key in the downloader, but they may bundle different torch minor versions, which can produce per-platform behavior differences for the same release tag. Consider pinning Windows to match (or reading both pins from a shared variable).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 364 - 368, The Linux job step named "Install PyTorch with CUDA 12.8" pins torch==2.7.0+cu128 and torchaudio==2.7.0+cu128 but the Windows job installs unpinned torch/torchaudio; update the Windows install step to pin the same versions (torch==2.7.0+cu128 and torchaudio==2.7.0+cu128) or extract these pins into a shared workflow variable (e.g., PYTORCH_VERSION) and use that variable in both the "Install PyTorch with CUDA 12.8" Linux step and the corresponding Windows install step so both platforms use identical torch/torchaudio versions.scripts/package_cuda.py (1)
1-13: Update the module docstring to reflect platform-suffixed archive names.Lines 5–6 still describe the outputs as
voicebox-server-cuda.tar.gzandcuda-libs-cu128.tar.gz, but the script now producesvoicebox-server-cuda-{platform}.tar.gzandcuda-libs-{version}-{platform}.tar.gz. The Usage block also lacks a--platformexample, which is now a required argument.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/package_cuda.py` around lines 1 - 13, The module docstring in scripts/package_cuda.py still lists old archive names and an outdated Usage example; update the docstring so the outputs are described as voicebox-server-cuda-{platform}.tar.gz and cuda-libs-{version}-{platform}.tar.gz (replace the current voicebox-server-cuda.tar.gz and cuda-libs-cu128.tar.gz text) and add a Usage example showing the required --platform argument (e.g., --platform linux-x86_64) along with the existing --output and --cuda-libs-version options; ensure the explanatory lines and examples reference the new {version} and {platform} placeholders consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 374-375: The Windows CUDA job "build-cuda-windows" is missing the
same Qwen3-TTS installation step present in the Linux CUDA job ("Install
Qwen3-TTS" which runs pip install --no-deps
git+https://github.com/QwenLM/Qwen3-TTS.git), causing feature parity drift;
either add the same pip install line to the Windows job alongside the existing
requirements.txt/chatterbox-tts/hume-tada installs, or if the omission is
intentional, add an inline comment in the "build-cuda-windows" job explaining
the incompatibility so the asymmetry is documented.
- Around line 342-381: The build-cuda-linux job lacks disk-space preparation and
a timeout; before the "Setup Python" step add the same free-disk-space action
used in the release job (jlumbroso/free-disk-space) to increase available disk
space for large CUDA .so files, and add a job-level timeout-minutes (match the
Ubuntu timeout used elsewhere, e.g., 30) to prevent silent hangs; also verify
parity with other CUDA jobs: confirm whether installing Qwen3-TTS in
build-cuda-linux (and not in build-cuda-windows) is intentional and whether
cuda-libs.json should be uploaded from build-cuda-linux similar to
build-cuda-windows, and if required add the upload step to the job.
In `@backend/services/cuda.py`:
- Around line 289-291: _current code computes _plat with a two-way ternary which
maps every non-win32 platform to "linux-x86_64", causing incorrect downloads on
macOS and ARM; change the platform resolution in backend/services/cuda.py so it
explicitly handles known platforms and raises a clear error for unsupported
ones: inspect sys.platform (and platform.machine() if you want to distinguish
x86_64 vs aarch64) and set _plat only for accepted values (e.g.,
"windows-x86_64" for "win32", "linux-x86_64" for linux x86_64, and optionally
"linux-aarch64" for aarch64), and if the platform is unknown (darwin, other
BSDs, or mismatched arch) raise a descriptive exception before computing
server_archive and libs_archive; update any uses in download_cuda_binary and
check_and_update_cuda_binary to rely on this guard.
---
Outside diff comments:
In `@scripts/package_cuda.py`:
- Around line 218-223: The help text for the "--torch-compat" argument is
inconsistent with its default: parser.add_argument sets
default=">=2.7.0,<2.11.0" but help says default is ">=2.6.0,<2.11.0"; update one
to match the other — either set default to ">=2.6.0,<2.11.0" or change the help
string to say "(default: >=2.7.0,<2.11.0)" — edit the parser.add_argument call
for "--torch-compat" to make the default and help message consistent.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 392-403: The Windows release job is uploading a platform-specific
manifest (cuda-libs.json) which is written per-platform by
scripts/package_cuda.py, causing the release to only expose the Windows manifest
and creating a race if Linux also uploads the same filename; update the "Upload
archives to GitHub Release" step in the Windows job to stop uploading
cuda-libs.json (or alternatively change both Windows and Linux upload steps to
upload platform-suffixed manifest filenames) so each platform either omits the
manifest from the release or uses unique names, and ensure references to
cuda-libs.json in that step are removed or renamed accordingly.
- Around line 364-368: The Linux job step named "Install PyTorch with CUDA 12.8"
pins torch==2.7.0+cu128 and torchaudio==2.7.0+cu128 but the Windows job installs
unpinned torch/torchaudio; update the Windows install step to pin the same
versions (torch==2.7.0+cu128 and torchaudio==2.7.0+cu128) or extract these pins
into a shared workflow variable (e.g., PYTORCH_VERSION) and use that variable in
both the "Install PyTorch with CUDA 12.8" Linux step and the corresponding
Windows install step so both platforms use identical torch/torchaudio versions.
In `@backend/services/cuda.py`:
- Around line 343-346: The local manifest write only emits {"version": ...};
change the write in the block that calls get_cuda_libs_manifest_path() so it
emits the same manifest shape that scripts/package_cuda.py produces (keys:
version, platform, torch_compat, archive, sha256) — populate platform with the
runtime platform (e.g., platform.system()/platform.platform()), copy or compute
torch_compat from the same source used elsewhere (or set to None/"" if unknown),
and set archive and sha256 to the appropriate values or empty strings; keep the
same json.dumps(..., indent=2) + "\n" formatting and ensure
get_installed_cuda_libs_version still reads version as before.
- Around line 4-12: Update the stale module-level docstring in the cuda module
to reflect the new archive naming: change references to
voicebox-server-cuda.tar.gz and cuda-libs-{version}.tar.gz to include the
platform suffix (e.g., voicebox-server-cuda-{platform}.tar.gz and
cuda-libs-{version}-{platform}.tar.gz) so the docstring at the top of
backend.services.cuda (module-level docstring) accurately describes the
downloaded archive names.
In `@scripts/package_cuda.py`:
- Around line 1-13: The module docstring in scripts/package_cuda.py still lists
old archive names and an outdated Usage example; update the docstring so the
outputs are described as voicebox-server-cuda-{platform}.tar.gz and
cuda-libs-{version}-{platform}.tar.gz (replace the current
voicebox-server-cuda.tar.gz and cuda-libs-cu128.tar.gz text) and add a Usage
example showing the required --platform argument (e.g., --platform linux-x86_64)
along with the existing --output and --cuda-libs-version options; ensure the
explanatory lines and examples reference the new {version} and {platform}
placeholders consistently.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 44db7131-8fc7-4627-bfb8-486d2d852e42
📒 Files selected for processing (3)
.github/workflows/release.ymlbackend/services/cuda.pyscripts/package_cuda.py
| build-cuda-linux: | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: write | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup Python | ||
| uses: actions/setup-python@v5 | ||
| with: | ||
| python-version: "3.12" | ||
| cache: "pip" | ||
|
|
||
| - name: Install Python dependencies | ||
| run: | | ||
| python -m pip install --upgrade pip | ||
| pip install pyinstaller | ||
| pip install -r backend/requirements.txt | ||
| pip install --no-deps chatterbox-tts | ||
| pip install --no-deps hume-tada | ||
|
|
||
| - name: Install PyTorch with CUDA 12.8 | ||
| run: | | ||
| pip install torch==2.7.0+cu128 torchaudio==2.7.0+cu128 \ | ||
| --index-url https://download.pytorch.org/whl/cu128 \ | ||
| --force-reinstall --no-deps | ||
|
|
||
| - name: Verify CUDA libraries are present | ||
| run: | | ||
| python -c "import torch; print(f'torch: {torch.__version__}'); print(f'CUDA version: {torch.version.cuda}')" | ||
|
|
||
| - name: Install Qwen3-TTS | ||
| run: pip install --no-deps git+https://github.com/QwenLM/Qwen3-TTS.git | ||
|
|
||
| - name: Build CUDA server binary (onedir) | ||
| working-directory: backend | ||
| env: | ||
| TORCH_CUDA_ARCH_LIST: "8.0;8.6;8.9;9.0;12.0+PTX" | ||
| run: python build_binary.py --cuda |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does PyInstaller require patchelf on Linux for onedir builds with shared libraries (e.g., torch CUDA .so files)?
💡 Result:
No. PyInstaller does not require you to have patchelf installed on Linux for onedir builds that include shared libraries (including large frameworks like torch CUDA .so files). What PyInstaller does do is: 1) Collect shared libraries and their dependencies into the onedir directory (or onefile archive) via its dependency analysis. 2) At runtime, adjust the dynamic library search path using LD_LIBRARY_PATH (its bootloader prepends the app’s top-level directory / sys._MEIPASS) so the collected .so files are found. The sources also show that missing or incorrect handling of .so dependencies is addressed by collecting the right libraries / fixing packaging (e.g., torch-related .so collection), not by requiring patchelf for onedir. Practical note: Some tools or workflows that post-process binaries may use patchelf, but that’s separate from PyInstaller’s core onedir packaging requirement. If you’re getting runtime errors about missing torch CUDA .so files, the fix is typically to ensure those libraries are actually collected into the frozen app (e.g., via hooks/spec adjustments), and to verify runtime search-path behavior, rather than installing patchelf.
Citations:
- 1: https://pyinstaller.org/en/latest/advanced-topics.html
- 2: https://pyinstaller.org/en/stable/common-issues-and-pitfalls.html
- 3: https://www.pyinstaller.org/
- 4: torch libtorch_cuda_linalg.so pyinstaller/pyinstaller-hooks-contrib#834
- 5: Running pyinstaller binary throws error related to shared library libbcc.so pyinstaller/pyinstaller#8887
🏁 Script executed:
# Check if the main 'release' job has free-disk-space step
rg -A 5 "free-disk-space" .github/workflows/release.ymlRepository: jamiepine/voicebox
Length of output: 256
🏁 Script executed:
# Check the build-cuda-windows job for Qwen3-TTS and cuda-libs.json
rg -B 5 -A 20 "build-cuda-windows:" .github/workflows/release.yml | head -80Repository: jamiepine/voicebox
Length of output: 768
🏁 Script executed:
# Check for timeout-minutes in release job
rg "timeout-minutes" .github/workflows/release.ymlRepository: jamiepine/voicebox
Length of output: 186
🏁 Script executed:
# Search for cuda-libs.json upload references
rg "cuda-libs.json" .github/workflows/release.ymlRepository: jamiepine/voicebox
Length of output: 104
🏁 Script executed:
# Get the full build-cuda-windows job
sed -n '318,340p' .github/workflows/release.ymlRepository: jamiepine/voicebox
Length of output: 971
🏁 Script executed:
# Get the full build-cuda-linux job
sed -n '342,410p' .github/workflows/release.ymlRepository: jamiepine/voicebox
Length of output: 2439
🏁 Script executed:
# Find which job uploads cuda-libs.json with context
rg -B 10 "cuda-libs.json" .github/workflows/release.ymlRepository: jamiepine/voicebox
Length of output: 570
build-cuda-linux is missing disk-space prep and timeout-minutes.
This job will hit two reproducible issues on ubuntu-latest:
-
Disk space. The main
releasejob explicitly usesjlumbroso/free-disk-spacebecause CUDA torch + PyInstaller--onedirbuilds easily exceed ubuntu-latest's ~14 GB free space. This new job is larger (cu128 .so files) and needs the same prep. -
Timeout protection. The main
releasejob setstimeout-minutes(30 min for Ubuntu). This new job has no timeout, risking silent hangs.
Also note:
build-cuda-linuxincludesQwen3-TTS, butbuild-cuda-windowsdoes not. Confirm this is intentional.build-cuda-windowsuploadscuda-libs.jsonto the release;build-cuda-linuxdoes not. This may be intentional (manifest platform tagging) or an omission.
Suggested additions before "Setup Python"
build-cuda-linux:
runs-on: ubuntu-latest
permissions:
contents: write
+ timeout-minutes: 30
steps:
- uses: actions/checkout@v4
+ - name: Free up disk space
+ uses: jlumbroso/free-disk-space@54081f138730dfa15788a46383842cd2f914a1be
+ with:
+ tool-cache: false
+ android: true
+ dotnet: true
+ haskell: true
+ large-packages: false
+ swap-storage: true
+
- name: Setup Python🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yml around lines 342 - 381, The build-cuda-linux
job lacks disk-space preparation and a timeout; before the "Setup Python" step
add the same free-disk-space action used in the release job
(jlumbroso/free-disk-space) to increase available disk space for large CUDA .so
files, and add a job-level timeout-minutes (match the Ubuntu timeout used
elsewhere, e.g., 30) to prevent silent hangs; also verify parity with other CUDA
jobs: confirm whether installing Qwen3-TTS in build-cuda-linux (and not in
build-cuda-windows) is intentional and whether cuda-libs.json should be uploaded
from build-cuda-linux similar to build-cuda-windows, and if required add the
upload step to the job.
| - name: Install Qwen3-TTS | ||
| run: pip install --no-deps git+https://github.com/QwenLM/Qwen3-TTS.git |
There was a problem hiding this comment.
Qwen3-TTS is installed on Linux but not in build-cuda-windows — feature parity drift.
The Windows CUDA job (lines 283–289) only installs requirements.txt + chatterbox-tts + hume-tada, while this Linux job additionally pulls git+https://github.com/QwenLM/Qwen3-TTS.git. After this PR, the Linux CUDA build will support Qwen3-TTS and the Windows CUDA build will not, leading to silent backend capability differences depending on which platform a user downloads from.
If the omission on Windows is deliberate (e.g., known build incompatibility), please add a comment so the asymmetry is documented; otherwise install Qwen3-TTS in both jobs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yml around lines 374 - 375, The Windows CUDA job
"build-cuda-windows" is missing the same Qwen3-TTS installation step present in
the Linux CUDA job ("Install Qwen3-TTS" which runs pip install --no-deps
git+https://github.com/QwenLM/Qwen3-TTS.git), causing feature parity drift;
either add the same pip install line to the Windows job alongside the existing
requirements.txt/chatterbox-tts/hume-tada installs, or if the omission is
intentional, add an inline comment in the "build-cuda-windows" job explaining
the incompatibility so the asymmetry is documented.
| _plat = "windows-x86_64" if sys.platform == "win32" else "linux-x86_64" | ||
| server_archive = f"voicebox-server-cuda-{_plat}.tar.gz" | ||
| libs_archive = f"cuda-libs-{CUDA_LIBS_VERSION}-{_plat}.tar.gz" |
There was a problem hiding this comment.
Non-Windows platforms silently resolve to linux-x86_64.
The ternary maps any sys.platform != "win32" (including darwin, ARM Linux, FreeBSD, etc.) to linux-x86_64. The PR description notes macOS is unaffected, but download_cuda_binary is reachable from the manual HTTP endpoint and from check_and_update_cuda_binary on startup; on a macOS host with a stale cuda-libs.json it would attempt to fetch …-linux-x86_64.tar.gz and either 404 or extract Linux .so files into the wrong tree. ARM64 Linux would silently get x86_64 binaries.
A small guard makes the intent explicit and produces a sensible error rather than a confusing 404.
🛡️ Suggested defensive guard
- _plat = "windows-x86_64" if sys.platform == "win32" else "linux-x86_64"
+ import platform as _platform
+ machine = _platform.machine().lower()
+ if sys.platform == "win32" and machine in ("amd64", "x86_64"):
+ _plat = "windows-x86_64"
+ elif sys.platform.startswith("linux") and machine in ("amd64", "x86_64"):
+ _plat = "linux-x86_64"
+ else:
+ raise RuntimeError(
+ f"CUDA backend is not available for {sys.platform}/{machine}"
+ )
server_archive = f"voicebox-server-cuda-{_plat}.tar.gz"
libs_archive = f"cuda-libs-{CUDA_LIBS_VERSION}-{_plat}.tar.gz"📝 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.
| _plat = "windows-x86_64" if sys.platform == "win32" else "linux-x86_64" | |
| server_archive = f"voicebox-server-cuda-{_plat}.tar.gz" | |
| libs_archive = f"cuda-libs-{CUDA_LIBS_VERSION}-{_plat}.tar.gz" | |
| import platform as _platform | |
| machine = _platform.machine().lower() | |
| if sys.platform == "win32" and machine in ("amd64", "x86_64"): | |
| _plat = "windows-x86_64" | |
| elif sys.platform.startswith("linux") and machine in ("amd64", "x86_64"): | |
| _plat = "linux-x86_64" | |
| else: | |
| raise RuntimeError( | |
| f"CUDA backend is not available for {sys.platform}/{machine}" | |
| ) | |
| server_archive = f"voicebox-server-cuda-{_plat}.tar.gz" | |
| libs_archive = f"cuda-libs-{CUDA_LIBS_VERSION}-{_plat}.tar.gz" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/services/cuda.py` around lines 289 - 291, _current code computes
_plat with a two-way ternary which maps every non-win32 platform to
"linux-x86_64", causing incorrect downloads on macOS and ARM; change the
platform resolution in backend/services/cuda.py so it explicitly handles known
platforms and raises a clear error for unsupported ones: inspect sys.platform
(and platform.machine() if you want to distinguish x86_64 vs aarch64) and set
_plat only for accepted values (e.g., "windows-x86_64" for "win32",
"linux-x86_64" for linux x86_64, and optionally "linux-aarch64" for aarch64),
and if the platform is unknown (darwin, other BSDs, or mismatched arch) raise a
descriptive exception before computing server_archive and libs_archive; update
any uses in download_cuda_binary and check_and_update_cuda_binary to rely on
this guard.
tauri/src-tauri/gen/schemas/linux-schema.json is auto-generated by Tauri on Linux during dev/build and is not meant to be committed.
2 participants
Problem
The "Download CUDA Backend" feature downloads
voicebox-server-cuda.tar.gzon all platforms, but only a Windows binary is published in releases. Linux users silently download and extract a Windows.exe, which is unusable, leaving them on the CPU backend with no explanation.Fix
Platform-aware archive names (
backend/services/cuda.py)Archive names now include the platform:
voicebox-server-cuda-linux-x86_64.tar.gz/cuda-libs-cu128-v1-linux-x86_64.tar.gzvoicebox-server-cuda-windows-x86_64.tar.gz/cuda-libs-cu128-v1-windows-x86_64.tar.gzPackaging script (
scripts/package_cuda.py)Added a required
--platformargument that stamps the platform identifier into all output archive and checksum filenames.Linux CI build job (
.github/workflows/release.yml)Added
build-cuda-linuxonubuntu-latestthat:torch==2.7.0+cu128from the PyTorch cu128 indexbuild_binary.py --cuda)--platform linux-x86_64No GPU is required in CI — PyInstaller bundles the CUDA
.solibraries from the pip-installednvidia-*packages at build time, the same way the Windows job bundles.dlls on a runner with no GPU.The existing Windows job is updated to pass
--platform windows-x86_64to match the new naming scheme.Notes
cuda-libsarchives are platform-specific (Windows.dllvs Linux.so)cuda-libs.jsonmanifest now includes aplatformfieldSummary by CodeRabbit
New Features
Improvements
Chores