[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Agggh! 64-bit bug still present in 1.3.2

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-06-03 16:18:15 CEST

Erik Huelsmann wrote:
> [Forwarding to dev@ ]
>
> On 6/3/06, Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>> There's still an RPM building present in the new 1.3.2 release: the
>> use of "/usr/lib" in the .spec files should be replaced with
>> "%{_libdir}", because on x86_64 the name of the directory for many
>> libraries is /usr/lib64. I've sent in the bug report and the patch
>> previously, darn it, and would appreciate seeing it brought into the
>> trunk. I published the patch at
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2521 several
>> months ago. Can we please have it integrated for various RedHat,
>> Fedora Core, and other users on 64-bit platforms, so that people
>> I've worked with can stop having to recompile their own versions
>> with my patches in order to use this software?
>
> May I bring to your attention that you're mailing the users@ list?
> Your question seems however targeted at the developers of Subversion.
> You're most likely to reach most of them on the dev@ mailing list when
> it comes to changing Subversion sources.

Yes, you may. Good pint. Guys on dev? Can we please get this patch
integrated for the next release? It's trivial, it provides a clear benefit,
it only affects RPM bundling, and it's very useful for people with 64-bit
hardware, increasingly common for server class setups (such as the one I
just did for a client, which is why I wrote the patch).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 3 17:56:31 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.