- Package:
- libsvn1
- Source:
- subversion
- Description:
- Shared libraries used by Apache Subversion
- Submitter:
- Josef Spillner
- Date:
- 2011-12-16 12:57:22 UTC
- Severity:
- minor
I've cloned and modified a SVN repository (svn+ssh://...), all works fine. But I cannot commit back my changes with git-svn dcommit. The error message looks like that after the password query: Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/SVN/Core.pm line 579. Authorization failed: at /usr/bin/git-svn line 3273 In the affected line it tries to call get_commit_editor, effectively in line 3083: $self->SUPER::get_commit_editor($log, $cb, @lock, $pool); The concatenation is probably hidden in the Perl bindings to SVN somewhere. Using Perl 5.10.0.
tags 486527 + moreinfo quit Hi, can you please add instructions on how to reproduce the issue by pasting the commands you run?, or can you check with the 1.6.0.x version from experimental whether it's been fixed upstream in the meantime? Thanks, Gerrit.
Am Freitag 03 Oktober 2008 16:33:09 schrieb Gerrit Pape: I've tried to debug it further, and it looks like a combination of 1) PEBKAC, 2) non-cautious Perl programming and 3) not very useful SVN error messages. 1) The authorisation error was due to the line auth-access = read instead of the default auth-access = write in svnserve.conf. So not being able to commit was correct in that case. 2) Nevertheless something like the attached patch should be committed to git-svn to let it handle errors without descriptions. 3) SVN should be improved to tell why authorisation failed. During my tests I've also tried git-svn from experimental. Just a note that the binary is located in /usr/lib/git-core. This is surely not intended? Josef
Hi Josef, Josef Spillner wrote, two years ago: Can you still reproduce this? I tried first with file:/// and was able to write, then with svn+ssh and received Authorization failed: Authorization failed at /usr/lib/git-core/git-svn line 4416 The underlying problem seems to be that in some circumstance libsvn was/is returning an svn_error_t with message equal to NULL. So it would be nice to track it down.
tags 486527 + unreproducible quit Hi again, Josef Spillner wrote: Ping? I'd still be very interested in a reproduction recipe. Marking unreproducible so heroes of bug reproduction know their work would be appreciated. :)
I hit this problem (I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422699 first, then this bug). Here's how I reproduced: Setup an account on a remote system with /bin/false as a login shell: remote# useradd -s /bin/false blah remote# passwd blah ... Try something that tickles the SVN/Core.pm code from the local system: local# git svn init -Ttrunk svn+ssh://blah@remote/junk ...
tags 486527 - moreinfo unreproducible found 486527 git/1:1.7.2.3-2 quit Quentin Neill wrote: Nice! Yes, I can reproduce this. Jonathan libsvn-perl version: 1.6.12dfsg-2
severity 486527 minor
retitle 486527 SVN::Ra::new: colon instead of period in message for tunnel connection problems
reassign 486527 libsvn1 1.6.17dfsg-3
quit
Hi,
Thanks again for the reproduction recipe. With libsvn-perl
1.6.17dfsg-3:
$ git svn init -Ttrunk svn+ssh://blah@localhost/junk
blah@localhost's password:
Network connection closed unexpectedly: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. at /usr/lib/git-core/git-svn line 2299
So the cause (svn_error_t with NULL message) is still present and
still produces a weird symptom. This time the symptom is less severe
than before: a goofy error message with colon promising explanation
and no delivery. So the fix to bug#422699 indeed improved things.
The svn_error_t comes from subversion/libsvn_ra_svn/marshal.c, in
readbuf_input():
SVN_ERR(svn_ra_svn__stream_read(conn->stream, data, len));
if (*len == 0)
return svn_error_create(SVN_ERR_RA_SVN_CONNECTION_CLOSED, NULL, NULL);
This regression seems to have come about in r870846. I'm not familiar
enough with libsvn to say if libsvn should be putting a message in the
svn_error_t object or the bindings should use a period instead of a
colon when the message is not present.
Hope that helps,
Jonathan