<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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.<br><br>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. <br>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.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> As it turns out, it is not all that hard to make a system deliverable<br>
> build using the following procedure:<br>
In fact, 'not that hard' would be:<br>
git clone <a href="https://aur.archlinux.org/cinelerrag-gg.git" rel="noreferrer" target="_blank">https://aur.archlinux.org/cinelerrag-gg.git</a><br>
cd cinelerra-gg<br><div>
makepkg -LCcf</div></blockquote><div><br></div><div>This build design would be the one that would fit "your" needs. Every month, I build:</div><div><br></div><div><div> ub14/deb ub18/deb ub17/deb ub16/deb leap14/rpm leap15/rpm ubuntu/deb mint18/deb \<br> fc26/rpm fc27/rpm fc28/rpm debian9i/deb debian8/deb debian9/deb arch/arch mint17/deb \</div><div> freebsd slk32 slk64<br></div><div><br></div><div>As you can see, there are several build designs that need to be accommodated. Your</div><div>suggestion does bare the fact that it is not as easy as it can be for you to do a bulid.</div><div><br></div><div>I can add the PKGBUILD I provided (or similar, if you have recommended changes) as</div><div>a file in the top level directory, so that it can operate as you wish. My build procedures</div><div>are in the "blds" directory. In fact, the PKGBUILD you have is just a simple composition of</div><div>blds/arch.bld and the monthly PKGBUILD which I normally use for each monthly build.</div><div>The dependency list is not customized to the vastly reduced build target design needed</div><div>when the thirdparty libraries are not built, where the build must rely only on system libraries.</div><div>If you have all of the demands needed to change the build design limit, you should remove</div><div>the --without features that can be removed. I am not very familiar with the current state</div><div>of the arch library series, and I think that you are vastly more qualified to make this kind</div><div>of judgement. If you can create a recommended PKGBUILD, I will be happy to add it to</div><div>the top level directory as you suggest.</div><div><br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Why is the --disable-static-build option to configure not documented,<br>
the various --disable-option possibilities are though?</div></blockquote>Disable static build defaults to "auto", which is no for system builds.</div><div>It is listed in ./configure --help. It did not need to be specified, but I put it in as a redundant</div><div>specification just to indicate that non-static builds are available. In fact, each monthly build</div><div>includes system packages that include thirdparty static, and are dynamically linked to most</div><div>normally available system libraries. The wide configuration of ffmpeg prevents just blasting</div><div>in a "one size fits all" type build config. I am only one good-guy after all.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>That is not what pkgrel [1] is for (hence my quote on versioning)!<br>
What you want is a consistent versioning, reflected in pkgver [2].</div></blockquote><div><br></div><div>These are monthly build ids, not any trick canonical naming system. As before, if you can</div><div>identify what you would like, I will be happy to add it as the top level build design for arch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>You will want to use devtools for that to achieve reproducibility.<br>
Also, there's no reason to use sudo here. Additionally, makepkg has a<br>
builtin log feature ( -L ), so there is no need for piping to tee<br>
manually.</div></blockquote><div><br></div><div>The data I provided was to illustrate that it is "not difficult" to produce a build. I did not say</div><div>it would be "perfect" for your needs. I am definitely not an expert on arch system build</div><div>designs. Any polish you can add would be widely appreciated.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> checking whether X_HAVE_UTF8_STRING is declared... no<br>
configure: error: Cinelerra requires utf8 support in X Windows.<br></div></blockquote><div><br></div><div>Strange, it is in /usr/include/X11/Xlib.h at line 70</div><div>and the autoconf test in configure looks good and succeeds on my arch system.</div><div>I have no idea why your getting this problem. I would check your system include</div><div>/usr/include/X11/Xlib.h for this line, and check the configure output of autogen.sh</div><div>to see if the test looks like:</div><div><font size="1">ac_fn_c_check_decl "$LINENO" "X_HAVE_UTF8_STRING" "ac_cv_have_decl_X_HAVE_UTF8_STRING" "#include <X11/Xlib.h><br>"<br>if test "x$ac_cv_have_decl_X_HAVE_UTF8_STRING" = xyes; then :<br>else<br> no_utf=yes<br>fi</font><br></div><div> <font size="2">Works for me.</font></div><div><font size="2"><br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font size="2">There are `--without-firewire --without-dv --without-dvb<br>
--without-video4linux2`, but the package dependencies are still pulled<br>
in in depends (also, that array should be named lower-case, not all<br>
upper case letters).<br></font></div></blockquote><div> <div>It is only recently that ffmpeg libraries have been widely published on mainstream distros.</div><div>The blds/*.bld scripts were created in haste, from a template build procedure that relied on</div><div>a reduced recipe. The --without feature set is more of a reflex action. I did not spend</div><div>a lot of time on any particular build design to determine the boundary of supported features.</div><div>It is definitely the case that using the thirdparty build when possible is more stable than most</div><div>system library sets. Heck, libxft is everywhere and is very dilapidated. I would recommend</div><div>that you use the thirdparty build if possbile for two reasons... 1) the version is known, current</div><div>and is more tested with this product. 2) in the event of a bug, the debug info can be easily</div><div>accessed since the source is always consistent to the binary. This is not easy to produce,</div><div>but... after using this for years I can say unequivocally that it is better. Also, what ARRAY?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>To get clarification about the dependencies, as this really doesn't jump<br>
at me: It seems to be okay to disable libzmpeg and commercial, but what<br>
is the latter actually pulling in/providing?<br>
I assume, that people would want something like lv2 integration. What is<br>
the rationale behind it being disabled?</div></blockquote><div> </div><div>A couple of years ago, I was so dismayed over rude TV commercials, that I began to</div><div>implement an "ad-blocker" for video. I mostly got it to work, but it requires too much</div><div>effort to maintain a database of signature clips of ads to block. I left it because it provides</div><div>a means to access reduced mpeg images in real time for ad suppression. It still needs</div><div>work, but the framework is valuable, and so it persists waiting for someone to make a</div><div>billion bucks by implementing an ad blocker for commercial TV.</div><div><br></div><div>The reason lv2 is disabled is that I ported lv2 at about the same time I created the *.bld</div><div>scripts. At the time, the lv2 support was pretty shaky. I opted to leave it out, but now it</div><div>may be ok to add it. It has not been tested at all in this way. It may or may not be possible.</div><div>My experience with lv2 was quite variable. some work well, some don't.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Another thing I found out is, that for ladspa integration, there's<br>
always the local version used, even if I provide `--disable-ladspa`, it <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>is set to "forced".</div></blockquote><div><br></div><div>When thirdparty is disabled, it is not built. I will fix the message in the ./configure output</div><div>to not indicate that it is in the build.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>> TO TEST: pacman -U ./cin-5.1-20181129-arch-x86_64.pkg.tar.xz (or<br>
> whatever) then type: cin</div></blockquote><div><br></div><div>Thanks for the suggestion.</div><div><br></div><div>I really appreciate you took the time to look hard at this. Hope to hear from you soon.<br></div><div>gg</div><div><br></div></div>
</div></div></div></div></div><br></div>