Files
stemdeckapp--stemdeck/scripts
Tha.Les 655b0d0e95 fix(linux): install CUDA runtime deps with the GPU torch wheel (#324) (#325)
The Linux NVIDIA package could not start its backend at all. Setup detected
the GPU and pip-installed torch==X+cuXXX with --no-deps, mirroring Windows.
But Linux CUDA wheels do not bundle the CUDA runtime -- they dlopen
libcublas/libcudnn/... out of the nvidia-* PyPI packages at import time, and
make-portable.sh strips exactly those packages to keep the tarball under
GitHub's 2 GiB asset cap. The result was a CUDA torch with no CUDA runtime:

    ValueError: libcublas.so.*[0-9] not found in the system path

app/main.py imports torch at module scope, so this killed the backend
outright ("backend did not become healthy within 90 seconds") on every
launch, not just GPU work.

- install_cuda_torch now runs a second, dependency-resolving pip pass on
  Linux only (cuda_wheel_needs_runtime_deps). Same specs and index, without
  --no-deps/--ignore-installed, so pip sees torch as satisfied and installs
  only the missing nvidia-* wheels. Windows keeps the single --no-deps swap:
  its wheels carry the DLLs in torch/lib and pulling ~2.5 GB of nvidia-*
  there would be pure waste. macOS is untouched (MPS path).
- Restore CPU torch when verify_cuda_torch fails. Recording torchDevice=cpu
  was never enough -- an unloadable CUDA wheel stays on disk and keeps the
  backend from importing torch at all. New reason
  "cuda-verify-failed-cpu-restore-failed" when even that fails.
- Extract run_pip_install (PID tracking, 20 min timeout, stderr logging) so
  both installs and the restore share one path.
- Add the missing "Linux tar.gz" option to the bug report template, as the
  reporter noted.

Co-authored-by: Thales <>
2026-07-26 00:19:59 +01:00
..