I'll try to install an Arch Linux VM (had it before and it failed), then I can test needed packages, and hopefully find out why you cannot compile. It works here on Manjaro, have not tried Endeavour (but seem to recall there was a problem there). Later this week. MatN On Tue, 29 Mar 2022 16:48:02 +0200 Andrea paz via Cin <[email protected]> wrote:

...

@Andrea, did not have time to add an Arch/Manjaro section.

I got the dependencies from Arch's AUR repository. I integrated other dependencies (mostly graphics libraries) and got the following minimal base:

alsa-lib alsa-utils aom cairo dav1d expat fftw flac gdb glu gtk2 harfbuzz inkscape dvdauthor udftools libavc1394 libdv libglvnd libiec1883 libjpeg-turbo libogg libpng libpulse libraw1394 libtheora libtif libva libva-utils libvdpau libvorbis libvpx libwebp libxv mesa-utils numactl openexr opus cmake ctags git libxml2 nasm perl-xml-libxml perl-xml-parser python xorg-mkfontscale yasm

In the README.arch file in the CinGG git there are many other dependencies. I wonder if they are all really necessary. I don't know the use of many of them; others I think are installed in arch, at least to have the graphics with xorg; for example libx11 I don't know if it is needed or if it can be removed. It must be said that many of them are dependencies of other packages in the list, so even without indicating them they are installed anyway. In short, many of these dependencies are very old and I don't know if they are still needed. Unfortunately, I can't check for myself because I still can't compile from git:

atk bzip2 fontconfig \ freetype2 fribidi gdk-pixbuf2 \ graphite libdatrie \ libffi \ libsndfile libthai \ libutil-linux \ libx11 libxau libxcb libxcomposite libxcursor \ libxdamage libxdmcp libxext libxfixes libxft libxi \ libxinerama libxrandr libxrender \ pango pcre pixman xz zlib \ xorg-fonts-misc ttf-dejavu \ inxi vdpauinfo clinfo

On Tue, 2022-03-29 at 21:53 +0200, Andrea paz wrote:

...

I'll try to install an Arch Linux VM ...

Be careful though: Manjaro has its own repositories that are not synchronized with Arch's. So it may happen that Arch has an updated package and Manjaro doesn't yet. This might explain why Manjaro works and Arch doesn't.

Endevour OS only has 2 more "aesthetic" repositories than Arch. All the important ones are exactly the same. So it's to be expected that if compilation doesn't work in Arch then it won't work in Endevour either. I suggest you to install Endevour (some of my friends have it without having problems) that is much faster or, at the limit, Arch with the arch-install script that automates a little the installation.

PS: How do you test "needed packages"? I could try that.

Arch install is rather primitive from the ISO. just a little less bad then Gentoo.. I don't know the arch-install script. Once I have a working VM with Arch, I make a snapshot without any extra packages. Get the CinGG source, then start building it. ./configure will report multiple missing things, find out which packages they are in, install those, see if they fix at least that problem, and record those as needed. And so on until .configure goes OK and CinGG builds. Create a new entry for Arch/Manjaro/Endeavour in blds_prepare, add the notted packages, save the file outside the Arch machine. Shutdown, restore the snapshot from before the package install, get the CinGG source again, update bld_prepare.sh with the saves one, run it, see if CinGG builds. What is the reason you are using Arch instead of Manjaro or Endeavour? MatN

Well, at least I got a working Arch VM, with XFCE dekstop, VBox guest utils with working folder sharing/clipboard/dragdrop, git installed, audio/video working (with Firefox youtube). This will be my pristine base, made a snapshot. Got cin source, ./configure reported as first error gtk+-2.0 missing. Will continue tomorrow or later. MatN On Tue, 29 Mar 2022 16:48:02 +0200 Andrea paz via Cin <[email protected]> wrote:

...

@Andrea, did not have time to add an Arch/Manjaro section.

I got the dependencies from Arch's AUR repository. I integrated other dependencies (mostly graphics libraries) and got the following minimal base:

