time for 5.0.9

[Dirk Hohndel]

Hi Steve,


> On Jun 12, 2022, at 4:34 AM, Steve <stevewilliams at internode.on.net> wrote:
> 
> Something I just tested using the 5.0.8-g89c6015cde4d daily appimage
> (due to me failing to build it locally, see at the end for more
> details)

Thanks for giving the EXACT version. That saved us a lot of back and forth.
That test build is about a month old, and the bug you describe below I fixed
last week... can you try 

https://subsurface-divelog.org/downloads/test/Subsurface-5.0.8-50-g3629a87fccdc-x86_64.AppImage

which includes my fix?

> I gotten used to not filling in all the details in the information tab
> until after I had imported from all my dive computers first because if
> I did the information got removed on subsequent dive computer imports.
> 
> I just did a night dive last night and thought I would test it again
> and the Visibility in the Information tab did not get removed after
> importing from a second computer but the others (Surface waves,
> Current, Surge and Chill) did get deleted.

I say this with a lot of appreciation for the fact that often it's more important to
get stuff to work... but if you run into things like this, PLEASE don't just work
around it. Send an email to the mailing list.

I never use the extra fields. Very few people appear to. And only a small part
of our users has multiple dive computers. And apparently the number of users
who use these fields, download from multiple dive computers, and also edit dives
between downloading is extremely small.

You know how I found this bug?
A user who was reporting two completely different bugs gave me access to their
cloud storage account, and as I was trying to understand what was happening
in their and what was going wrong with the cylinder edits that they did, I noticed
that the 'current' entry was deleted when they downloaded from their second dive
computer.

That's a bit too random for me.

So, people on this list. If you see something that seems wrong. PLEASE let me
know. You don't need to file a GitHub issue. Just send am email to this list. And
if I ignore you, send it again and say something like "hey, Dirk, wake up"...

Thanks.

Back to your email...

> Might be worth fixing if its an easy fix?

Yup, was super easy to fix.

https://github.com/subsurface/subsurface/commit/19b221d2035b9ea899b17385ff52c807e7a10cdf <https://github.com/subsurface/subsurface/commit/19b221d2035b9ea899b17385ff52c807e7a10cdf>


> Also I had just updated my laptop from Fedora 35 to 36 and tried to
> build the latest master to test but it failed. Info below:

Yeah, that's a known problem when your Qt version changes. The builds don't cleanly
pick up those changes...

Best way to deal with this is to remove all of the 'build' directories and run the build
script again.

> 
> /usr/bin/ld: cannot open linker script file
> /builddir/build/BUILD/qtbase-everywhere-src-5.15.3/.package_note-qt5-
> qtbase-5.15.3-2.fc36.x86_64.ld: No such file or directory
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:148: libqtgeoservices_googlemaps.so] Error 1

In your case the googlemaps build was referencing a specific linker script file that
was changed in the update and is no longer at the spot that qmake remembers
for it. Just remove that build directory and start from scratch and it should build
again.

A could of the developers very regularly build on Fedora (and one of our GitHub
test builds happens on Fedora - but that's one of the experimental Qt6 builds).
Also, of course, for Fedora we now have both test builds and release builds on
copr...

Thanks for the email with the report!

/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20220612/e7616e31/attachment.htm>