
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Steve,<div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 12, 2022, at 4:34 AM, Steve <<a href="mailto:stevewilliams@internode.on.net" class="">stevewilliams@internode.on.net</a>> wrote:</div><div class=""><div class=""><br class="">Something I just tested using the 5.0.8-g89c6015cde4d daily appimage<br class="">(due to me failing to build it locally, see at the end for more<br class="">details)<br class=""></div></div></blockquote><div><br class=""></div><div>Thanks for giving the EXACT version. That saved us a lot of back and forth.</div><div>That test build is about a month old, and the bug you describe below I fixed</div><div>last week... can you try </div><div><br class=""></div><div><a href="https://subsurface-divelog.org/downloads/test/Subsurface-5.0.8-50-g3629a87fccdc-x86_64.AppImage" class="">https://subsurface-divelog.org/downloads/test/Subsurface-5.0.8-50-g3629a87fccdc-x86_64.AppImage</a></div><div><br class=""></div><div>which includes my fix?</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I gotten used to not filling in all the details in the information tab<br class="">until after I had imported from all my dive computers first because if<br class="">I did the information got removed on subsequent dive computer imports.<br class=""><br class="">I just did a night dive last night and thought I would test it again<br class="">and the Visibility in the Information tab did not get removed after<br class="">importing from a second computer but the others (Surface waves,<br class="">Current, Surge and Chill) did get deleted.<br class=""></div></div></blockquote><div><br class=""></div><div>I say this with a lot of appreciation for the fact that often it's more important to</div><div>get stuff to work... but if you run into things like this, PLEASE don't just work</div><div>around it. Send an email to the mailing list.</div><div><br class=""></div><div>I never use the extra fields. Very few people appear to. And only a small part</div><div>of our users has multiple dive computers. And apparently the number of users</div><div>who use these fields, download from multiple dive computers, and also edit dives</div><div>between downloading is extremely small.</div><div><br class=""></div><div>You know how I found this bug?</div><div>A user who was reporting two completely different bugs gave me access to their</div><div>cloud storage account, and as I was trying to understand what was happening</div><div>in their and what was going wrong with the cylinder edits that they did, I noticed</div><div>that the 'current' entry was deleted when they downloaded from their second dive</div><div>computer.</div><div><br class=""></div><div>That's a bit too random for me.</div><div><br class=""></div><div>So, people on this list. If you see something that seems wrong. PLEASE let me</div><div>know. You don't need to file a GitHub issue. Just send am email to this list. And</div><div>if I ignore you, send it again and say something like "hey, Dirk, wake up"...</div><div><br class=""></div><div>Thanks.</div><div><br class=""></div><div>Back to your email...</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Might be worth fixing if its an easy fix?<br class=""></div></div></blockquote><div><br class=""></div>Yup, was super easy to fix.</div><div><br class=""></div><div><a href="https://github.com/subsurface/subsurface/commit/19b221d2035b9ea899b17385ff52c807e7a10cdf" class="">https://github.com/subsurface/subsurface/commit/19b221d2035b9ea899b17385ff52c807e7a10cdf</a></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Also I had just updated my laptop from Fedora 35 to 36 and tried to<br class="">build the latest master to test but it failed. Info below:<br class=""></div></div></blockquote><div><br class=""></div><div>Yeah, that's a known problem when your Qt version changes. The builds don't cleanly</div><div>pick up those changes...</div><div><br class=""></div><div>Best way to deal with this is to remove all of the 'build' directories and run the build</div><div>script again.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">/usr/bin/ld: cannot open linker script file<br class="">/builddir/build/BUILD/qtbase-everywhere-src-5.15.3/.package_note-qt5-<br class="">qtbase-5.15.3-2.fc36.x86_64.ld: No such file or directory<br class="">collect2: error: ld returned 1 exit status<br class="">make: *** [Makefile:148: libqtgeoservices_googlemaps.so] Error 1<br class=""></div></div></blockquote></div><br class=""></div><div class="">In your case the googlemaps build was referencing a specific linker script file that</div><div class="">was changed in the update and is no longer at the spot that qmake remembers</div><div class="">for it. Just remove that build directory and start from scratch and it should build</div><div class="">again.</div><div class=""><br class=""></div><div class="">A could of the developers very regularly build on Fedora (and one of our GitHub</div><div class="">test builds happens on Fedora - but that's one of the experimental Qt6 builds).</div><div class="">Also, of course, for Fedora we now have both test builds and release builds on</div><div class="">copr...</div><div class=""><br class=""></div><div class="">Thanks for the email with the report!</div><div class=""><br class=""></div><div class="">/D</div></body></html>