alsa-lib alsa-utils aom cairo dav1d expat fftw flac gdb glu gtk2 harfbuzz inkscape dvdauthor udftools libavc1394 libdv libglvnd libiec1883 libjpeg-turbo libogg libpng libpulse libraw1394 libtheora libtif libva libva-utils libvdpau libvorbis libvpx libwebp libxv mesa-utils numactl openexr opus cmake ctags git libxml2 nasm perl-xml-libxml perl-xml-parser python xorg-mkfontscale yasm

In the README.arch file in the CinGG git there are many other dependencies. I wonder if they are all really necessary. I don't know the use of many of them; others I think are installed in arch, at least to have the graphics with xorg; for example libx11 I don't know if it is needed or if it can be removed. It must be said that many of them are dependencies of other packages in the list, so even without indicating them they are installed anyway. In short, many of these dependencies are very old and I don't know if they are still needed. Unfortunately, I can't check for myself because I still can't compile from git:

atk bzip2 fontconfig \ freetype2 fribidi gdk-pixbuf2 \ graphite libdatrie \ libffi \ libsndfile libthai \ libutil-linux \ libx11 libxau libxcb libxcomposite libxcursor \ libxdamage libxdmcp libxext libxfixes libxft libxi \ libxinerama libxrandr libxrender \ pango pcre pixman xz zlib \ xorg-fonts-misc ttf-dejavu \ inxi vdpauinfo clinfo

That list seems to assume the Arch system has no GUI. I don't think setting up Arch for a GUI should be done by Cinelerra. If someone wants to build Cinelerra, it is resonable to required it is done on a system with working GUI and video/sound. If was not aware of this readme, else I would have documented the steps to get to a GUI system, but I installed not much. What I remember: xorg xfce4 xfce4-goodies pavucontrol . On that system, I am now testing what is really needed. So far the  bld_prepare change is: "arch") pacman -Syu git gtk2 nasm yasm cmake fftw patchelf boost boost-libs ;; Cinelerra-gg built once with this, inclusive appimage, am now running a control build from a pristine snapshot of the VM. I did notice when I started bin/cin that there were some errors in the terminal the first time, something about plugins. And I have not examined if there are more warnings in the build log than on say, Fedora. MatN On Thu, 2022-03-31 at 16:17 +0200, Andrea paz via Cin wrote:

This is the definitive list for README.sh; I propose to replace it with the one in the repository. Many packages will already be installed on the system, but it's better to keep them all (in Arch the base systems vary depending on the configuration of the various users...). I don't know if you should put the list inside bld_prepare.sh because the process is not totally automatic. In Arch, first you have to do a system update (pacman -Syu); then the pacman with all the list; confirm the will to install the packages of the list (and if there is an error you exit the pacman command and you have to give it again after the correction) and finally make sure that the process is successful.

alsa-lib alsa-utils aom cairo clinfo cmake ctags dav1d fftw flac freeglut gdb git glu graphite gtk2 harfbuzz inkscape inxi dvdauthor udftools jbigkit libavc1394 libdv libglvnd libiec61883 libjpeg-turbo libpulse libraw1394 libtheora libtiff libva libva-utils libvdpau libvorbis libvpx libxv libxml2 libwebp mesa-utils nasm numactl openexr opus pango perl-xml-libxml perl-xml-parser python ttf-dejavu vdpauinfo xorg-fonts-misc xorg-mkfontscale yasm

I enclose the README.arch file modified by me.

PS: I put a VM with EndeavourOS, but the build of CinGG fails causing the VM to crash.

With that, only the following in bld_prepare was needed to build

Cinelerra-gg: "arch") pacman -Syu gtk2 nasm yasm cmake fftw patchelf boost boost-libs \ base-devel libvdpau libva perl-xml-parser perl-carp libogg texinfo \ libsndfile

Sounds good. I have added this -- please check attached.

It seems to me the other platforms pull in far too much in bld_prepare.shfor building CinGG.

As you discover unnecessary items, send me the modified bld_prepare.sh.

Thanks Andrea as this needed updating -- but now I am confused by Mat's comments ?? On Thu, Mar 31, 2022 at 8:17 AM Andrea paz <[email protected]> wrote:

