On Mon, Sep 12, 2011 at 9:24 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Nico Kadel-Garcia wrote on Mon, Sep 12, 2011 at 09:17:09 -0400:
>> On Mon, Sep 12, 2011 at 8:16 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> > Nico Kadel-Garcia wrote on Mon, Sep 12, 2011 at 07:20:18 -0400:
>> >> On Mon, Sep 12, 2011 at 6:30 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> >> > Felipe Alvarez wrote on Mon, Sep 12, 2011 at 10:31:22 +1000:
>> >> >> Client: windows 7 x86_64 TortoiseSVN 1.5.9 (this version is REQUIRED!)
>> >> >> Server: Redhat 4 svn version 1.4.4 ( r25188 ) (this version is REQUIRED!)
>> >> >>
>> >> >
>> >> > These versions are ancient, unsupported, and contain known security holes.
>> >> >
>> >> >> Error Logs:
>> >> >> apache error_log: A failure occurred while driving the update report editor
>> >> >> apache error_log: Provider encountered an error while streaming a
>> >> >> REPORT response.
>> >> >
>> >> > Run tools/dev/which-error.py on the six-digit number in the above error
>> >> > message.
>> >>
>> >> Felipe, note that it's not "Red Hat 4". Red Hat 4.0 was published in
>> >> 1996. Red Hat Enterprise Linux 4.0, commonly referred to as RHEL 4.0,
>> >> was published in 2005. It is very painful to backport Subversion 1.6.x
>> >> to RHEL 4, due to dependencies on more recent Python for
>> >> configuration, and more recent swig and sqlite libraries for
>> >> operation,
>> >
>> > Python is not required for building from a source tarball.
>> >
>> > SWIG is only required for some of the bindings, and SQLite is optional
>> > on the server side (though it's mandatory on the client side in 1.7).
>>
>> Try running "autoconf" and "./configure" on RHEL 4. It's nasty. I've
>
> You don't need to run 'autoconf' when building from a tarball.
>
>> been publishing the updates to releases on RPMforge, and it's gotten
>> nasty. I don't know of anyone doing ongoing backports to RHEL 4.
The problem is *not* autoconf. It's wise to use autoconf on a new
platform to be sure of correct --include and --lib settings for your
environment, but I've got 1.6.17 open in mock right now. It's
appropriate to run autoconf if you roll the "apr" dependency back to
0.9.4, as needed for RHEL 4, if you don't want to edit ./configure and
have it overwritten if autoconf is run later. But that leaves plenty
of issues.
sqlite-3.3.6 is reported as unacceptable, that's why it demands a
local sqlite-amalgamation. That's what the SRPM's do for RHEL 5,
still.
swig-1.3.21 is reported as out of date and incompatible. This is why
the SRPM's used to contain a local copy, but that was discarded some
time back when support for it from people like me evaporated.
neon-0.24.7 is reported as incompatibly old, so libsvn_ra_neon is
prevented from compilation. That means no http:// access with the
Subversion binaries. The serf based compilation *might* work: i've not
had a chance to test it out, and it's certainly not a default RHEL
component. (It's available from RPMforge.)
python-2.4 or later is needed for the test suite and the Subversion
python bindings.
This is from just running the bare "./configure". There are software
tools that work well in multiple OS releases and are likely to remain
backportable. Subversion is *not* one of them, due to its ongoing
updates and reliance on more modern third party components.
Received on 2011-09-12 22:40:52 CEST