Re: Subversion on RedHat
On Tue, May 23, 2017 at 11:05 AM, Todd Armstrong wrote: > Cedric, Thanks for posting the bug details. > > We have been using Wandisco's releases and are quite thankful for them as > when we started using subversion a couple of years ago RHEL version was so > out of date even then that we couldn't really justify starting with what they > ship when 1.8 branch had so many improvements in it. > > The RHEL position has some merit, but given the advances between what they > are shipping and what is currently available they sound a lot more to me like > excellent reasons to ship svn17, svn18, svn19, etc. and use the availability > of higher version as a means to make it possible (and push) their customers > towards more current releases - seems like that could allow them to stay more > current on each version level branch and reduce backporting of fixes to older > versions by pointing those looking for them to newer versions that already > have them and are available as part of RHEL. Agreed, except for the dependency trees for building more recent versions of Subversion on, say, RHEL 6 or RHEL 7. I'm reviewing my old efforts at https://github.com/nkadel/, and I finally had to throw in the towel because of critical security component dependencies, where upgrading them enough for Subversion 1.9 would break existing libraries or requre parallel installing *those*. It got out of hand. Puttin gthem in the "sclo" repositories, installed over in /opt/rh/svn19/, would allow including those updated libraries there as well. It's just a lot of work, and no one's offered me money to try, so I've personally not pursued it.
Re: On the subversion I have a question to confirm
On May 23, 2017, at 04:56, shen...@snail.com wrote: >> >>> 2, if you can make changes, please provide the appropriate changes or >>> feasible recommendations; Also modified after the existence of the >>> repository is not available, etc. Please give instructions, modify the >>> historical version of the information is retained operating log? >> >> By default, modifying history is not possible. If the repository >> administrator enables history editing, the repository administrator needs to >> arrange for records to be kept. >> >> Keeping records of commits that create new revisions is possible with the >> built-in logging features (access log and operational log). > > Ask about your reply to the second question, how to open the editorial > function of the library? Repository administrators can edit the historical contents of files by using "svnadmin dump" to create a single-file representation of the repository, then use a dumpfile editing tool to make changes to it, then use "svnadmin load" to load that file into a new repository. This is not done in the normal course of using your repository. This is done in emergency situations, such as: someone committed an enormous file to the repository and you need to remove it to free up server disk space; or someone committed a password or other secret information that cannot stay there. Sometimes, this is used to try to recover a corrupted repository. Repository administrators can allow users to edit revision metadata, such as the author, date, time, and log message of a commit, by creating a pre-revprop-change hook. This is surely described in the svnbook.
Re: Error running make for subversion
Joseph, Anselm wrote on Tue, 23 May 2017 15:26 +: > Also, could it be something with the mod_dav_svn package for > subversion-1.9.5.tar? There has to be a reason why mod_dav_svn.so cannot be > built. > Thank You mod_dav_svn is part of subversion-*.tar. It might be a change in Apache httpd, though --- I use 2.4 and I don't know how much testing 1.9 gets with 2.2.
RE: Error running make for subversion
Also, could it be something with the mod_dav_svn package for subversion-1.9.5.tar? There has to be a reason why mod_dav_svn.so cannot be built. Thank You -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Tuesday, May 23, 2017 9:26 AM To: Joseph, Anselm Cc: Ryan Schmidt; users@subversion.apache.org Subject: Re: Error running make for subversion CAUTION - EXTERNAL EMAIL Joseph, Anselm wrote on Tue, 23 May 2017 12:40 +: > configure:5703: checking for apr_memcache_create in -laprutil-1 > configure:5728: gcc -o conftest -g -O2 -g -O2 -pthread -U__STR__ > -D_THREAD_SAFE -D_LARGEFILE64_SOURCE -I/opt/eai/ci/httpd-2.2.32/srclib/ > apr/include -I/opt/eai/ci/httpd-2.2.32/srclib/apr-util/include > -I/opt/eai/ci/libiconv-1.15/libiconv/lib/include -L/opt/freeware/lib -L/op > t/eai/ci/httpd-2.2.32/srclib/apr-util -laprutil-1 conftest.c -laprutil-1 >&5 > ld: 0711-317 ERROR: Undefined symbol: .apr_strtok > ld: 0711-317 ERROR: Undefined symbol: .apr_atoi64 > ld: 0711-317 ERROR: Undefined symbol: .apr_pstrmemdup ... > ld: 0711-317 ERROR: Undefined symbol: .apr_pstrdup These errors are odd: if the linker couldn't find these function, Subversion would fail to link. (All libraries, not just mod_dav_svn.) But you build and install successfully without mod_dav_svn... More below. > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > collect2: ld returned 8 exit status > configure:5728: $? = 1 > configure: failed program was: > | /* confdefs.h */ > -Original Message- > Joseph, Anselm wrote on Mon, 22 May 2017 21:30 +: > > -Original Message- > > From: Joseph, Anselm > > Sent: Thursday, May 18, 2017 3:07 PM > ⋮ > > libtool: install: warning: relinking `mod_dav_svn.la' > > libtool: install: (cd /opt/eai/ci/subversion/subversion/mod_dav_svn; > > /bin/sh "/opt/eai/ci/subversion/libtool" --tag CC --silent > > --mode=relink gcc -shared -g -O2 -g -O2 -pthread -L/opt/freeware/lib > > -rpath /opt/eai/ci/subversion-1.9.5/svn/libexec -avoid-version > > -module -o mod_dav_svn.la activity.lo authz.lo deadprops.lo > > liveprops.lo lock.lo merge.lo mirror.lo mod_dav_svn.lo > > posts/create_txn.lo reports/dated-rev.lo reports/deleted-rev.lo > > reports/file-revs.lo reports/get-location-segments.lo > > reports/get-locations.lo reports/get-locks.lo > > reports/inherited-props.lo reports/log.lo reports/mergeinfo.lo > > reports/replay.lo reports/update.lo repos.lo status.lo util.lo > > version.lo ../../subversion/libsvn_repos/libsvn_repos-1.la > > ../../subversion/libsvn_fs/libsvn_fs-1.la > > ../../subversion/libsvn_delta/libsvn_delta-1.la > > ../../subversion/libsvn_subr/libsvn_subr-1.la ) > > libtool: install: cp .libs/mod_dav_svn.aT > > /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.a > > libtool: install: cp .libs/mod_dav_svn.lai > > /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.la > > chmod 755 /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so > > chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or > > directory in the path name does not exist. On my machine, the output of 'make install' contains: libtool: install: install .libs/mod_dav_svn.soT /srv/svn/trunk/libexec/mod_dav_svn.so libtool: install: install .libs/mod_dav_svn.lai /srv/svn/trunk/libexec/mod_dav_svn.la libtool: install: install .libs/mod_dav_svn.a /srv/svn/trunk/libexec/mod_dav_svn.a The interesting thing here is that on my machine, it outputs .soT and .lai in this order, whereas on your machine, it outputs .aT and .lai and then fails. Perhaps configure had gotten the .so and .a endings swapped, and thinks shared libraries are .a and static libraries .so . Can you check that? On my machine: $ grep -B1 shrext_cmds= config.status libtool config.status-libext='a' config.status:shrext_cmds='.so' -- libtool-# Shared library suffix (normally ".so"). libtool:shrext_cmds=".so" I'm not sure where the 755 comes from, perhaps it's from httpd/apxs since there are no '755' in svn's source code. HTH. And sorry for the delay, I haven't had a mod_dav_svn build environment until today. Daniel > > apxs:Error: Command failed with rc=65536 . > > make: 1254-004 The error code from the last command is 1.
RE: Subversion on RedHat
To be totally clear (as I made a little typo)... the Bug # doesn't mean subversion will arrive in RHSCL but means they are investigating it. I suppose the more request they have in that direction the more they'll look into it. -Message d'origine- De : Todd Armstrong [mailto:todd.armstr...@newscycle.com] Envoyé : Tuesday, May 23, 2017 5:05 PM À : Cedric J.F. Blomart (MINFIN) ; Nico Kadel-Garcia ; Daniel Shahaf Cc : Subversion ; Robert Heller Objet : RE: Subversion on RedHat Cedric, Thanks for posting the bug details. We have been using Wandisco's releases and are quite thankful for them as when we started using subversion a couple of years ago RHEL version was so out of date even then that we couldn't really justify starting with what they ship when 1.8 branch had so many improvements in it. The RHEL position has some merit, but given the advances between what they are shipping and what is currently available they sound a lot more to me like excellent reasons to ship svn17, svn18, svn19, etc. and use the availability of higher version as a means to make it possible (and push) their customers towards more current releases - seems like that could allow them to stay more current on each version level branch and reduce backporting of fixes to older versions by pointing those looking for them to newer versions that already have them and are available as part of RHEL. -Original Message- From: Cedric J.F. Blomart (MINFIN) [mailto:cedric.blom...@minfin.fed.be] Sent: Tuesday, May 23, 2017 6:51 AM To: Nico Kadel-Garcia ; Daniel Shahaf Cc: Subversion ; Robert Heller Subject: RE: Subversion on RedHat RedHat is already evaluating is releasing a newer version of subversion is feasible in RHSCL (software collection). If anyone has the issue and support from redhat I think they should submit their case into #Bug 1162551. So RedHat are taking the direction of apart repository for newer version of subversion and not into including a "renamed" package into the default repository. Concerning version concurrency (client, server, build system), the only good solution is communication between the different parties. -Message d'origine- De : Nico Kadel-Garcia [mailto:nka...@gmail.com] Envoyé : Tuesday, May 23, 2017 1:34 PM À : Daniel Shahaf Cc : Cedric J.F. Blomart (MINFIN) ; Subversion ; Robert Heller Objet : Re: Subversion on RedHat On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf wrote: > Cedric J.F. Blomart (MINFIN) wrote on Tue, 23 May 2017 05:54 +: >> Multiple reasons are given for this non upgrade, manly that upgrade would be >> impacting for customer: >> For RHEL6: upgrade from 1.6 to 1.7 needing an upgrade (svn upgrade) if not >> done automated system will be blocked. Plus issues with shared file system >> needing an upgrade of clients. >> For RHEL7: impacting as working copy changed in 1.8 > > What about the server side? None of this explains why > svnadmin/svnserve/mod_dav_svn wouldn't be upgraded. > > (Well, they'd have to maintain two different copies of libsvn on the > system and ensure svn and svnadmin each picked the right one...) Yup! You would. It would be feasible to talk RHEL into adding an "sclo", or software collections library, version of Subversion over in /opt/rh/svn19/. It would pretty much guarantee emotional angst when the default Subversion 1.6.x was used on a working repository that was checked out with 1.9.x. If RHEL or a local admin swapped the default or reset the default on a Jenkins build environment, for example, I'd personally be quite upset. It would also be feasible to build an alternative package named "subvesion19", much as they used to publish multiple versions of gcc as gcc33, gcc44, etc. on the same system. So it's possible. But it's work. And I'll admit that frankly, RHEL 6 is getting a bit long in the tooth. And even git is suffering similar issues of being seriously out of date for the commercial releases of RHEL, so Subversion is not the only source control system suffering from this problem.
RE: Subversion on RedHat
Cedric, Thanks for posting the bug details. We have been using Wandisco's releases and are quite thankful for them as when we started using subversion a couple of years ago RHEL version was so out of date even then that we couldn't really justify starting with what they ship when 1.8 branch had so many improvements in it. The RHEL position has some merit, but given the advances between what they are shipping and what is currently available they sound a lot more to me like excellent reasons to ship svn17, svn18, svn19, etc. and use the availability of higher version as a means to make it possible (and push) their customers towards more current releases - seems like that could allow them to stay more current on each version level branch and reduce backporting of fixes to older versions by pointing those looking for them to newer versions that already have them and are available as part of RHEL. -Original Message- From: Cedric J.F. Blomart (MINFIN) [mailto:cedric.blom...@minfin.fed.be] Sent: Tuesday, May 23, 2017 6:51 AM To: Nico Kadel-Garcia ; Daniel Shahaf Cc: Subversion ; Robert Heller Subject: RE: Subversion on RedHat RedHat is already evaluating is releasing a newer version of subversion is feasible in RHSCL (software collection). If anyone has the issue and support from redhat I think they should submit their case into #Bug 1162551. So RedHat are taking the direction of apart repository for newer version of subversion and not into including a "renamed" package into the default repository. Concerning version concurrency (client, server, build system), the only good solution is communication between the different parties. -Message d'origine- De : Nico Kadel-Garcia [mailto:nka...@gmail.com] Envoyé : Tuesday, May 23, 2017 1:34 PM À : Daniel Shahaf Cc : Cedric J.F. Blomart (MINFIN) ; Subversion ; Robert Heller Objet : Re: Subversion on RedHat On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf wrote: > Cedric J.F. Blomart (MINFIN) wrote on Tue, 23 May 2017 05:54 +: >> Multiple reasons are given for this non upgrade, manly that upgrade would be >> impacting for customer: >> For RHEL6: upgrade from 1.6 to 1.7 needing an upgrade (svn upgrade) if not >> done automated system will be blocked. Plus issues with shared file system >> needing an upgrade of clients. >> For RHEL7: impacting as working copy changed in 1.8 > > What about the server side? None of this explains why > svnadmin/svnserve/mod_dav_svn wouldn't be upgraded. > > (Well, they'd have to maintain two different copies of libsvn on the > system and ensure svn and svnadmin each picked the right one...) Yup! You would. It would be feasible to talk RHEL into adding an "sclo", or software collections library, version of Subversion over in /opt/rh/svn19/. It would pretty much guarantee emotional angst when the default Subversion 1.6.x was used on a working repository that was checked out with 1.9.x. If RHEL or a local admin swapped the default or reset the default on a Jenkins build environment, for example, I'd personally be quite upset. It would also be feasible to build an alternative package named "subvesion19", much as they used to publish multiple versions of gcc as gcc33, gcc44, etc. on the same system. So it's possible. But it's work. And I'll admit that frankly, RHEL 6 is getting a bit long in the tooth. And even git is suffering similar issues of being seriously out of date for the commercial releases of RHEL, so Subversion is not the only source control system suffering from this problem.
RE: Error running make for subversion
From config.status... libext='a' shrext_cmds='.so' Sending the config.log for completeness. I am sure I am missing something...just don't know what. Thank you for your help. -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Tuesday, May 23, 2017 9:26 AM To: Joseph, Anselm Cc: Ryan Schmidt; users@subversion.apache.org Subject: Re: Error running make for subversion CAUTION - EXTERNAL EMAIL Joseph, Anselm wrote on Tue, 23 May 2017 12:40 +: > configure:5703: checking for apr_memcache_create in -laprutil-1 > configure:5728: gcc -o conftest -g -O2 -g -O2 -pthread -U__STR__ > -D_THREAD_SAFE -D_LARGEFILE64_SOURCE -I/opt/eai/ci/httpd-2.2.32/srclib/ > apr/include -I/opt/eai/ci/httpd-2.2.32/srclib/apr-util/include > -I/opt/eai/ci/libiconv-1.15/libiconv/lib/include -L/opt/freeware/lib -L/op > t/eai/ci/httpd-2.2.32/srclib/apr-util -laprutil-1 conftest.c -laprutil-1 >&5 > ld: 0711-317 ERROR: Undefined symbol: .apr_strtok > ld: 0711-317 ERROR: Undefined symbol: .apr_atoi64 > ld: 0711-317 ERROR: Undefined symbol: .apr_pstrmemdup ... > ld: 0711-317 ERROR: Undefined symbol: .apr_pstrdup These errors are odd: if the linker couldn't find these function, Subversion would fail to link. (All libraries, not just mod_dav_svn.) But you build and install successfully without mod_dav_svn... More below. > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > collect2: ld returned 8 exit status > configure:5728: $? = 1 > configure: failed program was: > | /* confdefs.h */ > -Original Message- > Joseph, Anselm wrote on Mon, 22 May 2017 21:30 +: > > -Original Message- > > From: Joseph, Anselm > > Sent: Thursday, May 18, 2017 3:07 PM > ⋮ > > libtool: install: warning: relinking `mod_dav_svn.la' > > libtool: install: (cd /opt/eai/ci/subversion/subversion/mod_dav_svn; > > /bin/sh "/opt/eai/ci/subversion/libtool" --tag CC --silent > > --mode=relink gcc -shared -g -O2 -g -O2 -pthread -L/opt/freeware/lib > > -rpath /opt/eai/ci/subversion-1.9.5/svn/libexec -avoid-version > > -module -o mod_dav_svn.la activity.lo authz.lo deadprops.lo > > liveprops.lo lock.lo merge.lo mirror.lo mod_dav_svn.lo > > posts/create_txn.lo reports/dated-rev.lo reports/deleted-rev.lo > > reports/file-revs.lo reports/get-location-segments.lo > > reports/get-locations.lo reports/get-locks.lo > > reports/inherited-props.lo reports/log.lo reports/mergeinfo.lo > > reports/replay.lo reports/update.lo repos.lo status.lo util.lo > > version.lo ../../subversion/libsvn_repos/libsvn_repos-1.la > > ../../subversion/libsvn_fs/libsvn_fs-1.la > > ../../subversion/libsvn_delta/libsvn_delta-1.la > > ../../subversion/libsvn_subr/libsvn_subr-1.la ) > > libtool: install: cp .libs/mod_dav_svn.aT > > /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.a > > libtool: install: cp .libs/mod_dav_svn.lai > > /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.la > > chmod 755 /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so > > chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or > > directory in the path name does not exist. On my machine, the output of 'make install' contains: libtool: install: install .libs/mod_dav_svn.soT /srv/svn/trunk/libexec/mod_dav_svn.so libtool: install: install .libs/mod_dav_svn.lai /srv/svn/trunk/libexec/mod_dav_svn.la libtool: install: install .libs/mod_dav_svn.a /srv/svn/trunk/libexec/mod_dav_svn.a The interesting thing here is that on my machine, it outputs .soT and .lai in this order, whereas on your machine, it outputs .aT and .lai and then fails. Perhaps configure had gotten the .so and .a endings swapped, and thinks shared libraries are .a and static libraries .so . Can you check that? On my machine: $ grep -B1 shrext_cmds= config.status libtool config.status-libext='a' config.status:shrext_cmds='.so' -- libtool-# Shared library suffix (normally ".so"). libtool:shrext_cmds=".so" I'm not sure where the 755 comes from, perhaps it's from httpd/apxs since there are no '755' in svn's source code. HTH. And sorry for the delay, I haven't had a mod_dav_svn build environment until today. Daniel > > apxs:Error: Command failed with rc=65536 . > > make: 1254-004 The error code from the last command is 1. config.log Description: config.log
Re: Error running make for subversion
Joseph, Anselm wrote on Tue, 23 May 2017 12:40 +: > configure:5703: checking for apr_memcache_create in -laprutil-1 > configure:5728: gcc -o conftest -g -O2 -g -O2 -pthread -U__STR__ > -D_THREAD_SAFE -D_LARGEFILE64_SOURCE -I/opt/eai/ci/httpd-2.2.32/srclib/ > apr/include -I/opt/eai/ci/httpd-2.2.32/srclib/apr-util/include > -I/opt/eai/ci/libiconv-1.15/libiconv/lib/include -L/opt/freeware/lib -L/op > t/eai/ci/httpd-2.2.32/srclib/apr-util -laprutil-1 conftest.c -laprutil-1 >&5 > ld: 0711-317 ERROR: Undefined symbol: .apr_strtok > ld: 0711-317 ERROR: Undefined symbol: .apr_atoi64 > ld: 0711-317 ERROR: Undefined symbol: .apr_pstrmemdup > ... > ld: 0711-317 ERROR: Undefined symbol: .apr_pstrdup These errors are odd: if the linker couldn't find these function, Subversion would fail to link. (All libraries, not just mod_dav_svn.) But you build and install successfully without mod_dav_svn... More below. > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > collect2: ld returned 8 exit status > configure:5728: $? = 1 > configure: failed program was: > | /* confdefs.h */ > -Original Message- > Joseph, Anselm wrote on Mon, 22 May 2017 21:30 +: > > -Original Message- > > From: Joseph, Anselm > > Sent: Thursday, May 18, 2017 3:07 PM > ⋮ > > libtool: install: warning: relinking `mod_dav_svn.la' > > libtool: install: (cd /opt/eai/ci/subversion/subversion/mod_dav_svn; > > /bin/sh "/opt/eai/ci/subversion/libtool" --tag CC --silent > > --mode=relink gcc -shared -g -O2 -g -O2 -pthread -L/opt/freeware/lib > > -rpath /opt/eai/ci/subversion-1.9.5/svn/libexec -avoid-version -module > > -o mod_dav_svn.la activity.lo authz.lo deadprops.lo liveprops.lo > > lock.lo merge.lo mirror.lo mod_dav_svn.lo posts/create_txn.lo > > reports/dated-rev.lo reports/deleted-rev.lo reports/file-revs.lo > > reports/get-location-segments.lo reports/get-locations.lo > > reports/get-locks.lo reports/inherited-props.lo reports/log.lo > > reports/mergeinfo.lo reports/replay.lo reports/update.lo repos.lo > > status.lo util.lo version.lo > > ../../subversion/libsvn_repos/libsvn_repos-1.la > > ../../subversion/libsvn_fs/libsvn_fs-1.la > > ../../subversion/libsvn_delta/libsvn_delta-1.la > > ../../subversion/libsvn_subr/libsvn_subr-1.la ) > > libtool: install: cp .libs/mod_dav_svn.aT > > /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.a > > libtool: install: cp .libs/mod_dav_svn.lai > > /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.la > > chmod 755 /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so > > chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or > > directory in the path name does not exist. On my machine, the output of 'make install' contains: libtool: install: install .libs/mod_dav_svn.soT /srv/svn/trunk/libexec/mod_dav_svn.so libtool: install: install .libs/mod_dav_svn.lai /srv/svn/trunk/libexec/mod_dav_svn.la libtool: install: install .libs/mod_dav_svn.a /srv/svn/trunk/libexec/mod_dav_svn.a The interesting thing here is that on my machine, it outputs .soT and .lai in this order, whereas on your machine, it outputs .aT and .lai and then fails. Perhaps configure had gotten the .so and .a endings swapped, and thinks shared libraries are .a and static libraries .so . Can you check that? On my machine: $ grep -B1 shrext_cmds= config.status libtool config.status-libext='a' config.status:shrext_cmds='.so' -- libtool-# Shared library suffix (normally ".so"). libtool:shrext_cmds=".so" I'm not sure where the 755 comes from, perhaps it's from httpd/apxs since there are no '755' in svn's source code. HTH. And sorry for the delay, I haven't had a mod_dav_svn build environment until today. Daniel > > apxs:Error: Command failed with rc=65536 . > > make: 1254-004 The error code from the last command is 1.
RE: Error running make for subversion
Thank you Daniel for taking the time to answer.
The complete configure command:
CC='gcc' CPP='gcc -E' ./configure --prefix=/opt/eai/ci/subversion-1.9.5/svn
--with-apache-libexecdir=/opt/eai/ci/httpd-2.2.32/apache/modules
--with-apr=/opt/eai/ci/httpd-2.2.32/srclib/apr/apr-1-config
--with-apr-util=/opt/eai/ci/httpd-2.2.32/srclib/apr-util/apu-1-config
--with-apxs=/opt/eai/ci/httpd-2.2.32/apache/bin/apxs --disable-nls
--enable-mod-activation
Not building in parallel, just running 'make' command.
Only one set of errors in config log:
configure:5703: checking for apr_memcache_create in -laprutil-1
configure:5728: gcc -o conftest -g -O2 -g -O2 -pthread -U__STR__
-D_THREAD_SAFE -D_LARGEFILE64_SOURCE -I/opt/eai/ci/httpd-2.2.32/srclib/
apr/include -I/opt/eai/ci/httpd-2.2.32/srclib/apr-util/include
-I/opt/eai/ci/libiconv-1.15/libiconv/lib/include -L/opt/freeware/lib -L/op
t/eai/ci/httpd-2.2.32/srclib/apr-util -laprutil-1 conftest.c -laprutil-1 >&5
ld: 0711-317 ERROR: Undefined symbol: .apr_strtok
ld: 0711-317 ERROR: Undefined symbol: .apr_atoi64
ld: 0711-317 ERROR: Undefined symbol: .apr_pstrmemdup
...
ld: 0711-317 ERROR: Undefined symbol: .apr_pstrdup
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
configure:5728: $? = 1
configure: failed program was:
| /* confdefs.h */
-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
Sent: Tuesday, May 23, 2017 4:59 AM
To: Joseph, Anselm
Cc: users@subversion.apache.org; Ryan Schmidt
Subject: Re: Error running make for subversion
You could try commenting out that 'chmod' command in Makefile or
build-outputs.mk, see if that lets the build proceed further, and then effect
it manually after 'make' finishes. (That's just a diagnostic workaround, not a
solution.)
What's your exact configure command (all arguments)? Are you disabling
building of shared libraries in some way?
Are you building in parallel ('make -j' or local equivalent)?
Check configure's output for any errors/warnings related to httpd. (If there's
a warning about "Assuming we use httpd 2.2+" that's normal.)
Don't have time to debug / reproduce myself, sorry.
Joseph, Anselm wrote on Mon, 22 May 2017 21:30 +:
> Hello All,
> I have been running in circles trying to fix this issue. Nothing seems to
> work. If you could take a couple of minutes to give some direction, it would
> be greatly appreciated.
> Thank You
>
> -Original Message-
> From: Joseph, Anselm
> Sent: Thursday, May 18, 2017 3:07 PM
> To: 'Ryan Schmidt'; Daniel Shahaf
> Cc: Subversion Users
> Subject: RE: Error running make for subversion
>
> Thank you both for responding.
> When I run configure --without-apxs, make install completes cleanly. But my
> problem is that mod_dav_svn.so is not building . I tried different options
> and still cannot get mod_dav_svn.so to build.
> When I run .configure with-apxs=
> /opt/eai/ci/httpd-2.2.32/apache/bin/apxs
> make install fails as follows:
> if true ; then cd subversion/mod_dav_svn ;
> /opt/eai/ci/subversion/build/install-sh -c -d
> "/opt/eai/ci/subversion-1.9.5/svn/libexec" ;
> /opt/eai/ci/httpd-2.2.32/apache/bin/apxs -i -S
> LIBEXECDIR="/opt/eai/ci/subversion-1.9.5/svn/libexec" -a -n dav_svn
> mod_dav_svn.la ; fi /opt/eai/ci/httpd-2.2.32/apache/build/instdso.sh
> SH_LIBTOOL='/opt/freeware/lib/apr-1/build/libtool' mod_dav_svn.la
> /opt/eai/ci/subversion-1.9.5/svn/libexec
> rm -f /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so
> /opt/freeware/lib/apr-1/build/libtool --mode=install cp mod_dav_svn.la
> /opt/eai/ci/subversion-1.9.5/svn/libexec/
> libtool: install: warning: relinking `mod_dav_svn.la'
> libtool: install: (cd /opt/eai/ci/subversion/subversion/mod_dav_svn;
> /bin/sh "/opt/eai/ci/subversion/libtool" --tag CC --silent
> --mode=relink gcc -shared -g -O2 -g -O2 -pthread -L/opt/freeware/lib
> -rpath /opt/eai/ci/subversion-1.9.5/svn/libexec -avoid-version -module
> -o mod_dav_svn.la activity.lo authz.lo deadprops.lo liveprops.lo
> lock.lo merge.lo mirror.lo mod_dav_svn.lo posts/create_txn.lo
> reports/dated-rev.lo reports/deleted-rev.lo reports/file-revs.lo
> reports/get-location-segments.lo reports/get-locations.lo
> reports/get-locks.lo reports/inherited-props.lo reports/log.lo
> reports/mergeinfo.lo reports/replay.lo reports/update.lo repos.lo
> status.lo util.lo version.lo
> ../../subversion/libsvn_repos/libsvn_repos-1.la
> ../../subversion/libsvn_fs/libsvn_fs-1.la
> ../../subversion/libsvn_delta/libsvn_delta-1.la
> ../../subversion/libsvn_subr/libsvn_subr-1.la )
> libtool: install: cp .libs/mod_dav_svn.aT
> /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.a
> libtool: install: cp .libs/mod_dav_svn.lai
> /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.la
> chmod 755 /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so
> chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or
> directory in the path
RE: Subversion on RedHat
RedHat is already evaluating is releasing a newer version of subversion is feasible in RHSCL (software collection). If anyone has the issue and support from redhat I think they should submit their case into #Bug 1162551. So RedHat are taking the direction of apart repository for newer version of subversion and not into including a "renamed" package into the default repository. Concerning version concurrency (client, server, build system), the only good solution is communication between the different parties. -Message d'origine- De : Nico Kadel-Garcia [mailto:nka...@gmail.com] Envoyé : Tuesday, May 23, 2017 1:34 PM À : Daniel Shahaf Cc : Cedric J.F. Blomart (MINFIN) ; Subversion ; Robert Heller Objet : Re: Subversion on RedHat On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf wrote: > Cedric J.F. Blomart (MINFIN) wrote on Tue, 23 May 2017 05:54 +: >> Multiple reasons are given for this non upgrade, manly that upgrade would be >> impacting for customer: >> For RHEL6: upgrade from 1.6 to 1.7 needing an upgrade (svn upgrade) if not >> done automated system will be blocked. Plus issues with shared file system >> needing an upgrade of clients. >> For RHEL7: impacting as working copy changed in 1.8 > > What about the server side? None of this explains why > svnadmin/svnserve/mod_dav_svn wouldn't be upgraded. > > (Well, they'd have to maintain two different copies of libsvn on the > system and ensure svn and svnadmin each picked the right one...) Yup! You would. It would be feasible to talk RHEL into adding an "sclo", or software collections library, version of Subversion over in /opt/rh/svn19/. It would pretty much guarantee emotional angst when the default Subversion 1.6.x was used on a working repository that was checked out with 1.9.x. If RHEL or a local admin swapped the default or reset the default on a Jenkins build environment, for example, I'd personally be quite upset. It would also be feasible to build an alternative package named "subvesion19", much as they used to publish multiple versions of gcc as gcc33, gcc44, etc. on the same system. So it's possible. But it's work. And I'll admit that frankly, RHEL 6 is getting a bit long in the tooth. And even git is suffering similar issues of being seriously out of date for the commercial releases of RHEL, so Subversion is not the only source control system suffering from this problem.
Re: Subversion on RedHat
On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf wrote: > Cedric J.F. Blomart (MINFIN) wrote on Tue, 23 May 2017 05:54 +: >> Multiple reasons are given for this non upgrade, manly that upgrade would be >> impacting for customer: >> For RHEL6: upgrade from 1.6 to 1.7 needing an upgrade (svn upgrade) if not >> done automated system will be blocked. Plus issues with shared file system >> needing an upgrade of clients. >> For RHEL7: impacting as working copy changed in 1.8 > > What about the server side? None of this explains why > svnadmin/svnserve/mod_dav_svn > wouldn't be upgraded. > > (Well, they'd have to maintain two different copies of libsvn on the system > and ensure > svn and svnadmin each picked the right one...) Yup! You would. It would be feasible to talk RHEL into adding an "sclo", or software collections library, version of Subversion over in /opt/rh/svn19/. It would pretty much guarantee emotional angst when the default Subversion 1.6.x was used on a working repository that was checked out with 1.9.x. If RHEL or a local admin swapped the default or reset the default on a Jenkins build environment, for example, I'd personally be quite upset. It would also be feasible to build an alternative package named "subvesion19", much as they used to publish multiple versions of gcc as gcc33, gcc44, etc. on the same system. So it's possible. But it's work. And I'll admit that frankly, RHEL 6 is getting a bit long in the tooth. And even git is suffering similar issues of being seriously out of date for the commercial releases of RHEL, so Subversion is not the only source control system suffering from this problem.
Re: SVN authz file not working when checkout on the same server
On 23.05.2017 10:27, 张乾龙 wrote: > When I create svn proj on a server, I modify authz and svnserve.conf to > control the access of other users, but after I tried many times and found: On > the same server, other user can use 'svn co file:///path/to/my/proj' to > checkout the svn proj without passwd even I config all users have no > authority to access my svn proj! Of cause, if other users on the same server > using 'svn co svn://' checkout my proj, the passwd and authority are needed. > > > Have I missed something when using SVN? Thanks! This is exactly as designed. You should restrict permissions on the filesystem where the repositories are stored so that only the 'svnserve' process user can read and write them. -- Brane
Re: Re: On the subversion I have a question to confirm
Hello: Ask about your reply to the second question, how to open the editorial function of the library? Snail 蜗牛数字 苏州蜗牛数字科技股份有限公司 沈磊/全球运维中心 TEL: +86(0512)67671313 MOB:13913112414 FAX:+86(0512)67671231 Email: shen...@snail.com Add：苏州工业园区中新大道西171号 平台官网：www.snail.com 企业官网：about.snail.com 请关注蜗牛新浪官方微博：http://weibo.com/woniushuzi 本邮件及其附件所载内容可能含有保密信息并受法律保护，任何人切勿传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。若您误收本邮件，请通知发件人，并删除原始邮件、附件及其所有复本。 This email (including any attachments) is confidential, may be legally privileged and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited. If you received this message in error, please contact the sender and destroy all copies of this email. From: Daniel Shahaf Date: 2017-05-22 16:28 To: shenlei CC: users; Andreas.Stieger Subject: Re: On the subversion I have a question to confirm shen...@snail.com wrote on Mon, 22 May 2017 11:40 +0800: > Hello, everyone: > In the process of using Subversion, there are several questions that I hope > someone can help to confirm, get the exact answer or official note > 1, Subversion can not modify the version number under the premise of > modifying the historical version of the content? People who can commit cannot change the contents of previous revisions; they can only add new revisions. The contents of old revisions can be changed by the repository administrator. This cannot be prevented by any system. It is not easy, but it is possible. > 2, if you can make changes, please provide the appropriate changes or > feasible recommendations; Also modified after the existence of the repository > is not available, etc. Please give instructions, modify the historical > version of the information is retained operating log? By default, modifying history is not possible. If the repository administrator enables history editing, the repository administrator needs to arrange for records to be kept. Keeping records of commits that create new revisions is possible with the built-in logging features (access log and operational log). > 3, hope to get the Subversion project official email or official authorized > reply, thank you for the help! You're welcome. Daniel
SVN authz file not working when checkout on the same server
When I create svn proj on a server, I modify authz and svnserve.conf to control the access of other users, but after I tried many times and found: On the same server, other user can use 'svn co file:///path/to/my/proj' to checkout the svn proj without passwd even I config all users have no authority to access my svn proj! Of cause, if other users on the same server using 'svn co svn://' checkout my proj, the passwd and authority are needed. Have I missed something when using SVN? Thanks!
Re: Subversion on RedHat
Cedric J.F. Blomart (MINFIN) wrote on Tue, 23 May 2017 05:54 +: > Multiple reasons are given for this non upgrade, manly that upgrade would be > impacting for customer: > For RHEL6: upgrade from 1.6 to 1.7 needing an upgrade (svn upgrade) if not > done automated system will be blocked. Plus issues with shared file system > needing an upgrade of clients. > For RHEL7: impacting as working copy changed in 1.8 What about the server side? None of this explains why svnadmin/svnserve/mod_dav_svn wouldn't be upgraded. (Well, they'd have to maintain two different copies of libsvn on the system and ensure svn and svnadmin each picked the right one...)
Re: Error running make for subversion
You could try commenting out that 'chmod' command in Makefile or
build-outputs.mk, see if that lets the build proceed further, and then effect
it manually after 'make' finishes. (That's just a diagnostic workaround,
not a solution.)
What's your exact configure command (all arguments)? Are you disabling
building of shared libraries in some way?
Are you building in parallel ('make -j' or local equivalent)?
Check configure's output for any errors/warnings related to httpd. (If there's
a warning about "Assuming we use httpd 2.2+" that's normal.)
Don't have time to debug / reproduce myself, sorry.
Joseph, Anselm wrote on Mon, 22 May 2017 21:30 +:
> Hello All,
> I have been running in circles trying to fix this issue. Nothing seems to
> work. If you could take a couple of minutes to give some direction, it would
> be greatly appreciated.
> Thank You
>
> -Original Message-
> From: Joseph, Anselm
> Sent: Thursday, May 18, 2017 3:07 PM
> To: 'Ryan Schmidt'; Daniel Shahaf
> Cc: Subversion Users
> Subject: RE: Error running make for subversion
>
> Thank you both for responding.
> When I run configure --without-apxs, make install completes cleanly. But my
> problem is that mod_dav_svn.so is not building . I tried different options
> and still cannot get mod_dav_svn.so to build.
> When I run .configure with-apxs= /opt/eai/ci/httpd-2.2.32/apache/bin/apxs
> make install fails as follows:
> if true ; then cd subversion/mod_dav_svn ;
> /opt/eai/ci/subversion/build/install-sh -c -d
> "/opt/eai/ci/subversion-1.9.5/svn/libexec" ;
> /opt/eai/ci/httpd-2.2.32/apache/bin/apxs -i -S
> LIBEXECDIR="/opt/eai/ci/subversion-1.9.5/svn/libexec" -a -n dav_svn
> mod_dav_svn.la ; fi /opt/eai/ci/httpd-2.2.32/apache/build/instdso.sh
> SH_LIBTOOL='/opt/freeware/lib/apr-1/build/libtool' mod_dav_svn.la
> /opt/eai/ci/subversion-1.9.5/svn/libexec
> rm -f /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so
> /opt/freeware/lib/apr-1/build/libtool --mode=install cp mod_dav_svn.la
> /opt/eai/ci/subversion-1.9.5/svn/libexec/
> libtool: install: warning: relinking `mod_dav_svn.la'
> libtool: install: (cd /opt/eai/ci/subversion/subversion/mod_dav_svn; /bin/sh
> "/opt/eai/ci/subversion/libtool" --tag CC --silent --mode=relink gcc -shared
> -g -O2 -g -O2 -pthread -L/opt/freeware/lib -rpath
> /opt/eai/ci/subversion-1.9.5/svn/libexec -avoid-version -module -o
> mod_dav_svn.la activity.lo authz.lo deadprops.lo liveprops.lo lock.lo
> merge.lo mirror.lo mod_dav_svn.lo posts/create_txn.lo reports/dated-rev.lo
> reports/deleted-rev.lo reports/file-revs.lo reports/get-location-segments.lo
> reports/get-locations.lo reports/get-locks.lo reports/inherited-props.lo
> reports/log.lo reports/mergeinfo.lo reports/replay.lo reports/update.lo
> repos.lo status.lo util.lo version.lo
> ../../subversion/libsvn_repos/libsvn_repos-1.la
> ../../subversion/libsvn_fs/libsvn_fs-1.la
> ../../subversion/libsvn_delta/libsvn_delta-1.la
> ../../subversion/libsvn_subr/libsvn_subr-1.la )
> libtool: install: cp .libs/mod_dav_svn.aT
> /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.a
> libtool: install: cp .libs/mod_dav_svn.lai
> /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.la
> chmod 755 /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so
> chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or
> directory in the path name does not exist.
> apxs:Error: Command failed with rc=65536 .
> make: 1254-004 The error code from the last command is 1.
>
>
> Stop.
>
> -Original Message-
> From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com]
> Sent: Wednesday, May 17, 2017 8:42 PM
> To: Daniel Shahaf
> Cc: Joseph, Anselm; Subversion Users
> Subject: Re: Error running make for subversion
>
> CAUTION - EXTERNAL EMAIL
>
>
>
> > On May 17, 2017, at 19:41, Ryan Schmidt
> > wrote:
> >
> >
> >> On May 16, 2017, at 17:18, Daniel Shahaf wrote:
> >>
> >> Joseph, Anselm wrote on Tue, May 16, 2017 at 21:04:57 +:
> >>> chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or
> >>> directory in the path name does not exist.
> >>> apxs:Error: Command failed with rc=65536
> >>
> >> Note that if you use svn:// or svn+ssh://, you don't need mod_dav_svn
> >> and can disable building it with --without-apxs to configure.
> >
> > You mean http:// and https://. mod_dav_svn isn't involved with svn:// or
> > svn+ssh://.
> >
>
> And, sorry, I mis-parsed your sentence. Never mind.
>
>
Re: On the subversion I have a question to confirm
[Forwarding to the list. Please remember to use "Reply to All" when answering.] shen...@snail.com wrote on Tue, 23 May 2017 14:08 +0800: > Hello: > Ask about your reply to the second question, how to open the > editorial function of the library? > > > > Snail 蜗牛数字 > 苏州蜗牛数字科技股份有限公司 > 沈磊/全球运维中心 > TEL: +86(0512)67671313 > MOB:13913112414 > FAX:+86(0512)67671231 > Email: shen...@snail.com > Add：苏州工业园区中新大道西171号 > 平台官网：www.snail.com > 企业官网：about.snail.com > 请关注蜗牛新浪官方微博：http://weibo.com/woniushuzi > > > 本邮件及其附件所载内容可能含有保密信息并受法律保护，任何人切勿传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。若您误收本邮件，请通知发件人，并删除原始邮件、附件及其所有复本。 > > This email (including any attachments) is confidential, may be legally > privileged and is for the intended recipient only. Access, disclosure, > copying, distribution, or reliance on any of it by anyone else > is prohibited. If you received this message in error, please contact the > sender and destroy all copies of this email. > > From: Daniel Shahaf > Date: 2017-05-22 16:28 > To: shenlei > CC: users; Andreas.Stieger > Subject: Re: On the subversion I have a question to confirm > shen...@snail.com wrote on Mon, 22 May 2017 11:40 +0800: > > Hello, everyone: > > In the process of using Subversion, there are several questions that I hope > > someone can help to confirm, get the exact answer or official note > > 1, Subversion can not modify the version number under the premise of > > modifying the historical version of the content? > > People who can commit cannot change the contents of previous revisions; they > can only add new revisions. > > The contents of old revisions can be changed by the repository administrator. > This cannot be prevented by any system. It is not easy, but it is possible. > > > 2, if you can make changes, please provide the appropriate changes or > > feasible recommendations; Also modified after the existence of the > > repository is not available, etc. Please give instructions, modify the > > historical version of the information is retained operating log? > > By default, modifying history is not possible. If the repository > administrator enables history editing, the repository administrator needs to > arrange for records to be kept. > > Keeping records of commits that create new revisions is possible with the > built-in logging features (access log and operational log). > > > 3, hope to get the Subversion project official email or official authorized > > reply, thank you for the help! > > You're welcome. > > Daniel
