Package Details: yabridge-git 3.1.0.r13.g671c6a4-1

Git Clone URL: https://aur.archlinux.org/yabridge-git.git (read-only, click to copy)
Package Base: yabridge-git
Description: A modern and transparent way to use Windows VST2 and VST3 plugins on Linux
Upstream URL: https://github.com/robbert-vdh/yabridge
Licenses: GPL3
Conflicts: yabridge
Provides: yabridge
Submitter: robbert-vdh
Maintainer: robbert-vdh
Last Packager: robbert-vdh
Votes: 2
Popularity: 0.131423
First Submitted: 2020-05-05 13:30
Last Updated: 2021-04-24 18:35

Latest Comments

SpotlightKid commented on 2021-03-08 13:40

@robbert-vdh: I disagree with your reasoning. Users installing VCS packages should know how to update them. They are not for general usage by by users who don't know what they are for.

robbert-vdh commented on 2021-03-08 13:08

@SpotlightKid Normally there is indeed no need to version bump VCS packages. In this case however there are a number of people who have used these yabridge-git and yabridgectl-git AUR packages in the past to test some changes. Most of these people use AUR helpers (which is the only place where version bumps have any significance), and they would otherwise not receive any updates anymore unless they remember to manually reinstall yabridge-git from time to time. To avoid confusion I thus keep the versions of all yabridge* AUR packages in sync. And while it is convention to not version bump VCS packages without any other changes (which is also rarely needed since the majority of packages don't have frequent releases that don't also require build changes anyways), there is also no official guideline that prohibits this. If you use an AUR helper and you don't want these packages to automatically update when you update your system, then you can add them to the IgnorePkg field in /etc/pacman.conf.

SpotlightKid commented on 2021-03-08 12:41

Please don't push PKGBUILD updates if there were no changes except the generated version number. You only need and only should update a VCS package when there are actual changes to the PKGBUILD necessary.

magillos commented on 2021-01-06 10:39

Your newest pkgbuild (1 job) takes nearly 7 minutes to build and takes a little swap. After removing '--unity=on' and with setting up 'ninja -C build' regardless of RAM available (I hope it's what you wanted me to check) it takes over 13 minutes and uses bit more swap. The problem with previous pkgbuild was not only build time, but also it would make system so unresponsive that sometimes it had to be killed with SysRq and build run again after reboot. If built after reboot it would finish successfully but only after quite long time and occupying literally the whole Ram and swap avaible. So to me the current pkgbuild is the winner. Thanks! (again)

robbert-vdh commented on 2021-01-06 00:21

@magillos Of course! Those unity builds take up quite a bit of RAM, but they do speed up compilation significantly. I've now changed it so it only builds a single target a time at 4 GB RAM, since building a single target can take up to 1.5-2 gigs so with two at a time you're probably already swapping. If you have the time to spare, could you check for me whether building one unity target at a time is still faster than doing a normal build? If you get rid of the --unity=on and replace the memory checks with a plain ninja -C build then it will do a normal non-unity build. And if you really have the time, I'm also curious whether doing two targets at a time (and swapping) is faster than doing only one like I now configured it, because it probably is.

magillos commented on 2021-01-05 23:30

Hey, I noticed your pkgbuild takes into consideration amount of ram available. Could you limit number of current jobs for systems with little ram even further? With 4GB of ram and 4GB of swap on hand the build uses nearly all resources and it takes ages to finish. Thanks for your work!