This is the definitive list for README.sh; I propose to replace it with the one in the repository. Many packages will already be installed on the system, but it's better to keep them all (in Arch the base systems vary depending on the configuration of the various users...). I don't know if you should put the list inside bld_prepare.sh because the process is not totally automatic. In Arch, first you have to do a system update (pacman -Syu); then the pacman with all the list; confirm the will to install the packages of the list (and if there is an error you exit the pacman command and you have to give it again after the correction) and finally make sure that the process is successful.

alsa-lib alsa-utils aom cairo clinfo cmake ctags dav1d fftw flac freeglut gdb git glu graphite gtk2 harfbuzz inkscape inxi dvdauthor udftools jbigkit libavc1394 libdv libglvnd libiec61883 libjpeg-turbo libpulse libraw1394 libtheora libtiff libva libva-utils libvdpau libvorbis libvpx libxv libxml2 libwebp mesa-utils nasm numactl openexr opus pango perl-xml-libxml perl-xml-parser python ttf-dejavu vdpauinfo xorg-fonts-misc xorg-mkfontscale yasm

I enclose the README.arch file modified by me.

PS: I put a VM with EndeavourOS, but the build of CinGG fails causing the VM to crash.

On Thursday, March 31, 2022, Andrea paz via Cin <[email protected]> wrote:

Mat is right, I too wonder if we really need gtk2 or perl or xorg fonts. I don't know how the titler and fonts management works in CinGG though, so I left them. I used to need other things like cmake (now maybe it's changed). The graphic libraries are probably partly installed by the DE, but I think it is not bad to leave them: if arch finds them already installed, it simply overwrites them without redownloading them, so it is a matter of seconds. Also the various ...-utils, vainfo, clinfo etc are not needed at all, but could be useful in case of problems, so I thought to leave them. You can remove alsa-lib; libpulse and python, because they are certainly automatically put in by DEs.

not really topical comment but on resource-constrained virtual systems I use fluxbox or something (not full DE)

Out of curiosity: there is also a list of dependencies in the AUR package, there are 32 of them. It can be found here: https://aur.archlinux.org/packages/cinelerra-gg

I mean, like you, I'm not sure if it's better to have a minimal list or to stay with an " excessive" one. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin

Andrea / MatN: About README.arch, now that my brain is working, is NOT a bld_prepare.sh option. It was mostly a "help" file for us here as we would be installing Arch from scratch on different computers. We started out with one of the URL internet lookups on "basic, easy install of Arch". Since it was so basic, what is in README.arch was all of the things we needed to work on building and testing CinGG on that distro. So, unless there is another package that should be added for installation, I would like to leave it as is. We can add on to the bottom like we did in June of 2020 when Mat provided notes for Manjaro and EndeavourOS. Hopefully this is satisfactory ?? On Thu, Mar 31, 2022 at 8:17 AM Andrea paz <[email protected]> wrote:

This is the definitive list for README.sh; I propose to replace it with the one in the repository. Many packages will already be installed on the system, but it's better to keep them all (in Arch the base systems vary depending on the configuration of the various users...). I don't know if you should put the list inside bld_prepare.sh because the process is not totally automatic. In Arch, first you have to do a system update (pacman -Syu); then the pacman with all the list; confirm the will to install the packages of the list (and if there is an error you exit the pacman command and you have to give it again after the correction) and finally make sure that the process is successful.

alsa-lib alsa-utils aom cairo clinfo cmake ctags dav1d fftw flac freeglut gdb git glu graphite gtk2 harfbuzz inkscape inxi dvdauthor udftools jbigkit libavc1394 libdv libglvnd libiec61883 libjpeg-turbo libpulse libraw1394 libtheora libtiff libva libva-utils libvdpau libvorbis libvpx libxv libxml2 libwebp mesa-utils nasm numactl openexr opus pango perl-xml-libxml perl-xml-parser python ttf-dejavu vdpauinfo xorg-fonts-misc xorg-mkfontscale yasm

