Package Details: audacity-openvino 3.7.7-10

Git Clone URL: https://aur.archlinux.org/audacity-openvino.git (read-only, click to copy)
Package Base: audacity-openvino
Description: Audacity - Digital audio editor with AI support via openvino (mod-openvino)
Upstream URL: https://audacityteam.org
Licenses: GPL-3.0-or-later
Conflicts: audacity
Provides: audacity, ladspa-host, lv2-host, vamp-host, vst-host, vst3-host
Submitter: felipe.facundes
Maintainer: selebray1998
Last Packager: selebray1998
Votes: 0
Popularity: 0.000000
First Submitted: 2025-10-27 13:00 (UTC)
Last Updated: 2026-07-30 03:57 (UTC)

Required by (175)

Sources (8)

Latest Comments

1 2 Next › Last »

aliu commented on 2026-07-06 02:13 (UTC)

That defeats the point of selecting a libtorch folder that's available. cuda should just be an optdepends; you need CUDA to build with CUDA-enabled libtorch.

felipe.facundes commented on 2026-07-06 00:41 (UTC)

CUDA Compiler Detection Issue

The original build block:

build() {
    cd "${srcdir}/audacity"

     # Use CUDA libtorch if available, then ROCm, then system libtorch, fall back to CPU
     if [ -d "/opt/libtorch-cuda" ]; then
       export LIBTORCH_ROOTDIR="/opt/libtorch-cuda"
     elif [ -d "/opt/libtorch-rocm" ]; then
       export LIBTORCH_ROOTDIR="/opt/libtorch-rocm"
     elif [ -d "/opt/libtorch" ]; then
       export LIBTORCH_ROOTDIR="/opt/libtorch"
     else
       export LIBTORCH_ROOTDIR="/opt/libtorch-cpu"
     fi

Causes the following build error when libtorch-cuda is installed but CUDA toolkit/nvcc is not available:

CMake Error at /opt/libtorch-cuda/share/cmake/Caffe2/public/cuda.cmake:47 (enable_language):
  No CMAKE_CUDA_COMPILER could be found.

  Tell CMake where to find the compiler by setting either the environment
  variable "CUDACXX" or the CMake cache entry CMAKE_CUDA_COMPILER to the full
  path to the compiler, or to the compiler name if it is in the PATH.
Call Stack (most recent call first):
  /opt/libtorch-cuda/share/cmake/Caffe2/Caffe2Config.cmake:86 (include)
  /opt/libtorch-cuda/share/cmake/Torch/TorchConfig.cmake:68 (find_package)
  modules/openvino-plugins-ai-audacity/mod-openvino/CMakeLists.txt:14 (find_package)

The current logic only checks for the existence of /opt/libtorch-cuda directory but doesn't verify if the CUDA compiler (nvcc) is actually available. This causes the build to fail when a user has libtorch-cuda installed but doesn't have the CUDA toolkit.

Simple fix that resolved the issue:

build() {
    cd "${srcdir}/audacity"

     # Use CUDA libtorch if available, then ROCm, then system libtorch, fall back to CPU
     if [ -d "/opt/libtorch-cuda" ] && command -v nvcc &> /dev/null; then
       export LIBTORCH_ROOTDIR="/opt/libtorch-cuda"
       export CMAKE_CUDA_COMPILER=$(command -v nvcc)
     elif [ -d "/opt/libtorch-rocm" ]; then
       export LIBTORCH_ROOTDIR="/opt/libtorch-rocm"
     elif [ -d "/opt/libtorch" ]; then
       export LIBTORCH_ROOTDIR="/opt/libtorch"
     else
       export LIBTORCH_ROOTDIR="/opt/libtorch-cpu"
     fi

This adds a check for the CUDA compiler availability (command -v nvcc) and explicitly sets CMAKE_CUDA_COMPILER to the compiler path, falling back to the next available option if the compiler isn't found.

selebray1998 commented on 2026-06-14 18:16 (UTC)

Yeah, I'm trying to fix that. Seems like an existing issue with the package when I took control over it. My gimp-openvino package is based on this one and has the same issue. I'm taking a look at it right now.

leenux commented on 2026-06-08 19:08 (UTC)

how do we get the "other" models into it? Downloading, checking, extracting and copying is easy, but it is on root ...

aliu commented on 2026-05-26 23:13 (UTC) (edited on 2026-05-26 23:13 (UTC) by aliu)

ah so you're doing a clean chroot (if you don't know what that is then it's pkgctl build), nice. try paru -U --chroot!

(if you're not using a clean chroot then just install the dependencies on your system before building)

selebray1998 commented on 2026-05-26 19:22 (UTC) (edited on 2026-05-26 21:15 (UTC) by selebray1998)

Good point about the epoch. I guess somehow it got changed. Do you know of a way to test with an AUR helper such as paru? Because the only way I know how is to push the package else if I do makepkg -si it fails because of dependencies. If I do makepkg --nodeps it doesn't show me where dependencies fail. I'd welcome the feedback because I don't want to blow up people's emails!

EDIT: Done. Next time I push the package with a change the epoch will be set to 1.

aliu commented on 2026-05-23 21:37 (UTC) (edited on 2026-05-23 21:40 (UTC) by aliu)

Thanks for updating! Why is this now epoch 2? That should almost never be used and in this case didn't seem to do anything. It's for when a newer version has a lower version number than previous versions.

Could the package be locally tested before pushing to the AUR? Every push sends an email to everyone subscribed.

selebray1998 commented on 2026-05-22 15:09 (UTC) (edited on 2026-05-22 17:34 (UTC) by selebray1998)

Trying to, however my group home currently blocks outgoing port 22. Trying to find a solution.

EDIT: torsocks did it. Pushing now. Let me know if you have any issues or suggestions. The primary objective was to get the package to actually build.

I had to edit the PKGBUILD to do some inline edits because whispers.cpp apparently dropped the speed_up struct. Go figure.

aliu commented on 2026-05-20 23:05 (UTC)

With the new maintainer, is this package going to be updated?

leenux commented on 2026-02-27 07:55 (UTC)

I was wrong, probably. Everything that is slowing down the ai train woulnd'tbe so bad, neither. The GCC13 is a mistake - ok. Still for an uninformed person like I am, it is a strange mistake - I am no packager and I would pay attention when it comes to dependencies and specially to compiler. And I am now writing about it because this a huge problem: I was not able to build GCC13 and I guess I have a lil experience when it comes to software compiling. Others might struggle - so just sayin: no need for GCC13. I was hoping the answer would have been: yeah we need GCC13 for backwards compatibility - but that aint the case here. I am happy par-anyoing - better this way then other way round. I will reaad the comments now carefully - seems, I have not understand the situation. Still - even after update, audacity-openvino is not building here. Funny though: I had it runnning here and then an update (AUR?) broke it.

1 2 Next › Last »