<div dir="ltr"><div>Good night, everyone.</div><div><br></div>Today I have tested the patched version (AppImage) of subsurface.<div><br><div>I began creating a new file:  complete_2.xml ; the file is almost equal to dive log used in my first message dated 16/02/2017 . The only differences are the date of the first dive in the log ( #15 .. the "fake" dive used as template for new dives in SmartTrak) and the correction of some misspellings in the notes section of several dives.</div><div><br></div><div>File first_482_2.xml was obtained from complete_2.xml by deleting dives from #483 to #501. I have checked the differences between the two files and, as expected, no differences have been detected other than the missing dives.</div><div><br></div><div>I ran subsurface once again, opening file first_482_2.xml and importing file complete_2.xml over it. The patched program DID NOT CRASH as the merge operation was performed. THIS IS GOOD NEWS, albeit not unexpected. The resulting log is file complete_3.xml .</div><div><br></div><div>I compared files complete_2.xml and complete_3.xml :</div><div>( diff -y -W 200 /home/ale/myfiles/Dropbox/subs<wbr>urface_testing/dive_log_xenial<wbr>/complete_2.xml  /home/ale/myfiles/Dropbox/sub<wbr>surface_testing/dive_log_xenia<wbr>l/complete_3.xml > diff_2_3 ).</div><div><br></div><div>In my opinion there is still something to be fixed in the merge procedure. Files complete_2 and complete_3 should be identical, since I would expect the merge operation to ignore the content of existing dives fro #15 to #482 and simply to add the deleted dives once again.</div><div><br></div><div>Looking into file diff_2_3 I have observed the following two unexpected behaviors:</div><div><ol><li>The records related to dive site description have been DUPLICATED<br></li><li>A large number of strings like <divetemperature air='0.0 C' water='20.0 C'/> has been replaced with <divetemperature air='0.0 C'/>; this happened in all dives imported from the old Aladin Air Z, on a few dives logged from the newer SmartTec and with ALL MANUALLY INSERTED DIVES, where air and water "divetemperature" values are obviously set to 0.0 C .  In any case I would expect not to find any difference in such records before and after the merge operation, since, as I have already said, the merge operation should import ONLY NEW DIVES and leave the existing dives UNCHANGED. Dives logged from the new Galileo Trimix seem to be unaffected.<br></li></ol><div>The problem about the deletion of the water temperature data is NOT in my opinion very important. The issue of dive site information being duplicated is more serious, if the user decides to repeatedly import new dives from SmartTrak logs and the new dives have been carried out in previously registered dive sites.</div><div><br></div><div>This is now even more important since I HAVE FOUND A BUG in the irda-utils package. This is NOT RELATED to subsurface development, but is a problem for all users of UWATEC devices with IR USB adapter (MCS7780).</div><div><br></div><div>I remember that I had some years go tried to replace SmartTrak with Jtrak, a Java application recommended by UWATEC. I was not satisfied with JTrak, but the irda interface was perfectly working under an old Fedora version.</div><div><br></div><div>Such irda interface is BROKEN in the new Fedora releases and the package maintainers are not at present able to suggest how the bug could be fixed. The irda-utils project has not been updated since 2011,</div><div><br></div><div>The irda interface works perfectly in Ubuntu trusty, but is BROKEN in Ubuntu xenial. I might be wrong, but my feeling is that the change from upstart to systemd is the explanation for the failure to start the irda service when the OS is booted. I am not saying that systemd is not good, I am just saying  that irda-utils needs new configuration files for systemd and that my trials to write such files have been up to now  definitely unsuccessful due to my apparent lack of knowledge about irda-utils and systemd.</div><div><br></div><div>As far as subsurface users are concerned, I am inclined to think that it will not be possible to get a working irda service in a short time. At present the only practical solution is repeatedly importing data from SmartTrack .</div><div><br></div><div>All the mentioned files can be found in folder in subdirectory  dive_log_xenial  on <a href="https://www.dropbox.com/sh/dsg43qcbo013i1k/AAC_vCS3cZeZar5i3HngCNq3a?dl=0" target="_blank">https://www.dropbox.com/sh/dsg<wbr>43qcbo013i1k/AAC_vCS3cZeZar5i3<wbr>HngCNq3a?dl=0</a></div></div><div><br></div><div>Very best regards.</div><div><br></div><div><br></div><div>Alessandro</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 16, 2017 at 5:02 PM, Linus Torvalds <span dir="ltr"><<a href="mailto:torvalds@linux-foundation.org" target="_blank">torvalds@linux-foundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 16, 2017 at 8:40 AM, Alessandro Volpi <<a href="mailto:volpial@gmail.com">volpial@gmail.com</a>> wrote:<br>
> I have reported the bug at 00:25 UTC.  You have located the bug and released<br>
> the patch at 01:10 UTC !<br>
><br>
> I have never seen something like that in my life  ... and I am 64 years old<br>
<br>
Don't get _too_ used to it. It doesn't always work quite that well -<br>
and not just because the developers may end up being busy doing other<br>
things.<br>
<br>
What really helped was that you had a good report and a repeatable<br>
test-case that you made available so that developers could trivially<br>
reproduce the problem.<br>
<br>
The bugs are much harder to fix when they aren't that well-behaved and<br>
the bug reports aren't so clear. So you should take credit for making<br>
it easy to fix.<br>
<br>
And obviously it would be good if you can also verify that everything<br>
else looks good after the merge with the new daily build.<br>
<br>
And as I wrote that, I just realized that I don't even know if there<br>
are daily Appimage builds - they're not in the downloads/daily<br>
directory.  Dirk, where do you put them these days?<br>
<span class="HOEnZb"><font color="#888888"><br>
            Linus<br>
</font></span></blockquote></div><br></div>