smtk2ssrf_test.AppImage: further testing

[Salvador Cuñat]

Good night Alessandro.

On Fri, Feb 17, 2017 at 03:04:06PM +0000, Alessandro Volpi wrote:
> 
> I have observed that smtk2ssrf does not consider the template dive to be a
> true dive (it is actually fake) and does not export it to the .xml file. I
> guess that 1/1/1900 is not a good date; if I have well understood your
> program reads it as 1/1/2000 , exactly one century later !
> 
I can see it there, in both your .xml files and mine.
It's being readed as 1/1/2000 because libmdb returns localized strings
for date and time. This wasn't a real problem for date, but actually
was for some times representations (e.g. duration of the dive or
surface time) because of that very big country using 12h and AM/PM
instead of 24h time. So the program fix a "neutral" locale to work; I
selected POSIX locale, but this has the drawback that has only two
digits for the year. This way  1900 becomes 00 and 00 becomes 2000. I
really never expected to find dates before 1969.

> Coming back to the issue of the .AppImage executables I point out that,
> theoretically, a computer program should ALWAYS BEHAVE THE SAME WAY with
> the same input data, unless the program gets entropy from a source like
> /dev/urandom . I mean that a program which is crashing once with a
> <SEGMENTATION FAULT> SHOULD ALWAYS CRASH WITH THE INSTRUCTION POINTER VALUE
> ALWAYS POINTING TO THE SAME INSTRUCTION. Moreover the program should always
> read the SAME  stuff ( right or wrong) in all records, including record
> #15. I do not understand why this record seems not to be as good as any
> other...
> 
The segmentation fault was due to libmdb failing to identify a table
in the .slg database. As I'm unable to reproduce the crash with your
.slg or any other, I think it could be triggered by a bad interaction
between libraries bundled in the appimage and the libraries in the
host machine.
As said above, dive #15 is in the xml files and it's imported as any
other (with the 01/01/2000 issue). At first I didn't see it because I
have the dive list in subsurface set to be date/time ordered, so it
didn't show the first one. Setting the order to dive number shows it
in first place. Subsurface xml format don't have this issues, so you
can simply edit the #15 dive to be 1900 again.

> Apparently IT IS NOT ... and I cannot imagine how this could happen. I am
> not familiar with AppImage building procedures and I read on your message
> that you are not also completely at ease with that.
> 
> Btw I have yesterday tried to run a Subsurface AppImage on Fedora 24. The
> program was working in spite of some complains about wrong libraries and
>  in spite of some problem probably related to the application fonts. I
> fully agree with you that the AppImage approach is somehow tricky. I guess
> that the question is much more complicated than simply including
> stand-alone instances of some shared libraries  in the executable ...
> 

It seems to be. But if Subsurface is running quite well and there are
running appimages for such complex programs as Firefox and others, it
shouldn't be that difficult to get this tiny tool to work. In fact,
except glib2.0 and libmdb the rest of libraries are the same that
those bundled in subsurface appimage.

> As far as the test of subsurface build scripts on Ubuntu xenial,  is
> concerned, I must admit that I was not able to carry it out as promised.
> This has been a busy week for me and I was forced to lend my laptop with
> xenial to a friend of mine.

Don't worry about it, I was just curious.

Best regards.

Salva.