[Cin] Packaging for Arch Linux

Sun Dec 30 04:14:59 CET 2018

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 <dave at sleepmap.de> 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-5.1/blds/PKGBUILD;h=04473dad26ce167c3a7aeb7905679e15cd175241;hb=HEAD
> [3]
> https://mudongliang.github.io/2016/07/11/relro-a-not-so-well-known-memory-corruption-mitigation-technique.html
> [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
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20181229/bd083b27/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PKGBUILD
Type: application/octet-stream
Size: 1848 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20181229/bd083b27/attachment.obj>