I tried to build the CinGG appimage with bld_appimage.sh, but I get the following error: $ ./bld_appimage.sh ./bld_appimage.sh: line 14: ./autogen.sh: No such file or directory ./bld_appimage.sh: line 15: ./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. mv: cannot stat 'Makefile': No such file or directory cp: cannot stat 'Makefile.devel': No such file or directory cp: cannot stat 'bin': No such file or directory linuxdeploy version 1-alpha (git commit ID 4c5b9c5), GitHub actions build 57 built on 2022-01-12 09:53:03 UTC -- Creating basic AppDir structure -- Creating directory AppDir/usr/bin/ Creating directory AppDir/usr/lib/ Creating directory AppDir/usr/share/applications/ Creating directory AppDir/usr/share/icons/hicolor/ Creating directory AppDir/usr/share/icons/hicolor/16x16/apps/ Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/ -- Deploying dependencies for existing files in AppDir -- -- Deploying executables -- ERROR: No such file or directory: bin/cin The only change I made to bld_appimage.sh is to put a "./" in front of the linuxdeploy-x86_64.AppImage command. However, the compilation of CinGG doesn't happen (I think because of paths not put or wrong...) and after, the folder "bin" is not copied in "AppDir/usr". Trying to use the absolute paths inside bld_appimage.sh, I get something similar. but there are more steps than before: $ LC_ALL=C ./bld_appimage.sh ./bld_appimage.sh: line 14: ./autogen.sh: No such file or directory ./bld_appimage.sh: line 15: ./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. mv: cannot stat 'Makefile': No such file or directory cp: cannot stat 'Makefile.devel': No such file or directory cp: cannot stat 'bin': No such file or directory ./bld_appimage.sh: line 27: ./linuxdeploy-x86_64.AppImage: Permission denied [paz@arch-paz blds]$ LC_ALL=C ./bld_appimage.sh ./bld_appimage.sh: line 14: ./autogen.sh: No such file or directory ./bld_appimage.sh: line 15: ./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. mv: cannot stat 'Makefile': No such file or directory cp: cannot stat 'Makefile.devel': No such file or directory cp: cannot stat 'bin': No such file or directory linuxdeploy version 1-alpha (git commit ID 4c5b9c5), GitHub actions build 57 built on 2022-01-12 09:53:03 UTC -- Creating basic AppDir structure -- Creating directory AppDir/usr/bin/ Creating directory AppDir/usr/lib/ Creating directory AppDir/usr/share/applications/ Creating directory AppDir/usr/share/icons/hicolor/ Creating directory AppDir/usr/share/icons/hicolor/16x16/apps/ Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/ -- Deploying dependencies for existing files in AppDir -- -- Deploying executables -- ERROR: No such file or directory: bin/cin [paz@arch-paz blds]$ LC_ALL=C ./bld_appimage.sh + rm -f global_config configure Makefile Makefile.in + rm -f aclocal.m4 depcomp compile install-sh ltmain.sh + rm -f config.log config.guess config.h config.h.in config.sub config.status missing + rm -rf autom4te.cache m4 + '[' '' = clean ']' + autoupdate autoupdate: error: 'configure.ac' is required + mkdir m4 + autoreconf --install autoreconf: error: 'configure.ac' is required ++ uname -o + '[' GNU/Linux = Android ']' + '[' -e /system/bin/app_process ']' ./bld_appimage.sh: line 15: /home/paz/cinelerra5/cinelerra-5.1/./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. mv: cannot stat 'Makefile': No such file or directory cp: cannot stat 'Makefile.devel': No such file or directory cp: cannot stat '/home/paz/cinelerra5/cinelerra-5.1/bin': No such file or directory linuxdeploy version 1-alpha (git commit ID 4c5b9c5), GitHub actions build 57 built on 2022-01-12 09:53:03 UTC -- Creating basic AppDir structure -- Creating directory AppDir/usr/bin/ Creating directory AppDir/usr/lib/ Creating directory AppDir/usr/share/applications/ Creating directory AppDir/usr/share/icons/hicolor/ Creating directory AppDir/usr/share/icons/hicolor/16x16/apps/ Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/ -- Deploying dependencies for existing files in AppDir -- -- Deploying executables -- ERROR: No such file or directory: bin/cin Can you tell me where I'm going wrong?
Does the normal ./bkd.sh work OK, do you get bin directory with all in it? MatN On Tue, 8 Feb 2022 08:39:59 +0100 Andrea paz via Cin <[email protected]> wrote:
I tried to build the CinGG appimage with bld_appimage.sh, but I get the following error:
$ ./bld_appimage.sh ./bld_appimage.sh: line 14: ./autogen.sh: No such file or directory ./bld_appimage.sh: line 15: ./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. mv: cannot stat 'Makefile': No such file or directory cp: cannot stat 'Makefile.devel': No such file or directory cp: cannot stat 'bin': No such file or directory linuxdeploy version 1-alpha (git commit ID 4c5b9c5), GitHub actions build 57 built on 2022-01-12 09:53:03 UTC
-- Creating basic AppDir structure -- Creating directory AppDir/usr/bin/ Creating directory AppDir/usr/lib/ Creating directory AppDir/usr/share/applications/ Creating directory AppDir/usr/share/icons/hicolor/ Creating directory AppDir/usr/share/icons/hicolor/16x16/apps/ Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/
-- Deploying dependencies for existing files in AppDir --
-- Deploying executables -- ERROR: No such file or directory: bin/cin
The only change I made to bld_appimage.sh is to put a "./" in front of the linuxdeploy-x86_64.AppImage command.
However, the compilation of CinGG doesn't happen (I think because of paths not put or wrong...) and after, the folder "bin" is not copied in "AppDir/usr".
Trying to use the absolute paths inside bld_appimage.sh, I get something similar. but there are more steps than before:
$ LC_ALL=C ./bld_appimage.sh ./bld_appimage.sh: line 14: ./autogen.sh: No such file or directory ./bld_appimage.sh: line 15: ./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. mv: cannot stat 'Makefile': No such file or directory cp: cannot stat 'Makefile.devel': No such file or directory cp: cannot stat 'bin': No such file or directory ./bld_appimage.sh: line 27: ./linuxdeploy-x86_64.AppImage: Permission denied [paz@arch-paz blds]$ LC_ALL=C ./bld_appimage.sh ./bld_appimage.sh: line 14: ./autogen.sh: No such file or directory ./bld_appimage.sh: line 15: ./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. mv: cannot stat 'Makefile': No such file or directory cp: cannot stat 'Makefile.devel': No such file or directory cp: cannot stat 'bin': No such file or directory linuxdeploy version 1-alpha (git commit ID 4c5b9c5), GitHub actions build 57 built on 2022-01-12 09:53:03 UTC
-- Creating basic AppDir structure -- Creating directory AppDir/usr/bin/ Creating directory AppDir/usr/lib/ Creating directory AppDir/usr/share/applications/ Creating directory AppDir/usr/share/icons/hicolor/ Creating directory AppDir/usr/share/icons/hicolor/16x16/apps/ Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/
-- Deploying dependencies for existing files in AppDir --
-- Deploying executables -- ERROR: No such file or directory: bin/cin [paz@arch-paz blds]$ LC_ALL=C ./bld_appimage.sh + rm -f global_config configure Makefile Makefile.in + rm -f aclocal.m4 depcomp compile install-sh ltmain.sh + rm -f config.log config.guess config.h config.h.in config.sub config.status missing + rm -rf autom4te.cache m4 + '[' '' = clean ']' + autoupdate autoupdate: error: 'configure.ac' is required + mkdir m4 + autoreconf --install autoreconf: error: 'configure.ac' is required ++ uname -o + '[' GNU/Linux = Android ']' + '[' -e /system/bin/app_process ']' ./bld_appimage.sh: line 15: /home/paz/cinelerra5/cinelerra-5.1/./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. mv: cannot stat 'Makefile': No such file or directory cp: cannot stat 'Makefile.devel': No such file or directory cp: cannot stat '/home/paz/cinelerra5/cinelerra-5.1/bin': No such file or directory linuxdeploy version 1-alpha (git commit ID 4c5b9c5), GitHub actions build 57 built on 2022-01-12 09:53:03 UTC
-- Creating basic AppDir structure -- Creating directory AppDir/usr/bin/ Creating directory AppDir/usr/lib/ Creating directory AppDir/usr/share/applications/ Creating directory AppDir/usr/share/icons/hicolor/ Creating directory AppDir/usr/share/icons/hicolor/16x16/apps/ Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/
-- Deploying dependencies for existing files in AppDir --
-- Deploying executables -- ERROR: No such file or directory: bin/cin
Can you tell me where I'm going wrong?
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!
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
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
Andrea,
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...
I had downloaded your appimage to try earlier on Fedora 32 which is out of
date so did not work. Now I have Fedora 35 built with only the default packages, but it is complaining about libzz2.so... missing so if I ever get the network up on that computer I will install bzip2-devel and re-try.
@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?
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? 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?
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
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...
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...
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). I tried renaming the created AppImage to have a .zip ending, then extract it to a temp directory. All files are there, but they have lost the executable status, so although you can run linuxdeploy with that directory as AppDir, the resulting AppImage won't work. How to use linuxdeploy: just use the linuxdeploy line from the bld_appimage script. MatN PS I tried make-static-appimage, but so far it fails creating a running AppImage.
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
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.
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. 2) Mat, could you notice, what particular problem prevented the compilation of the manual? What was changed? _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
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?
Andrea,
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?
After doing some revisions (OK, I went a little overboard with changes), I
checked this new section into GIT. You did a lot of work getting this content put together in an understandable way with easy to follow directions. I hope I did not edit any mistakes in and I did not test all of the command lines for correctness. ...Phyllis
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
*Subject: AppImage with Hardware Acceleration* After experimenting with different AppImages created on different computers, different Operating Systems with different graphics cards and different vaapi/vdpau libraries installed, or none of these libraries installed, I think I can safely conclude the following: 1) Hardware acceleration, vaapi or vdpau, works the same running either the created binary or the created AppImage from that binary on that same computer. 2) Hardware acceleration using an AppImage created on another computer running a different Operating System or even just a different level of Operating System, most likely will not work unless the user's computer just happens to have the same characteristics with respect to vaapi/vdpau as the computer where the AppImage was created. Does MatN or anyone else's experience differ from this? I did open BT #604 in case there is some way to make hardware acceleration more accessible. Glitterball3 uses a workaround (see forum) to create links to different libraries to get this to work, but varies so much. *************************************** Some experimental results ****************************** For example using Test1 (hockey.ts television recording) and Test2 (Life Untouched 4K HDR10 Demo.mp4 downloadable file): CinGG-20220131-x86_64.AppImage -on *AMD laptop *with Radeon RX-580 graphics card where AppImage was created (Fedora 32): Test1 hardware acceleration vaapi and vdpau both work as expected. Test2 hardware acceleration vaapi works, but vdpau does not - this is as expected. CinGG-20220131-x86_64-older_distros.AppImage - on AMD laptop with Radeon RX-580 using AppImage created on AMD Opteron Ubuntu 16.04: Test1 and Test2 hardware acceleration do not work due to missing Radeon so file. CinGG-20220131-x86-64-older_distros-multibit.AppImage - on AMD laptop with Radeon RX-580 using AppImage created on Intel 4-core with Broadwell graphics: Test1 hardware acceleration only vdpau works and that could be due to a "wrapper". Test2 hardware acceleration does not work. CinGG-20220131-x86_64.AppImage (same results as if built on this computer/this O/S) - on *Intel 4-core laptop* with Broadwell using AppImage created on AMD laptop with different O/S of Fedora 32: Test1 hardware acceleration only vaapi works, but vdpau does not. Test2 hardware acceleration does not work.. CinGG-20220131-x86_64-older_distros.AppImage - on Intel 4-core laptop with Broadwell using AppImage created on AMD Opteron Ubuntu 16.04: Test1 and Test2 hardware acceleration do not work. CinGG-20220131-x86-64-older_distros-multibit.AppImage - on Intel 4-core laptop with Broadwell using AppImage created on same computer but older O/S of Fedora 29: Test1 and Test2 hardware acceleration do not work.
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] _______________________________________________________________________________
On Fri, 11 Feb 2022 13:56:37 +0700 (+07) Georgy Salnikov <[email protected]> wrote: <snip>
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.
I could not get in to produce identical PDFs until I deleted the manual directory, and re-created it from the git. Yet git's diff did not show any differences... Anyway, now on Mint 19.3 and Mint 20.3 the same PDFs are produced, with one strange exception: on Mint 19.3, the last glossary entry about YUV (quite a large one) is completely missing. Page 695 from the latest git with Andrea's/Phyllis' changes. I see no errors in the logs. How can this happen? On Fedora 35, there are more differences, but I'd like to get this glossary items solved first. The YUV items is definitely present in the source .tex file. Mat
participants (6)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
mat -
mnieuw@zap.a2000.nl -
Phyllis Smith