1.9.0 is out, please bump Reproducible: Always
svn-1.9.0 is certainly NOT out, but 1.8.0 is! Please adjust title if possible.
i fixed the title
Created attachment 352228 [details] subversion-1.8.0.ebuild subversion-1.5.6-aix-dso.patch is disabled, because its not working anymore.
Created attachment 352230 [details] subversion-1.8.0.ebuild neon-support was dropped, so we have to use serf
if you are getting ‘svn: E175004: The PROPFIND response did not include the requested properties’ after ‘svn upgrade’, please check https://groups.google.com/forum/#!topic/tortoisesvn/o5taYV-bm0c
So maybe better to wait until 1.8.1 is out, saving bugzilla a lot of crying, and meanwhile get 1.7.10 in the tree as a simple rename of 1.7.9 appears to be enough.
Apache Subversion 1.8.1 is now released.
renaming my 1.8.0.ebuild to 1.8.3.ebuild seems to work fine
Created attachment 360286 [details, diff] subversion-1.8.1-revert_bdb6check.patch Attached is a patch to let >=subversion-1.8.1 compile against berkeley db-6...
I can't get it working with 'webdav-serf'. Module libs are installed in: /usr/libexec/mod_dav_svn.so And configuration is: LoadModule dav_svn_module modules/mod_dav_svn.so But apache can't find it: Cannot load /usr/lib64/apache2/modules/mod_dav_svn.so into server: /usr/lib64/apache2/modules/mod_dav_svn.so: cannot open shared object file: No such file or directory Any idea ?
1.8.x has also bindings for ruby1.9, so the dependency needs to be adjusted.
Created attachment 362284 [details, diff] subversion-1.8.0-hpux-dso.patch Updated hpux-dso patch. Please test.
(In reply to Eric Chatellier from comment #10) > But apache can't find it: > Cannot load /usr/lib64/apache2/modules/mod_dav_svn.so into server: > /usr/lib64/apache2/modules/mod_dav_svn.so: cannot open shared object file: > No such file or directory > > Any idea ? I just copied my /usr/libexec/mod_dav_svn.so and /usr/libexec/mod_authz_svn.so into /usr/lib64/apache2/modules/ and it seems to be working (can browse repositories via https, commit, TRAC is also updating). I've got no idea why the binaries ended up in a different directory and what other implications this may have. I'm eagerly awaiting a new ebuild (even an unstable one) for Subversion 1.8.x.
Created attachment 365128 [details, diff] diff from 1.7.13 to 1.8.5 So, using attachment 362284 [details, diff], given that attached ebuild has only enough for it not to bail out, I've given it a try to polish it. Didn't get much farther, but it's still something. Explanation of some changes: - version bumps in deps seem required by this version - ruby 1.9 just because - according to CHANGES, kwallet no longer requires nls (not using KDE, so not tested) - comment 10 addressed - CHANGES say bzip2 is used by some of the tools (doesn't specify which ones and the referenced commit isn't really helpful) (probably webdav-serf bits could be even more simplified, but meh)
*** Bug 492626 has been marked as a duplicate of this bug. ***
+*subversion-1.8.5 (06 Jan 2014) + + 06 Jan 2014; Lars Wendler <polynomial-c@gentoo.org> +subversion-1.8.5.ebuild, + +files/subversion-1.8.0-hpux-dso.patch, + +files/subversion-1.8.1-revert_bdb6check.patch: + Long overdue 1.8 bump. Thanks to all contributiors in bug #474848. +