svn: E170001: Unable to connect to a repository at URL svn://

[Jeff Kowalczyk]

On one system running ~amd64 Gentoo Linux, all svn:// repository URLs return
svn: E170001. I have tested repositories on multiple hosts e.g. Gentoo Overlay,
Zope, etc. to rule out auth issues with a specific server. My other Gentoo
~amd64 systems work fine with svn:// urls.

What dependency of subversion would be involved with svn:// URLs only, such that
a problem with that dependency would not affect subversion's ability to
interface with http(s):// urls?

I have rebuilt subversion, cyrus-sasl and neon. Current versions are:

dev-vcs/subversion-1.7.1
dev-libs/cyrus-sasl-2.1.25
net-libs/neon-0.29.6

Thanks,
Jeff

[Stefan Sperling]

E170001 means SVN_ERR_RA_NOT_AUTHORIZED.
This sounds some problem with your cyrus-sasl package.
Reminds me of this: http://marc.info/?l=openbsd-ports&m=131805779110751&w=2

[Daniel Shahaf]

Jeff Kowalczyk wrote on Mon, Dec 12, 2011 at 19:28:59 +0000:
> What dependency of subversion would be involved with svn:// URLs only, such that
> a problem with that dependency would not affect subversion's ability to
> interface with http(s):// urls?

cyrus-sasl

(which is an optional dependency, not a mandatory/required one)

[Jeff Kowalczyk]

Stefan Sperling <stsp <at> elego.de> writes:
> >
> > What dependency of subversion would be involved with svn:// URLs only,
> > such that
> > a problem with that dependency would not affect subversion's ability to
> > interface with http(s):// urls?
> >
> > I have rebuilt subversion, cyrus-sasl and neon. Current versions are:
> >
> > dev-vcs/subversion-1.7.1
> > dev-libs/cyrus-sasl-2.1.25
> > net-libs/neon-0.29.6
>
> E170001 means SVN_ERR_RA_NOT_AUTHORIZED.
> This sounds some problem with your cyrus-sasl package.
> Reminds me of this: http://marc.info/?l=openbsd-ports&m=131805779110751&w=2

Thanks for the suggestion. I just now rebuild cyrus-sasl and subversion in that
order. No change in behavior.

Jeff

[Stefan Sperling]

Well, I don't know if the temporary error (missing .la files) that slipped
into the OpenBSD package is also present in gentoo.

Just recompiling things won't magically fix anything.
You'll need to figure out if the gentoo sasl packages is broken or not.
Do other applications that use sasl work fine?

[Daniel Shahaf]

Do you use sasl authentication? If not, try building svn without sasl.

[Brenden Walker]

Just thought I'd chime in here as I'm on Gentoo and working fine. Just did an emerge --sync and double checked my update status.

subversion-1.6.17-r78
cyrus-sasl-2.1.23-r4
neon-0.29.6

Those are the latest stable packages on x86 and amd64.

I'm compiled with the following use flags enabled: apache2 berkdb dso extras gnome-keyring sasl webdav-neon

[Jeff Kowalczyk]

Brenden Walker <BKWalker <at> drbsystems.com> writes:
> Just thought I'd chime in here as I'm on Gentoo and working fine.
> Just did an emerge --sync and double checked my update status.
>
> subversion-1.6.17-r78
> cyrus-sasl-2.1.23-r4
> neon-0.29.6
>
> Those are the latest stable packages on x86 and amd64.
>
> I'm compiled with the following use flags enabled:
> apache2 berkdb dso extras gnome-keyring sasl webdav-neon

Thanks everyone for the help.

Like Branden, I have four other Gentoo ~amd64 boxes with subversion use flag
sasl, and they work fine. This laptop has always worked fine too, until about
2011-12-05.

Gentoo currently removes .la files, IIUC, after the source compilation stage. I
ran the deprecated tool to find and remove them, just in case. No .la files were
found from any package.

$ sudo lafilefixer --justfixit
...
/usr/lib64/libsasl2.la already clean, skipping update.
...

The subversion and cyrus-sasl packages are built with the following use flags.
(-sasl configured just now)

dev-libs/cyrus-sasl-2.1.25 USE="gdbm mysql pam postgres
sqlite ssl -authdaemond -berkdb -java -kerberos -ldapdb
-openldap -sample -srp -static-libs -urandom"

dev-vcs/subversion-1.7.1 USE="apache2 bash-completion nls
perl python webdav-neon
-berkdb -ctypes-python -debug -doc -dso -extras -gnome-keyring
-java -kde -ruby -sasl -vim-syntax -webdav-serf"

I am now able to access svn:// urls, so the local problem is masked, although
not fully understood. I'd like to follow it to the cause so I can file a Gentoo
bug if needed.

Are there any files under etc/ or ~/.subversion that might influence
subversion's protocol to access to svn:// urls? I had previously cleared out
~/.subversion/auth FWIW. I'm grasping for something that might be different on
this machine than the others.

Thanks,
Jeff

[Daniel Shahaf]

Jeff Kowalczyk wrote on Mon, Dec 12, 2011 at 20:59:00 +0000:
> I am now able to access svn:// urls, so the local problem is masked, although
> not fully understood. I'd like to follow it to the cause so I can file a Gentoo
> bug if needed.
>

Can you eavesdrop the svn:// protocol handshake and see which
authentication methods are being (a) offered by the server, (b) used?

Protocol docs in in subversion/libsvn_ra_svn/protocol.

> Are there any files under etc/ or ~/.subversion that might influence
> subversion's protocol to access to svn:// urls? I had previously cleared out
> ~/.subversion/auth FWIW. I'm grasping for something that might be different on
> this machine than the others.
>

Does libsasl have any client-side config files?

> Thanks,
> Jeff
>

[Jeff Kowalczyk]

I will see if I can get wireshark to isolate that traffic.

Re: config files, are those under /etc what you were asking about?

$ sudo equery files cyrus-sasl |grep "/etc"
/etc
/etc/conf.d
/etc/conf.d/saslauthd
/etc/init.d
/etc/init.d/pwcheck
/etc/init.d/saslauthd
/etc/pam.d
/etc/pam.d/saslauthd
/etc/sasl2
/etc/sasl2/.keep_dev-libs_cyrus-sasl-2

Thanks,
Jeff

[Daniel Shahaf]

Jeff Kowalczyk wrote on Mon, Dec 12, 2011 at 22:03:15 +0000:
> Daniel Shahaf <d.s <at> daniel.shahaf.name> writes:
> > Jeff Kowalczyk wrote on Mon, Dec 12, 2011 at 20:59:00 +0000:
> > > I am now able to access svn:// urls, so the local problem is
> > > masked, although not fully understood. I'd like to follow it to
> > > the cause so I can file a Gentoo bug if needed.
> > >
> >
> > Can you eavesdrop the svn:// protocol handshake and see which
> > authentication methods are being (a) offered by the server, (b)
> > used?
> >
> > Protocol docs in in subversion/libsvn_ra_svn/protocol.
> >
> > > Are there any files under etc/ or ~/.subversion that might
> > > influence subversion's protocol to access to svn:// urls? I had
> > > previously cleared out ~/.subversion/auth FWIW. I'm grasping for
> > > something that might be different on this machine than the others.
> >
> > Does libsasl have any client-side config files?
>
> I will see if I can get wireshark to isolate that traffic.
>
> Re: config files, are those under /etc what you were asking about?
>

Those don't seem to be "client-side" config files --- except perhaps for
the contents of /etc/sasl2 (if any).