Hi! On 2018-12-29 20:14:59 (-0700), Good Guy wrote:
As it turns out, it is not all that hard to make a system deliverable build using the following procedure: In fact, 'not that hard' would be: git clone https://aur.archlinux.org/cinelerrag-gg.git cd cinelerra-gg makepkg -LCcf
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 With build you mean source tarball, right?
cp /tmp/PKGBUILD . Where does the PKGBUILD come from? Where is it maintained? After all, it is not the same as the one in the source tarball (see my note about confusing sources and structures). Why is the --disable-static-build option to configure not documented, the various --disable-option possibilities are though?
# attached to email chown -R goodguy:goodguy . # your user name here sudo -u goodguy makepkg 2>&1 | tee pkg-arch.log You will want to use devtools for that to achieve reproducibility. Also, there's no reason to use sudo here. Additionally, makepkg has a builtin log feature ( -L ), so there is no need for piping to tee manually.
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 That is not what pkgrel [1] is for (hence my quote on versioning)! What you want is a consistent versioning, reflected in pkgver [2].
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. For me this ends right at configure in:
checking whether X_HAVE_UTF8_STRING is declared... no configure: error: Cinelerra requires utf8 support in X Windows. which is strange, as I have not run into this before!
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. There are `--without-firewire --without-dv --without-dvb --without-video4linux2`, but the package dependencies are still pulled in in depends (also, that array should be named lower-case, not all upper case letters).
To get clarification about the dependencies, as this really doesn't jump at me: It seems to be okay to disable libzmpeg and commercial, but what is the latter actually pulling in/providing? I assume, that people would want something like lv2 integration. What is the rationale behind it being disabled? Another thing I found out is, that for ladspa integration, there's always the local version used, even if I provide `--disable-ladspa`, it is set to "forced".
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 What one really should to do is to run namcap [1] on that package, instead of installing it! This would also help in decimating the huge amount of unneeded dependencies, this package pulls in (some of which should at best be optdepends, but many are already provided by pulling in one of the others)!
Best, David [1] https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel [2] https://wiki.archlinux.org/index.php/PKGBUILD#pkgver [3] https://wiki.archlinux.org/index.php/Namcap -- https://sleepmap.de