[Cin] Packaging for Arch Linux

[Good Guy]

David: your feedback is very much appreciated and we will do what we can to
resolve the issues you brought up as best as possible, but if it is still
too burdensome for you, you have to consider whether or not you feel it is
worth your time.

We do monthly builds for Arch, Centos, Debian 8 & 9, Fedora 26-29,
Leap/Suse 15, 42 & 10bit, Mint 18 & 19, Slackware 32 and 64 bit, Ubuntu 14,
16, 17, 18 & 32bit v14, and FreeBSD.  The build procedures we use have to
work for all of these as automatically as possible using XEN.  Even then we
still have to do some manual work.
GG's expertise is in programming languages and writing build scripts was
only something he had to do to get cinelerra-gg software usable.  It would
be really great to have a person whose expertise is in writing build
scripts help out and still leave our XEN working.

> 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
>

This build design would be the one that would fit "your" needs.  Every
month, I build:

  ub14/deb ub18/deb ub17/deb ub16/deb leap14/rpm leap15/rpm ubuntu/deb
mint18/deb \
  fc26/rpm fc27/rpm fc28/rpm debian9i/deb debian8/deb debian9/deb arch/arch
mint17/deb \
  freebsd slk32 slk64

As you can see, there are several build designs that need to be
accommodated.  Your
suggestion does bare the fact that it is not as easy as it can be for you
to do a bulid.

I can add the PKGBUILD I provided (or similar, if you have recommended
changes) as
a file in the top level directory, so that it can operate as you wish.  My
build procedures
are in the "blds" directory.  In fact, the PKGBUILD you have is just a
simple composition of
blds/arch.bld and the monthly PKGBUILD which I normally use for each
monthly build.
The dependency list is not customized to the vastly reduced build target
design needed
when the thirdparty libraries are not built, where the build must rely only
on system libraries.
If you have all of the demands needed to change the build design limit, you
should remove
the --without features that can be removed.  I am not very familiar with
the current state
of the arch library series, and I think that you are vastly more qualified
to make this kind
of judgement.  If you can create a recommended PKGBUILD, I will be happy to
add it to
the top level directory as you suggest.


Why is the --disable-static-build option to configure not documented,
> the various --disable-option possibilities are though?
>
Disable static build defaults to "auto", which is no for system builds.
It is listed in ./configure --help.  It did not need to be specified, but I
put it in as a redundant
specification just to indicate that non-static builds are available.  In
fact, each monthly build
includes system packages that include thirdparty static, and are
dynamically linked to most
normally available system libraries.   The wide configuration of ffmpeg
prevents just blasting
in a "one size fits all" type build config.  I am only one good-guy after
all.

That is not what pkgrel [1] is for (hence my quote on versioning)!
> What you want is a consistent versioning, reflected in pkgver [2].
>

These are monthly build ids, not any trick canonical naming system.  As
before, if you can
identify what you would like, I will be happy to add it as the top level
build design for arch.

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.
>

The data I provided was to illustrate that it is "not difficult" to produce
a build.  I did not say
it would be "perfect" for your needs.  I am definitely not an expert on
arch system build
designs.  Any polish you can add would be widely appreciated.

  checking whether X_HAVE_UTF8_STRING is declared... no
>   configure: error: Cinelerra requires utf8 support in X Windows.
>

Strange, it is in /usr/include/X11/Xlib.h at line 70
and the autoconf test in configure looks good and succeeds on my arch
system.
I have no idea why your getting this problem.  I would check your system
include
/usr/include/X11/Xlib.h for this line, and check the configure output of
autogen.sh
to see if the test looks like:
ac_fn_c_check_decl "$LINENO" "X_HAVE_UTF8_STRING"
"ac_cv_have_decl_X_HAVE_UTF8_STRING" "#include <X11/Xlib.h>
"
if test "x$ac_cv_have_decl_X_HAVE_UTF8_STRING" = xyes; then :
else
  no_utf=yes
fi
Works for me.

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).
>

It is only recently that ffmpeg libraries have been widely published on
mainstream distros.
The blds/*.bld scripts were created in haste, from a template build
procedure that relied on
a reduced recipe.  The --without feature set is more of a reflex action.  I
did not spend
a lot of time on any particular build design to determine the boundary of
supported features.
It is definitely the case that using the thirdparty build when possible is
more stable than most
system library sets.  Heck, libxft is everywhere and is very dilapidated.
I would recommend
that you use the thirdparty build if possbile for two reasons... 1) the
version is known, current
and is more tested with this product.  2)  in the event of a bug, the debug
info can be easily
accessed since the source is always consistent to the binary.  This is not
easy to produce,
but... after using this for years I can say unequivocally that it is
better.  Also, what ARRAY?

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?
>

A couple of years ago, I was so dismayed over rude TV commercials, that I
began to
implement an "ad-blocker" for video.  I mostly got it to work, but it
requires too much
effort to maintain a database of signature clips of ads to block.  I left
it because it provides
a means to access reduced mpeg images in real time for ad suppression.  It
still needs
work, but the framework is valuable, and so it persists waiting for someone
to make a
billion bucks by implementing an ad blocker for commercial TV.

The reason lv2 is disabled is that I ported lv2 at about the same time I
created the *.bld
scripts.  At the time, the lv2 support was pretty shaky.  I opted to leave
it out, but now it
may be ok to add it.  It has not been tested at all in this way.  It may or
may not be possible.
My experience with lv2 was quite variable.  some work well, some don't.

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".
>

When thirdparty is disabled, it is not built.  I will fix the message in
the ./configure output
to not indicate that it is in the build.

> TO TEST: pacman -U ./cin-5.1-20181129-arch-x86_64.pkg.tar.xz (or
> > whatever) then type: cin
>

Thanks for the suggestion.

I really appreciate you took the time to look hard at this.  Hope to hear
from you soon.
gg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20181230/b6d0465e/attachment.html>