Re: 4.9.3 preparations
(Apologies for trying to post to the list from an email address not registered on the list.) Mac binaries downloaded and tested. The various items (clicking on flags, save to cloud) that have been reported aren't an issue. Scanning found the Cosmiq, as expected, and was able to import dives. However, it has been a of months since I used the computer for a dive and somehow the date got reset to 2015 and these dives are causing an import error as far as I can see. Will continue trying but personally I do not see this as a serious problem for/with Subsurface since the issue is almost certainly with Deepblu/Cosmiq+ and all of the other dives (I did a force reload into a new dive log to test) and will export the XML from the Deeplblu backup site and give it a scan, I just don't have time today. This is probably a tip for anyone buying a Deepblu Cosmiq+: Don't just charge it before diving (I am sure that there is a PADI specialty covering such things!), connect to some device somewhere so that the Cosmiq+ can reset itself. And yes, I know that the date is on the front, but 5s and 9s aren't that different *and* with my eyes at my age! David PS I don't post too often, but wanted to say in response to "how do we make people aware of changes and new versions" (thread from a month or so ago); around here in Western Canada word of mouth is working fairly well. I was reminded about that when I went through through some of the gas planning stuff, which I was showing to some people using Z-planner or Y-planner or some such and Subsurface just *blew* their socks off! "And its free - what's the catch?" was about their only question! On 2019-09-09 1:16 a.m., Dirk Hohndel wrote: >> On Sep 9, 2019, at 5:04 AM, David Owen wrote: >> >> I didn't see any MacOS binaries. Not sure if that it is to do with the >> extra hoops that apps need to go through, so I took the tar file from >> the continuous build directory and built and tested that. > I made the official binaries just a few minutes ago. The Mac one is now at > https://subsurface-divelog.org/downloads/Subsurface-4.9.3.dmg > >> No issues so >> far. I can see the Cosmiq+ in the list of computers but am struggling >> to work out how to connect it. Presumably this isn't yet supported from >> MacOS, or at least I haven't figured out how to get it to work. Will >> have a look with an official Linux binary tomorrow. > That's BLE, right? That should work on the Mac as well. > You should scan for it from Subsurface and it should find it. > > /D > > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Also note that it works if I put the compiled libssl path at the end of the LD_LIBRARY_PATH like so LD_LIBRARY_PATH=/tmp/.mount_SubsurCt4MZJ/usr/lib/:$LD_LIBRARY_PATH:~/local/openssl/ /tmp/.mount_SubsurCt4MZJ/AppRun -v On Mon, Sep 9, 2019 at 1:18 PM Paul Buxton wrote: > Yes it will use the same path, but if QT is looking for different versions > it may find both the one in the package and the one on the platform. > Is that the first or last reference to libssl you get in strace? > > I have now downloaded and built openssl locally. > If I add its folder to LD_LIBRARY_PATH before running then it all looks to > work. > > Attached the strace | grep ssl of both with and without this added to > the path. > > I do see the same reference to libssl in my strace, but further down in > the strace log there are some more calls to open libssl, and afterwards a > failure to resolve OPENSLL_init_ssl > > Doing nm -aD on the library in the appimage confirms that this symbol is > not present, but it is present in the version of libssl I have built > locally. > > > > > On Mon, Sep 9, 2019 at 12:21 PM Dirk Hohndel wrote: > >> On Mon, Sep 09, 2019 at 11:26:22AM +0100, Paul Buxton wrote: >> > Hmm, doesn't make any difference on mine. >> > Googling I did fine some references that suggest that Qt networking >> loads >> > libssl and libcrypto using dlopen, which would not show up as a >> dependency >> > through ldd >> > >> https://code.qt.io/cgit/qt/qtbase.git/tree/src/network/ssl/qsslsocket_openssl_symbols.cpp >> > So whilst ldd is listing that it is linked against 1.0 it may actually >> be >> > picking up 1.1 from your library path. >> >> But dlopen() should use the same LD_LIBRARY_PATH, right? >> >> Anyway, I ran this through strace and I am indeed opening the 1.0 library: >> >> openat(AT_FDCWD, >> "/tmp/.mount_SubsurzTksC9/usr/bin/../lib/libssl.so.1.0.0", >> O_RDONLY|O_CLOEXEC) = 3 >> >> Could you check which one you are opening? >> >> /D >> >> ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Yes it will use the same path, but if QT is looking for different versions
it may find both the one in the package and the one on the platform.
Is that the first or last reference to libssl you get in strace?
I have now downloaded and built openssl locally.
If I add its folder to LD_LIBRARY_PATH before running then it all looks to
work.
Attached the strace | grep ssl of both with and without this added to
the path.
I do see the same reference to libssl in my strace, but further down in the
strace log there are some more calls to open libssl, and afterwards a
failure to resolve OPENSLL_init_ssl
Doing nm -aD on the library in the appimage confirms that this symbol is
not present, but it is present in the version of libssl I have built
locally.
On Mon, Sep 9, 2019 at 12:21 PM Dirk Hohndel wrote:
> On Mon, Sep 09, 2019 at 11:26:22AM +0100, Paul Buxton wrote:
> > Hmm, doesn't make any difference on mine.
> > Googling I did fine some references that suggest that Qt networking loads
> > libssl and libcrypto using dlopen, which would not show up as a
> dependency
> > through ldd
> >
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/network/ssl/qsslsocket_openssl_symbols.cpp
> > So whilst ldd is listing that it is linked against 1.0 it may actually be
> > picking up 1.1 from your library path.
>
> But dlopen() should use the same LD_LIBRARY_PATH, right?
>
> Anyway, I ran this through strace and I am indeed opening the 1.0 library:
>
> openat(AT_FDCWD,
> "/tmp/.mount_SubsurzTksC9/usr/bin/../lib/libssl.so.1.0.0",
> O_RDONLY|O_CLOEXEC) = 3
>
> Could you check which one you are opening?
>
> /D
>
>
open("/tmp/.mount_Subsur5zpE75/usr/bin/../lib/libssl.so.1.0.0",
O_RDONLY|O_CLOEXEC) = 3
open("/tmp/.mount_Subsur5zpE75/usr/lib/libssl.so.1.0.0", O_RDONLY) = 7
open("/tmp/.mount_Subsur5zpE75/usr/lib/libssl.so.1.0.0", O_RDONLY) = 14
open("/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)
open("haswell/libssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("haswell/libssl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("/tmp/.mount_Subsur5zpE75/usr/bin/../lib/libssl.so", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libssl.so", O_RDONLY|O_CLOEXEC) = 32
open("/tmp/.mount_Subsur5zpE75/usr/bin/../lib/libssl", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libssl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
open("/usr/lib/x86_64-linux-gnu/libssl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
open("/lib/libssl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libssl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("haswell/ssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("haswell/ssl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/tmp/.mount_Subsur5zpE75/usr/bin/../lib/ssl.so", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/ssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
open("/usr/lib/x86_64-linux-gnu/ssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
open("/lib/ssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open("/tmp/.mount_Subsur5zpE75/usr/bin/../lib/ssl", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/ssl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/usr/lib/x86_64-linux-gnu/ssl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
open("/lib/ssl", O_RDONLY|O_CLOEXEC)= -1 ENOENT (No such file or directory)
open("/usr/lib/ssl", O_RDONLY|O_CLOEXEC) = 32
stat("/usr/lib/x86_64-linux-gnu/libssl.so", {st_mode=S_IFREG|0644,
st_size=428384, ...}) = 0
open("/usr/lib/x86_64-linux-gnu/haswell/libssl.so", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
access("/usr/lib/x86_64-linux-gnu/haswell/libssl.so", F_OK) = -1 ENOENT (No
such file or directory)
open("/usr/lib/x86_64-linux-gnu/libssl.so", O_RDONLY|O_CLOEXEC) = 32
access("/usr/lib/x86_64-linux-gnu/libssl.so", F_OK) = 0
open("/tmp/.mount_Subsur5zpE75/usr/lib/haswell/libssl.so.1.0.0",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/tmp/.mount_Subsur5zpE75/usr/lib/haswell/libssl.so.1.0.0", F_OK) = -1
ENOENT (No such file or directory)
open("/tmp/.mount_Subsur5zpE75/usr/lib/haswell/libssl.so.1.0.0.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/tmp/.mount_Subsur5zpE75/usr/lib/haswell/libssl.so.1.0.0.so", F_OK) =
-1 ENOENT (No such file or directory)
open("/tmp/.mount_Subsur5zpE75/usr/lib/libssl.so.1.0.0", O_RDONLY|O_CLOEXEC) =
32
write(2, "QSslSocket: cannot resolve OPENS"..., 44QSslSocket: cannot resolve
OPENSSL_init_ssl
Re: 4.9.3 preparations
On Mon, Sep 09, 2019 at 11:26:22AM +0100, Paul Buxton wrote: > Hmm, doesn't make any difference on mine. > Googling I did fine some references that suggest that Qt networking loads > libssl and libcrypto using dlopen, which would not show up as a dependency > through ldd > https://code.qt.io/cgit/qt/qtbase.git/tree/src/network/ssl/qsslsocket_openssl_symbols.cpp > So whilst ldd is listing that it is linked against 1.0 it may actually be > picking up 1.1 from your library path. But dlopen() should use the same LD_LIBRARY_PATH, right? Anyway, I ran this through strace and I am indeed opening the 1.0 library: openat(AT_FDCWD, "/tmp/.mount_SubsurzTksC9/usr/bin/../lib/libssl.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3 Could you check which one you are opening? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Hmm, doesn't make any difference on mine. Googling I did fine some references that suggest that Qt networking loads libssl and libcrypto using dlopen, which would not show up as a dependency through ldd https://code.qt.io/cgit/qt/qtbase.git/tree/src/network/ssl/qsslsocket_openssl_symbols.cpp So whilst ldd is listing that it is linked against 1.0 it may actually be picking up 1.1 from your library path. On Mon, Sep 9, 2019 at 10:25 AM Dirk Hohndel wrote: > On Mon, Sep 09, 2019 at 10:03:44AM +0100, Dirk Hohndel wrote: > > On Mon, Sep 09, 2019 at 09:50:07AM +0100, Paul Buxton wrote: > > > Reviewing my log I also see an message Incompatible version of SSL > > > > > > Doing some googling this looks relevant. > > > https://github.com/probonopd/linuxdeployqt/issues/209 > > > > > > Basically it looks like Qt>5.10 expect to use openssl 1.1. > > > The package we are supplying includes openssl 1.0 > > > I am guessing that on distros with newer versions of Openssl the > Appimage > > > is picking up the right version to use. > > > > Our emails crossed (i.e., I didn't see yours before sending mine). Yes, > > that is a reasonable conclusion. Now I need to figure out if I even can > > include an openssl 1.1 library with the Trusty based build... > > No, that isn't the problem: > > Let's force the AppImage to use the bundled openssl library... checking > that this works: > > $ LD_LIBRARY_PATH=/tmp/.mount_SubsurMl62lz/usr/lib:$LD_LIBRARY_PATH ldd > /tmp/.mount_SubsurMl62lz/AppRun | grep ssl > libssl.so.1.0.0 => > /tmp/.mount_SubsurMl62lz/usr/lib/libssl.so.1.0.0 (0x7f55aeb85000) > > OK, so this picks up the included one > > $ LD_LIBRARY_PATH=/tmp/.mount_SubsurMl62lz/usr/lib:$LD_LIBRARY_PATH > /tmp/.mount_SubsurMl62lz/AppRun -v > Subsurface v4.9.3, > built with libdivecomputer v0.7.0-devel-Subsurface-NG > (ce6d9896a79afaa82641132e338f8744714c8593) > built with Qt Version 5.12.4, runtime from Qt Version 5.12.4 > built with libgit2 0.26.0 > [...] > no SSL warnings > [...] > > cloud URL set as " > https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org] > " > Opening cloud storage from: " > https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org] > " > git storage: Synchronising data file > git storage: update local repo > sync with remote > https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org] > git storage: Sync with cloud storage > Cloud storage: checking connection to cloud server > Checking cloud connection... > git storage: Waiting for cloud connection (1 second(s) passed) > git storage: fetch remote > git storage: Successful cloud connection, fetch remote > git storage: check remote status > git storage: try to update > git storage: Done syncing with cloud storage > git storage: Load dives from local cache > git storage: Successfully opened dive data > > So there is something weird about that specific SSL library on your > system, or more specifically there's something that our AppImage doesn't > like. > > I don't think there's a way to force the AppImage to use its bundled SSL > lib without mounting it - but this might be a workaround for now... > > /D > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Mon, Sep 09, 2019 at 10:03:44AM +0100, Dirk Hohndel wrote: > On Mon, Sep 09, 2019 at 09:50:07AM +0100, Paul Buxton wrote: > > Reviewing my log I also see an message Incompatible version of SSL > > > > Doing some googling this looks relevant. > > https://github.com/probonopd/linuxdeployqt/issues/209 > > > > Basically it looks like Qt>5.10 expect to use openssl 1.1. > > The package we are supplying includes openssl 1.0 > > I am guessing that on distros with newer versions of Openssl the Appimage > > is picking up the right version to use. > > Our emails crossed (i.e., I didn't see yours before sending mine). Yes, > that is a reasonable conclusion. Now I need to figure out if I even can > include an openssl 1.1 library with the Trusty based build... No, that isn't the problem: Let's force the AppImage to use the bundled openssl library... checking that this works: $ LD_LIBRARY_PATH=/tmp/.mount_SubsurMl62lz/usr/lib:$LD_LIBRARY_PATH ldd /tmp/.mount_SubsurMl62lz/AppRun | grep ssl libssl.so.1.0.0 => /tmp/.mount_SubsurMl62lz/usr/lib/libssl.so.1.0.0 (0x7f55aeb85000) OK, so this picks up the included one $ LD_LIBRARY_PATH=/tmp/.mount_SubsurMl62lz/usr/lib:$LD_LIBRARY_PATH /tmp/.mount_SubsurMl62lz/AppRun -v Subsurface v4.9.3, built with libdivecomputer v0.7.0-devel-Subsurface-NG (ce6d9896a79afaa82641132e338f8744714c8593) built with Qt Version 5.12.4, runtime from Qt Version 5.12.4 built with libgit2 0.26.0 [...] no SSL warnings [...] cloud URL set as "https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org]; Opening cloud storage from: "https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org]; git storage: Synchronising data file git storage: update local repo sync with remote https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org] git storage: Sync with cloud storage Cloud storage: checking connection to cloud server Checking cloud connection... git storage: Waiting for cloud connection (1 second(s) passed) git storage: fetch remote git storage: Successful cloud connection, fetch remote git storage: check remote status git storage: try to update git storage: Done syncing with cloud storage git storage: Load dives from local cache git storage: Successfully opened dive data So there is something weird about that specific SSL library on your system, or more specifically there's something that our AppImage doesn't like. I don't think there's a way to force the AppImage to use its bundled SSL lib without mounting it - but this might be a workaround for now... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Mon, Sep 09, 2019 at 09:50:07AM +0100, Paul Buxton wrote: > Reviewing my log I also see an message Incompatible version of SSL > > Doing some googling this looks relevant. > https://github.com/probonopd/linuxdeployqt/issues/209 > > Basically it looks like Qt>5.10 expect to use openssl 1.1. > The package we are supplying includes openssl 1.0 > I am guessing that on distros with newer versions of Openssl the Appimage > is picking up the right version to use. Our emails crossed (i.e., I didn't see yours before sending mine). Yes, that is a reasonable conclusion. Now I need to figure out if I even can include an openssl 1.1 library with the Trusty based build... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Mon, Sep 09, 2019 at 09:22:28AM +0100, Paul Buxton wrote: > Tried with the --cloud-timeout, no change (other than taking 15 secs to > timeout). > > I am able to go back to the 4.9.1 appimage and it has no issues talking to > github. > I am also able to log into the cloud.subsurface-divelog.org (didn't know > that existed, nice!) with my username/credentials > So I don't think it is the network here. Reasonable conclusion. > My first thought was perhaps we were not supplying openssl as part of the > package > So I mounted the appimage and did > ldd usr/bin/subsurface | grep ssl > which returned > libssl.so.1.0.0 => /tmp/.mount_SubsurBX6Yhm/usr/bin/../lib/libssl.so.1.0.0 > (0x7f1a11a71000) > > Tried this on both and get the same result, so I think openssl library > version is not the issue. > I will do some googling to see if there are any known qt networking > related, as I note that the package uses a newer version of QT than > previously. But I think it actually might be the SSL version after all, as that's the one thing that appears to be different here: $ ~/Downloads/Subsurface-4.9.3-x86_64.AppImage -v Subsurface v4.9.3, built with libdivecomputer v0.7.0-devel-Subsurface-NG (ce6d9896a79afaa82641132e338f8744714c8593) built with Qt Version 5.12.4, runtime from Qt Version 5.12.4 built with libgit2 0.26.0 [...] NO openssl errors... [...] cloud URL set as "https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org]; Opening cloud storage from: "https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org]; git storage: Synchronising data file git storage: update local repo sync with remote https://cloud.subsurface-divelog.org//git/d...@hohndel.org[d...@hohndel.org] git storage: Sync with cloud storage Cloud storage: checking connection to cloud server Checking cloud connection... git storage: Waiting for cloud connection (1 second(s) passed) git storage: fetch remote git storage: Successful cloud connection, fetch remote git storage: check remote status git storage: try to update git storage: Done syncing with cloud storage git storage: Load dives from local cache git storage: Successfully opened dive data And if I check the SSL library in use $ ldd /tmp/.mount_SubsurMl62lz/AppRun | grep ssl libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x7fc70b25a000) See how it uses openssl 1.1? And those two have api incompatibilities. This is of course all built in a Docker image based on a heavily update Ubuntu Trusty, so... hrmpf... I don't /think/ anything in the openssl setup should have changed between the 4.9.1 and 4.9.3 AppImage... But of course if cloud storage were broken for a lot of people, that would be BAD... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Reviewing my log I also see an message Incompatible version of SSL Doing some googling this looks relevant. https://github.com/probonopd/linuxdeployqt/issues/209 Basically it looks like Qt>5.10 expect to use openssl 1.1. The package we are supplying includes openssl 1.0 I am guessing that on distros with newer versions of Openssl the Appimage is picking up the right version to use. Paul On Mon, Sep 9, 2019 at 9:22 AM Paul Buxton wrote: > Tried with the --cloud-timeout, no change (other than taking 15 secs to > timeout). > > I am able to go back to the 4.9.1 appimage and it has no issues talking to > github. > I am also able to log into the cloud.subsurface-divelog.org (didn't know > that existed, nice!) with my username/credentials > So I don't think it is the network here. > > My first thought was perhaps we were not supplying openssl as part of the > package > So I mounted the appimage and did > ldd usr/bin/subsurface | grep ssl > which returned > libssl.so.1.0.0 => /tmp/.mount_SubsurBX6Yhm/usr/bin/../lib/libssl.so.1.0.0 > (0x7f1a11a71000) > > Tried this on both and get the same result, so I think openssl library > version is not the issue. > I will do some googling to see if there are any known qt networking > related, as I note that the package uses a newer version of QT than > previously. > > > On Mon, Sep 9, 2019 at 8:11 AM Dirk Hohndel wrote: > >> >> > On Sep 9, 2019, at 8:00 AM, Paul Buxton >> wrote: >> > >> > Hmm, trying the AppImage on my work machine. The previous bug is fixed >> (crash when clicking flags on the map). But the git cloud storage looks to >> be having issues. >> > See attached >> > Ubuntu 16 >> > 4.4.0-145-generic #171-Ubuntu SMP Tue Mar 26 12:43:40 UTC 2019 x86_64 >> x86_64 x86_64 GNU/Linux >> > >> >> >> cloud URL set as " >> https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com] >> " >> Opening cloud storage from: " >> https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com] >> " >> git storage: Synchronising data file >> git storage: Sync with cloud storage >> git storage: Waiting for cloud connection (2 second(s) passed) >> git storage: Waiting for cloud connection (3 second(s) passed) >> git storage: Waiting for cloud connection (4 second(s) passed) >> git storage: Cloud connection failed >> connection test to cloud server failed QNetworkReply::UnknownNetworkError >> "TLS initialization failed" 0 "" >> git storage: Can't reach cloud server, working with local data >> git storage: Load dives from local cache >> >> So that could mean that there's an issue with the server (tested a minute >> ago, Works For Me (TM)), there's an issue with the AppImage (tested that on >> ArchLinux, see before, Works For Me (TM), or there's a network issue where >> you are. >> >> Which makes me wonder if maybe there's an issue with connectivity from >> your machine to the cloud server (it's on AWS, Oregon zone). >> >> Can you access https://cloud.subsurface-divelog.org from a browser and >> log in with your Subsurface cloud credentials? >> >> Alternatively, have you tried starting the AppImage with a >> --cloud-timeout=15 or similar argument, to give it more time to connect? >> >> /D > > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Tried with the --cloud-timeout, no change (other than taking 15 secs to timeout). I am able to go back to the 4.9.1 appimage and it has no issues talking to github. I am also able to log into the cloud.subsurface-divelog.org (didn't know that existed, nice!) with my username/credentials So I don't think it is the network here. My first thought was perhaps we were not supplying openssl as part of the package So I mounted the appimage and did ldd usr/bin/subsurface | grep ssl which returned libssl.so.1.0.0 => /tmp/.mount_SubsurBX6Yhm/usr/bin/../lib/libssl.so.1.0.0 (0x7f1a11a71000) Tried this on both and get the same result, so I think openssl library version is not the issue. I will do some googling to see if there are any known qt networking related, as I note that the package uses a newer version of QT than previously. On Mon, Sep 9, 2019 at 8:11 AM Dirk Hohndel wrote: > > > On Sep 9, 2019, at 8:00 AM, Paul Buxton > wrote: > > > > Hmm, trying the AppImage on my work machine. The previous bug is fixed > (crash when clicking flags on the map). But the git cloud storage looks to > be having issues. > > See attached > > Ubuntu 16 > > 4.4.0-145-generic #171-Ubuntu SMP Tue Mar 26 12:43:40 UTC 2019 x86_64 > x86_64 x86_64 GNU/Linux > > > > > cloud URL set as " > https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com] > " > Opening cloud storage from: " > https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com] > " > git storage: Synchronising data file > git storage: Sync with cloud storage > git storage: Waiting for cloud connection (2 second(s) passed) > git storage: Waiting for cloud connection (3 second(s) passed) > git storage: Waiting for cloud connection (4 second(s) passed) > git storage: Cloud connection failed > connection test to cloud server failed QNetworkReply::UnknownNetworkError > "TLS initialization failed" 0 "" > git storage: Can't reach cloud server, working with local data > git storage: Load dives from local cache > > So that could mean that there's an issue with the server (tested a minute > ago, Works For Me (TM)), there's an issue with the AppImage (tested that on > ArchLinux, see before, Works For Me (TM), or there's a network issue where > you are. > > Which makes me wonder if maybe there's an issue with connectivity from > your machine to the cloud server (it's on AWS, Oregon zone). > > Can you access https://cloud.subsurface-divelog.org from a browser and > log in with your Subsurface cloud credentials? > > Alternatively, have you tried starting the AppImage with a > --cloud-timeout=15 or similar argument, to give it more time to connect? > > /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
> On Sep 9, 2019, at 5:04 AM, David Owen wrote: > > I didn't see any MacOS binaries. Not sure if that it is to do with the > extra hoops that apps need to go through, so I took the tar file from > the continuous build directory and built and tested that. I made the official binaries just a few minutes ago. The Mac one is now at https://subsurface-divelog.org/downloads/Subsurface-4.9.3.dmg > No issues so > far. I can see the Cosmiq+ in the list of computers but am struggling > to work out how to connect it. Presumably this isn't yet supported from > MacOS, or at least I haven't figured out how to get it to work. Will > have a look with an official Linux binary tomorrow. That's BLE, right? That should work on the Mac as well. You should scan for it from Subsurface and it should find it. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
I didn't see any MacOS binaries. Not sure if that it is to do with the extra hoops that apps need to go through, so I took the tar file from the continuous build directory and built and tested that. No issues so far. I can see the Cosmiq+ in the list of computers but am struggling to work out how to connect it. Presumably this isn't yet supported from MacOS, or at least I haven't figured out how to get it to work. Will have a look with an official Linux binary tomorrow. David On 2019-09-07 9:34 a.m., Dirk Hohndel wrote: > This took a lot longer than expected. > What else is new. > I think we finally have the Qt 5.9 issue resolved (THANK YOU Berthold) > and a couple of crashes one could produce in the same area of code even with > the latest Qt. > We also have a Qt 5.12 based AppImage - and that one REALLY needs testing. > > I am just about to head to Portugal - and there are some small issues with > creating releases remotely because of the slightly esoteric setup I now use > for the website. I'll give it a try :-) > > What I'd really ask everyone to do is > - look at the translations > - try the binaries > - let me know > > I'd hate to have to immediately go into "oh, we need ANOTHER release" mode > after this one. > > Linus, is there anything in libdivecomputer we should pull? > > > Assuming I can get things to work from Portugal, I'd like to get 4.9.3 tagged > on Monday and released on Tuesday. Please don't wait with testing the builds > until after I have tagged the release :-/ > > /D > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Forgot the most important thing. THANK YOU FOR TESTING! /D (the first official 4.9.3 builds are slowly showing up on https://subsurface-divelog.org/downloads - in case others feel like testing as well) > On Sep 9, 2019, at 8:11 AM, Dirk Hohndel wrote: > > >> On Sep 9, 2019, at 8:00 AM, Paul Buxton >> wrote: >> >> Hmm, trying the AppImage on my work machine. The previous bug is fixed >> (crash when clicking flags on the map). But the git cloud storage looks to >> be having issues. >> See attached >> Ubuntu 16 >> 4.4.0-145-generic #171-Ubuntu SMP Tue Mar 26 12:43:40 UTC 2019 x86_64 x86_64 >> x86_64 GNU/Linux >> > > > cloud URL set as > "https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com]; > Opening cloud storage from: > "https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com]; > git storage: Synchronising data file > git storage: Sync with cloud storage > git storage: Waiting for cloud connection (2 second(s) passed) > git storage: Waiting for cloud connection (3 second(s) passed) > git storage: Waiting for cloud connection (4 second(s) passed) > git storage: Cloud connection failed > connection test to cloud server failed QNetworkReply::UnknownNetworkError > "TLS initialization failed" 0 "" > git storage: Can't reach cloud server, working with local data > git storage: Load dives from local cache > > So that could mean that there's an issue with the server (tested a minute > ago, Works For Me (TM)), there's an issue with the AppImage (tested that on > ArchLinux, see before, Works For Me (TM), or there's a network issue where > you are. > > Which makes me wonder if maybe there's an issue with connectivity from your > machine to the cloud server (it's on AWS, Oregon zone). > > Can you access https://cloud.subsurface-divelog.org from a browser and log in > with your Subsurface cloud credentials? > > Alternatively, have you tried starting the AppImage with a > --cloud-timeout=15 or similar argument, to give it more time to connect? > > /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
> On Sep 9, 2019, at 8:00 AM, Paul Buxton > wrote: > > Hmm, trying the AppImage on my work machine. The previous bug is fixed (crash > when clicking flags on the map). But the git cloud storage looks to be having > issues. > See attached > Ubuntu 16 > 4.4.0-145-generic #171-Ubuntu SMP Tue Mar 26 12:43:40 UTC 2019 x86_64 x86_64 > x86_64 GNU/Linux > cloud URL set as "https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com]; Opening cloud storage from: "https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com]; git storage: Synchronising data file git storage: Sync with cloud storage git storage: Waiting for cloud connection (2 second(s) passed) git storage: Waiting for cloud connection (3 second(s) passed) git storage: Waiting for cloud connection (4 second(s) passed) git storage: Cloud connection failed connection test to cloud server failed QNetworkReply::UnknownNetworkError "TLS initialization failed" 0 "" git storage: Can't reach cloud server, working with local data git storage: Load dives from local cache So that could mean that there's an issue with the server (tested a minute ago, Works For Me (TM)), there's an issue with the AppImage (tested that on ArchLinux, see before, Works For Me (TM), or there's a network issue where you are. Which makes me wonder if maybe there's an issue with connectivity from your machine to the cloud server (it's on AWS, Oregon zone). Can you access https://cloud.subsurface-divelog.org from a browser and log in with your Subsurface cloud credentials? Alternatively, have you tried starting the AppImage with a --cloud-timeout=15 or similar argument, to give it more time to connect? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Hmm, trying the AppImage on my work machine. The previous bug is fixed
(crash when clicking flags on the map). But the git cloud storage looks to
be having issues.
See attached
Ubuntu 16
4.4.0-145-generic #171-Ubuntu SMP Tue Mar 26 12:43:40 UTC 2019 x86_64
x86_64 x86_64 GNU/Linux
On Sun, Sep 8, 2019 at 12:42 PM Paul Buxton
wrote:
> I have tested Windows and Appimage installer from
> https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous
> build.
> These look to work ok for me.
> I will try the Appimage one on my work machine tomorrow as well as that is
> the one I saw a crash on with 4.9.1 (unable to reproduce locally).
>
> Paul
>
> On Sat, Sep 7, 2019 at 9:48 PM Jef Driesen
> wrote:
>
>> On 7/09/19 20:16, Linus Torvalds wrote:
>> > Now, there are other changes that Jef did to the Mares code, but the
>> > BLE-specific change I see is his changes to do the BLE packet cache,
>> > so it really looks like that might be it.
>>
>> I doubt that change will fix Fabio's problem. That patch is needed to
>> discard a
>> corrupt packet. It won't help if there is no response or an empty packet.
>>
>> Jef
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>
git_remote_repo: accessing
https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com
git storage: update local repo
sync with remote
https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com]
delete proxy setting
Cloud storage: checking connection to cloud server
Checking cloud connection...
QSslSocket: cannot resolve OPENSSL_init_ssl
QSslSocket: cannot resolve OPENSSL_init_crypto
QSslSocket: cannot resolve ASN1_STRING_get0_data
QSslSocket: cannot resolve EVP_CIPHER_CTX_reset
QSslSocket: cannot resolve RSA_bits
QSslSocket: cannot resolve OPENSSL_sk_new_null
QSslSocket: cannot resolve OPENSSL_sk_push
QSslSocket: cannot resolve OPENSSL_sk_free
QSslSocket: cannot resolve OPENSSL_sk_num
QSslSocket: cannot resolve OPENSSL_sk_pop_free
QSslSocket: cannot resolve OPENSSL_sk_value
QSslSocket: cannot resolve DH_get0_pqg
QSslSocket: cannot resolve SSL_CTX_set_options
QSslSocket: cannot resolve SSL_CTX_set_ciphersuites
QSslSocket: cannot resolve SSL_set_psk_use_session_callback
QSslSocket: cannot resolve SSL_get_client_random
QSslSocket: cannot resolve SSL_SESSION_get_master_key
QSslSocket: cannot resolve SSL_session_reused
QSslSocket: cannot resolve SSL_set_options
QSslSocket: cannot resolve TLS_method
QSslSocket: cannot resolve TLS_client_method
QSslSocket: cannot resolve TLS_server_method
QSslSocket: cannot resolve X509_STORE_CTX_get0_chain
QSslSocket: cannot resolve X509_getm_notBefore
QSslSocket: cannot resolve X509_getm_notAfter
QSslSocket: cannot resolve X509_get_version
QSslSocket: cannot resolve OpenSSL_version_num
QSslSocket: cannot resolve OpenSSL_version
Incompatible version of OpenSSL
QSslSocket::connectToHostEncrypted: TLS initialization failed
Cloud storage: unable to connect to cloud server
git load handling file 00-Subsurface
git load handling file Site-056f48d7
git load handling file Site-28d46750
git load handling file Site-3e91e4ef
git load handling file Site-a297547e
git load handling file Site-bb67bd11
git load handling file Site-e071bb96
git load handling file Dive-1
git load handling file Divecomputer
git load handling file Dive-2
git load handling file Divecomputer
git load handling file Dive-3
git load handling file Divecomputer
git load handling file Dive-4
git load handling file Divecomputer
git load handling file Dive-5
git load handling file Divecomputer
git load handling file Dive-6
git load handling file Divecomputer
git load handling file Dive-7
git load handling file Divecomputer
git load handling file Dive-8
git load handling file Divecomputer
git load handling file Dive-9
git load handling file Divecomputer
git load handling file Dive-10
git load handling file Divecomputer
Subsurface v4.9.2-44-g15869731e1e3,
built with libdivecomputer v0.7.0-devel-Subsurface-NG
(ce6d9896a79afaa82641132e338f8744714c8593)
built with Qt Version 5.12.4, runtime from Qt Version 5.12.4
built with libgit2 0.26.0
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 4.5."
loading dive data from ("/user/pcb/.subsurface/pcb.xml")
File locations:
cloud URL set as
"https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com];
Local git storage: /user/pcb/.subsurface/cloudstorage/f81a301809603fec
Cloud URL:
https://cloud.subsurface-divelog.org//git/paulbuxton.m...@googlemail.com[paulbuxton.m...@googlemail.com]
Image filename table: /user/pcb/.subsurface/hashes
Local picture directory: /user/pcb/.subsurface/picturedata/
cloud URL set as
Re: 4.9.3 preparations
I have tested Windows and Appimage installer from https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous build. These look to work ok for me. I will try the Appimage one on my work machine tomorrow as well as that is the one I saw a crash on with 4.9.1 (unable to reproduce locally). Paul On Sat, Sep 7, 2019 at 9:48 PM Jef Driesen wrote: > On 7/09/19 20:16, Linus Torvalds wrote: > > Now, there are other changes that Jef did to the Mares code, but the > > BLE-specific change I see is his changes to do the BLE packet cache, > > so it really looks like that might be it. > > I doubt that change will fix Fabio's problem. That patch is needed to > discard a > corrupt packet. It won't help if there is no response or an empty packet. > > Jef > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On 7/09/19 20:16, Linus Torvalds wrote: Now, there are other changes that Jef did to the Mares code, but the BLE-specific change I see is his changes to do the BLE packet cache, so it really looks like that might be it. I doubt that change will fix Fabio's problem. That patch is needed to discard a corrupt packet. It won't help if there is no response or an empty packet. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Sat, Sep 7, 2019 at 12:21 PM Fabio Capriati wrote: > > If you have a Android version with new Beta version of libdivelog, I can > test it on my Mares Smart DC. Hmm. Travis successfully built the Android version at https://travis-ci.org/Subsurface-divelog/subsurface/jobs/582100407 but I don't actually know where the binaries end up and if we can download them. I think Dirk is on a flight to Lisbon right now, so I decided to just merge that libdivecomputer update into subsurface. I think that in turn should make it should up eventually as https://github.com/Subsurface-divelog/subsurface/releases/download/continuous/subsurface-mobile-build-arm-debug.apk but those aren't signed, so they are a pain. I dunno. I guess we'll need to wait for Dirk anyway. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Il sab 7 set 2019, 18:54 Linus Torvalds ha scritto: > On Sat, Sep 7, 2019 at 8:34 AM Dirk Hohndel wrote: > > > > Linus, is there anything in libdivecomputer we should pull? > > I just checked Jef's branch, and merged it. It has a Mares BLE packet > caching fix that *might* explain that the Mares BLUELINK Pro > apparently doesn't work any more. > Since I don't have a dive computer to test with, I can't really say. > But that fix looks obvious and harmless even if it doesn't end up > making any difference. Hi, If you have a Android version with new Beta version of libdivelog, I can test it on my Mares Smart DC. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Sat, Sep 7, 2019 at 9:54 AM Linus Torvalds wrote: > > I've done the merge, I'm doing a test build, and I'll make a pull > request. Travis is happy, things look ok. For reference, this is the diffstat of the updates from Jef: src/divesystem_idive_parser.c | 131 +++--- src/mares_iconhd.c| 2 + 2 files changed, 95 insertions(+), 38 deletions(-) so the risk is literally to just from that iDive parsing (the Mares changes really can't break anything, particularly as Fabio reported (again) that it apparently used to work in 4.8.3 but doesn't work in 4.9.2. Now, there are other changes that Jef did to the Mares code, but the BLE-specific change I see is his changes to do the BLE packet cache, so it really looks like that might be it. So I'd suggest just merging it. The possible breakage is very limited, and it does look like it might fix things. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Sat, Sep 7, 2019 at 8:34 AM Dirk Hohndel wrote: > > Linus, is there anything in libdivecomputer we should pull? I just checked Jef's branch, and merged it. It has a Mares BLE packet caching fix that *might* explain that the Mares BLUELINK Pro apparently doesn't work any more. Since I don't have a dive computer to test with, I can't really say. But that fix looks obvious and harmless even if it doesn't end up making any difference. It also merges up my i200C changes (but that doesn't change anything in our tree, just history) and improves support for the Ratio iDive dive computers' pressure transmitters. I've done the merge, I'm doing a test build, and I'll make a pull request. However, I can't test either the Mares nor the iDive changes, so it's a slight judgement call. The Mares changes I can't imagine breaking anything. The iDive changes _look_ good too, but do some odd things (send a pressure of 0 for "pressure lost", which shouldn't affect us because I think we'll just ignore it, but..) So I think merging it is good, but the iDive thing is a _slight_ risk. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
4.9.3 preparations
This took a lot longer than expected. What else is new. I think we finally have the Qt 5.9 issue resolved (THANK YOU Berthold) and a couple of crashes one could produce in the same area of code even with the latest Qt. We also have a Qt 5.12 based AppImage - and that one REALLY needs testing. I am just about to head to Portugal - and there are some small issues with creating releases remotely because of the slightly esoteric setup I now use for the website. I'll give it a try :-) What I'd really ask everyone to do is - look at the translations - try the binaries - let me know I'd hate to have to immediately go into "oh, we need ANOTHER release" mode after this one. Linus, is there anything in libdivecomputer we should pull? Assuming I can get things to work from Portugal, I'd like to get 4.9.3 tagged on Monday and released on Tuesday. Please don't wait with testing the builds until after I have tagged the release :-/ /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
