[Cin] Packaging for Arch Linux
dave at sleepmap.de
Sun Dec 30 11:30:33 CET 2018
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
> 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
> 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  is for (hence my quote on versioning)!
What you want is a consistent versioning, reflected in pkgver .
> 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  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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Cin