added subversion 1.1.0_rc1 - _builds_ with all USE flags (language bindings compile, but untested) - No problems noted using client and mod_dav_svn based server Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 36955 [details] subversion-1.1.0_rc1.ebuild Commented out some of the old stuff, maybe swig language bindings need some tweaking (at least did not test/compile applications using svn language bindings).
Created attachment 37866 [details] subversion-1.1.0_rc2.ebuild subversion-1.1.0-rc2 added
There is now an ebuild for rc2 in the tree. Please try it.
I've tried emerging 1.1.0_rc2, but if fails during configure about unable to find Berkeley DB 4.0.14, even though I have that specific version emerged.
Does remerging apache2 help? Quite possibly your apache is compiled with a different db4 version. Recompiling apache2 should help.
The client/server of this ebuild work fine! I fixed some errors, which have also been in my ebuild: - libsvnjavahl-1.so had unresolved symbols because it did not get linked against libstdc++ - svn-config contains unsubstituted SVN_DB_* variables (they are emptied now if unset, seems they are introduced for doing bdb detection in later releases, e.g. when not building against apr) Testing the java native bindings: I just found this strange svnup-0.8.0.jar using JNI bindings; strange because it has a hardcoded classpath pointing to svnjavahl.jar in its manifest and ignores user classpath settings. So this test succeeded: cp /usr/lib/svn-javahl/svn-javahl.jar svnjavahl.jar; java -jar svnup-0.8.0.jar 2 patches follow (1rst against ebuild, 2nd to be placed in ${PORTDIR}/dev-util/subversion/files)
Created attachment 38400 [details, diff] subversion-1.1.0_rc2_ebuild.diff subversion-1.1.0_rc2_ebuild.diff: Patch against the current subversion ebuild in cvs (portage tree).
Created attachment 38401 [details, diff] subversion-1.1.0-rc2-build.patch subversion-1.1.0-rc2-build.patch: Patch for forgotton variable substitution in configure.in and linking libsvnjavahl-1.so to libstdc++.
Thanks, the patch makes sense indeed. Will you also post it upstream?
I'm afraid i cannot upstream it because i'm not a gentoo developer... Or should i post the full ebuild instead of a patch?
No, the ebuild is not interesting for upstream, but the patch is. It is not a gentoo specific problem. It are just two errors that upstream got into the code.
thanks, didn't know about that upstream issues until now. i filed a different link patch to subversion; i suppose it will be included in the 1.1.0-rc3 release scheduled for the next days
Closing, This version is in the tree allready for some time