I enclose the README.arch file modified by me.

PS: I put a VM with EndeavourOS, but the build of CinGG fails causing the VM to crash.

PK for me.

Andrea, Glad you explained -- I kept looking at possible Italian phrases that might be abbreviated PK. But I remember you said you had big hands for the mouse so figured your finger just hit the wrong key. On Thu, Mar 31, 2022 at 9:43 PM Andrea paz <[email protected]> wrote:

PK for me.

...

Sorry, OK for me.

...

On Tue, Jun 28, 2022 at 2:54 PM Miroslav Rovis via Cin < [email protected]> wrote:

I'm not sure this is out of time for a reply, but the topic is this one.

It is never out of time to have updated information and is much appreciated.

The bld_prepare.sh file is just as mnieuw attached it, plus some small additions for arch distro.

Installing Cinelerra from git yesterday on my Debian machine, and I'm running Debian Testing, when following: https://cinelerra-gg.org/download/CinelerraGG_Manual/single_user_build.html

I get this at this step:

# ./blds/bld_prepare.sh Reading package lists... Building dependency tree... Reading state information... Package python is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: 2to3 python-is-python3 python2-minimal python2 dh-python

E: Unable to locate package libdc1394-22-dev E: Package 'python' has no installation candidate

The solution for me was to edit the file, and the file that worked for me (I also changed the Ubuntu lines, as probably there is no python package in Ubuntu either, at least not in Ubuntu based on Debian Testing):

pls find the attached: bld_prepare.sh that worked for me:

The lines than changed concern only those packages as reported unavailable, not located by apt, above.

So that these updates do not got lost for future versions of ubuntu and

debian, I have checked into GIT blds/bld_prepare.sh with options for "debian-testing" and "ubuntu-testing" which when new Operating Systems releases come up, the script can be updated to reflect version XX of ubuntu/debian.

The question of whether to install from root/user is best left to Phyllis. She always uses her system as root and so I think operating as root is more tested and stable. Users using other distros can report if they need to be root to compile. I compile as a user on Arch and have not noticed any problems: like you I think it would be better not to recommend being root. However I do not know how to operate on the code and my judgment has no concrete justification. Perhaps you can add in the manual, at each sentence that requires you to be root, a sentence indicating that that step can also work as a simple user. Phyllis, what do you think?

I get or never built it as root, just as an ordinary user. The only time you need it (as sudo) is to install it system-wide. MatN On Wed, 29 Jun 2022 15:40:29 -0600 Phyllis Smith via Cin <[email protected]> wrote:

Andrea, Since it looks like we were replying at the same time, I will respond to your email by just saying, any step you have been running successfully as an ordinary user, you can update the manual to remove any root reference in that area. That would be better and safer for everyone. If there are any questionable references, we can just add one line towards the beginning of the manual, stating that if something does not work as a user, try sudo.

On Wed, Jun 29, 2022 at 3:27 PM Andrea paz <[email protected]> wrote:

...

The question of whether to install from root/user is best left to Phyllis. She always uses her system as root and so I think operating as root is more tested and stable. Users using other distros can report if they need to be root to compile. I compile as a user on Arch and have not noticed any problems: like you I think it would be better not to recommend being root. However I do not know how to operate on the code and my judgment has no concrete justification.

Perhaps you can add in the manual, at each sentence that requires you to be root, a sentence indicating that that step can also work as a simple user.

Phyllis, what do you think?

On 220630-13:31+0200, Andrea paz via Cin wrote:

I tried to change the manual by recommending to build as a normal user. See if you think it is okay. Particularly the part about the CinGG desktop icon. Can it also be done without being sudo?

