Hi, Thank you for your email regarding your effort. As it turns out, it is not all that hard to make a system deliverable build using the following procedure: rm -rf /tmp/arch mkdir /tmp/arch cd /tmp/arch cp -a /tmp/cin_5.1.20181229-src.tgz . # you can get a tarball from last month's build here: # https://www.cinelerra-gg.org/download/pkgs/src/cin_5.1.20181129-src.tgz cp /tmp/PKGBUILD . # attached to email chown -R goodguy:goodguy . # your user name here sudo -u goodguy makepkg 2>&1 | tee pkg-arch.log You will have to update the md5sum in PKGBUILD to match the tarball you use. The cin_5.1.20181129-src.tgz tarball has: 3a964b60b7f2e216474841f1d64587c4 Be SURE to change the date in the PKGBUILD to match the tarball version. line 4: pkgrel=20181129 This produces a build with no thirdparty libraries, and is dynamically linked to system shared libraries, not to any build local binaries. It does add a variety of shared libraries as plugins, and a few executables needed by the program for utilities. I did test this, and it worked at least once. If you have any problems, or just have questions, or just are very friendly... feel free to chat us up. Can't tell the future, but I suspect that you will be able to do this quite easily. gg PS: there are a few spurious warnings, due to differences in the fffmpeg build config between the system ffmpeg and the thirdparty build... I will look into this as time permits. TO TEST: pacman -U ./cin-5.1-20181129-arch-x86_64.pkg.tar.xz (or whatever) then type: cin On Sat, Dec 29, 2018 at 3:07 PM David Runge <[email protected]> wrote:
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 -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin