Yeah, that is why I'm working towards getting a 64-bit server, so I can
play with this stuff. I don't have any 64-bit server at the moment so
can't test out things myself.
- David
On Mon, 5 Jun 2006, Toby Johnson wrote:
> David Summers wrote:
>>
>> On Mon, 5 Jun 2006, Toby Johnson wrote:
>>
>>> Nico Kadel-Garcia wrote:
>>>> 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).
>>> Hello Nico,
>>>
>>> I've also unsuccessfully sent patches for this issue to David Summers
>>> (whom I'm also copying in) but I didn't realize the .spec sources were in
>>> the "official" repository. You may have better luck submitting a new patch
>>> directly to this list with [PATCH] in the subject (making sure it still
>>> applies cleanly to the latest trunk), although I don't know if anyone else
>>> would be willing to apply the patches.
>>>
>>> If no one is still willing to apply your patch then I will offer to host
>>> the corrected SRPMs and RHEL-4 64 bit binaries myself, but of course
>>> getting this bug fixed in the trunk would be preferable.
>>>
>>
>> Yes, please post the patch to trunk to the dev list and I'll try to pick it
>> up and run with it. I've been EXTREMELY busy the last couple of months and
>> when I have had time to work on it, I have not been able to cleanly apply
>> the pathches I've received from various people. However, sorry for
>> dropping the ball, personal health and busy schedule have slowed me way
>> down on it.
>>
>> I'm hoping to get a new 64-bit server within the month and then I'll be
>> trying this stuff out on my own system(s).
>
> Hi David, thanks for your help with the specfile... I didn't mean to imply
> you were "dropping the ball", just assumed you were too busy to integrate and
> test the patch so I was seeing if another dev could handle it. I didn't
> realize before that the OS-specific package files were kept in the official
> SVN repo or I would have sent my patch to the list instead (although it looks
> like Nico's is better anyway). I'll be glad to help with testing in any way I
> can.
>
> Also FWIW, I don't know if you received or remember my last email, but the
> free-as-in-beer VmWare Server is capable of running 64-bit virtual OSes, even
> on a 32-bit host OS, as long as your CPU is actually 64 bit. I'm running
> 64-bit CentOS 4 under WinXP 32-bit and it works great for testing specfiles
> on multiple OSes!
>
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david_at_summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 6 19:36:38 2006