I found this line now reads (from the .tex file you attached): \item You can install it without being \textbf{root} or without using \textit{sudo}. In case of problems you can use +\textit{sudo} to avoid permissions issue. while previously it read (from https://cinelerra-gg.org/download/CinelerraGG_Manual/single_user_build.html): 2. Recommend you build and run as root, just to avoid permission issues initially. And that is much better. There may be other changes you made, but unfortunately is is not easy to compare HTML with tex files, and I don't have enough time to install texinfo and do it the right way. If I had a diff btwn the previous version of the .tex file and the current, that would do better.

PS: (@Miroslav) I am interested in your steps to build in Debian (given my inadequate knowledge in compiling); can you explain them to me? I will. And I think I will not use a separate topic for it, it is sufficiently related to this thread.

I'll do it next. Just one thing. I believe mnieuw is right (interpolating the citation from his email):

I get or never built it as root, just as an ordinary user.

The only time you need it (as sudo) is to install it system-wide.

And so what I previously wrote, that I something like "sudo -s make install" after I ran "make" on the source, that wasn't necessary either. I should've run it as ordinary user as well. I'll send my steps next. [...]

\item You can install it without being \textbf{root} or without using \textit{sudo}. In case of problems you can use \textit{sudo} to avoid permissions issue. \item The \textit{git} step has to download many files (approx 130\,MB) so allow time. [...]

-- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr my PGP-key: https://www.croatiafidelis.hr/FCF13245ED247DCE443855B7EA9884884FBAF0AE.asc

Andrea, thanks. I have checked your changes into the Manual GIT (I did a little tweaking first, but if you want to tweak what I changed, that is OK). On Thu, Jun 30, 2022 at 5:31 AM Andrea paz <[email protected]> wrote:

I tried to change the manual by recommending to build as a normal user. See if you think it is okay. Particularly the part about the CinGG desktop icon. Can it also be done without being sudo?

PS: (@Miroslav) I am interested in your steps to build in Debian (given my inadequate knowledge in compiling); can you explain them to me?

Features5.pdf was 269 pages long AND that consisted of only the "new" features, not Cinelerra in general. On Sun, Jul 3, 2022 at 1:35 AM Andrea paz <[email protected]> wrote:

Good; it is a good thing for users to highlight parts of the manual that need improvement. We started out with the 212-page CinCV manual and now we have exceeded 700 pages! I no longer have Features5.pdf, so I can't remember how many pages it was.

It's not the Debian way to run make on a source as root, but as normal user.

I still have in my .bash_history the commands (and some logs) how I built my Cinelerra, and ran only 'bld_prepare.sh' and later 'make install' as root, or was it the equivalent: sudo -s <bld_prepare.sh/make install>.

All the other commands, the Debian way, is run them as user. E.g. it's a bad idea to git clone as root.

The thing is, on Gentoo, which I don't run and don't have since several years now, the packages are built and installed as root, that's fine. And probably on some of the other distros too, just not on any Debian based distro.

On no distro is it a good idea to git clone as root, I believe, and a newbie reader would go it all as root when she or he reads: https://cinelerra-gg.org/download/CinelerraGG_Manual/single_user_build.html

Unfortunately I don't have enough time, else I would very gladly install all the texinfo and try and send a patch for the texinfo source of the documentaion.

At this point in the email, I added Andrea to recipients of this mail now, as I think I remember he works that source, but guys forgive me if I misremember.

So if I'm correct, Anrdea, should that part of the manual be rewritten?

It would be better to do as many steps as possible as an ordinary user or at least using "sudo" instead of as the "root" user and if *Andrea* thoroughly tests these and wants to update the Manual, that would be good. Here, we spent so many early years working on computers that to us "root" IS our ordinary user name !! Since I have added to the manual over time and always run as root, I hate to introduce steps to the manual that I have never tried as any user except root.

And, since I don't have time to work the source now and send patches, are you interested that I write how I built and installed it, which would be a good Debian way to build and install from source? In a separate topic?

Although that would be useful, I think more people just use the AppImage than build it from source. More useful would be reporting bugs so that if a volunteer programmer comes along, they can work on those.

On 220629-21:32+0200, Miroslav Rovis wrote: [...]

On 220628-19:58-0600, Phyllis Smith wrote:

...

On Tue, Jun 28, 2022 at 2:54 PM Miroslav Rovis via Cin < [email protected]> wrote: [...]

...

Installing Cinelerra from git yesterday on my Debian machine, and I'm running Debian Testing, when following: https://cinelerra-gg.org/download/CinelerraGG_Manual/single_user_build.html

I get this at this step:

# ./blds/bld_prepare.sh Reading package lists... Building dependency tree... Reading state information... Package python is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: 2to3 python-is-python3 python2-minimal python2 dh-python

Pls. see this line (I refer to it further down):

...

...

E: Unable to locate package libdc1394-22-dev E: Package 'python' has no installation candidate

The solution for me was to edit the file, and the file that worked for me (I also changed the Ubuntu lines, as probably there is no python package in Ubuntu either, at least not in Ubuntu based on Debian Testing):

pls find the attached: bld_prepare.sh that worked for me:

The lines than changed concern only those packages as reported unavailable, not located by apt, above.

So that these updates do not got lost for future versions of ubuntu and debian, I have checked into GIT blds/bld_prepare.sh with options for "debian-testing" and "ubuntu-testing" which when new Operating Systems releases come up, the script can be updated to reflect version XX of ubuntu/debian.

I've pulled and seen your above said changes.

If anybody checked the plain debian as first argument to bld_prepare.sh, and that it works fine, then these changes are not yet in Debian stable (which I believe is Bullseye since a few months ago IIRC).

But these changes, if they're not in Debian stable already, are very likely coming to Bullseye the Debian stable. The time schedule of it, and the possible but rare backtracking, is also stuff that only expert packagers get to be familiar with, and I'm not one.

Looking into other matters, I figured out some more. Is this the bld_prepare.sh as currently is in master: https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra... I think it it (I have only so much time). I downloaded it and diffed it with the modified one that worked for me, and the: libdc1394-22-dev is still in it, and likely shouldn't be. These are the Debian versions: Buster = oldstable Bullseye = stable Bookworm = testing Sid = unstable --- The first three change with time, e.g. Buster was stable, now is oldstable. Bullseye was testing, now is stable, and so forth. And here's why I write it. For clarity, this is what I changed (so you don't have to look up old emails, for this part): This is the: diff <as-I-found-it-back-10-or-so-days-ago>/blds/bld_prepare.sh <as-I-changed-it>/blds/bld_prepare.sh 88c88 < libdc1394-22-dev libflac-dev libjbig-dev libvdpau-dev libva-dev \ ---

libdc1394-25 libdc1394-dev libflac-dev libjbig-dev libvdpau-dev libva-dev \

90c90 < autoconf automake debhelper libgtk2.0-dev libpulse-dev python \ ---

autoconf automake debhelper libgtk2.0-dev libpulse-dev 2to3 python-is-python3 python2-minimal python2 dh-python \

101c101 < libdc1394-22-dev libiec61883-dev libflac-dev libjbig-dev libusb-1.0-0-dev \ ---

libdc1394-25 libdc1394-dev libiec61883-dev libflac-dev libjbig-dev libusb-1.0-0-dev \

104c104 < libpulse-dev libtool python \ ---

libpulse-dev libtool 2to3 python-is-python3 python2-minimal python2 dh-python \

The way to find out if, allow quick paste:

But these changes, if they're not in Debian stable already is look up on packages.debian.org pages, like:

https://packages.debian.org/bullseye/2to3 Look at that! This package is in stable! https://packages.debian.org/buster/2to3 It is in oldstable too! Different version though. https://packages.debian.org/bookworm/2to3 Different version in testing as well, take a look! https://packages.debian.org/buster/python But python is also in oldstable. https://packages.debian.org/bullesys/python However not in stable anymore. The changes have caught! However it really takes somebody with probably best stable Debian to test building from source. This only helps a bit, I hope. IOW, the bld_prepare.sh is likely still not good, I'm afraid. I know it's bad news, and I'm only able to give it this much time. Because of other work, I have had time to encode with Cinelerra for even less time yet than it took me to prepare for this email, since I installed it a week ago. Thanks for your patience! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr my PGP-key: https://www.croatiafidelis.hr/FCF13245ED247DCE443855B7EA9884884FBAF0AE.asc