Hi, attached is an update blds/bld_prepare.sh script. It has two changes: - Extra entries to install the patchelf, boost_regex and boost_filesystem packages. - A fix for Suse, the test for the link was failing. @Andrea, did not have time to add an Arch/Manjaro section. Suse installs all packages, but it fails on the linking stage of the new makeappimage tool. Have to look at it. MatN
OK, I will check this into GIT next time I boot the desktop. It is always good to have at least 1 other person test stuff so am testing on my newest backup laptop with Fedora 35. On Mon, Mar 28, 2022 at 11:39 AM mnieuw--- via Cin < [email protected]> wrote:
Hi, attached is an update blds/bld_prepare.sh script.
It has two changes: - Extra entries to install the patchelf, boost_regex and boost_filesystem packages. - A fix for Suse, the test for the link was failing.
@Andrea, did not have time to add an Arch/Manjaro section.
Suse installs all packages, but it fails on the linking stage of the new makeappimage tool. Have to look at it.
MatN -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
@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
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
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.
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
I have choosen to put it in a seperate subdirectory of cinelerra-5.1, because it is not part of the product (cinGG), and should not be cleared when doing make clean or autogen clean. It normally needs to be built just once. Also, this keeps the possibility open that maybe we need other building tools to help create the product. Then each tool can have its own subdirectory of the tools subdirectory. makeappimage is indeed a derative of linuxdeploy, plugin support removed and build using autotools (like most of CinGG) rather than cmake. Much simpler and easier to understand. MatN
From line 6 of the new bld_appimage.sh it says:
60 # Use own version of linuxdeploy, makeappimage. This should be in 61 # subdirectory tools, if not, go to tools/makeappimagetool and do bld.sh 62 # there. That will place the makeappimage executable in tools, and 63 # then delete all other generated files (except the small log). The tools 64 # directory is not cleared with "make clean" or "autogen.sh clean" Maybe you should correct "subdirectory tools" in "subdirectory cinelerra-5.1"? If you confirm it I'll fix the manual by putting the "our" linuxdeploy (i.e. "makeappimagetool", if I understand correctly) instead of the git one.
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
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.
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.
I have now setup an Arch VM with fluxbox as windows manager, using the minimum system I could get working. 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 ;; Using fluxbox, the ram usage was impressive small: while building CinGG, it used less than 200 MB RAM, according to "free -h" . Tomorrow I'll add the manual without tex-full, that pulls in far too much. The used disk space after building does not change much: 8 - 9 G, between 2 times ARCH with XFCE desktop, and one with fluxbox. It seems to me the other platforms pull in far too much in bld_prepare.shfor building CinGG. MatN PS None of the 3 Arch installs in a VM went without hitches. Several time I had to kill VirtualBox because the desktop froze, usually after getting a lot of "enter" keystrokes, or after doing "fdisk -l" during the initial stages of the install process. Could be a VBOX isssue, of course, but none of the other distro VMs had that that I can remember.
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.
Checked into GIT MatN's mod as listed below (only this so far) for Arch bld_prepare.sh On Fri, Apr 1, 2022 at 3:48 PM mat via Cin <[email protected]> wrote:
I have now setup an Arch VM with fluxbox as windows manager, using the minimum system I could get working. 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 ;;
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.
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. 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.
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
Cinelerra itself does not use gtk (straigh X instead), but multiple of the thirdparty things. So gtk2 is a must. Don't know about ctags. cmake is needed. I did a new VM, this time documenting all steps. When installing xfce4 and xfce4-goodies, it pulls in a LOT of multimedia stuff, most of those we have in thirdparty I think. I'll see what more I have to install for CinGG build. MatN On Thu, 2022-03-31 at 19:26 +0200, Andrea paz via Cin 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.
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.
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.
Fine with me. MatN On Thu, 2022-03-31 at 14:22 -0600, Phyllis Smith via Cin wrote:
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.
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.
I'm not sure this is out of time for a reply, but the topic is this one. On 220328-19:32+0200, mnieuw--- via Cin wrote:
Hi, attached is an update blds/bld_prepare.sh script.
It has two changes: - Extra entries to install the patchelf, boost_regex and boost_filesystem packages. - A fix for Suse, the test for the link was failing.
@Andrea, did not have time to add an Arch/Manjaro section.
Suse installs all packages, but it fails on the linking stage of the new makeappimage tool. Have to look at it.
MatN
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. -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr my PGP-key: https://www.croatiafidelis.hr/FCF13245ED247DCE443855B7EA9884884FBAF0AE.asc
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.
There's also a reference for Anreas paz below. On 220628-19:58-0600, Phyllis Smith wrote:
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. Cinelerra community's work is even more appreciated here. I really enjoy Cinelerra ever more. Great program by a great team!
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.
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. Slightly related, and as I'm not expert in the field I'm hesitant to start the topic: 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? 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? Wish I had more time, because it's such a great program and team! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr my PGP-key: https://www.croatiafidelis.hr/FCF13245ED247DCE443855B7EA9884884FBAF0AE.asc
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?
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?
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?
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?
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
On 220630-16:29+0200, Miroslav Rovis wrote:
On 220630-13:31+0200, Andrea paz via Cin wrote: [...]
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.
This is how I do it. I open: https://cinelerra-gg.org/download/CinelerraGG_Manual/single_user_build.html (I updated it in the following paste with your change on the line from you new .tex file) And I follow. Will add citation mark to the pasted HTML text, so to distinguish my notes:
You need at least 6 GB of disk storage to operate a build + you need to have “git” installed. 2.9G <where-i-buil-it>/Cin/cinelerra5/ You do not need to be root (or sudo ...) to install, except to run bld_prepare.sh which calls in the distro's package manager. However if there are problems with permissions you can try to compile as root. The git step has to download many files (approx 130 MB) so allow time. 442M <where-i-git-cloned-it>/cinelerra5/ (but I might not have used the option --depth 1)
Run the following commands (this takes awhile): # This is where you need the 6GB of disk space 2.9G in my case (as above) cd /<build_path>/ git clone --depth 1 "git://git.cinelerra-gg.org/goodguy/cinelerra.git" cinelerra5 I might not have used the option --depth 1, I don't remember the first time I cloned, and afterwards I've always only pulled. So, this line in my case goes:
git pull (since git knows where to pull from, i.e. from where it cloned the first time) And here we go. The point of my mails
# Toplevel directory: cd cinelerra5/cinelerra-5.1
Only the following must be run "sudo -s " (on Debian and Debian-based systems, and very probably on most other if not all distros):
./blds/bld_prepare.sh <os> sudo -s ./blds/bld_prepare.sh debian (because that installs all the dependencies, libraries and other, into the system, as now your changed line reads)
And all the following as regular user:
./autogen.sh ./configure --with-single-user make 2>&1 | tee log make install Actually I made it wrong and ran sudo -s make install. Will not anymore.
Regarding the desktop icons, which you asked about, I don't install them and I don't use them, can't tell. That's it! Regards! -- 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?
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.
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.
So in totale we went from 212+269=481 Pages to more than 700; not bar! Il dom 3 lug 2022, 15:26 Phyllis Smith <[email protected]> ha scritto:
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-15:33-0600, Phyllis Smith wrote:
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 !! That must have been 1990s or even earlier? I knew no computing at all until 1997 or so... Still, that's an age ago! so many things changed. But this is a digression. Freely forgo! 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. I can't have a say with AppImage. My way is from source. I need to reply to Andrea's mail now.
-- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr my PGP-key: https://www.croatiafidelis.hr/FCF13245ED247DCE443855B7EA9884884FBAF0AE.asc
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
On 220704-19:36+0200, Miroslav Rovis wrote: [...]
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. Sid is forever unstable (I forgot to write that down.) [...]
-- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr my PGP-key: https://www.croatiafidelis.hr/FCF13245ED247DCE443855B7EA9884884FBAF0AE.asc
participants (6)
-
Andrea paz -
Andrew Randrianasulu -
mat -
Miroslav Rovis -
mnieuw@zap.a2000.nl -
Phyllis Smith