Arch Linux User Repository

Are you sure it's their own implementation or that it's just copied into there from somewhere? I'd ideally like to devendor it entirely (and build the C stuff in (a) separate package(s)) and then just link to it. Think that's doable?

Ok, after looking at this for just a bit, here is what I see. Initially, noisetorch was using the ladspa plugin provided by https://github.com/werman/noise-suppression-for-voice (which in turn uses xiph's rnnoise library. It was embedding the binary, and I modified it to make use of the actual shared library.

Now, noisetorch has its own implementation of the ladspa plugin, again based on xiph's rnnoise library (provides librnnoise.so). I think what we need is the rnnoise_ladspa.so that is built here https://github.com/lawl/NoiseTorch/tree/master/c/ladspa. I have a PKGBUILD available here https://github.com/erbrecht/noisetorch-aur-package. It tries to rely on the rnnoise.so shared library, but it doesn't work since it's not the ladspa plugin (I think).

Sorry it took a while. I'm now setting the capability directly on the binary in the install file. Thanks for that suggestion.

I took a look at your changes and I implemented most of them except the dependency 2. I'm also working on linking rnnoise. It should be pretty straight forward. I'll try to get to that as soon as I can.

I originally had hicolor-icon-theme as a dependency but removed it after this feedback (https://bbs.archlinux.org/viewtopic.php?pid=1917440#p1917440). It seems to make sense.

Also, export GOPATH="$srcdir/go" is there so that the go build dependencies don't end up in the user's system. go clean -modcache cleans the source directory after the build so all those dependencies don't take up space. I'd be inclined to leave those unless there is a pressing reason to remove them. I did remove the go clean command from the prepare function since it's not really necessary before the build.

Yeah, that sounds like a sound idea. Also, take a look at my changes and perhaps adopt most of them.

Is it the desired behaviour that the noisetorch binary sets the capabilities for itself? As noisetorch is no longer usable without the capability cap_sys_resource I would assume that the best place to set it is the install file (like it is done for e.g. ping).

Ideally I'd want to separately package the C dependencies and dynamically link them in. As a start, I packaged rnnoise. Can you try linking that dynamically instead of the weird soname embedding that's going on?

Apart from that, this would be my current PKGBUILD: https://gitlab.archlinux.org/-/snippets/5

I did some minor cleanup on the PKGBUILD. It follows the go packaging guidelines as far as I can tell, and I believe it is reproducible. Updating the pkgver in the PKGBUILD is all I have been doing for the past couple releases, otherwise the current version builds no problem without intervention.

Make sure to clean up the package and make it reproducible/make it comply with go package guidelines.

@Svenstaro Absolutely not, go right ahead! Is there anything you need me to do?

@znoble360 The readme is indeed incorrect, but if the application prompts for creds to set the capability, it appears to operates on itself instead of a fixed path 1 and 2.

That executable function might have problems dealing with symlinks, but if the package is installed as-is, it should work. I haven't touched the setcap command on my system and I see:

$ getcap /usr/bin/noisetorch
/usr/bin/noisetorch cap_sys_resource=eip

You mind me pulling this into [community]?