Arch Linux User Repository

@robbert-vdh thanks, it worked

You've added /usr/lib/vst to yabridgectl. Don't do that. Run yabridgectl rm /usr/lib/vst and just hit enter at the prompt.

Hey everyone, anyone getting this kinda error?

Error: Could not remove '/usr/lib/vst/TPA-1.so'

Caused by: Permission denied (os error 13)

Before I would downgrade wine-staging but that failed to fix it..

@jpcima Unity builds sadly require a ton of memory. I now set the number of jobs to one job per every four gigabytes of memory available instead of only limiting the number of jobs when you have less than 8 gigabytes of memory (ninja defaults to $(nproc)). Let me know if that works better for you.

My machine has total_memory=14, and yet this build manages to oom kill my running processes. (note: it's 4-core/8-thread AMD)

@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.

@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.

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.

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)

@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.