Re: cloud.subsurface-divelog.org auth error
> On Aug 27, 2017, at 2:14 PM, Cristian Ionescu-Idbohrn > wrote: > > On Sun, 27 Aug 2017, Dirk Hohndel wrote: >>> On Aug 27, 2017, at 10:15 AM, Yury Akudovich wrote: >>> I've rebuilt the library and Subsurface with https support and now it works! >>> Unfortunately I can't install your deb packages because of dependency >>> on libssl1.0.0, but in my Debian buster(testing) is only libssl1.1 >>> available. >> >> Hmm - I have a hard time matching Ubuntu and Debian versions. Even the >> Artful repo isn't new enough for Buster? > > Thing is, you can have both libssl1.0.2 _and_ libssl1.1 installed on > debian buster/sid. Your choice is to install libssl1.0-dev (instead > of libssl-dev), should you choose to use libssl1.0-dev (headers, lib) > for development. In my case, this is what I currently have installed: > > libssl1.0-dev:amd64 install > ^ > libssl1.0.0:amd64 install > libssl1.0.2:amd64 install > libssl1.1:amd64 install > libssl1.1:i386 install > > on debian sid. There are still quite a few packages that lack > libssl1.1 support in the distro. Much better answer than mine :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: cloud.subsurface-divelog.org auth error
On Sun, 27 Aug 2017, Dirk Hohndel wrote: > > On Aug 27, 2017, at 10:15 AM, Yury Akudovich wrote: > > I've rebuilt the library and Subsurface with https support and now it works! > > Unfortunately I can't install your deb packages because of dependency > > on libssl1.0.0, but in my Debian buster(testing) is only libssl1.1 > > available. > > Hmm - I have a hard time matching Ubuntu and Debian versions. Even the > Artful repo isn't new enough for Buster? Thing is, you can have both libssl1.0.2 _and_ libssl1.1 installed on debian buster/sid. Your choice is to install libssl1.0-dev (instead of libssl-dev), should you choose to use libssl1.0-dev (headers, lib) for development. In my case, this is what I currently have installed: libssl1.0-dev:amd64 install ^ libssl1.0.0:amd64 install libssl1.0.2:amd64 install libssl1.1:amd64 install libssl1.1:i386 install on debian sid. There are still quite a few packages that lack libssl1.1 support in the distro. Cheers, -- Cristian ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: removing Marble traces from the Subsurface tree
On 27 August 2017 at 23:34, Dirk Hohndel wrote: > >> On Aug 24, 2017, at 8:55 PM, Miika Turkia wrote: >> >> On Thu, Aug 24, 2017 at 11:49 PM, Lubomir I. Ivanov >> wrote: >>> with the new map widget we started phasing out the Marble globe... >>> the transition is smooth in the lines of using NO_MARBLE as toggle - >>> i.e. it either uses Marble or QtLocation. >>> >>> we should probably start removing it as a dependency from both c++, >>> cmake and build scripts (i might needs some help for the later). but >>> the question is - should we? do we want to keep it? >>> >>> i got no issue reports about the new Map widget which means all is good >>> with it. >> >> Any idea about the following error message? >> >> qrc:/MapWidget.qml:45: Error: Cannot assign [undefined] to >> QDeclarativeGeoMapType* >> qml: MapWidget.qml: cannot find a plugin with the name 'googlemaps' >> >> I am currently getting no map when compiling myself. I am pretty sure >> it did work earlier with this laptop, but not anymore. But then again, >> it might have been different laptop where the new map was working. > > So now that this is fixed, I think we should go back to doing two things > > a) figure out how to package this for the distros / AppImage > b) start ripping out all the Marble dependencies and code, etc > > I could really use some help with a) - I'll be at a conference in Las Vegas > all week and doubt I'll have any time to spend on Subsurface :-( > i can probably do b) + the "clear map cache on language change" during the week. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: removing Marble traces from the Subsurface tree
> On Aug 24, 2017, at 8:55 PM, Miika Turkia wrote: > > On Thu, Aug 24, 2017 at 11:49 PM, Lubomir I. Ivanov > wrote: >> with the new map widget we started phasing out the Marble globe... >> the transition is smooth in the lines of using NO_MARBLE as toggle - >> i.e. it either uses Marble or QtLocation. >> >> we should probably start removing it as a dependency from both c++, >> cmake and build scripts (i might needs some help for the later). but >> the question is - should we? do we want to keep it? >> >> i got no issue reports about the new Map widget which means all is good with >> it. > > Any idea about the following error message? > > qrc:/MapWidget.qml:45: Error: Cannot assign [undefined] to > QDeclarativeGeoMapType* > qml: MapWidget.qml: cannot find a plugin with the name 'googlemaps' > > I am currently getting no map when compiling myself. I am pretty sure > it did work earlier with this laptop, but not anymore. But then again, > it might have been different laptop where the new map was working. So now that this is fixed, I think we should go back to doing two things a) figure out how to package this for the distros / AppImage b) start ripping out all the Marble dependencies and code, etc I could really use some help with a) - I'll be at a conference in Las Vegas all week and doubt I'll have any time to spend on Subsurface :-( /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: cloud.subsurface-divelog.org auth error
> On Aug 27, 2017, at 10:15 AM, Yury Akudovich wrote: > > Dirk, > > Sorry for delayed reply, I was on vacation. > > You were right, my local build wasn't able to sync to cloud because of > lack of https support in libgit2. There is bug open about that: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832798. The interdependency of how things are built on Linux distros are one of the key challenges for us. See the latest battle with the googlemaps plugin not compiling on Ubuntu and Debian systems. > I've rebuilt the library and Subsurface with https support and now it works! > Unfortunately I can't install your deb packages because of dependency > on libssl1.0.0, but in my Debian buster(testing) is only libssl1.1 > available. Hmm - I have a hard time matching Ubuntu and Debian versions. Even the Artful repo isn't new enough for Buster? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: removing Marble traces from the Subsurface tree
On 27 August 2017 at 01:14, Dirk Hohndel wrote: > On Sat, Aug 26, 2017 at 04:52:49PM +0300, Lubomir I. Ivanov wrote: >> 1) >> here is a PR with a small change in the googlemaps plugin's qmake to >> allow using headers from relative paths: >> https://github.com/vladest/googlemaps/pull/15 >> >> 2) >> attached is my updated script to fetch the QtLocation and >> QtPositioning private headers from the Qt repository. >> if someone has the time you can integrated that into our build.sh. >> >> one potential problem here is that i don't know how to place the >> headers in install_root and tell the qmake of the googlemaps plugin to >> use install_root in a non-disruptive way (i.e. only we care about >> install_root). instead the solution might be to simply copy the header >> folders inside the googlemaps plugin folder it will work. >> >> NOTE: both these changes require qmake5. >> need to leave in a minute and will be back on sunday afternoon (EET). > > I took your script, made a few modifications (I really wanted those > include files under our install-root), included it in the build script, > and pushed all of that to master. > > vladest just merged your PR, so now this compiles and runs with working > maps on Ubuntu 16.10 (that's what I had a VM of); I also tested ArchLinux > and Fedora 25. I'd love to hear if this works on other Linux flavors that > people care about. oops, i've missed this email, started working on the changes myself and created a PR. just saw the email and canceled the PR, which really was less complete of an implementation. thanks lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: cloud.subsurface-divelog.org auth error
Dirk, Sorry for delayed reply, I was on vacation. You were right, my local build wasn't able to sync to cloud because of lack of https support in libgit2. There is bug open about that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832798. I've rebuilt the library and Subsurface with https support and now it works! Unfortunately I can't install your deb packages because of dependency on libssl1.0.0, but in my Debian buster(testing) is only libssl1.1 available. Thank you! On 4 August 2017 at 14:58, Dirk Hohndel wrote: > >> On Aug 4, 2017, at 3:54 AM, Yury Akudovich wrote: >> >> I've also tried to do `curl` and `git clone` to the URL and it also >> failed, but it can succeed if I remove second `[email]` in the end of >> the URL. So I think there is some bigger problem then just https >> support. I can also try to do tcpdump to double check connection, if >> needed. BTW, The OS is Debian testing. > > You didn't actually address the question whether the official AppImage works. > >> $ curl -u some.em...@gmail.com -v >> 'https://cloud.subsurface-divelog.org//git/some.em...@gmail.com\[some.em...@gmail.com\]' > > curl against an https git URL with our "magic" branch syntax. Unlikely to do > anything useful > >> $ curl -u some.em...@gmail.com -v >> 'https://cloud.subsurface-divelog.org//git/some.em...@gmail.com' > > Again curl again an https git URL, now without the branch. Still not going to > do anything useful > >> $ git clone >> 'https://cloud.subsurface-divelog.org//git/some.em...@gmail.com\[some.em...@gmail.com\]' >> Cloning into 'some.em...@gmail.com\[some.em...@gmail.com\]'... >> Username for 'https://cloud.subsurface-divelog.org': some.em...@gmail.com >> Password for 'https://some.em...@gmail.com@cloud.subsurface-divelog.org': >> fatal: Authentication failed for >> 'https://cloud.subsurface-divelog.org//git/some.em...@gmail.com\[some.em...@gmail.com\]/' > > The branch syntax only works in Subsurface, not with curl > >> $ git clone 'https://cloud.subsurface-divelog.org//git/some.em...@gmail.com' >> Cloning into 'some.em...@gmail.com'... >> Username for 'https://cloud.subsurface-divelog.org': some.em...@gmail.com >> Password for 'https://some.em...@gmail.com@cloud.subsurface-divelog.org': >> remote: Counting objects: 49, done. >> remote: Compressing objects: 100% (28/28), done. >> remote: Total 49 (delta 10), reused 0 (delta 0) >> Unpacking objects: 100% (49/49), done. >> warning: remote HEAD refers to nonexistent ref, unable to checkout. > > That almost works, except that you need to tell git that you want the > 'some.em...@gmail.com' branch. > > git clone -b some.em...@gmail.com > https://cloud.subsurface-divelog.org//git/some.em...@gmail.com > > should work > > But none of these will answer the question why your Subsurface build isn't > working. > > /D -- With best regards, Yury Akudovich ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
