search

osam-cologne / archlinux-proaudio

Actively maintained binary package repo for Arch Linux of free and open source pro-audio software.
https://arch.osamc.de/
The Unlicense
43 stars 2 forks source link

Package VCV Rack plugins #97

Open cbix opened 2 years ago

cbix commented 2 years ago

Why should we package VCV Rack plugins?

Plugins

This list is mostly copied from VCV Library, Cardinal sources and wiki. WIP and Done are ticked off.

alefnull commented 2 years ago

(i hope it's alright that i'm commenting here) just wanted to drop a line and say i added a LICENSE file to my repo, so you should be able to include my plugin in this now. thanks for raising the issue with me :)

cbix commented 2 years ago

Thanks a lot @alefnull, also noticed there was a new release recently 🎉 I'll get at packaging a few more plugins soon hopefully :)

alefnull commented 2 years ago

no problem! and yeah, there will likely be some more releases in the near future too, as I've picked up a collaborator and we've only just started with the one module, but we already have others in the works. 😉

cbix commented 1 year ago

@alefnull FYI your modules finally made it into our repo and the AUR 🎉

alefnull commented 1 year ago

@alefnull FYI your modules finally made it into our repo and the AUR 🎉

cool! 😀 thanks for including me!

baconpaul commented 1 year ago

Hello

I believe you maintain the AUR version of VCVRack

The AUR version of VCV Rack currently appears to build in a way which results in a binary unable to load certain binaries from the VCV Rack library. Specifically, Surge XT (where I am a maintainer) doesn't load from library in the AUR rack. Also, newly, VCV Rack Free (previously Fundamental) seems not to. https://community.vcvrack.com/t/neither-surgext-nor-vcv-free-plugins-are-installing-updating-in-vcvrack-arch-linux-6-3-x/19969/42?u=baconpaul there's one such example.

This is causing a bit of a support burden for us. I currently have a FAQ which I paste into forums telling folks who want to use surge to not to use the AUR version, or to self build all of surge themselves. Most choose the former. I would say we get a user failing to use surge in rack on arch about every 8-10 days right now.

I don't run Arch so I haven't replicated this, but the rack forum (and our discord and rack discord) have quite a few similar examples. Some symbol incompatible etc... at dlopen time. You can subscribe to Surge XT in the rack library, run this rack, and you will see the red dot to upgrade never clears and you get a log message about a bad symbol.

I believe among the ways to rectify this situation you could consider the following:

  1. Use compatible libraries to the rack binary system for all your builds and test a variety of library plugins with your builds. You could do this, perhaps, using the rack docker image to do a build, or through some other mechanism. Add SurgeXT and VCV Free to your pre-release test checklist.
  2. Remove your modified vcv rack build from the AUR
  3. Make your modified vcv rack AUR download the rack binary directly from the rack downloads site rather than building
  4. Make the vcv rack AUR result in a build not able to dynamically load from the official library by patching the source
  5. Build and bundle surge xt (as well as all other broken plugins) with your package (although, of course, that wouldn't solve commercial plugins which had the same problem)
  6. Some other solution I which fits your workflow.

I hope you consider one of these, though; it is a bummer that Arch users use your package and can't use the more popular libraries.

Thank you for your attention to this matter!

cbix commented 1 year ago

Thanks for the info @baconpaul, I believe the best solution here is to vendor the problematic libraries again. We previously de-vendored those that are available as dynamic libraries. I'll look into the issue at hand to figure out which libs should be statically linked. Also looking into the future, maybe one measure to reduce ABI issues would be to check for differences to the official binaries during build (check() in PKGBUILD).

cbix commented 1 year ago

Wrt shipping the original binary

Make your modified vcv rack AUR download the rack binary directly from the rack downloads site rather than building

there's the vcvrack-bin package doing that and it would be against AUR guidelines to do the same in the vcvrack package.

baconpaul commented 1 year ago

Yeah so the last time I ran arch it was called gentoo. :) I have no idea what the solution is which is why I was hesitant in my list

but appreciate you looking. Surge xt rack is a pretty easy build too (but big) so for the surge problem specifically I suppose you could go that route.

thanks!

baconpaul commented 1 year ago

there's the vcvrack-bin package doing that and it would be against AUR guidelines to do the same in the vcvrack package.

Thank you! This is very useful. I will instruct Surge users who experience this break to try that package. Appreciated.

ArchieLinux commented 1 year ago

Many thanks! As the OP in the VCVRack thread cited above by @baconpaul, I can confirm that after makepkg and makepkg --install the vcvrack-bin-git now allows me to access SurgeXT plugins after all.

However, VCVRack is now telling me (by a red dot on Help menu) to upgrade to version 2.3.0 (from the 2.2.3 bin version). Having tried to use the direct download (2.3.0) previously, I spent several hours without success (i.e., would not install the SurgeXT and VCV Free/Foundation plugins).

Question: Should I simply ignore the upgrade message and hope someone produces a bin-git version of the latest VCVRack 2.3.0 at some point?

SpotlightKid commented 1 year ago

@ArchieLinux If you are logged in on aur.archlinux.org, you can leave a comment. You could try asking what is holding up the package update and/or ask whether you can offer any help.

If a package is flagged out-of-date and doesn't get an update for while, eventually somebody will come along and request the package to be orphaned so somebody else can take it over. If it has been flagged out-of-date for a while this request is usually granted.

ArchieLinux commented 1 year ago

@SpotlightKid Just left such a request.

If I thought I could be of genuine help, I'd offer ;-) Still in learning mode when it comes to building packages, compiling bins, ...

baconpaul commented 1 year ago

by the way, I'm not an arch user. The only way it seemed to create an aur account is to add the output of a pacman command, and I'm assuming zsh: pacman command not found is not what folks wanted. I don't know if anyone here can do anything about it, but perhaps an alternate way to avoid bots would allow maintainers of popular multi-platform open source packages give feedback on aur builds? any ideas?

SpotlightKid commented 1 year ago

That's a stupid way to do a captcha. That wasn't there when i created my account (years ago).

We're not really the right address to complain about this, though. We're not officially affiliated with the Arch project.

SpotlightKid commented 1 year ago

@baconpaul BTW, most AUR package maintainers put their email in the PKGBUILD file, which you can view from the AUR package page via a link on the upper right.

baconpaul commented 1 year ago

well i'm not sure if it is stupid. but if the intent is to do anything other than drive away non arch users maybe it is!

thanks anyway! let me know if i can help with surge and so forth at least. and appreciate the attention here to get this subset of our users back in the water.

baconpaul commented 1 year ago

@baconpaul BTW, most AUR package maintainers put their email in the PKGBUILD file, which you can view from the AUR package page via a link on the upper right.

thanks! I found this thread by googling the maintainer of vcvrack and finding the GitHub; an email is a better way for sure.

Appreciated