Re: Long-pending patch for Stratus VOS build

2003-01-16 Thread Dave Dykstra
I think the below patch is the cause of the failure of the Irix 6.5 type
on build.samba.org, because it is complaining about line 73 of the
Makefile which at least on my Linux machine is
rsync$(EXEEXT): $(OBJS)

It might be easiest for somebody who has an Irix machine that they can
use to debug this further.

- Dave


On Fri, Jan 10, 2003 at 01:49:37PM -0600, Dave Dykstra wrote:
 On Fri, Jan 10, 2003 at 11:33:00AM -0800, Wayne Davison wrote:
  On Fri, Jan 10, 2003 at 01:23:45PM -0500, Green, Paul wrote:
   The following patch still applies cleanly to the current cvs copy of rsync.
  
  Or did before the most recent Makefile.in changes.  It's easy to merge
  this one problem, though.
  
   Does anyone object to having these changes applied now, during the
   pre-release phase?
  
  Here are my comments on the changes:
  
   + The Makefile.in changes look very safe and needed.
  
   + The install-sh change to the dsttmp value looks good.
  
   ? I have a question about the portability of the u_FOO - uFOO_t
 changes.  The former is the BSD syntax for the unsigned FOO typedefs,
 and the latter is what, POSIX?  The changes work on Linux, at least.
 Perhaps we should just make these changes and try it out on the
 compile farm.
  
   + The inet_pton changes look right to make the code consistent.  The
 only possible glitch might be a system that has a prototype for
 inet_pton() but not the library code -- if the prototype conflicts,
 the compile would fail (there are ways to work around this, but let's
 worry about that if we actually find some weird system with this
 problem).
  
  I'd be glad to check in the + changes now if Dave thinks now is a good
  time.
 
 
 Ok, go ahead.  I think it's ok to try out the ? patch on the compile
 farm too.  I know that Cygwin also uses $(EXEEXT), but apparently its
 make has been more thoroughly modified to handle things automatically
 so the Makefile doesn't have to use it as much.
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Long-pending patch for Stratus VOS build

2003-01-10 Thread Green, Paul
The following patch still applies cleanly to the current cvs copy of rsync.
I apply it each night after I grab rsync from the build farm. Without it, I
don't get far at all.  The purpose of the patch is to add executable
extension handling, which we need, and to clean up a few POSIX things and
supply defaults for a few #defines we don't have. (See the original letter
for full details).

Does anyone object to having these changes applied now, during the
pre-release phase?

http://lists.samba.org/pipermail/rsync/2002-November/008937.html

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: Long-pending patch for Stratus VOS build

2003-01-10 Thread Wayne Davison
On Fri, Jan 10, 2003 at 01:23:45PM -0500, Green, Paul wrote:
 The following patch still applies cleanly to the current cvs copy of rsync.

Or did before the most recent Makefile.in changes.  It's easy to merge
this one problem, though.

 Does anyone object to having these changes applied now, during the
 pre-release phase?

Here are my comments on the changes:

 + The Makefile.in changes look very safe and needed.

 + The install-sh change to the dsttmp value looks good.

 ? I have a question about the portability of the u_FOO - uFOO_t
   changes.  The former is the BSD syntax for the unsigned FOO typedefs,
   and the latter is what, POSIX?  The changes work on Linux, at least.
   Perhaps we should just make these changes and try it out on the
   compile farm.

 + The inet_pton changes look right to make the code consistent.  The
   only possible glitch might be a system that has a prototype for
   inet_pton() but not the library code -- if the prototype conflicts,
   the compile would fail (there are ways to work around this, but let's
   worry about that if we actually find some weird system with this
   problem).

I'd be glad to check in the + changes now if Dave thinks now is a good
time.

..wayne..
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



Re: Long-pending patch for Stratus VOS build

2003-01-10 Thread Dave Dykstra
On Fri, Jan 10, 2003 at 11:33:00AM -0800, Wayne Davison wrote:
 On Fri, Jan 10, 2003 at 01:23:45PM -0500, Green, Paul wrote:
  The following patch still applies cleanly to the current cvs copy of rsync.
 
 Or did before the most recent Makefile.in changes.  It's easy to merge
 this one problem, though.
 
  Does anyone object to having these changes applied now, during the
  pre-release phase?
 
 Here are my comments on the changes:
 
  + The Makefile.in changes look very safe and needed.
 
  + The install-sh change to the dsttmp value looks good.
 
  ? I have a question about the portability of the u_FOO - uFOO_t
changes.  The former is the BSD syntax for the unsigned FOO typedefs,
and the latter is what, POSIX?  The changes work on Linux, at least.
Perhaps we should just make these changes and try it out on the
compile farm.
 
  + The inet_pton changes look right to make the code consistent.  The
only possible glitch might be a system that has a prototype for
inet_pton() but not the library code -- if the prototype conflicts,
the compile would fail (there are ways to work around this, but let's
worry about that if we actually find some weird system with this
problem).
 
 I'd be glad to check in the + changes now if Dave thinks now is a good
 time.


Ok, go ahead.  I think it's ok to try out the ? patch on the compile
farm too.  I know that Cygwin also uses $(EXEEXT), but apparently its
make has been more thoroughly modified to handle things automatically
so the Makefile doesn't have to use it as much.

I'm looking at the --copy-unsafe-links problem and it looks very
badly broken.  I was the one who put it in the first place based on a
contributed patch, and now I'm not sure it ever worked.  It's going to
take a while to trace through the history to figure out if it worked once
and if so when it broke.  The fix is not likely to impact much, though,
so I don't think 2.5.6pre1 will need to be held up because of it because
it can go in later.

- Dave
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html



RE: Long-pending patch for Stratus VOS build

2003-01-10 Thread Green, Paul
Wayne Davison [mailto:[EMAIL PROTECTED]] wrote:
Here are my comments on the changes:

 ? I have a question about the portability of the u_FOO - uFOO_t
   changes.  The former is the BSD syntax for the unsigned FOO typedefs,
   and the latter is what, POSIX?  The changes work on Linux, at least.
   Perhaps we should just make these changes and try it out on the
   compile farm.

Yes, uFOO_t is POSIX, 1990, IIRC.  



Thanks!
PG
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html