Yes, using the normal bld.sh is OK. I understood my mistake. I had run the script in .../cinelerra-5.1/blds; moving the script in .../cinelerra-5.1 there are no problems and the appimage obtained works fine. If you want to try this appimage of mine on your distros, you can download it from: https://drive.google.com/file/d/1cDd1yMXZL4k7dkyyHuXxQndcK5JF6weF/view?usp=s... Thanks!

I built this evening the AppImage on Fedora_35 from the git without problems. The vaapi works fine too (tested decoding), on the platform I built it on; not yet tested on other platforms. I had some problems building the manual from the git, but this was my first manual build on Fedora; I selectively installed texlive packages until I got the PDF and HTML manuals; but there might still be some missing. The PDF was produced, I saw some wrong things on the frontpage, and I think it has less pages on than the one on cinelerra-gg.org. I need to look at the error log. HTML was produced, did not have time yet to build an appInage with built-in help. Will try the builds on Mint next. MatN On Tue, 8 Feb 2022 14:29:17 -0700 Phyllis Smith via Cin <[email protected]> wrote:

Andrea, thank you very much for taking the time to create an AppImage.

If you want to try this appimage of mine on your distros, you can

...

download it from:

https://drive.google.com/file/d/1cDd1yMXZL4k7dkyyHuXxQndcK5JF6weF/view?usp=s...

My system is still at glibc 2.31 and you always keep your Arch updated and the AppImage seems to be at 2.33 so I could not run it . Am installing Fedora 35, the latest, and will try it there. Thank you, Phyllis

