[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: Toby Johnson <toby_at_etjohnson.us>
Date: 2006-06-05 21:26:09 CEST

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!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 5 21:26:32 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.