It is definitely gnutls.
I tried to access same https/webdav url using curl (compiled with
gnutls) and had same problems. After recompiling without gnutls
everything worked just fine.
It is not necessarily error in gnutls - it may be just that interface
is different to that used by openssl.
It
Hi,
Using neon backend, it fails with exactly with the same scenario as before
(repeatly ask me the ssl certificate path).
Using libserf (0.2.0-1) backend, it fails with this error:
svn: Error running context: Appel système interrompu
Appel système interrompu=Interrupted system call
Simon
Le
Can you test using the Debian package (v1.5) from experimental? [1]
Not easily, sorry. I am running Ubuntu Hardy (8.04) and the package for
Debian Experimental requires so many new depends that it breaks my
system (I tried this before the ubuntu package came out).
Technically the Ubuntu package
On 6/26/08, Seamus Allan [EMAIL PROTECTED] wrote:
I am using an Ubuntu package which has been created from the Intrepid
Subversion 1.5.0 package.
Can you test using the Debian package (v1.5) from experimental? [1]
Thanks
[1] http://packages.debian.org/source/experimental/subversion
Hi, I thought I'd drop a line to say that I am having similar issues
(cf svn: OPTIONS of 'https://foo.ru/bar': Could not read status line:
SSL
error: Rehandshake was requested by the peer. (https://foo.ru) )
I am using an Ubuntu package which has been created from the Intrepid
Subversion
On Wed, Jun 25, 2008 at 4:42 AM, Peter Samuelson [EMAIL PROTECTED] wrote:
[Dmitry Kurochkin]
Actually, error with serf backend is not the same:
svn update
svn: Error running context: Internal error
I hate to ask yet another round-trip of testing, but serf 0.2.0 was
recently uploaded to
Could you gentlemen test subversion 1.5.0dfsg1-1 from experimental to
see if the SSL client certificate problems remain? I suspect these are
neon and/or gnutls problems, but Subversion 1.4.x did not officially
support neon 0.28, so 1.5.0 may be better.
Thanks.
--
Peter Samuelson |
[Peter Samuelson]
Could you gentlemen test subversion 1.5.0dfsg1-1 from experimental to
see if the SSL client certificate problems remain?
Also, if you're testing 1.5.0 anyway, could you also test the serf
backend? In ~/.subversion/servers, in the [global] section:
http-library = serf
Hi.
On Tue, Jun 24, 2008 at 11:35 PM, Peter Samuelson [EMAIL PROTECTED] wrote:
[Peter Samuelson]
Could you gentlemen test subversion 1.5.0dfsg1-1 from experimental to
see if the SSL client certificate problems remain?
Also, if you're testing 1.5.0 anyway, could you also test the serf
On Tue, Jun 24, 2008 at 11:42 PM, Dmitry Kurochkin
[EMAIL PROTECTED] wrote:
It still fails. But with a new error:
svn update
svn: OPTIONS of 'https://foo.ru/bar': Could not read status line: SSL
error: Rehandshake was requested by the peer. (https://foo.ru)
Serf backend does not help, same
[Dmitry Kurochkin]
Actually, error with serf backend is not the same:
svn update
svn: Error running context: Internal error
I hate to ask yet another round-trip of testing, but serf 0.2.0 was
recently uploaded to unstable. If you are still using serf 0.1.2,
could you upgrade and try
Hello,
Here is some more information:
I downgraded subversion and libsvn1 to 1.4.2dfsg1-2 (this is the version
availaible in debian-stable), and installed libneon26 and libneon26-gnutls
(required by the 1.4.2dfsg1-2), and everything works well now.
It is probable that the bug is not in
Hi!
Latest subversion/1.4.6dfsg1-4 breaks ssl for me too. But in another way:
svn update
svn: PROPFIND request failed on '/svn/foobar'
svn: PROPFIND of '/svn/foobar': Could not read status line: SSL error:
Rehandshake was requested by the peer. (https://example.com)
I have downgraded to
Laszlo, can you take a look at bug #480041? libneon27-gnutls fails to
access a subversion repository hosted on sarge with backports, where
libneon26 worked. I've asked the reporter to try libneon27 (openssl).
Thanks,
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To
[Oleksandr Moskalenko]
Current subversion linked against libneon27-gnutls fails to nogotiate
a certificate with an apache2 server when accessing a https/webdav
svn repository.
Thank you for the detailed bug report. I have two questions.
- You mention cadaver which also uses
15 matches
Mail list logo
