On Thu, Jan 26, 2017 at 2:44 PM, Michael Silberman
<Michael.Silberman_at_netgear.com> wrote:
> Thank you Stefan. I'll contact Wandisco. I couldn't find Python 2.7 for the RHEL from the libraries we have. But, I'll let roll back and wait on Wandisco Support. Was hoping someone else in community had experience with this before.
Building and replacing the system Python is *begging* for pain. You
can break RPM itself very badly, and be forced to use tools like the
old "rpm2cpio.sh" script to take apart and restore your RPMs for RPM
itself.
Python 2.7 and other releases are in the "Software Collections
Library" for RHEL, and would be installed in /opt/rh/. There are tools
in the SRPM's for those "python27" or "python33" packages, for
building fresh RPMs and SRPMs in the "python27" or "python33" working
environments. RHEL and CentOS publish SRPM's for those, and you could,
if you want to spend the work, build a "python27-srpm" that would work
from the relevant "/opt/rh" directory and use Python 2.7. I did
precisely this for a very large set of Python modules needed for
"airflow" software last year at my workplace. It's at
https://github.com/SkyhookWireless/airflowrepobuilder .
I'd do some things differently now, but it may give some ideas of how
to build up the necessary tool chain for a more recent Subversion, if
you feel the need.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Thursday, January 26, 2017 11:35 AM
> To: Michael Silberman <Michael.Silberman_at_Netgear.com>
> Cc: Pavel Lyalyakin <pavel.lyalyakin_at_visualsvn.com>; users_at_subversion.apache.org
> Subject: Re: Setup post-commit mailer fails
>
> On Thu, Jan 26, 2017 at 07:23:41PM +0000, Michael Silberman wrote:
>> Thank you!
>> I'm not sure how they installed the packages but assuming they used yum to do it.
>> # yum list | egrep -i "svn|subversion"
>> acp-gfr-scripts-svn.noarch 1.7.4.1-56 installed
>> ltrace.x86_64 0.5-28.45svn.el6 @anaconda-RedHatEnterpriseLinux-201604140956.x86_64/6.8
>> mod_dav_svn.x86_64 1.9.4-1 @/mod_dav_svn-1.9.4-1.x86_64
>> subversion.x86_64 1.9.4-1 @/subversion-1.9.4-1.x86_64
>> subversion-debuginfo.x86_64 1.9.4-1 @/subversion-debuginfo-1.9.4-1.x86_64
>> subversion-fsfswd.x86_64 1.9.4-1 @/subversion-fsfswd-1.9.4-1.x86_64
>> subversion-javahl.x86_64 1.9.4-1 @/subversion-javahl-1.9.4-1.x86_64
>> svn-multisite-plus.x86_64 1:1.9.2.2-147 @/svn-multisite-plus-1.9.2.2-147.x86_64
>> eclipse-svnkit.x86_64 1.3.0-3.el6 rhel-6-server-rpms
>> kmid.i686 2.0-0.14.20080213svn.el6 rhel-6-server-rpms
>> kmid.x86_64 2.0-0.14.20080213svn.el6 rhel-6-server-rpms
>> kmid-common.noarch 2.0-0.14.20080213svn.el6 rhel-6-server-rpms
>> libdvdread.x86_64 4.1.4-0.3.svn1183.el6 rhel-6-server-rpms
>> matchbox-window-manager.x86_64 1.2-6.20070628svn.1.el6 rhel-6-server-rpms
>> sgabios-bin.noarch 0-0.3.20110621svn.el6 rhel-6-server-rpms
>> subversion.i686 1.6.11-15.el6_7 rhel-6-server-rpms
>> subversion-javahl.i686 1.6.11-15.el6_7 rhel-6-server-rpms
>> svnkit.x86_64 1.3.0-3.el6 rhel-6-server-rpms
>>
>> I downloaded the Python 2.7 tarball from
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.python.org_ft
>> p_python_2.7.13_Python-2D2.7.13.tgz&d=DwIBAg&c=mPqdMxlQPdltZylzF3sRPA&
>> r=3Cfm8zsX3deZqG3JCZLpFealAzwN9AMA_A7tQtJEAFY&m=Dv0gxKU1HhkAPMuDjqwvzr
>> LyGvn3V4_6h4luN4iS-f0&s=vTrgDL9hg-xEIBTiU8JycAkiR7QFMTRZ1A-ZiDzQ4UI&e=
>> I built it and installed alternate target.
>
> Why did you compile Python yourself from source?
> Was there no standard Python 2.7 RPM you could install in RHEL6?
>
>> I installed the RPM from https://urldefense.proofpoint.com/v2/url?u=http-3A__opensource.wandisco.com_rhel_6_svn-2D1.9_RPMS_x86-5F64_subversion-2Dpython-2D1.9.4-2D1.x86-5F64.rpm&d=DwIBAg&c=mPqdMxlQPdltZylzF3sRPA&r=3Cfm8zsX3deZqG3JCZLpFealAzwN9AMA_A7tQtJEAFY&m=Dv0gxKU1HhkAPMuDjqwvzrLyGvn3V4_6h4luN4iS-f0&s=_VJ1uvTP0-t-g27bv4WrTyJGxjr_40BXCdb1PvHk7I0&e= .
>>
>> Does this help? Is there another set of commands to run that would provide more useful information?
>
> I think you should ask Wandisco's support to figure out what they would do to get the Python bindings running.
> (Perhaps someone else reading this list happens to know this -- I don't.)
>
> Generally, you should install the exact same things the distributor had installed on the system which compiled these packages. Anything else is a mix and match that can cause all sorts of problems.
Received on 2017-01-28 12:05:29 CET