You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nico Kadel-Garcia <nk...@comcast.net> on 2006/06/02 22:53:07 UTC
Agggh! 64-bit bug still present in 1.3.2
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Mon, 5 Jun 2006, Nico Kadel-Garcia wrote:
> Toby Johnson wrote:
>
>> 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.
>
> Hmm. Maybe David's swamped right now? His work on this up to now has been
> very helpful, providing RPM's and SRPM's for i386 architecture. My patch is
> on
>
>> 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.
>
> My latest patch is at:
>
> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
>
OK, Thanks for the info. Will take a look at it hopefully today.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue tracker)
Posted by Marcus Rueckert <da...@web.de>.
On 2006-06-06 14:57:40 -0500, David Summers wrote:
> I've been trying for a year or so to figure out why people with NFS and
> NIS were having error/warning messages printed out in their
> /var/log/messages with a path showing MY build environment home directory
> and saying it couldn't find the libraries in that path.
>
> I finally figured out a few months ago that it was the -rpath during the
> build. I tried multiple ways of setting it during the build and couldn't
> get it to change. I found out about the chrpath command and it took me
> all of 5 minutes to try it out and fix the problem. If there is a better
> way, I'm all ears; I've spent a lot of time on the problem over the last
> year or so and this was the only way I could figure out to fix the
> problem.
>
> Reference bug # 1456
>
-L../ -lsvn_client
stuff like that breaks the rpath. (libtool voodoo). if you use libtool
to link the binaries you can just do ../../libsvn_client.la and the
problem will be gone.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue tracker)
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "Marcus Rueckert" <da...@web.de>
To: "Toby Johnson" <to...@etjohnson.us>
Cc: "David James" <dj...@collab.net>; "Nico Kadel-Garcia"
<nk...@comcast.net>; "dev" <de...@subversion.tigris.org>;
<da...@summersoft.fay.ar.us>
Sent: Tuesday, June 06, 2006 2:51 PM
Subject: Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in
issue tracker)
> On 2006-06-06 10:56:19 -0400, Toby Johnson wrote:
>> Issue 2. The "chrpath" call failed for me:
>>
>> --- 8< ----- snip ----- >8 ---
>> + chrpath -r /usr/lib64
>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so
>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so:
>> no rpath or runpath tag found.
>> error: Bad exit status from /home/toby/rpms/tmp/rpm-tmp.51994 (%install)
>>
> running chrpath inside the build process sounds a bit scary.
>
> darix
OK, first thing: the original SPEC files, and my patches to them, were only
run under and tested with RedHat bog-standard RPM setups. That means no
.rpmmacros and and no use of $HOME/rpms as a root. Could you try building it
without my patch in place and see what you get? And try it without the
.rpmmacros?
Second: the chrpath fun and games certainly predates my patch. RedHat does
not use it in their Fedora Core 5 subversion-1.3.1 version, which is
actually not bad, and might serve as a good reference..
I don't have a Linux box today to play with, but should later this week: I
won't have a 64-bit system again for a while, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issuetracker)
Posted by Marcus Rueckert <da...@web.de>.
On 2006-06-06 19:45:19 -0400, Nico Kadel-Garcia wrote:
> >On 2006-06-06 17:35:34 -0400, Nico Kadel-Garcia wrote:
> >>Take a look at the Fedora Core 5 SRPM and .spec file for
> >>subversion-1.3.1.
> >>It does some similar things, but not as part of the .spec file. Instead,
> >>the rpath option is moved out of the "LINK" command, and into a
> >>"LINK_LIBS"
> >>command, and that is called only when linking libraries, not when linking
> >>programs. This makes good sense to me and seems to help eliminate the RPM
> >>build whackiness, and can be backported to other versons of RedHat or
> >>Fedora.
> >
> >are you sure the rpath issue is still valid? it doesnt looks like that
> >to me. i tested with 1.3.2.
>
> How did you test it
reading the build log. i still saw a few -L$BUILD_DIR but no params in
the cmdline for setting the rpath.
and i double checked with maxb. he stated that svn used the la files for
linking since quite some time already instead "-L../.... -lsomelib"
hope that helps
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issuetracker)
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "Marcus Rueckert" <da...@web.de>
To: "Nico Kadel-Garcia" <nk...@comcast.net>
Cc: "Toby Johnson" <to...@etjohnson.us>; "David Summers"
<da...@summersoft.fay.ar.us>; "David James" <dj...@collab.net>; "dev"
<de...@subversion.tigris.org>
Sent: Tuesday, June 06, 2006 6:12 PM
Subject: Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in
issuetracker)
> On 2006-06-06 17:35:34 -0400, Nico Kadel-Garcia wrote:
>> Take a look at the Fedora Core 5 SRPM and .spec file for
>> subversion-1.3.1.
>> It does some similar things, but not as part of the .spec file. Instead,
>> the rpath option is moved out of the "LINK" command, and into a
>> "LINK_LIBS"
>> command, and that is called only when linking libraries, not when linking
>> programs. This makes good sense to me and seems to help eliminate the RPM
>> build whackiness, and can be backported to other versons of RedHat or
>> Fedora.
>
> are you sure the rpath issue is still valid? it doesnt looks like that
> to me. i tested with 1.3.2.
How did you test it
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issuetracker)
Posted by Marcus Rueckert <da...@web.de>.
On 2006-06-06 17:35:34 -0400, Nico Kadel-Garcia wrote:
> Take a look at the Fedora Core 5 SRPM and .spec file for subversion-1.3.1.
> It does some similar things, but not as part of the .spec file. Instead,
> the rpath option is moved out of the "LINK" command, and into a "LINK_LIBS"
> command, and that is called only when linking libraries, not when linking
> programs. This makes good sense to me and seems to help eliminate the RPM
> build whackiness, and can be backported to other versons of RedHat or
> Fedora.
are you sure the rpath issue is still valid? it doesnt looks like that
to me. i tested with 1.3.2.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in
issuetracker)
Posted by David Summers <da...@summersoft.fay.ar.us>.
Thanks for the pointer.
This has been incorporated into trunk as of r20041 and subsequently
nominated for backport to 1.3.x and 1.4.x.
- David
On Tue, 6 Jun 2006, Nico Kadel-Garcia wrote:
> ----- Original Message ----- From: "David Summers"
>>
>> On Tue, 6 Jun 2006, Toby Johnson wrote:
>>
>>> Marcus Rueckert wrote:
>>>> On 2006-06-06 10:56:19 -0400, Toby Johnson wrote:
>>>>
>>>>> Issue 2. The "chrpath" call failed for me:
>>>>>
>>>>> --- 8< ----- snip ----- >8 ---
>>>>> + chrpath -r /usr/lib64
>>>>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so
>>>>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so:
>>>>> no rpath or runpath tag found.
>>>>> error: Bad exit status from /home/toby/rpms/tmp/rpm-tmp.51994 (%install)
>>>>>
>>>>>
>>>> running chrpath inside the build process sounds a bit scary.
>>>>
>>>>
>>> That was my first reaction as well... if the library can't be found during
>>> the build, that sounds like a config problem. I'm pretty sure that the
>>> chrpath build-time dependency is a recent addition (in 1.3.1 I think);
>>> David, do you remember why this was needed?
>>>
>>
>> I've been trying for a year or so to figure out why people with NFS and NIS
>> were having error/warning messages printed out in their /var/log/messages
>> with a path showing MY build environment home directory and saying it
>> couldn't find the libraries in that path.
>>
>> I finally figured out a few months ago that it was the -rpath during the
>> build. I tried multiple ways of setting it during the build and couldn't
>> get it to change. I found out about the chrpath command and it took me all
>> of 5 minutes to try it out and fix the problem. If there is a better way,
>> I'm all ears; I've spent a lot of time on the problem over the last year or
>> so and this was the only way I could figure out to fix the problem.
>
> Take a look at the Fedora Core 5 SRPM and .spec file for subversion-1.3.1. It
> does some similar things, but not as part of the .spec file. Instead, the
> rpath option is moved out of the "LINK" command, and into a "LINK_LIBS"
> command, and that is called only when linking libraries, not when linking
> programs. This makes good sense to me and seems to help eliminate the RPM
> build whackiness, and can be backported to other versons of RedHat or Fedora.
>
>
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issuetracker)
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "David Summers" <da...@summersoft.fay.ar.us>
To: "Toby Johnson" <to...@etjohnson.us>
Cc: "David James" <dj...@collab.net>; "Nico Kadel-Garcia"
<nk...@comcast.net>; "dev" <de...@subversion.tigris.org>
Sent: Tuesday, June 06, 2006 3:57 PM
Subject: Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in
issuetracker)
>
> On Tue, 6 Jun 2006, Toby Johnson wrote:
>
>> Marcus Rueckert wrote:
>>> On 2006-06-06 10:56:19 -0400, Toby Johnson wrote:
>>>
>>>> Issue 2. The "chrpath" call failed for me:
>>>>
>>>> --- 8< ----- snip ----- >8 ---
>>>> + chrpath -r /usr/lib64
>>>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so
>>>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so:
>>>> no rpath or runpath tag found.
>>>> error: Bad exit status from /home/toby/rpms/tmp/rpm-tmp.51994
>>>> (%install)
>>>>
>>>>
>>> running chrpath inside the build process sounds a bit scary.
>>>
>>>
>> That was my first reaction as well... if the library can't be found
>> during the build, that sounds like a config problem. I'm pretty sure that
>> the chrpath build-time dependency is a recent addition (in 1.3.1 I
>> think); David, do you remember why this was needed?
>>
>
> I've been trying for a year or so to figure out why people with NFS and
> NIS were having error/warning messages printed out in their
> /var/log/messages with a path showing MY build environment home directory
> and saying it couldn't find the libraries in that path.
>
> I finally figured out a few months ago that it was the -rpath during the
> build. I tried multiple ways of setting it during the build and couldn't
> get it to change. I found out about the chrpath command and it took me
> all of 5 minutes to try it out and fix the problem. If there is a better
> way, I'm all ears; I've spent a lot of time on the problem over the last
> year or so and this was the only way I could figure out to fix the
> problem.
Take a look at the Fedora Core 5 SRPM and .spec file for subversion-1.3.1.
It does some similar things, but not as part of the .spec file. Instead, the
rpath option is moved out of the "LINK" command, and into a "LINK_LIBS"
command, and that is called only when linking libraries, not when linking
programs. This makes good sense to me and seems to help eliminate the RPM
build whackiness, and can be backported to other versons of RedHat or
Fedora.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping support for RedHat 7.3 unless someone else picks it up
Posted by David Summers <da...@summersoft.fay.ar.us>.
Thanks,
But this is on a company machine so I can't do that.
But I appreciate the sentiment.
- David Summers
On Sat, 17 Jun 2006, Nico Kadel-Garcia wrote:
> David Summers wrote:
>> To whom it may concern,
>> I've recently finished upgrading all my servers to RedHat Enterprise
>> Linux 4 and put RHEL3 into "maintenance mode" where I have it running
>> as a VMWARE guest and will continue to support the Subversion RPMs on
>> RHEL3 for probably quite some time. To do this I've had to drop
>> support for RedHat 7.3 to free up disk space on my VMWARE server for RHEL3.
>>
>> Therefore, unless someone else picks up where I left off, Subversion
>> 1.3.2 is the last release for RedHat 7.3 using my RPMs.
>
> David, what do you need to expand the space on your VMware server? Man, I'll
> *BUY* you a decent size disk if it'll help, I'm bouncing around too much to
> maintain that kind of stable web site that you're doing.
>
>> I've just noticed that 1.4.X no longer compiles because of an APR
>> requirement upgrade to APR >= 0.9.7 (I'm working on fixing that right
>> now on RH8, 9, RHEL3, and RHEL4) (I've verified that APR 0.9.12 is a
>> binary drop-in replacement for APR 0.9.4 that comes with RHEL3 and
>> RHEL4 so I'll be making that available ASAP and fixing the RPMS to
>> compile with it).
>> If anyone would like to pick up where I left off on RedHat 7.3, please
>> feel free. I'll be glad to help you get a compile environment set up
>> to build it and then help you along modifying it to compile
>> Subversion 1.4.X and later (trunk).
>>
>> Interesting Side Note: It looks like the Fedora Legacy Project is
>> still maintaining RedHat 7.3 security and critical updates at
>> http://fedoralegacy.org URL.
>
>
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Dropping support for RedHat 7.3 unless someone else picks it up
Posted by David Summers <da...@summersoft.fay.ar.us>.
Thanks,
But this is on a company machine so I can't do that.
But I appreciate the sentiment.
- David Summers
On Sat, 17 Jun 2006, Nico Kadel-Garcia wrote:
> David Summers wrote:
>> To whom it may concern,
>> I've recently finished upgrading all my servers to RedHat Enterprise
>> Linux 4 and put RHEL3 into "maintenance mode" where I have it running
>> as a VMWARE guest and will continue to support the Subversion RPMs on
>> RHEL3 for probably quite some time. To do this I've had to drop
>> support for RedHat 7.3 to free up disk space on my VMWARE server for RHEL3.
>>
>> Therefore, unless someone else picks up where I left off, Subversion
>> 1.3.2 is the last release for RedHat 7.3 using my RPMs.
>
> David, what do you need to expand the space on your VMware server? Man, I'll
> *BUY* you a decent size disk if it'll help, I'm bouncing around too much to
> maintain that kind of stable web site that you're doing.
>
>> I've just noticed that 1.4.X no longer compiles because of an APR
>> requirement upgrade to APR >= 0.9.7 (I'm working on fixing that right
>> now on RH8, 9, RHEL3, and RHEL4) (I've verified that APR 0.9.12 is a
>> binary drop-in replacement for APR 0.9.4 that comes with RHEL3 and
>> RHEL4 so I'll be making that available ASAP and fixing the RPMS to
>> compile with it).
>> If anyone would like to pick up where I left off on RedHat 7.3, please
>> feel free. I'll be glad to help you get a compile environment set up
>> to build it and then help you along modifying it to compile
>> Subversion 1.4.X and later (trunk).
>>
>> Interesting Side Note: It looks like the Fedora Legacy Project is
>> still maintaining RedHat 7.3 security and critical updates at
>> http://fedoralegacy.org URL.
>
>
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Dropping support for RedHat 7.3 unless someone else picks it up
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
David Summers wrote:
> To whom it may concern,
> I've recently finished upgrading all my servers to RedHat Enterprise
> Linux 4 and put RHEL3 into "maintenance mode" where I have it running
> as a VMWARE guest and will continue to support the Subversion RPMs on
> RHEL3 for probably quite some time. To do this I've had to drop
> support for RedHat 7.3 to free up disk space on my VMWARE server for
> RHEL3.
>
> Therefore, unless someone else picks up where I left off, Subversion
> 1.3.2 is the last release for RedHat 7.3 using my RPMs.
David, what do you need to expand the space on your VMware server? Man, I'll
*BUY* you a decent size disk if it'll help, I'm bouncing around too much to
maintain that kind of stable web site that you're doing.
> I've just noticed that 1.4.X no longer compiles because of an APR
> requirement upgrade to APR >= 0.9.7 (I'm working on fixing that right
> now on RH8, 9, RHEL3, and RHEL4) (I've verified that APR 0.9.12 is a
> binary drop-in replacement for APR 0.9.4 that comes with RHEL3 and
> RHEL4 so I'll be making that available ASAP and fixing the RPMS to
> compile with it).
> If anyone would like to pick up where I left off on RedHat 7.3, please
> feel free. I'll be glad to help you get a compile environment set up
> to build it and then help you along modifying it to compile
> Subversion 1.4.X and later (trunk).
>
> Interesting Side Note: It looks like the Fedora Legacy Project is
> still maintaining RedHat 7.3 security and critical updates at
> http://fedoralegacy.org URL.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Dropping support for RedHat 7.3 unless someone else picks it up
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
David Summers wrote:
> To whom it may concern,
> I've recently finished upgrading all my servers to RedHat Enterprise
> Linux 4 and put RHEL3 into "maintenance mode" where I have it running
> as a VMWARE guest and will continue to support the Subversion RPMs on
> RHEL3 for probably quite some time. To do this I've had to drop
> support for RedHat 7.3 to free up disk space on my VMWARE server for
> RHEL3.
>
> Therefore, unless someone else picks up where I left off, Subversion
> 1.3.2 is the last release for RedHat 7.3 using my RPMs.
David, what do you need to expand the space on your VMware server? Man, I'll
*BUY* you a decent size disk if it'll help, I'm bouncing around too much to
maintain that kind of stable web site that you're doing.
> I've just noticed that 1.4.X no longer compiles because of an APR
> requirement upgrade to APR >= 0.9.7 (I'm working on fixing that right
> now on RH8, 9, RHEL3, and RHEL4) (I've verified that APR 0.9.12 is a
> binary drop-in replacement for APR 0.9.4 that comes with RHEL3 and
> RHEL4 so I'll be making that available ASAP and fixing the RPMS to
> compile with it).
> If anyone would like to pick up where I left off on RedHat 7.3, please
> feel free. I'll be glad to help you get a compile environment set up
> to build it and then help you along modifying it to compile
> Subversion 1.4.X and later (trunk).
>
> Interesting Side Note: It looks like the Fedora Legacy Project is
> still maintaining RedHat 7.3 security and critical updates at
> http://fedoralegacy.org URL.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Dropping support for RedHat 7.3 unless someone else picks it up
Posted by David Summers <da...@summersoft.fay.ar.us>.
To whom it may concern,
I've recently finished upgrading all my servers to RedHat Enterprise
Linux 4 and put RHEL3 into "maintenance mode" where I have it running as a
VMWARE guest and will continue to support the Subversion RPMs on RHEL3 for
probably quite some time. To do this I've had to drop support for RedHat
7.3 to free up disk space on my VMWARE server for RHEL3.
Therefore, unless someone else picks up where I left off, Subversion 1.3.2
is the last release for RedHat 7.3 using my RPMs.
I've just noticed that 1.4.X no longer compiles because of an APR
requirement upgrade to APR >= 0.9.7 (I'm working on fixing that right now
on RH8, 9, RHEL3, and RHEL4) (I've verified that APR 0.9.12 is a binary
drop-in replacement for APR 0.9.4 that comes with RHEL3 and RHEL4 so I'll
be making that available ASAP and fixing the RPMS to compile with it).
If anyone would like to pick up where I left off on RedHat 7.3, please
feel free. I'll be glad to help you get a compile environment set up to
build it and then help you along modifying it to compile Subversion 1.4.X
and later (trunk).
Interesting Side Note: It looks like the Fedora Legacy Project is still
maintaining RedHat 7.3 security and critical updates at
http://fedoralegacy.org URL.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Dropping support for RedHat 7.3 unless someone else picks it up
Posted by David Summers <da...@summersoft.fay.ar.us>.
To whom it may concern,
I've recently finished upgrading all my servers to RedHat Enterprise
Linux 4 and put RHEL3 into "maintenance mode" where I have it running as a
VMWARE guest and will continue to support the Subversion RPMs on RHEL3 for
probably quite some time. To do this I've had to drop support for RedHat
7.3 to free up disk space on my VMWARE server for RHEL3.
Therefore, unless someone else picks up where I left off, Subversion 1.3.2
is the last release for RedHat 7.3 using my RPMs.
I've just noticed that 1.4.X no longer compiles because of an APR
requirement upgrade to APR >= 0.9.7 (I'm working on fixing that right now
on RH8, 9, RHEL3, and RHEL4) (I've verified that APR 0.9.12 is a binary
drop-in replacement for APR 0.9.4 that comes with RHEL3 and RHEL4 so I'll
be making that available ASAP and fixing the RPMS to compile with it).
If anyone would like to pick up where I left off on RedHat 7.3, please
feel free. I'll be glad to help you get a compile environment set up to
build it and then help you along modifying it to compile Subversion 1.4.X
and later (trunk).
Interesting Side Note: It looks like the Fedora Legacy Project is still
maintaining RedHat 7.3 security and critical updates at
http://fedoralegacy.org URL.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Dropping support for RedHat 7.3 unless someone else picks it up
Posted by David Summers <da...@summersoft.fay.ar.us>.
To whom it may concern,
I've recently finished upgrading all my servers to RedHat Enterprise
Linux 4 and put RHEL3 into "maintenance mode" where I have it running as a
VMWARE guest and will continue to support the Subversion RPMs on RHEL3 for
probably quite some time. To do this I've had to drop support for RedHat
7.3 to free up disk space on my VMWARE server for RHEL3.
Therefore, unless someone else picks up where I left off, Subversion 1.3.2
is the last release for RedHat 7.3 using my RPMs.
I've just noticed that 1.4.X no longer compiles because of an APR
requirement upgrade to APR >= 0.9.7 (I'm working on fixing that right now
on RH8, 9, RHEL3, and RHEL4) (I've verified that APR 0.9.12 is a binary
drop-in replacement for APR 0.9.4 that comes with RHEL3 and RHEL4 so I'll
be making that available ASAP and fixing the RPMS to compile with it).
If anyone would like to pick up where I left off on RedHat 7.3, please
feel free. I'll be glad to help you get a compile environment set up to
build it and then help you along modifying it to compile Subversion 1.4.X
and later (trunk).
Interesting Side Note: It looks like the Fedora Legacy Project is still
maintaining RedHat 7.3 security and critical updates at
http://fedoralegacy.org URL.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in
issue tracker)
Posted by Philip Martin <ph...@codematters.co.uk>.
David Summers <da...@summersoft.fay.ar.us> writes:
> I finally figured out a few months ago that it was the -rpath during
> the build. I tried multiple ways of setting it during the build and
> couldn't get it to change. I found out about the chrpath command and
> it took me all of 5 minutes to try it out and fix the problem. If
> there is a better way, I'm all ears; I've spent a lot of time on the
> problem over the last year or so and this was the only way I could
> figure out to fix the problem.
>
> Reference bug # 1456
Using chrpath doesn't seem like the right way to fix this.
When I build Subversion the module in the build directory has an RPATH
that refers to the build directory:
$ objdump -x subversion/mod_dav_svn/.libs/mod_dav_svn.so | grep RPATH
RPATH /home/pm/sw/subversion/obj/subversion/libsvn_repos/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_fs/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_delta/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_subr/.libs:/usr/local/subversion/lib
When I run 'make install' it uses apxs to install the module and this
relinks the module, creating .libs/mod_dav_svn.soT, which has no
references to the build directory:
$ objdump -x subversion/mod_dav_svn/.libs/mod_dav_svn.soT | grep RPATH
RPATH /usr/local/subversion/lib
The relink command uses Apache's installed libtool. After running
'make install DESTDIR=zz' I can reproduce the relink using:
$ (cd subversion/mod_dav_svn/ && /usr/local/apache2/build/libtool --mode=install cp mod_dav_svn.la /home/pm/sw/subversion/obj/zz/usr/local/apache2/modules/)
I'm using Debian's patched libtool so perhaps it works slightly
differently, but if your libtool is leaving behind references to the
build dir then that seems like a bug. When I run the libtool relink
command it prints the gcc command used to relink, what do you see when
you run it?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Tue, 6 Jun 2006, Toby Johnson wrote:
> Marcus Rueckert wrote:
>> On 2006-06-06 10:56:19 -0400, Toby Johnson wrote:
>>
>>> Issue 2. The "chrpath" call failed for me:
>>>
>>> --- 8< ----- snip ----- >8 ---
>>> + chrpath -r /usr/lib64
>>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so
>>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so:
>>> no rpath or runpath tag found.
>>> error: Bad exit status from /home/toby/rpms/tmp/rpm-tmp.51994 (%install)
>>>
>>>
>> running chrpath inside the build process sounds a bit scary.
>>
>>
> That was my first reaction as well... if the library can't be found during
> the build, that sounds like a config problem. I'm pretty sure that the
> chrpath build-time dependency is a recent addition (in 1.3.1 I think); David,
> do you remember why this was needed?
>
I've been trying for a year or so to figure out why people with NFS and
NIS were having error/warning messages printed out in their
/var/log/messages with a path showing MY build environment home directory
and saying it couldn't find the libraries in that path.
I finally figured out a few months ago that it was the -rpath during the
build. I tried multiple ways of setting it during the build and couldn't
get it to change. I found out about the chrpath command and it took me
all of 5 minutes to try it out and fix the problem. If there is a better
way, I'm all ears; I've spent a lot of time on the problem over the last
year or so and this was the only way I could figure out to fix the
problem.
Reference bug # 1456
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by Toby Johnson <to...@etjohnson.us>.
Marcus Rueckert wrote:
> On 2006-06-06 10:56:19 -0400, Toby Johnson wrote:
>
>> Issue 2. The "chrpath" call failed for me:
>>
>> --- 8< ----- snip ----- >8 ---
>> + chrpath -r /usr/lib64
>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so
>> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so:
>> no rpath or runpath tag found.
>> error: Bad exit status from /home/toby/rpms/tmp/rpm-tmp.51994 (%install)
>>
>>
> running chrpath inside the build process sounds a bit scary.
>
>
That was my first reaction as well... if the library can't be found
during the build, that sounds like a config problem. I'm pretty sure
that the chrpath build-time dependency is a recent addition (in 1.3.1 I
think); David, do you remember why this was needed?
toby
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue tracker)
Posted by Marcus Rueckert <da...@web.de>.
On 2006-06-06 10:56:19 -0400, Toby Johnson wrote:
> Issue 2. The "chrpath" call failed for me:
>
> --- 8< ----- snip ----- >8 ---
> + chrpath -r /usr/lib64
> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so
> /home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so:
> no rpath or runpath tag found.
> error: Bad exit status from /home/toby/rpms/tmp/rpm-tmp.51994 (%install)
>
running chrpath inside the build process sounds a bit scary.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by Toby Johnson <to...@etjohnson.us>.
Toby Johnson wrote:
> Issue 4. When installing the RPMs, Apache is restarted twice. No
> biggie, but I couldn't figure out why this was happening.
Sorry, I realized the reason for this as soon as I sent the email. I was
doing an rpm -Uvh, so Apache restarted once while removing my old RPM,
and once while installing the new one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by Toby Johnson <to...@etjohnson.us>.
David James wrote:
> On 6/5/06, Toby Johnson <to...@etjohnson.us> wrote:
>> David James wrote:
>>
>> > Toby, can you test Nico's patch and confirm that it
>> >
>> I assume you meant to finish this sentence with "confirm that it
>> compiles", so yes, I'll confirm it tonight.
>
> Thanks! I just want to make sure the fix is good before we release it :)
>
> Cheers,
>
> David
Hello all, I still have a few issues with building the RPMs on x86-64
using Nico's latest patch.
Issue 1. rmbuild is not able to apply apr.patch cleanly on trunk, since
configure.in has changed and no longer matches. See apr.patch.patch
(attached) for fix.
Issue 2. The "chrpath" call failed for me:
--- 8< ----- snip ----- >8 ---
+ chrpath -r /usr/lib64
/home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so
/home/toby/rpms/tmp/subversion-1.5.0-19957/usr/lib64/httpd/modules/mod_authz_svn.so:
no rpath or runpath tag found.
error: Bad exit status from /home/toby/rpms/tmp/rpm-tmp.51994 (%install)
RPM build errors:
Bad exit status from /home/toby/rpms/tmp/rpm-tmp.51994 (%install)
make: *** [build_rpm_files] Error 1
--- 8< ----- snip ----- >8 ---
I'm not very familiar w/ chrpath, but ldd seemed to indicate that
mod_authz_svn.so was indeed finding all its libraries:
--- 8< ----- snip ----- >8 ---
libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0
(0x0000002a95667000)
libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0
(0x0000002a95793000)
libz.so.1 => /usr/lib64/libz.so.1 (0x0000002a958b2000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a959c7000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95adc000)
libaprutil-0.so.0 => /usr/lib64/libaprutil-0.so.0
(0x0000002a95d0f000)
libldap-2.2.so.7 => /usr/lib64/libldap-2.2.so.7 (0x0000002a95e28000)
liblber-2.2.so.7 => /usr/lib64/liblber-2.2.so.7 (0x0000002a95f5e000)
libdb-4.2.so => /lib64/tls/libdb-4.2.so (0x0000002a9606c000)
libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x0000002a9624c000)
libapr-0.so.0 => /usr/lib64/libapr-0.so.0 (0x0000002a9636e000)
librt.so.1 => /lib64/tls/librt.so.1 (0x0000002a9649a000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a965b5000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000002a9673b000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000002a9686f000)
libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0 (0x0000002a96973000)
libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0
(0x0000002a96a79000)
/lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000002a96b82000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000002a96c97000)
libssl.so.4 => /lib64/libssl.so.4 (0x0000002a96dae000)
libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000002a96eeb000)
libsvn_fs_fs-1.so.0 => /usr/lib64/libsvn_fs_fs-1.so.0
(0x0000002a9711a000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
(0x0000002a97238000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000002a9734e000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000002a974bf000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000002a975c2000)
--- 8< ----- snip ----- >8 ---
Removing the 2 calls to "chrpath" allowed the build to continue. As far
as I can tell, the resulting modules are working fine without the
chrpath call. Nico, is chrpath working and necessary for you on x86-64?
Is there a way to tell whether it's necessary before calling it?
Issue 3. I had an unpackaged file during the build process, which was
causing rpmbuild to fail. I worked around this by setting
"_unpackaged_files_terminate_build" to 0, but I don't know enough about
RPM to know how to fix this the right way.
--- 8< ----- snip ----- >8 ---
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/toby/rpms/tmp/subversion-1.5.0-19957
error: Installed (but unpackaged) file(s) found:
/usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi/perllocal.pod
--- 8< ----- snip ----- >8 ---
Issue 4. When installing the RPMs, Apache is restarted twice. No biggie,
but I couldn't figure out why this was happening.
Issue 5. Not an issue with the spec file, but with the Makefile for
building the RPMs:
--- 8< ----- snip ----- >8 ---
cd /home/toby/rpms/sources/subversion-1.5.0-19957/../../rpms/i386; for
oldfile in *19957*; do newfile=`echo ${oldfile} | sed -e
"s/-1.5.0-19957.i386.rpm/-1.5.0-19957.rhel4.i386.rpm/"`; echo Moving
${oldfile} to ${newfile}; mv -f ${oldfile} ${newfile}; done
Moving *19957* to *19957*
mv: cannot stat `*19957*': No such file or directory
make: *** [brand_files] Error 1
--- 8< ----- snip ----- >8 ---
Of course this is because the platform is hardcoded as i386, but since
this is just cleanup stuff after the build has finished it's not a big deal.
Aside from these minor issues, the RPMs are now building for me on
x86-64 (CentOS 4).
toby
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue tracker)
Posted by David James <dj...@collab.net>.
On 6/5/06, Toby Johnson <to...@etjohnson.us> wrote:
> David James wrote:
> > On 6/5/06, Nico Kadel-Garcia <nk...@comcast.net> wrote:
> >> > 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.
> >>
> >> Hmm. Maybe David's swamped right now? His work on this up to now has
> >> been
> >> very helpful, providing RPM's and SRPM's for i386 architecture. My
> >> patch is
> >> on
> >>
> >> > 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.
> >>
> >> My latest patch is at:
> >>
> >>
> >> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
> >>
> >
> > Hi Nico,
> >
> > I'm not terribly familiar with the syntax for RPM spec files, but I
> > looked at your patch and it seems quite reasonable and useful.
> > Assuming that your patch is required to compile the RHEL-4 binaries on
> > x86_64, and that it does not cause any problems on other
> > architectures, it seems like it is definitely a good idea to commit it
> > and backport to 1.3.x.
> >
> > Cheers,
> >
> > David
> >
> > Toby, can you test Nico's patch and confirm that it
> >
> I assume you meant to finish this sentence with "confirm that it
> compiles", so yes, I'll confirm it tonight.
Thanks! I just want to make sure the fix is good before we release it :)
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by Toby Johnson <to...@etjohnson.us>.
David James wrote:
> On 6/5/06, Nico Kadel-Garcia <nk...@comcast.net> wrote:
>> > 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.
>>
>> Hmm. Maybe David's swamped right now? His work on this up to now has
>> been
>> very helpful, providing RPM's and SRPM's for i386 architecture. My
>> patch is
>> on
>>
>> > 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.
>>
>> My latest patch is at:
>>
>>
>> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
>>
>
> Hi Nico,
>
> I'm not terribly familiar with the syntax for RPM spec files, but I
> looked at your patch and it seems quite reasonable and useful.
> Assuming that your patch is required to compile the RHEL-4 binaries on
> x86_64, and that it does not cause any problems on other
> architectures, it seems like it is definitely a good idea to commit it
> and backport to 1.3.x.
>
> Cheers,
>
> David
>
> Toby, can you test Nico's patch and confirm that it
>
I assume you meant to finish this sentence with "confirm that it
compiles", so yes, I'll confirm it tonight.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue tracker)
Posted by David James <dj...@collab.net>.
On 6/5/06, Nico Kadel-Garcia <nk...@comcast.net> wrote:
> > 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.
>
> Hmm. Maybe David's swamped right now? His work on this up to now has been
> very helpful, providing RPM's and SRPM's for i386 architecture. My patch is
> on
>
> > 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.
>
> My latest patch is at:
>
> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
Hi Nico,
I'm not terribly familiar with the syntax for RPM spec files, but I
looked at your patch and it seems quite reasonable and useful.
Assuming that your patch is required to compile the RHEL-4 binaries on
x86_64, and that it does not cause any problems on other
architectures, it seems like it is definitely a good idea to commit it
and backport to 1.3.x.
Cheers,
David
Toby, can you test Nico's patch and confirm that it
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue tracker)
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Toby Johnson wrote:
> Nico Kadel-Garcia wrote:
>> My latest patch is at:
>>
>>
>> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
>>
>
> Nico, as long as we're replacing hardcoded paths with built-in
> rpmbuild macros, shouldn't the following substitutions also be made?
>
> /usr/bin => %{_bindir}
> /usr/include => %{_includedir}
> /usr/share/man => %{_mandir}
> /usr/share => %{_datadir}
Yes, in theory. I was trying to get the bare minimum of necessary patches in
place. Also, I vaguely remember having had adventures with the %{_datadir}
definitions for RedHat 7.x, although I don't have a version to test with
anymore (and haven't for a year and a half).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by Marcus Rueckert <da...@web.de>.
On 2006-06-22 08:53:24 -0500, David Summers wrote:
> OK, that patch fails when I applied it to a 32-bit system so we need
> an %ifarch statement there. If you could do that and try it out and if it
> works send that patch or tonight I can try to do that and send it to you
> and then you could try it out and let me know. Either way is fine. If I
> don't hear from you then I'll try to generate that tonight and send it
> out.
that sounds ugly. shouldnt those %{_*dir} macros save you from ifarch?
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Tue, 27 Jun 2006, Toby Johnson wrote:
> David Summers wrote:
>> Toby (and others),
>> I commited these changes as of r20256. Please check out trunk and
>> compile it on 64-bit RHEL3/RHEL4 and let me know of any problems. If you
>> can get a clean working build then let me know and I'll nominate the
>> changes in trunk for backport to 1.4.X and 1.3.X.
>
> Yes, I just did a build from trunk and it worked fine on x86_64/rhel-4.
>
Great! I'll nominate the appropriate revisions for backport to 1.4.x and
1.3.x.
Thanks!
- David
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by Toby Johnson <to...@etjohnson.us>.
David Summers wrote:
> Toby (and others),
> I commited these changes as of r20256. Please check out trunk and
> compile it on 64-bit RHEL3/RHEL4 and let me know of any problems. If you
> can get a clean working build then let me know and I'll nominate the
> changes in trunk for backport to 1.4.X and 1.3.X.
Yes, I just did a build from trunk and it worked fine on x86_64/rhel-4.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by David Summers <da...@summersoft.fay.ar.us>.
Toby (and others),
I commited these changes as of r20256. Please check out trunk and
compile it on 64-bit RHEL3/RHEL4 and let me know of any problems. If you
can get a clean working build then let me know and I'll nominate the
changes in trunk for backport to 1.4.X and 1.3.X.
Thanks.
- David Summers
On Sun, 25 Jun 2006, David Summers wrote:
> Date: Sun, 25 Jun 2006 22:28:41 -0500 (CDT)
> From: David Summers <da...@summersoft.fay.ar.us>
> Reply-To: David Summers <da...@summersoft.fay.ar.us>
> To: Toby Johnson <to...@etjohnson.us>
> Cc: Nico Kadel-Garcia <nk...@comcast.net>, dev <de...@subversion.tigris.org>
> Subject: Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
>
>
> On Thu, 22 Jun 2006, Toby Johnson wrote:
>
>> David Summers wrote:
>>>
>>> OK, that patch fails when I applied it to a 32-bit system so we need
>>> an %ifarch statement there. If you could do that and try it out and if it
>>> works send that patch or tonight I can try to do that and send it to you
>>> and then you could try it out and let me know. Either way is fine. If I
>>> don't hear from you then I'll try to generate that tonight and send it
>>> out.
>> Hi David,
>>
>> I'll work on getting that added; can you specify which part of the patch
>> causes the failure? (Or what the failure message is...)
>>
>
> OK. False alarm, sorry. I must have done something wrong the first time I
> applied the patch. I just re-applied it and compiled on CentOS4 and
> everything compiled correctly this time. Wierd.
>
> I'll do some more testing and then commit it to trunk. At that point we can
> nominate it for back-port to 1.4.x and probably even 1.3.x.
>
> Thanks for the patch!
>
>
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Thu, 22 Jun 2006, Toby Johnson wrote:
> David Summers wrote:
>>
>> OK, that patch fails when I applied it to a 32-bit system so we need
>> an %ifarch statement there. If you could do that and try it out and if it
>> works send that patch or tonight I can try to do that and send it to you
>> and then you could try it out and let me know. Either way is fine. If I
>> don't hear from you then I'll try to generate that tonight and send it out.
> Hi David,
>
> I'll work on getting that added; can you specify which part of the patch
> causes the failure? (Or what the failure message is...)
>
OK. False alarm, sorry. I must have done something wrong the first time
I applied the patch. I just re-applied it and compiled on CentOS4 and
everything compiled correctly this time. Wierd.
I'll do some more testing and then commit it to trunk. At that point we
can nominate it for back-port to 1.4.x and probably even 1.3.x.
Thanks for the patch!
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by Toby Johnson <to...@etjohnson.us>.
Toby Johnson wrote:
> David Summers wrote:
>>
>> OK, that patch fails when I applied it to a 32-bit system so we need
>> an %ifarch statement there. If you could do that and try it out and
>> if it works send that patch or tonight I can try to do that and send
>> it to you and then you could try it out and let me know. Either way
>> is fine. If I don't hear from you then I'll try to generate that
>> tonight and send it out.
> Hi David,
>
> I'll work on getting that added; can you specify which part of the
> patch causes the failure? (Or what the failure message is...)
>
FYI, I just tried building on CentOS-4 32-bit, with all tests enabled,
and it built cleanly with all tests passed. What are the specifics of
your build system? I can't imagine which of the three lines I changed
could be causing the failure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by Toby Johnson <to...@etjohnson.us>.
David Summers wrote:
>
> OK, that patch fails when I applied it to a 32-bit system so we need
> an %ifarch statement there. If you could do that and try it out and
> if it works send that patch or tonight I can try to do that and send
> it to you and then you could try it out and let me know. Either way
> is fine. If I don't hear from you then I'll try to generate that
> tonight and send it out.
Hi David,
I'll work on getting that added; can you specify which part of the patch
causes the failure? (Or what the failure message is...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by David Summers <da...@summersoft.fay.ar.us>.
OK, that patch fails when I applied it to a 32-bit system so we need
an %ifarch statement there. If you could do that and try it out and if it
works send that patch or tonight I can try to do that and send it to you
and then you could try it out and let me know. Either way is fine. If I
don't hear from you then I'll try to generate that tonight and send it
out.
Thanks.
- David
On Wed, 21 Jun 2006, Toby Johnson wrote:
> Date: Wed, 21 Jun 2006 00:54:48 -0400
> From: Toby Johnson <to...@etjohnson.us>
> To: David Summers <da...@summersoft.fay.ar.us>
> Cc: Nico Kadel-Garcia <nk...@comcast.net>, dev <de...@subversion.tigris.org>
> Subject: Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
>
> David Summers wrote:
>>
>> On Mon, 5 Jun 2006, Toby Johnson wrote:
>>
>>> Nico Kadel-Garcia wrote:
>>>> My latest patch is at:
>>>>
>>>> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
>>>
>>>
>>> Nico, as long as we're replacing hardcoded paths with built-in rpmbuild
>>> macros, shouldn't the following substitutions also be made?
>>>
>>> /usr/bin => %{_bindir}
>>> /usr/include => %{_includedir}
>>> /usr/share/man => %{_mandir}
>>> /usr/share => %{_datadir}
>>>
>>
>> If someone could try the latest trunk and see if my /usr/bin -> %{_bindir}
>> and /usr/lib -> %{_libdir} has helped 64-bit users at all and let me know,
>> it would be appreciated.
>>
>> I still don't have a 64-bit system but I will soon order one (yay, more
>> toys) so hopefully soon I'll be able to verify this stuff.
>>
>> Until then, I either need feedback from someone else or if someone could
>> offer a login on a 64-bit system for a while that would be appreciated.
>>
>> If we can get a clean 64-bit RPM build on trunk then we can back-port to
>> 1.4.x and/or 1.3.x.
>>
>
> Hello David, I finished running without checks enabled on 64-bit CentOS-4 and
> hit a couple snags, which the attached patch corrects (just a couple more
> missed /usr/lib64 locations). I'm assuming the patch can/should be applied
> for the other distros as well but I currently have no means of testing those.
>
> The Makefile for building the RPMs still doesn't work, due to the hardcoded
> 32-bit paths in there, but I'm not really worried about that... it makes it
> up to and including creation of the RPMs anyway.
>
> I'll run again with full tests and let you know if I find anything else.
>
> toby
>
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by Toby Johnson <to...@etjohnson.us>.
Nico Kadel-Garcia wrote:
> Toby Johnson wrote:
>
>>> Hello David, I finished running without checks enabled on 64-bit
>>> CentOS-4 and hit a couple snags, which the attached patch corrects
>>> (just a couple more missed /usr/lib64 locations). I'm assuming the
>>> patch can/should be applied for the other distros as well but I
>>> currently have no means of testing those.
>>>
>>> The Makefile for building the RPMs still doesn't work, due to the
>>> hardcoded 32-bit paths in there, but I'm not really worried about
>>> that... it makes it up to and including creation of the RPMs anyway.
>>>
>>> I'll run again with full tests and let you know if I find anything
>>> else.
>>>
>>> toby
>
> Hmm. David? It looks like you integrated in my earlier patch, not the
> later one I published in the bug system at
> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch.
I'm not sure what was different between your latest patch and what David
changed, but I confirmed that with the patch attached to my previous
email, the build completes correctly with all tests enabled.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Toby Johnson wrote:
>> Hello David, I finished running without checks enabled on 64-bit
>> CentOS-4 and hit a couple snags, which the attached patch corrects
>> (just a couple more missed /usr/lib64 locations). I'm assuming the
>> patch can/should be applied for the other distros as well but I
>> currently have no means of testing those.
>>
>> The Makefile for building the RPMs still doesn't work, due to the
>> hardcoded 32-bit paths in there, but I'm not really worried about
>> that... it makes it up to and including creation of the RPMs anyway.
>>
>> I'll run again with full tests and let you know if I find anything
>> else.
>>
>> toby
Hmm. David? It looks like you integrated in my earlier patch, not the later
one I published in the bug system at
http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 [PATCH]
Posted by Toby Johnson <to...@etjohnson.us>.
David Summers wrote:
>
> On Mon, 5 Jun 2006, Toby Johnson wrote:
>
>> Nico Kadel-Garcia wrote:
>>> My latest patch is at:
>>>
>>>
>>> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
>>
>>
>> Nico, as long as we're replacing hardcoded paths with built-in
>> rpmbuild macros, shouldn't the following substitutions also be made?
>>
>> /usr/bin => %{_bindir}
>> /usr/include => %{_includedir}
>> /usr/share/man => %{_mandir}
>> /usr/share => %{_datadir}
>>
>
> If someone could try the latest trunk and see if my /usr/bin ->
> %{_bindir}
> and /usr/lib -> %{_libdir} has helped 64-bit users at all and let me
> know, it would be appreciated.
>
> I still don't have a 64-bit system but I will soon order one (yay,
> more toys) so hopefully soon I'll be able to verify this stuff.
>
> Until then, I either need feedback from someone else or if someone
> could offer a login on a 64-bit system for a while that would be
> appreciated.
>
> If we can get a clean 64-bit RPM build on trunk then we can back-port
> to 1.4.x and/or 1.3.x.
>
Hello David, I finished running without checks enabled on 64-bit
CentOS-4 and hit a couple snags, which the attached patch corrects (just
a couple more missed /usr/lib64 locations). I'm assuming the patch
can/should be applied for the other distros as well but I currently have
no means of testing those.
The Makefile for building the RPMs still doesn't work, due to the
hardcoded 32-bit paths in there, but I'm not really worried about
that... it makes it up to and including creation of the RPMs anyway.
I'll run again with full tests and let you know if I find anything else.
toby
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by Toby Johnson <to...@etjohnson.us>.
David Summers wrote:
> If someone could try the latest trunk and see if my /usr/bin ->
> %{_bindir}
> and /usr/lib -> %{_libdir} has helped 64-bit users at all and let me
> know, it would be appreciated.
>
> I still don't have a 64-bit system but I will soon order one (yay,
> more toys) so hopefully soon I'll be able to verify this stuff.
>
> Until then, I either need feedback from someone else or if someone
> could offer a login on a 64-bit system for a while that would be
> appreciated.
>
> If we can get a clean 64-bit RPM build on trunk then we can back-port
> to 1.4.x and/or 1.3.x.
>
Many thanks for your help on this David! I will test it on my 64-bit
CentOS 4 and let you know how it goes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Mon, 5 Jun 2006, Toby Johnson wrote:
> Nico Kadel-Garcia wrote:
>> My latest patch is at:
>>
>> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
>
> Nico, as long as we're replacing hardcoded paths with built-in rpmbuild
> macros, shouldn't the following substitutions also be made?
>
> /usr/bin => %{_bindir}
> /usr/include => %{_includedir}
> /usr/share/man => %{_mandir}
> /usr/share => %{_datadir}
>
If someone could try the latest trunk and see if my /usr/bin -> %{_bindir}
and /usr/lib -> %{_libdir} has helped 64-bit users at all and let me know,
it would be appreciated.
I still don't have a 64-bit system but I will soon order one (yay, more
toys) so hopefully soon I'll be able to verify this stuff.
Until then, I either need feedback from someone else or if someone could
offer a login on a 64-bit system for a while that would be appreciated.
If we can get a clean 64-bit RPM build on trunk then we can back-port to
1.4.x and/or 1.3.x.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue
tracker)
Posted by Toby Johnson <to...@etjohnson.us>.
Nico Kadel-Garcia wrote:
> My latest patch is at:
>
>
> http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
>
Nico, as long as we're replacing hardcoded paths with built-in rpmbuild
macros, shouldn't the following substitutions also be made?
/usr/bin => %{_bindir}
/usr/include => %{_includedir}
/usr/share/man => %{_mandir}
/usr/share => %{_datadir}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2 (PATCH already in issue tracker)
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Toby Johnson wrote:
> 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.
Hmm. Maybe David's swamped right now? His work on this up to now has been
very helpful, providing RPM's and SRPM's for i386 architecture. My patch is
on
> 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.
My latest patch is at:
http://subversion.tigris.org/nonav/issues/showattachment.cgi/558/x86_64.patch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
David Summers wrote:
> 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).
I posted the URL to the copy in the bugzilla elsewhere. I'm glad you'll get
an x86_64 system, David: if you need any help with the vagaries of such
deployments, let me know. I've done a few thousand OS installs on such
hardware, and significant device driver integration as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Tue, 6 Jun 2006, Nico Kadel-Garcia wrote:
> ----- Original Message ----- From: "David Summers"
> <da...@summersoft.fay.ar.us>
> To: "Toby Johnson" <to...@etjohnson.us>
> Cc: "David Summers" <da...@summersoft.fay.ar.us>;
> "Nico Kadel-Garcia" <nk...@comcast.net>; "dev" <de...@subversion.tigris.org>
> Sent: Tuesday, June 06, 2006 1:21 PM
> Subject: Re: Agggh! 64-bit bug still present in 1.3.2
>
>
>>
>> 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
>
> Along those lines, David, could you possibly move that "bin" directory of
> RPM's to "i386", or make an i386 symlynk, and add an "x86_64" directory when
> you have the hardware to build those? It would make mirroring or yum'ifying
> that material a lot easier.
Good idea. Will do.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "David Summers" <da...@summersoft.fay.ar.us>
To: "Toby Johnson" <to...@etjohnson.us>
Cc: "David Summers" <da...@summersoft.fay.ar.us>;
"Nico Kadel-Garcia" <nk...@comcast.net>; "dev" <de...@subversion.tigris.org>
Sent: Tuesday, June 06, 2006 1:21 PM
Subject: Re: Agggh! 64-bit bug still present in 1.3.2
>
> 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
Along those lines, David, could you possibly move that "bin" directory of
RPM's to "i386", or make an i386 symlynk, and add an "x86_64" directory when
you have the hardware to build those? It would make mirroring or yum'ifying
that material a lot easier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by David Summers <da...@summersoft.fay.ar.us>.
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 <nk...@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@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
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by Toby Johnson <to...@etjohnson.us>.
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 <nk...@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
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by David Summers <da...@summersoft.fay.ar.us>.
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 <nk...@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).
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@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
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by Toby Johnson <to...@etjohnson.us>.
Nico Kadel-Garcia wrote:
> Erik Huelsmann wrote:
>> [Forwarding to dev@ ]
>>
>> On 6/3/06, Nico Kadel-Garcia <nk...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Erik Huelsmann wrote:
> [Forwarding to dev@ ]
>
> On 6/3/06, Nico Kadel-Garcia <nk...@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
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by Erik Huelsmann <eh...@gmail.com>.
[Forwarding to dev@ ]
On 6/3/06, Nico Kadel-Garcia <nk...@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.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Agggh! 64-bit bug still present in 1.3.2
Posted by Erik Huelsmann <eh...@gmail.com>.
[Forwarding to dev@ ]
On 6/3/06, Nico Kadel-Garcia <nk...@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.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org