smtk2ssrf_test.AppImage: further testing

[Salvador Cuñat]

Good night Alessandro, thank you very much for such a detailed testing.

On Wed, Feb 15, 2017 at 11:14:08PM +0000, Alessandro Volpi wrote:
> I have tested two versions of the AppImage on Fedora 24 (64bit)
> 
> 
>    1. [~/bin]$file smtk2ssrf_test.AppImage :: smtk2ssrf_test.AppImage: ELF
>    64-bit LSB executable, x86-64, version 1, dynamically linked, interpreter
>    /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18,
>    BuildID[sha1]=30434935ca0d1a94a0eb2853b71390dfe2e9017f, stripped
>    2. [~/myfiles/downloads]$file smtk2ssrf_test.AppImage ::
>    smtk2ssrf_test.AppImage: ELF 64-bit LSB executable, x86-64, version 1,
>    dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
>    2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped
> 
> The two .AppImage file will be briefly indicated as "old" (1.)  and "new"
> (2.) in the following text.
> 
> First trial:
> 
> The old AppImage was launched from a terminal, relying on the GUI. The
> resulting files are:
> smtk2_old_gui_out.txt, containing the output on the terminal
> smtk2_old_gui_log.txt , containing the program's output on the GUI window.
> smtk2_old_gui.xml , the input file for subsurface
> 
> Second trial :
> 
> The old AppImage was launched from the terminal indicating input and output
> file as command arguments. The resulting files are:
> smtk2_old_out.txt, containing the output on the terminal
> smtk2_old.xml , the input file for subsurface
> 
> Third trial :
> 
> The new AppImage was launched from the terminal indicating input and output
> file as command arguments. The resulting files are:
> smtk2_new_out.txt, containing the output on the terminal
> smtk2_new.xml , the input file for subsurface
> 
> Fourth trial :
> 
> The new AppImage was launched from a terminal, relying on the GUI. The
> resulting files are:
> smtk2_new_gui_out.txt, containing the output on the terminal
> smtk2_new_gui_log.txt , containing the program's output on the GUI window.
> smtk2_new_gui.xml , the input file for subsurface
> 
> After examining the four .xml files I found out that three of them are
> identical. The different file is smtk2_old. The only different record is
> dive 415, where the notes were not correctly read. It is worth while to
> point out that dive 415 was manually inserted in SmartTrak, since no UWATEC
> dive computer was used for the dive. On the other hand this is not the only
> dive manually inserted; it is simply the only dive where an error has been
> ascertained.
I can see the difference between both xml files, but I don't really
understand the reason for it. I've runned 7 different versions
(appimages and builds from sources) on your slg file and #415's notes
are always readed. 
> 
> Another unexpected behavior is that the new AppImage, when launched in GUI
> mode complains about missing libGL components. On the other hand dnf says
> that required packages are installed and latest version. This might be
> related to the nvidia proprietary drivers. In spite of the allegedly
> missing components the program seems to run flawlessly. Moreover I do not
> understand why libGL should be required for a 2D graphic application such
> as smtk2ssrf .
> 
I don't think this is appimage related, I'd put my money on Qt.

> Another even more surprising event was a SEGMENTATION FAULT crash when i
> tried to launch the new AppImage as  command line application (see file
> smtk2_new_out.txt). I tried to do that a second time and the program ran
> flawlessly.
> 
This seems libmdb related. Never saw it before, not in my old 32b
laptop nor my 64b one.

> I do not know anything about the behavior of .AppImage executables, but is
> was apparent that, running 2 times with same input file may result in
> different output file; moreover I was not sure that the different result
> was actually dependent on the sunning condition, command line or GUI.
> 
> I have thus run once again the "Second trial"; surprisingly the resulting
> file smtk2_old_2.xml is not equal to smtk2_old.xml but is identical to the
> .xml files obtained in trials 1, 3 , 4 ; the question of the GUI is not in
> my opinion relevant.
> 
> I have also tested the new AppImage on my laptop, with a freshly installed
> Ubuntu xenial OS.
> 
> I have not saved the files, but I can tell you that, also with xenial I
> have got different .xml files running the AppImage more than once.
> 
> My conclusion is that, SOMEHOW, RUNNING THE APPLICATION WITH THE SAME INPUT
> MAY RESULT IN DIFFERENT .XML FILES, DEPENDING ON SOME EXTERNAL DISTURBANCE.
> THE ERROR IS ALWAYS IN THE NOTES OF DIVE 415 !
> i CANNOT IMAGINE HOW THAT COULD HAPPEN ... I begin doubting about AppImage
> "relocatability" ...
> 
I can't agree with you on this. I'm actually using suburface 4.6.0
appimage without any issue. This problems seems to be more related to
my own inability to produce a stable appimage.
I love it's philosophy, but libraries management through different
distros is a true pain.

BTW, I'm seeing in all produced divelogs (also in slg file) a dive
numbered #15, which seems to lack of date and time (well it claims to
be 01-01-2000 at 00:00:00) and any other info but the suit.  Is it
correct or some kind of weird artifact from the Access database?

And finally, have you tried to build from sources on Xenial?

Again, thanks for your heavy testing.

Best regards.

Salva.