subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nico Kadel-Garcia <>
Subject Re: Setup post-commit mailer fails
Date Sat, 28 Jan 2017 11:05:20 GMT
On Thu, Jan 26, 2017 at 2:44 PM, Michael Silberman
<> 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 "" script to take apart and restore your RPMs for RPM

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 .

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 []
> Sent: Thursday, January 26, 2017 11:35 AM
> To: Michael Silberman <>
> Cc: Pavel Lyalyakin <>;
> 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                  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:               @/svn-multisite-plus-
>> 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
>> 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
>> Does this help? Is there another set of commands to run that would provide more useful
> 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.

View raw message