Package Details: noisetorch 0.10.0-3

Git Clone URL: (read-only, click to copy)
Package Base: noisetorch
Description: Real-time microphone noise suppression on Linux.
Upstream URL:
Licenses: GPL3
Provides: noisetorch
Submitter: erbrecht
Maintainer: erbrecht
Last Packager: erbrecht
Votes: 5
Popularity: 1.17
First Submitted: 2020-12-11 15:09
Last Updated: 2021-02-09 14:25

Latest Comments

1 2 3 Next › Last »

erbrecht commented on 2021-04-05 12:38

We've actually been making an effort to move this into the official repos. I think I 100% agree with you though.

ainola commented on 2021-03-25 04:25

What I'm arguing is that it doesn't matter what the license says. The license could explicitly say "arch linux users can never use this package" but that doesn't mean anything because this is a build script, not the program itself. We're doing nothing but providing the recipe for users to build/install locally on their machines. The author is mistakenly thinking that they have control over what users do with source that is made available to the public. It doesn't matter if it's GPL, proprietary, or ultra-illegal-you-cannot-change-anything-because-i-said-so license.

Again, if this were in the official repos with pre-built packages then it'd be a different story.

erbrecht commented on 2021-03-24 12:51

You may be right, but it's a little unclear. Section 7c states that a GPLv3 licensor can apply additional terms:

Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version.

It doesn't really say this is a requirement only for redistribution or packaged versions, so I'm not really sure if it's enforceable.

Either way, I think I'm pretty much done maintaining this. I thought it would be an interesting foray into building packages, but it has been a bad experience. Normally this kind of thing is right up my alley, and I love that I've been able to contribute a bit to Arch.

If someone wants to take over I'd be glad to help transition. I actually started a bit of work to create a new make target for distros that use go build tags to selectively include go source instead of patching things ( If upstream accepts this method, which they stated they would, they wouldn't be asking us to rename the package. I just don't want to maintain this package since it's basically been an uphill battle from the start.

ainola commented on 2021-03-22 15:47

I do not believe that we are under any obligation to change the name so long as this is in the AUR. This is not distribution of pre-built software, this is a build script for users to create binaries for themselves. It's why the AUR is able to have myriad proprietary softwares in the repository. If Arch were to include noisetorch in the official repositories then I imagine Arch would then need to solicit a fork.

Unless there's going to be serious potential ramifications (legal threats, pushing the dev into going open-code in some misguided attempt to "fix" the situation, etc.) it seems like the package can just continue to live, patched, in the AUR alongside countless other softwares that upstream authors do not bless.

The author has demonstrated a lack of tact that ensures a barrier to mutuality; I propose we just continue doing our thing in the AUR and make software that's proper in accordance to sane packaging.

znoble360 commented on 2021-02-28 17:53

Or noiseflashlight

Widowan commented on 2021-02-28 15:23

Can't it be like "noisetorch-patched" or something?

Svenstaro commented on 2021-02-25 17:37

I'm not really sure where this hostility from upstream is coming from. I suppose you can just rename it to not-noisetorch and move on with this. :p what a silly upstream move.

erbrecht commented on 2021-02-25 15:54

I was notified by the owner of the repo that starting with the next release, they will be adding a restriction to modified versions of the application:

Addition to the license is here:

We'll need to either change the name of this package, or stop distributing it this way. I'm open to naming suggestions, but with this latest change we can't push this into [community] as-is.

erbrecht commented on 2021-02-19 14:11

It looks like their own implementation. They mentioned in the release notes that it's their own, and the repo doesn't seem to contain any submodules or links to other repos.

I created a PKGBUILD for their ladspa implementation:

I also updated my experimental PKGBUILD to properly link the library:

Everything seems to work fine.

Svenstaro commented on 2021-02-09 19:27

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?