Re: Problem accessing cloud behind a proxy

2017-11-16 Thread Davide DB
On 15 November 2017 at 17:12, Lubomir I. Ivanov  wrote:
> this is from:
>
>> rename of 
>> C:\Users\ddebenedictis\AppData\Roaming\Subsurface/cloudstorage/29fc20f013e9f1fb
>>  to 
>> "C:\\Users\\ddebenedictis\\AppData\\Roaming\\Subsurface/cloudstorage/29fc20f013e9f1fb.1"
>>  failed
>> exclusive write access obtained...closing handle!rename failed: 5
>
> core/windows.c:subsurface_dir_rename()
>
> status 5, means ERROR_ACCESS_DENIED
>
> Davide, something is preventing the directory rename:
> - antivirus software?
> - the '29fc20f013e9f1fb.1' directory already exists?
>
> lubomir

The directory was apparently OK. Maybe starting and stopping
Subsurface via CTRL+C on command line left some file hold by some
process. I deleted everything and started from scratch.

Everything works fine now!

Now when I use WI-FI or tethering with direct internet access
Subsurface doesn't look for proxy anymore.

Thanks a lot.

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Lubomir I. Ivanov
On 15 November 2017 at 17:56, Dirk Hohndel  wrote:
> On Wed, Nov 15, 2017 at 04:44:24PM +0100, Davide DB wrote:
>> On 15 November 2017 at 16:28, Dirk Hohndel  wrote:
>>
>> > The interesting thing to me is that "Checking cloud connection..."
>> > "Successful cloud connection".
>> > Which means that the teapot worked, which means that Qt was able to use
>> > the proxy information that you entered.
>> > It's only libgit2 that somehow can't get things to work right :-(
>>
>> Ok, so in the meantime... From my previous log without proxy I saw that at
>> a certain point aI was able to download dives but then I got a local rename
>> error.
>
> I was hoping that Lubomir had an idea what that was all about.
>

this is from:

> rename of 
> C:\Users\ddebenedictis\AppData\Roaming\Subsurface/cloudstorage/29fc20f013e9f1fb
>  to 
> "C:\\Users\\ddebenedictis\\AppData\\Roaming\\Subsurface/cloudstorage/29fc20f013e9f1fb.1"
>  failed
> exclusive write access obtained...closing handle!rename failed: 5

core/windows.c:subsurface_dir_rename()

status 5, means ERROR_ACCESS_DENIED

Davide, something is preventing the directory rename:
- antivirus software?
- the '29fc20f013e9f1fb.1' directory already exists?

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Dirk Hohndel
On Wed, Nov 15, 2017 at 04:44:24PM +0100, Davide DB wrote:
> On 15 November 2017 at 16:28, Dirk Hohndel  wrote:
> 
> > The interesting thing to me is that "Checking cloud connection..."
> > "Successful cloud connection".
> > Which means that the teapot worked, which means that Qt was able to use
> > the proxy information that you entered.
> > It's only libgit2 that somehow can't get things to work right :-(
> 
> Ok, so in the meantime... From my previous log without proxy I saw that at
> a certain point aI was able to download dives but then I got a local rename
> error.

I was hoping that Lubomir had an idea what that was all about.

> What does it mean? And what does it mean "*Linus does not like non-fat milk*"
> :)

That's part of our I AM A TEAPOT protocol.
https://www.ietf.org/rfc/rfc2324.txt
https://sitesdoneright.com/blog/2013/03/what-is-418-im-a-teapot-status-code-error

Strictly speaking our use of the 418 return to authenticate that we are
talking to our own server is incorrect in that 4xx codes are errors, yet
we take the code (together with the correct response text message of
"Linus does not like non-far milk" (which is, btw, a true statement)) to
mean that we are actually talking to our cloud backend and not some
impostor in the middle.

> Sorry for being a pita but now are several months I don't use Subsurface. I
> have most of my "empty" dives on my mobile phone.

I will admit that I'm embarrassed by that. And I will continue to work on
my attempt to implement proxy authentication differently.

I will also admit that you appear to be the only person I know who's only
access to a computer is a computer behind an authentication-only reverse
proxy firewall. The mere idea that someone wouldn't own a laptop that they
could use at home or at a coffee shop in order to connect to the internet
is... rather hard to understand for me. Given what I make an hour in my
day job and the amount of time I have spent on this so far, I can
comfortably say that it would be significantly easier if I just bought
such a laptop and sent it to you...

Only half joking.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Davide DB
On 15 November 2017 at 16:28, Dirk Hohndel  wrote:

>
> The interesting thing to me is that "Checking cloud connection..."
> "Successful cloud connection".
> Which means that the teapot worked, which means that Qt was able to use
> the proxy information that you entered.
> It's only libgit2 that somehow can't get things to work right :-(
>


Ok, so in the meantime... From my previous log without proxy I saw that at
a certain point aI was able to download dives but then I got a local rename
error.
What does it mean? And what does it mean "*Linus does not like non-fat milk*"
:)

Sorry for being a pita but now are several months I don't use Subsurface. I
have most of my "empty" dives on my mobile phone.


-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Dirk Hohndel

> On Nov 15, 2017, at 7:22 AM, Davide DB  wrote:
> 
> Has this executable different log traces?

It should have the same log information as previous versions (as far as 
Subsurface is concerned).
But it uses a newer version of libgit2. I was hoping that would make a 
difference (and added Robert's patch).

> I'm trying again with the proxy and I don't get anymore the incorrect 
> parameter error but just a timeout.
> Proxy data seems to be correct.

I now need to find the time to go back to my experimental branch where I tried 
to use a proxy callback to
enter the authentication information.

The interesting thing to me is that "Checking cloud connection..." "Successful 
cloud connection".
Which means that the teapot worked, which means that Qt was able to use the 
proxy information that you entered.
It's only libgit2 that somehow can't get things to work right :-(

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Davide DB
Dirk,

Has this executable different log traces?
I'm trying again with the proxy and I don't get anymore the incorrect
parameter error but just a timeout.
Proxy data seems to be correct.

C:\Program Files (x86)\Subsurface>subsurface.exe -v

C:\Program Files (x86)\Subsurface>
Subsurface v4.7.4-21-gbd9dad7371f8,
built with libdivecomputer v0.6.0-devel-Subsurface-branch
(7de3a549ee588fef4702ee9d894e390aca43950d)
built with Qt Version 5.9.1, runtime from Qt Version 5.9.1
built with libgit2 0.26.0
validateGL(): created OpenGLContext.
validateGL(): obtained QOpenGLFunctions.
validateGL(): detected OpenGL version 3.3.
Plugins Directory:  QDir( "C:/Program Files (x86)/Subsurface/plugins" ,
nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) ,
QDir::Filters( Dirs|Files|Drives|AllEntries ) )
cloud URL set as "
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
"
loading dive data from ("
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
")
git storage: Synchronising data file
git storage: update local repo
sync with remote
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
git storage: Sync with cloud storage
*set proxy to "http://USER:p...@proxydomain.domain.it:8080
"*
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
remote fetch failed (failed to send request: Timeout dell'operazione
(*operation
timeout*)
)
git storage: Done syncing with cloud storage
git storage: Load dives from local cache
git storage: Successfully opened dive data
Set the current dive site: 0

File locations:

cloud URL set as "
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
"
Local git storage:
C:\Users\ddebenedictis\AppData\Roaming\Subsurface/cloudstorage/29fc20f013e9f1fb
Cloud URL:
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
Image hashes: C:\Users\ddebenedictis\AppData\Roaming\Subsurface/hashes
Local picture directory:
C:\Users\ddebenedictis\AppData\Roaming\Subsurface/picturedata/
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Lubomir I. Ivanov
On 15 November 2017 at 17:20, Dirk Hohndel  wrote:
> On Wed, Nov 15, 2017 at 05:08:49PM +0200, Lubomir I. Ivanov wrote:
>> On 15 November 2017 at 17:03, Dirk Hohndel  wrote:
>> > On Wed, Nov 15, 2017 at 04:36:25PM +0200, Lubomir I. Ivanov wrote:
>> >> On 15 November 2017 at 16:27, Dirk Hohndel  wrote:
>> >> >
>> >> > With Lubomir's changes there are two ways to get the console output:
>> >> >
>> >> > You can run from cmd.exe - then the output is shown on the screen, but 
>> >> > not
>> >> > saved to the log files.
>> >> > Or you can run this by double clicking on the executable. Then the log
>> >> > output is saved to the two log files.
>> >> >
>> >>
>> >> something to note here, is that by default when the Subsurface.exe is
>> >> started from the desktop shortcut, the log files would remain mostly
>> >> empty because the executable does not receive any "-v" arguments.
>> >> so to see verbose output the user has to manually append the "-v"s in
>> >> the desktop shortcut  field.
>> >
>> > Which makes me wonder... should we just use verbose=1 as default if
>> > started from the shortcut on Windows?
>> >
>>
>> i was implying the same question, in a way.
>> but then, what if the user needs to see something which requires more
>> verbose levels?
>> he/she has to append more "-v"s to the shortcut.
>>
>> would "1" suffice, by default?
>
> IIRC the higher levels give you detailed parsing info and similar
> extremely verbose information. I rarely see a reason to go there.
> So I think '1' is a reasonable default for this.
>

ok, sounds good.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Dirk Hohndel
On Wed, Nov 15, 2017 at 05:08:49PM +0200, Lubomir I. Ivanov wrote:
> On 15 November 2017 at 17:03, Dirk Hohndel  wrote:
> > On Wed, Nov 15, 2017 at 04:36:25PM +0200, Lubomir I. Ivanov wrote:
> >> On 15 November 2017 at 16:27, Dirk Hohndel  wrote:
> >> >
> >> > With Lubomir's changes there are two ways to get the console output:
> >> >
> >> > You can run from cmd.exe - then the output is shown on the screen, but 
> >> > not
> >> > saved to the log files.
> >> > Or you can run this by double clicking on the executable. Then the log
> >> > output is saved to the two log files.
> >> >
> >>
> >> something to note here, is that by default when the Subsurface.exe is
> >> started from the desktop shortcut, the log files would remain mostly
> >> empty because the executable does not receive any "-v" arguments.
> >> so to see verbose output the user has to manually append the "-v"s in
> >> the desktop shortcut  field.
> >
> > Which makes me wonder... should we just use verbose=1 as default if
> > started from the shortcut on Windows?
> >
> 
> i was implying the same question, in a way.
> but then, what if the user needs to see something which requires more
> verbose levels?
> he/she has to append more "-v"s to the shortcut.
> 
> would "1" suffice, by default?

IIRC the higher levels give you detailed parsing info and similar
extremely verbose information. I rarely see a reason to go there.
So I think '1' is a reasonable default for this.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Davide DB
On 15 November 2017 at 15:27, Dirk Hohndel  wrote:
>
> Davide, can you test with this binary:
>
>
http://subsurface-divelog.org/downloads/test/subsurface-4.7.4-21-gbd9dad7371f8.exe
>
> That will tell us what libgit thinks the proxy might be.
>
> With Lubomir's changes there are two ways to get the console output:
>
> You can run from cmd.exe - then the output is shown on the screen, but not
> saved to the log files.
> Or you can run this by double clicking on the executable. Then the log
> output is saved to the two log files.
>

Ok, something has changed.

At first I tested everything with the subsurface-4.7.2-74-g577bf57ddfb8.exe
(no joy)
Then I tested 4.74 (no joy)
Then I cleared subsurface proxy settings from Windows registry and again
tested with 4.7.4 (no joy)
Installing subsurface-4.7.4-21-gbd9dad7371f8.exe Subsurface must have
changed something in the Windows registry because now I get completely
different errors...


*First try with subsurface.exe -v (I see the progress bar downloading 80
dives but at the end I get an error and no dives are displayed)*

C:\Program Files (x86)\Subsurface>subsurface.exe -v

C:\Program Files (x86)\Subsurface>
Subsurface v4.7.4-21-gbd9dad7371f8,
built with libdivecomputer v0.6.0-devel-Subsurface-branch
(7de3a549ee588fef4702ee9d894e390aca43950d)
built with Qt Version 5.9.1, runtime from Qt Version 5.9.1
built with libgit2 0.26.0
validateGL(): created OpenGLContext.
validateGL(): obtained QOpenGLFunctions.
validateGL(): detected OpenGL version 3.3.
Plugins Directory:  QDir( "C:/Program Files (x86)/Subsurface/plugins" ,
nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) ,
QDir::Filters( Dirs|Files|Drives|AllEntries ) )
cloud URL set as "
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
"
loading dive data from ("
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
")
git storage: Synchronising data file
git storage: update local repo
sync with remote
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
git storage: Sync with cloud storage
delete proxy setting
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: Transfer from storage (0/60)
git storage: Transfer from storage (1/60)
git storage: Transfer from storage (2/60)
git storage: Transfer from storage (3/60)
git storage: Transfer from storage (4/60)
git storage: Transfer from storage (5/60)
git storage: Transfer from storage (6/60)
git storage: Transfer from storage (7/60)
git storage: Transfer from storage (8/60)
git storage: Transfer from storage (9/60)
git storage: Transfer from storage (10/60)
git storage: Transfer from storage (11/60)
git storage: Transfer from storage (12/60)
git storage: Transfer from storage (13/60)
git storage: Transfer from storage (14/60)
git storage: Transfer from storage (15/60)
git storage: Transfer from storage (16/60)
git storage: Transfer from storage (17/60)
git storage: Transfer from storage (18/60)
git storage: Transfer from storage (19/60)
git storage: Transfer from storage (20/60)
git storage: Transfer from storage (21/60)
git storage: Transfer from storage (22/60)
git storage: Transfer from storage (23/60)
git storage: Transfer from storage (24/60)
git storage: Transfer from storage (25/60)
git storage: Transfer from storage (26/60)
git storage: Transfer from storage (27/60)
git storage: Transfer from storage (28/60)
git storage: Transfer from storage (29/60)
git storage: Transfer from storage (30/60)
git storage: Transfer from storage (31/60)
git storage: Transfer from storage (32/60)
git storage: Transfer from storage (33/60)
git storage: Transfer from storage (34/60)
git storage: Transfer from storage (35/60)
git storage: Transfer from storage (36/60)
git storage: Transfer from storage (37/60)
git storage: Transfer from storage (38/60)
git storage: Transfer from storage (39/60)
git storage: Transfer from storage (40/60)
git storage: Transfer from storage (41/60)
git storage: Transfer from storage (42/60)
git storage: Transfer from storage (43/60)
git storage: Transfer from storage (44/60)
git storage: Transfer from storage (45/60)
git storage: Transfer from storage (46/60)
git storage: Transfer from storage (47/60)
git storage: Transfer from storage (48/60)
git storage: Transfer from storage (49/60)
git storage: Transfer from storage (50/60)
git storage: Transfer from storage (51/60)
git storage: Transfer from storage (52/60)
git storage: Transfer from storage (53/60)
git storage: Transfer from storage (54/60)
git storage: Transfer from storage (55/60)
git storage: Transfer from storage (56/60)
git storage: Transfer from storage (57/60)
git storage: Transfer from storage (58/60)
git storage: Transfer from storage (59/60)
git storage: Transfer from storage (60/60)
git storage: 

Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Dirk Hohndel
On Wed, Nov 15, 2017 at 04:36:25PM +0200, Lubomir I. Ivanov wrote:
> On 15 November 2017 at 16:27, Dirk Hohndel  wrote:
> >
> > With Lubomir's changes there are two ways to get the console output:
> >
> > You can run from cmd.exe - then the output is shown on the screen, but not
> > saved to the log files.
> > Or you can run this by double clicking on the executable. Then the log
> > output is saved to the two log files.
> >
> 
> something to note here, is that by default when the Subsurface.exe is
> started from the desktop shortcut, the log files would remain mostly
> empty because the executable does not receive any "-v" arguments.
> so to see verbose output the user has to manually append the "-v"s in
> the desktop shortcut  field.

Which makes me wonder... should we just use verbose=1 as default if
started from the shortcut on Windows?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Dirk Hohndel

> On Nov 15, 2017, at 6:04 AM, Robert Helling  wrote:
> 
> Dirk,
> 
> 
>> On 15. Nov 2017, at 14:44, Dirk Hohndel > > wrote:
>> 
>> Fun fact: if you push to a branch on Subsurface-divelog/subsurface (which 
>> you can, Robert), the CI will build a Windows binary for you. And even for a 
>> PR it will do that (and the log will show you where on transfer.sh the 
>> binary can be found.
> 
> 
> I followed the mailing list in as much as I am aware of that. But the patch I 
> attached was for libgit2 (to provide more debugging information) and that as 
> far as I understand I cannot get into our travis build. I wanted to 
> understand what that library thinks it should take as proxy (which would then 
> be a hint as to where look further).

My mistake. I triggered a new local build on our old infrastructure where I can 
easily modify libraries like this.

Davide, can you test with this binary:

http://subsurface-divelog.org/downloads/test/subsurface-4.7.4-21-gbd9dad7371f8.exe

That will tell us what libgit thinks the proxy might be.

With Lubomir's changes there are two ways to get the console output:

You can run from cmd.exe - then the output is shown on the screen, but not 
saved to the log files.
Or you can run this by double clicking on the executable. Then the log output 
is saved to the two log files.

Thanks

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Dirk Hohndel

> On Nov 15, 2017, at 6:14 AM, Davide DB  wrote:
> 
> These test were performed with the
> subsurface-4.7.2-74-g577bf57ddfb8.exe on download/test and 4.7.4
> official.

Thanks.

> Ok so I understood correctly.
> 
> Given that I spent 99% of my time working with pc behind a company
> proxy with authentication I decided to use tethering on my mobile
> phone to get 4G connection just to download/upload my logbook on the
> cloud.

I feel terrible that you spend 99% of your time working... (sorry for the 
silly attempt at humor).

> This sound interesting...
> I have several PC which are behind my company proxy with authentication.
> The hack procedure is:
> 
> - disable onboard gigabit network adapter
> - connect my mobile phone via USB
> - enable USB tethering on my mobile phone
> - Windows automagically install the new network adapter
> - I test the internet connection:
> --- I disable proxy use on internet explorer: direct internet connection
> --- I open Chrome and successfully connect to
> http://cloud.subsurface-divelog.org/ (I get the user/pwd prompt)
> --- I open cmd prompt and i ping a random webisite
> - I launch Subsurface from the command prompt with the -v -v prompt
> (the network preferences shows No Proxy and ALL proxy fields empty)
> - I still see that infamous incorrect parameter proxy error :(
> 
> PS
> Just to be sure, once I disable proxy use on Internet Explorer, all my
> apps that access internet and have proxy settings inside don't work.
> Google Chrome inherits proxy settings from IE so it works.
> Putty has its own proxy settings so it won't works.
> 
> So I don't have a system proxy I guess

That seems like a thorough analysis.

See my next email for more testing requests...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Dirk Hohndel

> On Nov 15, 2017, at 2:59 AM, Davide DB  wrote:
> 
> Hi Robert,
> 
> Dirk looked into this weeks ago:
> 
> On 3 November 2017 at 17:31, Dirk Hohndel  > wrote:
> Preliminary results of this (and some more googling). There appears to be an 
> issue with
> libgit2 and authenticated proxies on Windows (and only on Windows) - which is 
> why I never
> saw this in my testing. I'm trying to figure out what the correct workaround 
> might be
> 
> https://github.com/libgit2/libgit2/issues/4069 
> 
> 
> I no longer have access to the proxy that requires authentication, I'll need 
> to build one
> to test, I guess :-)

I actually build a proxy with authentication just to be able to test that :-)

> AFAIK for the time being is not possible to use a proxy (until someone 
> correct libgit2).

Subsurface 4.7.4 happily uses a proxy without authentication on Windows. It's 
the user/password embedded in the proxy URL (which works fine on Mac and Linux) 
that throws Windows into failure.

> The problem now is that I get a temporary direct access to internet but I 
> cannot get rid of the previous proxy settings on my pc.
> Maybe the subsurface trace log is not correct because I erased that values 
> form my registry.

If you get that error, it's trying to use a proxy. I wonder... do you have a 
system wide proxy set for your Windows machine? Is libgit2 trying to be clever 
and picking up those settings (and then getting it wrong)?

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Dirk Hohndel

> On Nov 15, 2017, at 2:09 AM, Robert Helling  wrote:
>> 
>> Cloud storage: successfully checked connection to cloud server
>> git storage: fetch remote
>> git storage: Successful cloud connection, fetch remote
>> remote fetch failed (Failed to set proxy: Parametro non corretto.
>> )
>> git storage: Done syncing with cloud storage
> 
> 
> I looked for the origin of this error message. “remote fetch failed” is 
> Subsurface talking, “failed to set proxy” is libgit2. This only occurs in 
> winhttp.c when a call to WinHttpSetOption fails. 
> 
> So I googled for that call and found 
> 
> https://msdn.microsoft.com/de-de/library/windows/desktop/aa384114(v=vs.85).aspx
>  
> 
> 
> Most of this I don’t understand (having touched no windows system for a very 
> long time. But my guess that the only thing that could be non-corretto would 
> be the proxy url (and that part of the code that has this error message is 
> only run when proxy_url is non-NULL). But of course it should be empty (and 
> the fact that Subsurface says earlier "delete proxy setting” should mean that 
> that parameter got deleted.
> 
> So it would be interesting to know what libgit2 thinks should be the proxy 
> url.
> 
> Unfortunately, I cannot build windows binaries but if anybody can I would say 
> it’s worth trying to apply this patch to llibgit2 and then see what it 
> produces.

Fun fact: if you push to a branch on Subsurface-divelog/subsurface (which you 
can, Robert), the CI will build a Windows binary for you. And even for a PR it 
will do that (and the log will show you where on transfer.sh the binary can be 
found.

What I noticed when trying to debug Davide's problem before (the problem that 
on Windows we don't support a proxy with password) is that libgit2 apparently 
is talking directly to winhttp and that that doesn't understand proxy URLs with 
password embedded in them. So clearly Davide is correct and his previous proxy 
settings are somehow retained.

I got side-tracked by all the Travis work and didn't continue to investigate 
this - I had started a branch where I was trying to use the new proxy callback 
feature in libgit2 0.26 to try to work around this issue.

BTW, Davide, are you testing a binary from downloads/testing, or a binary from 
GitHub? Those are slightly different - but both of them should handle settings 
the same way... IIRC I switched the on on GitHub around to no longer link 
against libcurl as clearly that proxy functionality wasn't used on Windows...

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Davide DB
On 15 November 2017 at 11:09, Robert Helling  wrote:

> Hi,
>
> On 15. Nov 2017, at 10:13, Davide DB  wrote:
>
> Cloud storage: successfully checked connection to cloud server
> git storage: fetch remote
> git storage: Successful cloud connection, fetch remote
> *remote fetch failed (Failed to set proxy: Parametro non corretto.*
> )
> git storage: Done syncing with cloud storage
>
>
> I looked for the origin of this error message. “remote fetch failed” is
> Subsurface talking, “failed to set proxy” is libgit2. This only occurs in
> winhttp.c when a call to WinHttpSetOption fails.
>
> So I googled for that call and found
>
> https://msdn.microsoft.com/de-de/library/windows/desktop/
> aa384114(v=vs.85).aspx
>
> Most of this I don’t understand (having touched no windows system for a
> very long time. But my guess that the only thing that could be non-corretto
> would be the proxy url (and that part of the code that has this error
> message is only run when proxy_url is non-NULL). But of course it should be
> empty (and the fact that Subsurface says earlier "delete proxy setting”
> should mean that that parameter got deleted.
>
> So it would be interesting to know what libgit2 thinks should be the proxy
> url.
>
> Unfortunately, I cannot build windows binaries but if anybody can I would
> say it’s worth trying to apply this patch to llibgit2 and then see what it
> produces.
>
>

Hi Robert,

Dirk looked into this weeks ago:

On 3 November 2017 at 17:31, Dirk Hohndel  wrote:

> Preliminary results of this (and some more googling). There appears to be
> an issue with
> libgit2 and authenticated proxies on Windows (and only on Windows) - which
> is why I never
> saw this in my testing. I'm trying to figure out what the correct
> workaround might be
>
> https://github.com/libgit2/libgit2/issues/4069
>
> I no longer have access to the proxy that requires authentication, I'll
> need to build one
> to test, I guess :-)
>
> /D
>
>

AFAIK for the time being is not possible to use a proxy (until someone
correct libgit2).
The problem now is that I get a temporary direct access to internet but I
cannot get rid of the previous proxy settings on my pc.
Maybe the subsurface trace log is not correct because I erased that values
form my registry.

Thanks

Davide
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-15 Thread Davide DB
I found Subsurface network settings saved into Windows registry.

I deleted all value set.

Now my network dialog it's "virgin"


[image: Inline images 1]


Despite of the above settings I still get "wrong parameter" on Proxy and
I'm not able to connect anymore to the cloud. Internet is working.

I give up


C:\Program Files (x86)\Subsurface>ping repubblica.it

Esecuzione di Ping repubblica.it [213.92.16.101] con 32 byte di dati:
Risposta da 213.92.16.101: byte=32 durata=31ms TTL=50
Risposta da 213.92.16.101: byte=32 durata=38ms TTL=50
Risposta da 213.92.16.101: byte=32 durata=41ms TTL=50

Statistiche Ping per 213.92.16.101:
Pacchetti: Trasmessi = 3, Ricevuti = 3,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 31ms, Massimo =  41ms, Medio =  36ms


C:\Program Files (x86)\Subsurface>subsurface.exe -v -v

C:\Program Files (x86)\Subsurface>
Subsurface v4.7.4,
built with libdivecomputer v0.6.0-devel-Subsurface-branch (
7de3a549ee588fef4702ee9d894e390aca43950d)
built with Qt Version 5.9.1, runtime from Qt Version 5.9.1
built with libgit2 0.24.5
Subsurface v4.7.4,
built with libdivecomputer v0.6.0-devel-Subsurface-branch (
7de3a549ee588fef4702ee9d894e390aca43950d)
built with Qt Version 5.9.1, runtime from Qt Version 5.9.1
built with libgit2 0.24.5
validateGL(): created OpenGLContext.
validateGL(): obtained QOpenGLFunctions.
validateGL(): detected OpenGL version 3.3.
Plugins Directory:  QDir( "C:/Program Files (x86)/Subsurface/plugins" ,
nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) ,
QDir::Filters( Dirs|Files|Drives|AllEntries ) )
cloud URL set as "https://cloud.subsurface-divelog.org//git/dbdavide@
gmail.com[dbdav...@gmail.com]"
loading dive data from ("https://cloud.subsurface-divelog.org//git/dbdavide@
gmail.com[dbdav...@gmail.com]")
git_remote_repo: accessing https://cloud.subsurface-
divelog.org//git/dbdav...@gmail.com
git storage: Synchronising data file
git storage: update local repo
sync with remote https://cloud.subsurface-divelog.org//git/dbdavide@
gmail.com[dbdav...@gmail.com]
git storage: Sync with cloud storage
delete proxy setting
Cloud storage: checking connection to cloud server
Checking cloud connection...
Cloud storage: successfully checked connection to cloud server
git storage: fetch remote
git storage: Successful cloud connection, fetch remote
*remote fetch failed (Failed to set proxy: Parametro non corretto.*
)
git storage: Done syncing with cloud storage
git storage: Load dives from local cache
git storage: Successfully opened dive data
Set the current dive site: 0

File locations:

cloud URL set as "https://cloud.subsurface-divelog.org//git/dbdavide@
gmail.com[dbdav...@gmail.com]"
Local git storage: C:\Users\ddebenedictis\AppData\Roaming\Subsurface/
cloudstorage/29fc20f013e9f1fb
Cloud URL: https://cloud.subsurface-divelog.org//git/dbdavide@
gmail.com[dbdav...@gmail.com]
Image hashes: C:\Users\ddebenedictis\AppData\Roaming\Subsurface/hashes
Local picture directory: C:\Users\ddebenedictis\AppData\Roaming\Subsurface/
picturedata/

Set the current dive site: 0
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-14 Thread Davide DB
On 14 November 2017 at 18:53, Lubomir I. Ivanov  wrote:
> On 14 November 2017 at 19:47, Davide DB  wrote:
>> Log files are empty. This is what I get from command line:
>>
>> C:\Program Files (x86)\Subsurface>subsurface.exe -v
>>
>
> the Subsurface desktop shortcut does not have the -v option by default.
> you can add the "-v" there and the verbose output will be fed into the
> log files.
> without it, they would indeed be mostly empty.
>
> lubomir

Even with the -v option those two files remain empty.
Actually only subsurface_out.log is being populated with a newline char 0x0D0A.

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-14 Thread Lubomir I. Ivanov
On 14 November 2017 at 19:47, Davide DB  wrote:
> Log files are empty. This is what I get from command line:
>
> C:\Program Files (x86)\Subsurface>subsurface.exe -v
>

the Subsurface desktop shortcut does not have the -v option by default.
you can add the "-v" there and the verbose output will be fed into the
log files.
without it, they would indeed be mostly empty.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-14 Thread Davide DB
Log files are empty. This is what I get from command line:

C:\Program Files (x86)\Subsurface>subsurface.exe -v

C:\Program Files (x86)\Subsurface>
Subsurface v4.7.4,
built with libdivecomputer v0.6.0-devel-Subsurface-branch
(7de3a549ee588fef4702ee9d894e390aca43950d)
built with Qt Version 5.9.1, runtime from Qt Version 5.9.1
built with libgit2 0.24.5
validateGL(): created OpenGLContext.
validateGL(): obtained QOpenGLFunctions.
validateGL(): detected OpenGL version 3.3.
Plugins Directory:  QDir( "C:/Program Files (x86)/Subsurface/plugins"
, nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) ,
QDir::Filters( Dirs|Files|Drives|AllEntries ) )
cloud URL set as
"https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com];
loading dive data from
("https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com];)
git storage: Synchronising data file
git storage: update local repo
sync with remote
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
git storage: Sync with cloud storage
delete proxy setting
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
remote fetch failed (Failed to set proxy: Parametro non corretto.
)
git storage: Done syncing with cloud storage
git storage: Load dives from local cache
git storage: Successfully opened dive data
Set the current dive site: 0

File locations:

cloud URL set as
"https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com];
Local git storage:
C:\Users\davide\AppData\Roaming\Subsurface/cloudstorage/29fc20f013e9f1fb
Cloud URL: 
https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
Image hashes: C:\Users\davide\AppData\Roaming\Subsurface/hashes
Local picture directory: C:\Users\davide\AppData\Roaming\Subsurface/picturedata/
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-14 Thread Davide DB
On 14 November 2017 at 18:17, Davide DB  wrote:
> On 14 November 2017 at 18:11, Davide DB  wrote:
>> Hi all,
>>
>> I connected without proxy via my mobile phone.
>> I set "No proxy" on preference dialog. I saved and restarted
>> Subsurface several times.
>> No way to connect to the cloud. The UI is plain wrong because it says
>> successfull connection but no dives are displayed.
>>
>> Starting Subsurface with -v I see from the cmd window that it still
>> using the proxy getting the the infamous "incorrect parameter" error.
>>
>> Where are those preference saved? How I can delete them?
>>
>> Thank you in advance
>
> Found it:
>
> C:\Users\davide\AppData\Local\Subsurface\Subsurface\cache\qmlcache
>
> Once deleted two .qmlc files it works.
>
> I guess it's a bug. Once you set a proxy, it continue to use it even
> if you set "No proxy".

I was wrong.
I messed with preferences and it loaded an old xml file.

I deleted everything in

C:\Users\davide\AppData\Local\Subsurface\Subsurface\cache
C:\Users\davide\AppData\Roaming\Subsurface\Subsurface

My preferences are depitched here and despite of proxy settings are grayed
out they are still there...

[image: Inline images 3]


>From the log I still get proxy "incorrect parameter"

Where are stored proxy settings?

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-14 Thread Davide DB
On 14 November 2017 at 18:11, Davide DB  wrote:
> Hi all,
>
> I connected without proxy via my mobile phone.
> I set "No proxy" on preference dialog. I saved and restarted
> Subsurface several times.
> No way to connect to the cloud. The UI is plain wrong because it says
> successfull connection but no dives are displayed.
>
> Starting Subsurface with -v I see from the cmd window that it still
> using the proxy getting the the infamous "incorrect parameter" error.
>
> Where are those preference saved? How I can delete them?
>
> Thank you in advance

Found it:

C:\Users\davide\AppData\Local\Subsurface\Subsurface\cache\qmlcache

Once deleted two .qmlc files it works.

I guess it's a bug. Once you set a proxy, it continue to use it even
if you set "No proxy".


-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-14 Thread Davide DB
Hi all,

I connected without proxy via my mobile phone.
I set "No proxy" on preference dialog. I saved and restarted
Subsurface several times.
No way to connect to the cloud. The UI is plain wrong because it says
successfull connection but no dives are displayed.

Starting Subsurface with -v I see from the cmd window that it still
using the proxy getting the the infamous "incorrect parameter" error.

Where are those preference saved? How I can delete them?

Thank you in advance
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-03 Thread Davide DB
On 3 November 2017 at 17:31, Dirk Hohndel  wrote:

> Preliminary results of this (and some more googling). There appears to be
> an issue with
> libgit2 and authenticated proxies on Windows (and only on Windows) - which
> is why I never
> saw this in my testing. I'm trying to figure out what the correct
> workaround might be
>
> https://github.com/libgit2/libgit2/issues/4069
>
> I no longer have access to the proxy that requires authentication, I'll
> need to build one
> to test, I guess :-)
>
> /D
>

Thanks to look into this.

I could do more tests from Monday



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-03 Thread Dirk Hohndel

> On Nov 2, 2017, at 10:04 AM, Davide DB  wrote:
>> 
>> git storage: Synchronising data file
>> git storage: create_local_repo
>> Cloud storage: checking connection to cloud server
>> Checking cloud connection...
>> git storage: Waiting for cloud connection (1 second(s) passed)
>> git storage: Waiting for cloud connection (2 second(s) passed)
>> git storage: Waiting for cloud connection (3 second(s) passed)
>> set proxy to "http://someuser:somepassw...@proxydomain.domain.it:8080 
>> "
>> error message was Failed to set proxy: Parametro non corretto.
> 
> OK, so I never tested having a password encoded in the proxy URL.
> I'm guessing that we don't unpack that correctly. This gives me more code to 
> stare at.

Preliminary results of this (and some more googling). There appears to be an 
issue with
libgit2 and authenticated proxies on Windows (and only on Windows) - which is 
why I never
saw this in my testing. I'm trying to figure out what the correct workaround 
might be

https://github.com/libgit2/libgit2/issues/4069 


I no longer have access to the proxy that requires authentication, I'll need to 
build one
to test, I guess :-)

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-02 Thread Davide DB
Il 02 nov 2017 5:11 PM, "Dirk Hohndel"  ha scritto:

Hi Davide,


When I manually access cloud via UI I get:


What exactly does that mean? Do you mean you are clicking on File->Open
cloud storage (Apri memoria cloud)?



Yes



git storage: Synchronising data file
git storage: create_local_repo
Cloud storage: checking connection to cloud server
Checking cloud connection...
git storage: Waiting for cloud connection (1 second(s) passed)
git storage: Waiting for cloud connection (2 second(s) passed)
git storage: Waiting for cloud connection (3 second(s) passed)
set proxy to "http://someuser:somepassw...@proxydomain.domain.it:8080;
error message was Failed to set proxy: Parametro non corretto.


OK, so I never tested having a password encoded in the proxy URL.
I'm guessing that we don't unpack that correctly. This gives me more code
to stare at.

/D


Thanks
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Problem accessing cloud behind a proxy

2017-11-02 Thread Dirk Hohndel
Hi Davide,

> On Nov 2, 2017, at 1:36 AM, Davide DB  wrote:
> 
> 
> File locations:
> 
> cloud URL set as 
> "https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
>  
> "
> Local git storage: 
> C:\Users\someuser\AppData\Roaming\Subsurface/cloudstorage/29fc20f013e9f1fb
> Cloud URL: 
> https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
>  
> 
> Image hashes: C:\Users\someuser\AppData\Roaming\Subsurface/hashes
> Local picture directory: 
> C:\Users\someuser\AppData\Roaming\Subsurface/picturedata/
> 
> build with Qt Version 5.9.1, runtime from Qt Version 5.9.1
> subsurface.facebook: Current url call 
> QUrl("https://www.facebook.com/login.php?skip_api_login=1_key=427722490709000_next=1=https%3A%2F%2Fwww.facebook.com%2Fv2.5%2Fdialog%2Fo
>  
> 
> F%2Fwww.facebook.com 
> %2Fconnect%2Flogin_success.html%3Ferror%3Daccess_denied%26error_code%3D200%26error_description%3DPermissions%2Berror%26error_reason%3Duser_denied%23_%3D_=popup
> subsurface.facebook: Response without access token!
> QNetworkReplyImplPrivate::error: Internal problem, this method must only be 
> called once.
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://someu...@proxy.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://proxydomain.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://someu...@proxydomain.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://proxydomain.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://someu...@proxydomain.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://proxydomain.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://someu...@proxydomain.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://proxydomain.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://someu...@proxydomain.domain.it:8080 
> '
> QNetworkAccessCache::addEntry: overriding active cache entry 
> 'auth:proxy-http://proxydomain.domain.it:8080' 
> 
> 
> When I manually access cloud via UI I get:

What exactly does that mean? Do you mean you are clicking on File->Open cloud 
storage (Apri memoria cloud)? 

> cloud URL set as 
> "https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
>  
> "
> Opening cloud storage from: 
> "https://cloud.subsurface-divelog.org//git/dbdav...@gmail.com[dbdav...@gmail.com]
>  
> "
> Set the current dive site: 0
> git storage: Synchronising data file
> git storage: create_local_repo
> Cloud storage: checking connection to cloud server
> Checking cloud connection...
> git storage: Waiting for cloud connection (1 second(s) passed)
> git storage: Waiting for cloud connection (2 second(s) passed)
> git storage: Waiting for cloud connection (3 second(s) passed)
> set proxy to "http://someuser:somepassw...@proxydomain.domain.it:8080 
> "
> error message was Failed to set proxy: Parametro non corretto.

OK, so I never tested having a password encoded in the proxy URL.
I'm guessing that we don't unpack that correctly. This gives me more code to 
stare at.

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface