Hey there, I have just dropped the cinelerra-cv package from the official repositories on Arch Linux (to the AUR). Initially I planned on replacing it with cinelerra-gg, but I don't think this is very feasible at this point in time. I started to attempt a build, that is dynamically linked against the required system libraries [1], but it seems to be an equal amount of work compared to cinelerra-cv, which is not at all feasible. This is not because of the libraries themselves failing to work or missing symbols or anything like that, but because the build system actively prevents building a dynamically linked application! However, I already hack-fixed a great deal of things compared to the upstream provided attempt [2] (on a static build), which really doesn't need to depend on all the packages, that the PKGBUILD lists in depends=() (because of its static nature). That aside, a static build of this size in the official repositories of Arch Linux is not ever going to become a reality (nor in any other distribution), if nearly all of the components are available as a package. Therefore I would like you to consider to fix a great deal regarding the build system of cinelerra-gg to remedy this situation and move towards a (mostly) dynamically linked application instead. I believe this can be fairly straight forward with dynamic rebuilds against different versions of the required libraries in a continuous integration pipeline! The tools are there. In case static builds is what you will be going for no matter what, disregard the rest of my e-mail. That being said, I had to hack in nearly all of the --libs (which could just easily be gotten by calls to pkg-config, instead of hardcoding some of them or just not making them available at all) and also some of the --cflags for lv2 integration. I'm left with a (working!) application (probably with a bunch of broken edges), that - unfortunately - doesn't feature full RELRO [3] (because LDFLAGS are not propagated throughout all the components), PIE [4] (not implemented), has executable stack [5] (which I haven't encountered before with any of the other software I package, but is apparently pretty bad) and *a lot* of "unused shared library" references (due to the bizarre "libs" files being used to store all the library names instead of dynamically assembling them, when needed). The naming of the project, its subdirectories and (un-)declared/undocumented thirdparties (which of them are real thirdparties, which are your own/modified?) are confusing. The project does not (yet) have a form of versioning (at least not reflected in actual git tags), unless you're up for using calver (I recommend semver to actually be able to discern different levels of stability, feature availability and to work towards a roadmap). Considering providing (unsupported) builds for Arch Linux: Please use the AUR for providing PKGBUILDs and name the package according to your upstream (cinelerra-gg), unless you have the intent to rename the project. Make sure to use devtools [8] (e.g. `extra-x86_64-build -c` in the directory of the PKGBUILD) to build your package. It will give you *a lot* of additional information, as the package build is done in a pristine containered build, using systemd-nspawn. In case cin [7] is done by you: Please, never push binary data to the repositories! Closing, please don't get me wrong: It's your project and all, but this is a situation, that will drive away any potential packager of the software as it's just too complicated to plainly build (no matter the eventual runtime problems one might get)! I know this project has come a long way, but I believe it would benefit from a general cleanup and restructuring, which will render it much more accessible! Best, David P.S.: If you have any questions regarding the Arch Build System (ABS), or packaging on Arch Linux, or my PKGBUILD (which was still a WIP, when I stopped), shoot away! [1] http://pkgbuild.com/~dvzrv/aur/cinelerra-gg/PKGBUILD [2] https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra... [3] https://mudongliang.github.io/2016/07/11/relro-a-not-so-well-known-memory-co... [4] https://en.wikipedia.org/wiki/Position-independent_code [5] https://en.wikipedia.org/wiki/Executable_space_protection [6] https://aur.archlinux.org [7] https://aur.archlinux.org/cgit/aur.git/tree/?h=cin [8] https://www.archlinux.org/packages/extra/any/devtools/ -- https://sleepmap.de