@MatN Thanks to Glitterball3 (https://www.cinelerra-gg.org/forum/postid/2022/), Phyllis added a section in the manual on how to unzip an appimage so you can make additions and changes to it. To complete the process, I found a way to recompress the folders back into an appimage using the "appimagetool" tool. However, this program is not in the repositories of all distros (Fedora, for example), so it's not universal enough to put in the manual. We can also do compression with "linuxdeploy", but I don't know how to do it. Do you have any idea how to use linuxdeploy to recompress the "squashfs-root" folder into a new appimage?

On Wednesday, February 9, 2022, mnieuw--- via Cin < [email protected]> wrote:

1. Change an AppImage. I have not tested re-compression, but as far as I know now an AppImage is a normal zip file with the internal layout specified. Can't you just zip the changed directory structure?

it seems appimage uses squashfs, not plain zip.. https://stackoverflow.com/questions/64564820/how-to-use-appimagetool-to-crea... (see log there) and there is header (script?) mounting image if you make it executable.. and this header somewhat limited to gzip-compressed squashfs? https://github.com/AppImage/AppImageKit/issues/1101

2. I cannot create a full AppImage on Mint 19.3 at the moment, because the manual does not build there any more. I can build an AppImage without the manual.

MatN

On Wed, 9 Feb 2022 10:03:00 +0100 Andrea paz via Cin <[email protected]> wrote:

...

@MatN Thanks to Glitterball3 (https://www.cinelerra-gg.org/forum/postid/2022/), Phyllis added a section in the manual on how to unzip an appimage so you can make additions and changes to it. To complete the process, I found a way to recompress the folders back into an appimage using the "appimagetool" tool. However, this program is not in the repositories of all distros (Fedora, for example), so it's not universal enough to put in the manual. We can also do compression with "linuxdeploy", but I don't know how to do it. Do you have any idea how to use linuxdeploy to recompress the "squashfs-root" folder into a new appimage?

-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin

Maybe https://github.com/kost/static-appimage/releases it worth a look, I came across it last year, but have not use it (yet). The source is in the "go" language, but I cannot make out how it compresses, it pulls in a lot of things. But maybe it solves your problem, executables are downloadable too. MatN On Wed, 2022-02-09 at 15:45 +0100, Andrea paz via Cin wrote:

Yes, appimage uses squashfs and then compresses it with gzip or something else. This is done, for example, with the command:

appimagetool --comp .../squashfs-root /tmp/my-appimage.appimage

(see: https://github.com/AppImage/AppImageKit)

But appimagetool is not available for all distros; for example I couldn't find it for Fedora. Also linuxdeploy is used to create/compress an appimage, but reading the manual I don't really understand how to do it...

On Wed, 2022-02-09 at 15:45 +0100, Andrea paz via Cin wrote:

Yes, appimage uses squashfs and then compresses it with gzip or something else. This is done, for example, with the command:

appimagetool --comp .../squashfs-root /tmp/my-appimage.appimage

(see: https://github.com/AppImage/AppImageKit)

But appimagetool is not available for all distros; for example I couldn't find it for Fedora. Also linuxdeploy is used to create/compress an appimage, but reading the manual I don't really understand how to do it...

You can download the appimagetool for your enviroment from https://github.com/AppImage/AppImageKit/releases MatN

linuxdeploy is basically a AppDir preparation tool. Once it is ready with that, it calls its built-in appimage creation plugin (which I guess is the same as appimagetool).

You're right Mat: just use linuxdeploy replacing the "AppDir" folder with "squashfs-root": ./linuxdeploy-x86_64.AppImage --appdir squashfs-root --output appimage I tried creating a new section in the manual, but it needs a major revision. What do you guys think? Do these procedures work for you?

On Thu, 10 Feb 2022 09:35:48 +0700 (+07) Georgy Salnikov <[email protected]> wrote:

On Wed, 9 Feb 2022, mnieuw--- via Cin wrote:

...

2. I cannot create a full AppImage on Mint 19.3 at the moment, because the manual does not build there any more. I can build an AppImage without the manual.

I stand corrected. It works today?? On Mint 19.3, Mint 20.3 and Fedora_35 I can build PDF and HTML version from latest git source.

On the problems of converting the manual.

1) As the manual is absolutely architecture-independent, nothing is against building it under some most convenient platform (that, for example, where all the necessary latex/html tools are installed/configured) and then populating the resulting manual over all the other needed platforms.

Unless you want to build the complete AppImage inclusive the nice built-in help. Then the manual needs to be built too.

2) Mat, could you notice, what particular problem prevented the compilation of the manual? What was changed?

In the "translate_manual" script, I selected the option for png images for the HTML version. On Fedora_35, the build goes fine but has one page more than the January download from CinGG. I installed packages one by one until it completed, because I wanted to know which packages are really needed. I was thinking of making something like the "blds/bld_prepare.sh" script in the CinGG source, which installs needed packages for the distro. In any case for Fedora I had to install: texlive texlive-subsitutefont texlive-mathdesign texlive-t2 texlive-multirow texlive-was texlive-wrapfig texlive-nomencl latex2html and maybe texlive-tex4ht too (not sure). No "error:" in the log, quite a few "warning:" . And the HTML front page has some color indicating texts, like "CinBlue" just before "The" On Mint 19.3, the PDF is only 701 pages instead of 728 on Fedora (same source). I cannot remember which packages I installed, likely I used "texlive-full", which pulls in far too much. This is not available on Fedora. No "error:" in the log, quite a few "warning:" , among which Label 'sub:how_it_works: multiply defined . On Mint 20.3, the PDF is 730 pages. here I also installed texlive-full . There is a difference in the messages in the terminal at the end of a build (the html build). Compared to Mint 20.3, on Mint 19.3, there are 4 extra lines like: No number for "Infowindowswiththe"Detail"box" plus some differences in the line of "Unknown commands:" Compared to Mint 20.3, on Fedora_35 there are more differences, such as: no implementation found for class 'memoir' which is strange because texlive-memoir is installed. MatN

On Thu, 10 Feb 2022 [email protected] wrote:

...

1) As the manual is absolutely architecture-independent, nothing is against building it under some most convenient platform (that, for example, where all the necessary latex/html tools are installed/configured) and then populating the resulting manual over all the other needed platforms.

Unless you want to build the complete AppImage inclusive the nice built-in help. Then the manual needs to be built too.

I meant the following. The built-in context help engine is, of course, architecture dependent. As it is actually part of the CGG binary, it is built from the sources of CGG itself (not from the sources of the manual) and then comes into AppImage inside the CGG binary executable. The perl script which performs searching for the proper html page to display on pressing Alt/H resides also in the CGG (not manual's) source tree and is installed together with the whole CGG. The context help pages are nothing else than the html form of the manual. These html pages are platform independent, and technically even CGG-version independent. Nothing prevents from translating these pages on some most convenient computer (with good configured TeX system and latex2html) followed by the addition of them to different CGG binary installations. The context help engine, technically, takes no assumption about any correspondence between itself and the contents of the html manual pages, except that there should exist a file with the name 'Contents.html'. Technically it is possible to put there some html files produced for some other version of CGG, nothing will crash, context help will still work and even often yield reasonable pages for displaying. So one needs to ensure only logical (not binary) correspondence between CGG and its manual to get the consistent information of the help pages.

In the "translate_manual" script, I selected the option for png images for the HTML version.

On Fedora_35, the build goes fine but has one page more than the January download from CinGG. I installed packages one by one until it

There can be more or less html pages in the manual, depending on the number of LaTeX sections. If Andrea adds a section to the LaTeX manual, probably it will lead to one more html file in the result.

completed, because I wanted to know which packages are really needed. I was thinking of making something like the "blds/bld_prepare.sh" script in the CinGG source, which installs needed packages for the distro. In any case for Fedora I had to install: texlive texlive-subsitutefont texlive-mathdesign texlive-t2 texlive-multirow texlive-was texlive-wrapfig texlive-nomencl latex2html and maybe texlive-tex4ht too (not sure).

No "error:" in the log, quite a few "warning:" . And the HTML front page has some color indicating texts, like "CinBlue" just before "The"

On Mint 19.3, the PDF is only 701 pages instead of 728 on

The correctly installed TeX system MUST unconditionally produce IDENTICALLY typeset pdf pages on ANY computer/OS. If you get different number of pages, it means you have some quirks (incompleteness) in your TeX installation. For example, if you have not installed the 'makeindex' program, you will get neither Index nor Glossary sections in pdf. Also, to get the complete pdf result, it is necessary to run at least 3 times pdflatex and 3 times makeindex in that sequence, as in the translate_manual script.

Fedora (same source). I cannot remember which packages I installed, likely I used "texlive-full", which pulls in far too much. This is not available on Fedora.

No "error:" in the log, quite a few "warning:" , among which Label 'sub:how_it_works: multiply defined .

You can grep '\label{sub:how_it_works}' through the .tex files to check if it was not a mistake in the latex-sources of the manual.

On Mint 20.3, the PDF is 730 pages. here I also installed texlive-full .

There is a difference in the messages in the terminal at the end of a build (the html build). Compared to Mint 20.3, on Mint 19.3, there are 4 extra lines like: No number for "Infowindowswiththe"Detail"box" plus some differences in the line of "Unknown commands:"

Latex2html prints a lot of messages while translation. Usually the warnings like "Unknown command" are not critical, as long as the html result looks acceptable. Latex2html expects that it can encounter some LaTeX commands which it does not support natively. If so, latex2html either tries to feed the proper part of LaTeX text to pdflatex itself to convert it into a generated image (so are the math expression except the simplest ones), or to output the argument of the command assuming the command can be ignored. In any case you will see the message "Unknown command".

Compared to Mint 20.3, on Fedora_35 there are more differences, such as: no implementation found for class 'memoir' which is strange because texlive-memoir is installed.

Mat, check your latex2html version: latex2html -version If the version is older than something like 2021.2, then the class 'memoir' is not yet supported, you have to upgrade (or patch) latex2html to translate CGG manual. Georgy _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________