You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jonathan Nieder <jr...@gmail.com> on 2011/11/03 08:54:04 UTC
auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of 5
providers)
Hi,
Building r1196980:
svn export ~/src/subversion svn-test
cd svn-test
./autogen.sh
mkdir BUILD
cd BUILD
PYTHON=python RUBY=ruby \
../configure --prefix=$HOME/opt/subversion \
--mandir=\$${prefix}/share/man \
--with-apr=/usr \
--with-apr-util=/usr \
--with-neon=/usr \
--with-serf=/usr \
--with-berkeley-db=:::db \
--with-sasl=/usr \
--with-editor=editor \
--with-ruby-sitedir=/usr/lib/ruby \
--with-swig=/usr \
--with-kwallet --with-gnome-keyring \
--enable-javahl --without-jikes \
--with-jdk=/usr/lib/jvm/default-java \
--with-junit=/usr/share/java/junit.jar \
--with-apxs=/usr/bin/apxs2 --disable-mod-activation
make check
I get the following result:
Running tests in auth-test [1/89].............................FAILURE
Running tests in cache-test [2/89]............................success
[... lots of successes snipped ...]
The failure is described in tests.log:
START: auth-test
svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
END: auth-test
ELAPSED: auth-test 0:00:00.179133
Indeed, instrumenting the test, we learn that the actual number of
providers returned is 1.
Known problem?
Jonathan
The ancient libtool issue
Posted by Jonathan Nieder <jr...@gmail.com>.
Daniel Shahaf wrote:
> http://bugs.debian.org/291641
>
> Note that it's specific to Debian, i.e., it isn't present in upstream libtool.
Thanks, that's useful. Excitingly enough, Philip's test case
passes for me!
That's because I use gold, which uses --no-copy-dt-needed-entries
by default. If I uninstall binutils-gold (so ld.bfd gets used
instead), the test case fails.
Jonathan
$ dpkg-query -W binutils libtool
binutils 2.21.90.20111025-1
libtool 2.4.2-1
Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of
5 providers)
Posted by Daniel Shahaf <da...@elego.de>.
Jonathan Nieder wrote on Sun, Nov 13, 2011 at 10:32:44 -0600:
> Daniel Shahaf wrote:
>
> > Why won't the loader look for them in the right place?
> >
> > Is this the ancient Debian libtool issue, or something else?
>
> Could you give a pointer or summary for the ancient Debian libtool
> issue? I ask because in the past I've filed bugs against libtool and
> it seems to have a reasonable maintenance team that can fix things
> (and because I'm always a bit of a skeptic ;-)).
>
http://bugs.debian.org/291641
Note that it's specific to Debian, i.e., it isn't present in upstream libtool.
Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of 5
providers)
Posted by Jonathan Nieder <jr...@gmail.com>.
Daniel Shahaf wrote:
> Why won't the loader look for them in the right place?
>
> Is this the ancient Debian libtool issue, or something else?
Could you give a pointer or summary for the ancient Debian libtool
issue? I ask because in the past I've filed bugs against libtool and
it seems to have a reasonable maintenance team that can fix things
(and because I'm always a bit of a skeptic ;-)).
For the case at hand: libtool never gets told that the auth-test wants
to load auth providers because they are loaded using dlopen(), not
ordinary library linkage. So libtool can avoid blame for this
particular problem.
Thanks,
Jonathan
Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of 5
providers)
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Nov 13, 2011 at 06:14:57PM +0200, Daniel Shahaf wrote:
> Philip Martin wrote on Thu, Nov 03, 2011 at 10:55:49 +0000:
> > Yes. The kwallet and gnome keyring providers are loaded dynamically and
> > the loader will not look for providers in the right place.
>
> Why won't the loader look for them in the right place?
dlopen() accepts either an absolute pathname or the basename
of a shared library. In the latter case, the library is searched
in the standard library search path, and in dirs in LD_LIBRARY_PATH.
If we specified an absolute path we'd have to compile the abspath
of the working copy containing the shared libs into the binaries
to run tests. And re-compile with a different abspath during 'make install'.
It would also prevent moving an existing SVN installation to a different
prefix without recompilation. This could cause problems for packagers.
Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of
5 providers)
Posted by Daniel Shahaf <da...@elego.de>.
Philip Martin wrote on Mon, Nov 14, 2011 at 08:59:46 +0000:
> Daniel Shahaf <da...@elego.de> writes:
>
> > Philip Martin wrote on Thu, Nov 03, 2011 at 10:55:49 +0000:
> >> Jonathan Nieder <jr...@gmail.com> writes:
> >>
> >> > The failure is described in tests.log:
> >> >
> >> > START: auth-test
> >> > svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
> >> > FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
> >> > END: auth-test
> >> > ELAPSED: auth-test 0:00:00.179133
> >> >
> >> > Indeed, instrumenting the test, we learn that the actual number of
> >> > providers returned is 1.
> >> >
> >> > Known problem?
> >>
> >> Yes. The kwallet and gnome keyring providers are loaded dynamically and
> >> the loader will not look for providers in the right place.
> >
> > Why won't the loader look for them in the right place?
> >
> > Is this the ancient Debian libtool issue, or something else?
> >
> > Asking because fixing the loader seems to be a more correct solution
> > than fixing EVERYONE who runs the auth-test binary to set LD_LIBRARY_PATH
> > first.
>
> What sort of fix to the loader? The installed code cannot load dynamic
> libraries from the build dir, that would be a security issue. So that
> means the test code cannot load from the build dir by default either,
> unless we do some sort of recompilation on install. The only way for
> the test code to load modules from the build dir is to use
> LD_LIBRARY_PATH or LD_PRELOAD.
Short of recompile-at-install, would it make sense to getenv() at
auth-test.c:main() and do a sanity check on $LD_LIBRARY_PATH and
$LD_PRELOAD? That way, at least, callers that forget to set those env
vars will not accidentally load the wrong shared libs.
Re: auth-test fails (E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers)
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <da...@elego.de> writes:
> Philip Martin wrote on Thu, Nov 03, 2011 at 10:55:49 +0000:
>> Jonathan Nieder <jr...@gmail.com> writes:
>>
>> > The failure is described in tests.log:
>> >
>> > START: auth-test
>> > svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
>> > FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
>> > END: auth-test
>> > ELAPSED: auth-test 0:00:00.179133
>> >
>> > Indeed, instrumenting the test, we learn that the actual number of
>> > providers returned is 1.
>> >
>> > Known problem?
>>
>> Yes. The kwallet and gnome keyring providers are loaded dynamically and
>> the loader will not look for providers in the right place.
>
> Why won't the loader look for them in the right place?
>
> Is this the ancient Debian libtool issue, or something else?
>
> Asking because fixing the loader seems to be a more correct solution
> than fixing EVERYONE who runs the auth-test binary to set LD_LIBRARY_PATH
> first.
What sort of fix to the loader? The installed code cannot load dynamic
libraries from the build dir, that would be a security issue. So that
means the test code cannot load from the build dir by default either,
unless we do some sort of recompilation on install. The only way for
the test code to load modules from the build dir is to use
LD_LIBRARY_PATH or LD_PRELOAD.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of
5 providers)
Posted by Daniel Shahaf <da...@elego.de>.
Philip Martin wrote on Thu, Nov 03, 2011 at 10:55:49 +0000:
> Jonathan Nieder <jr...@gmail.com> writes:
>
> > The failure is described in tests.log:
> >
> > START: auth-test
> > svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
> > FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
> > END: auth-test
> > ELAPSED: auth-test 0:00:00.179133
> >
> > Indeed, instrumenting the test, we learn that the actual number of
> > providers returned is 1.
> >
> > Known problem?
>
> Yes. The kwallet and gnome keyring providers are loaded dynamically and
> the loader will not look for providers in the right place.
Why won't the loader look for them in the right place?
Is this the ancient Debian libtool issue, or something else?
Asking because fixing the loader seems to be a more correct solution
than fixing EVERYONE who runs the auth-test binary to set LD_LIBRARY_PATH
first.
(Consider people who run it outside of 'make check' --- 'cd sth &&
./auth-test 5')
Thanks,
Daniel
Re: auth-test fails (E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers)
Posted by Philip Martin <ph...@wandisco.com>.
Jonathan Nieder <jr...@gmail.com> writes:
> The failure is described in tests.log:
>
> START: auth-test
> svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
> FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
> END: auth-test
> ELAPSED: auth-test 0:00:00.179133
>
> Indeed, instrumenting the test, we learn that the actual number of
> providers returned is 1.
>
> Known problem?
Yes. The kwallet and gnome keyring providers are loaded dynamically and
the loader will not look for providers in the right place. There are
several ways to get the test to PASS:
- If you install in the final destination before running the tests then
the providers will be loaded from the install dir.
- If you add --enable-local-library-preloading the libtool files will be
edited to preload the providers. We have had some problems in the
past with this editing breaking the scripts.
- Or you can set LD_PRELOAD yourself.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: auth-test fails (E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers)
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Shahaf wrote:
> Jonathan Nieder wrote:
> > svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
> > FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
> >
> > Indeed, instrumenting the test, we learn that the actual number of
> > providers returned is 1.
> >
> > Known problem?
>
> Buildbots are green and I don't remember this one
> before. Can you set a breakpoint in the test and check
> which four providers aren't returned?
> (Or, if that's easier, which one provider _is_ returned.)
I get this too when I run "make davautocheck" but not with "make check" or "make svnserveautocheck". The "svn.simple" provider is the only one returned.
I build and test in a separate directory from the source tree. I build with Gnome-keyring support.
Before running the tests, I set LD_LIBRARY_PATH="$OBJ_DIR/subversion/libsvn_auth_gnome_keyring/.libs". But when "auth-test" gets run, it find that LD_LIBRARY_PATH is set to
"<OBJ_DIR>/subversion/libsvn_ra_neon/.libs:
<OBJ_DIR>/subversion/libsvn_ra_local/.libs:
<OBJ_DIR>/subversion/libsvn_ra_svn/.libs"
Lo! and behold: svnserveautocheck.sh sets LD_LIBRARY_PATH="...:$LD_LIBRARY_PATH" whereas davautocheck.sh (and dav-mirror-autocheck.sh) overwrites the old value.
Blame... me. I inserted the ":$LD_LIBRARY_PATH" to svnserveautocheck.sh back in 2009, and I failed to spot the same thing being needed in these other places.
Thanks for the report.
Fixed in r1197065.
- Julian
Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array
of 5 providers)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Thursday, November 03, 2011 2:54 AM, "Jonathan Nieder" <jr...@gmail.com> wrote:
> Hi,
>
> Building r1196980:
>
> svn export ~/src/subversion svn-test
> cd svn-test
> ./autogen.sh
> mkdir BUILD
> cd BUILD
> PYTHON=python RUBY=ruby \
> ../configure --prefix=$HOME/opt/subversion \
> --mandir=\$${prefix}/share/man \
> --with-apr=/usr \
> --with-apr-util=/usr \
> --with-neon=/usr \
> --with-serf=/usr \
> --with-berkeley-db=:::db \
That works? We should mention it in the help output...
> --with-sasl=/usr \
> --with-editor=editor \
> --with-ruby-sitedir=/usr/lib/ruby \
> --with-swig=/usr \
> --with-kwallet --with-gnome-keyring \
> --enable-javahl --without-jikes \
> --with-jdk=/usr/lib/jvm/default-java \
> --with-junit=/usr/share/java/junit.jar \
> --with-apxs=/usr/bin/apxs2 --disable-mod-activation
> make check
>
> I get the following result:
>
> Running tests in auth-test [1/89].............................FAILURE
> Running tests in cache-test [2/89]............................success
> [... lots of successes snipped ...]
>
> The failure is described in tests.log:
>
> START: auth-test
> svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
> FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
> END: auth-test
> ELAPSED: auth-test 0:00:00.179133
>
> Indeed, instrumenting the test, we learn that the actual number of
> providers returned is 1.
>
> Known problem?
>
Buildbots are green and I don't remember this one before. Can you set a
breakpoint in the test and check which four providers aren't returned?
(Or, if that's easier, which one provider _is_ returned.)
> Jonathan
>
Re: [RFC/PATCH] Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of 5
providers)
Posted by Jonathan Nieder <jr...@gmail.com>.
Philip Martin wrote:
> I committed this, with a small tweak to move where the variables are
> set.
Thanks, Philip. I like the tweak.
Re: [RFC/PATCH] Re: auth-test fails (E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers)
Posted by Philip Martin <ph...@wandisco.com>.
Jonathan Nieder <jr...@gmail.com> writes:
> [[[
> * Makefile.in (check): Set LD_LIBRARY_PATH so the just-built versions
> of auth plugins are used when running the test suite. Otherwise,
> auth-test can easily fail because some auth provider it expects to
> find is missing.
> ]]]
I committed this, with a small tweak to move where the variables are
set. Thanks!
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
[RFC/PATCH] Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of 5
providers)
Posted by Jonathan Nieder <jr...@gmail.com>.
Stefan Sperling wrote:
> On Thu, Nov 03, 2011 at 02:54:04AM -0500, Jonathan Nieder wrote:
>> START: auth-test
>> svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
>> FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
[...]
> Try setting LD_LIBRARY_PATH so that libs from your custom Subversion build
> are found when Subversion's kwallet and gnome-keyring plugins are dlopen()ed.
Nice! As long as I run "make all" first (to make sure the kwallet and
gnome-keyring plugins were built), setting LD_LIBRARY_PATH works.
Here's a rough patch to make that second step unnecessary.
[[[
* Makefile.in (check): Set LD_LIBRARY_PATH so the just-built versions
of auth plugins are used when running the test suite. Otherwise,
auth-test can easily fail because some auth provider it expects to
find is missing.
]]]
Index: Makefile.in
===================================================================
--- Makefile.in (revision 1197345)
+++ Makefile.in (working copy)
@@ -444,6 +444,10 @@ check-javahl: check-apache-javahl
check-all-javahl: check-apache-javahl check-tigris-javahl
+gnome_auth_dir = $(abs_builddir)/subversion/libsvn_auth_gnome_keyring/.libs
+kwallet_auth_dir = $(abs_builddir)/subversion/libsvn_auth_kwallet/.libs
+auth_plugin_dirs = $(gnome_auth_dir):$(kwallet_auth_dir)
+
# "make check CLEANUP=true" will clean up directories for successful tests.
# "make check TESTS=subversion/tests/cmdline/basic_tests.py"
# will perform only basic tests (likewise for other tests).
@@ -484,6 +488,7 @@ check: bin @TRANSFORM_LIBTOOL_SCRIPTS@ $(TEST_DEPS
flags="--list --milestone-filter=$(MILESTONE_FILTER) \
--mode-filter=$(MODE_FILTER) --log-to-stdout $$flags"; \
fi; \
+ LD_LIBRARY_PATH='$(auth_plugin_dirs):$(LD_LIBRARY_PATH)' \
$(PYTHON) $(top_srcdir)/build/run_tests.py \
--config-file $(top_srcdir)/subversion/tests/tests.conf \
$$flags \
Re: auth-test fails (E200006:
svn_auth_get_platform_specific_client_providers should return an array of 5
providers)
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 03, 2011 at 02:54:04AM -0500, Jonathan Nieder wrote:
> The failure is described in tests.log:
>
> START: auth-test
> svn_tests: E200006: svn_auth_get_platform_specific_client_providers should return an array of 5 providers
> FAIL: lt-auth-test 1: test retrieving platform-specific auth providers
> END: auth-test
> ELAPSED: auth-test 0:00:00.179133
>
> Indeed, instrumenting the test, we learn that the actual number of
> providers returned is 1.
>
> Known problem?
>
> Jonathan
Try setting LD_LIBRARY_PATH so that libs from your custom Subversion build
are found when Subversion's kwallet and gnome-keyring plugins are dlopen()ed.