Re: cvs commit: apr/test aprtest.dsp aprtest.dsw aprtest.win Makefile.in sendfile.c testmmap.c client.dsp htdigest.dsp server.dsp test.dsw testarg.dsp testfile.dsp testproc.dsp testsig.dsp testsock.dsp testsuite.dsw testthread.dsp testucs.dsp timetest.dsp

2000-12-04 Thread Greg Stein
On Mon, Dec 04, 2000 at 03:39:23PM -0800, [EMAIL PROTECTED] wrote: > > > > (the standard crypt() is generally non-portable and would remain in APR; > > > > that should solve Ryan's request for a way to hash [not encode] > > > > passwords) > > > > > > We don't have a crypt routine, and there has

Re: Populating apr-util now.

2000-12-04 Thread Greg Stein
On Mon, Dec 04, 2000 at 03:30:56PM -0800, [EMAIL PROTECTED] wrote: > > The new httpd-2.0 repository is basically working, but now we need to > populate apr-util, because without it Apache won't build. I am not moving > anything out of APR that is already there, because that can wait. this is > j

Re: cvs commit: apr/test aprtest.dsp aprtest.dsw aprtest.win Makefile.in sendfile.c testmmap.c client.dsp htdigest.dsp server.dsp test.dsw testarg.dsp testfile.dsp testproc.dsp testsig.dsp testsock.dsp testsuite.dsw testthread.dsp testucs.dsp timetest.dsp

2000-12-04 Thread rbb
> > > (the standard crypt() is generally non-portable and would remain in APR; > > > that should solve Ryan's request for a way to hash [not encode] > > > passwords) > > > > We don't have a crypt routine, and there has been no discussion of putting > > crypt into APR so far. > > htpasswd uses

Populating apr-util now.

2000-12-04 Thread rbb
The new httpd-2.0 repository is basically working, but now we need to populate apr-util, because without it Apache won't build. I am not moving anything out of APR that is already there, because that can wait. this is just meant to get the bare minimum into apr-util so that the Apache developers

Re: cvs commit: apr/test aprtest.dsp aprtest.dsw aprtest.win Makefile.in sendfile.c testmmap.c client.dsp htdigest.dsp server.dsp test.dsw testarg.dsp testfile.dsp testproc.dsp testsig.dsp testsock.dsp testsuite.dsw testthread.dsp testucs.dsp timetest.dsp

2000-12-04 Thread Greg Stein
On Mon, Dec 04, 2000 at 03:11:54PM -0800, [EMAIL PROTECTED] wrote: > > > I would really prefer that we keep some way to encode passwords in > > > APR. This is a portability issue, so -1 (vote, not veto) for removing > > > md5 from APR. > > > > I'm +1 on moving them to apr-util ... MD5 hashing is

Re: cvs commit: apr/test aprtest.dsp aprtest.dsw aprtest.win Makefile.in sendfile.c testmmap.c client.dsp htdigest.dsp server.dsp test.dsw testarg.dsp testfile.dsp testproc.dsp testsig.dsp testsock.dsp testsuite.dsw testthread.dsp testucs.dsp timetest.dsp

2000-12-04 Thread rbb
> > I would really prefer that we keep some way to encode passwords in > > APR. This is a portability issue, so -1 (vote, not veto) for removing > > md5 from APR. > > I'm +1 on moving them to apr-util ... MD5 hashing is entirely portable. That > is also where SHA-1 hashing is located. > > (the

Re: cvs commit: apr/test testmmap.c

2000-12-04 Thread rbb
>return 1; > +#else > +fprintf(stdout,"APR MMAP Test\n*\n\n"); > +fprintf(stdout,"Failed! APR was not built with MMAP.\n"); > +return -1; > +#endif >} Please do not fail with a -1 here. make test checks to determine if we have failed with a -1 a

Re: cvs commit: apr/test aprtest.dsp aprtest.dsw aprtest.win Makefile.in sendfile.c testmmap.c client.dsp htdigest.dsp server.dsp test.dsw testarg.dsp testfile.dsp testproc.dsp testsig.dsp testsock.dsp testsuite.dsw testthread.dsp testucs.dsp timetest.dsp

2000-12-04 Thread Greg Stein
On Mon, Dec 04, 2000 at 02:54:33PM -0800, [EMAIL PROTECTED] wrote: > > > > Index: Makefile.in > > > === > > > -TARGETS= [EMAIL PROTECTED]@ \ > > > - [EMAIL PROTECTED]@ \ > > > +TARGETS= [EMAIL PROTECTED]@ \ > > > > md

RE: cvs commit: apr/test aprtest.dsp aprtest.dsw aprtest.win Makefile.in sendfile.c testmmap.c client.dsp htdigest.dsp server.dsp test.dsw testarg.dsp testfile.dsp testproc.dsp testsig.dsp testsock.dsp testsuite.dsw testthread.dsp testucs.dsp timetest.dsp

2000-12-04 Thread rbb
> > Index: Makefile.in > > === > > -TARGETS= [EMAIL PROTECTED]@ \ > > - [EMAIL PROTECTED]@ \ > > +TARGETS= [EMAIL PROTECTED]@ \ > > md5 (et. al.) are all moving to aprutil, correct? I would really prefer that we keep some

Re: use of libtool

2000-12-04 Thread Greg Stein
On Mon, Dec 04, 2000 at 11:42:06PM +0100, Branko Cibej wrote: > Greg Stein wrote: >... > > Sure, we'd get it to work on Linux and *BSD. Possily a Solaris and AIX box. > > But the rest? Eek. > > You're an optimist. AIX already gets a few eeks from me. Non-ELF > platforms are mostly goblins. :-) O

RE: cvs commit: apr/test aprtest.dsp aprtest.dsw aprtest.win Makefile.in sendfile.c testmmap.c client.dsp htdigest.dsp server.dsp test.dsw testarg.dsp testfile.dsp testproc.dsp testsig.dsp testsock.dsp testsuite.dsw testthread.dsp testucs.dsp timetest.dsp

2000-12-04 Thread William A. Rowe, Jr.
Three bits I didn't intend to commit, please comment if they cause problems: > wrowe 00/12/04 14:26:56 > > Log: > A brand new (and -greatly- simplified) test build > environment for Win32 > > Revision ChangesPath > 1.30 +2 -7 apr/test/Makefile.in > > Index

Re: use of libtool

2000-12-04 Thread Branko Čibej
Greg Stein wrote: I think we're going to have to / want to use libtool there, too. libtool already does it correctly for each platform, and I would *not* be confident in the slightest of us getting it right. It wouldn't be "a simple shell script"... I know that much. +1 on using libtool. I have the

RE: Where is aprlib.dsp?

2000-12-04 Thread William A. Rowe, Jr.
> From: Jim Jagielski [mailto:[EMAIL PROTECTED] > Sent: Monday, December 04, 2000 4:19 PM > > William A. Rowe, Jr. wrote: > > > > IMHO, all these win32 buildisms aught to land in helpers/ ... if > > there is no disagreement I'll drop them there (.mak/.dsp/.dsw). > > ./helpers has historically be

Re: cvs commit: apr/include apr.hw

2000-12-04 Thread Jeff Trawick
[EMAIL PROTECTED] writes: > wrowe 00/12/03 20:10:47 >/* Definitions that APR programs need to work properly. */ >#define APR_SSIZE_T_FMT "d" > +#define APR_SIZE_T_FMT "d" Darn it... Sorry! -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:

Re: cvs access for httpd group

2000-12-04 Thread rbb
> I think we will need to do that. The problem with ampersand modules > is that they naturally assume that both modules are owned by the same > groups. If we use one within httpd for apr, then we are assuming that > everyone doing a writable checkout of httpd should also have a writable > apr.

Re: [PATCH] apr_make_os_sock()

2000-12-04 Thread rbb
> > Won't it need to be different on different platforms? I mean, Windows > > wants a SOCKET, and I wouldn't put it past M$ to change the sockaddr to > > some windows specific structure in the future. > > The prototype will be the same... that is why we have the apr_os_sock_t > type. > > We sho

Re: cvs access for httpd group

2000-12-04 Thread Roy T. Fielding
> In Subversion, our analogue to "buildconf" checks for the foreign-project > subdirectories. If they aren't there, an error message is printed out > describing where/how to get that subdir and install it. > > If the auto-checkout modules thing doesn't work, then we can always have > buildconf che

Re: [PATCH] apr_make_os_sock()

2000-12-04 Thread Greg Stein
On Sun, Dec 03, 2000 at 09:27:45AM -0500, Jeff Trawick wrote: > Hopefully I didn't miss any comments on the mailing list last night > (where is that archive again?). > > Here is enough to look at to make sure I didn't screw anything up. I > added family and type parameters too so that APR doesn't

Re: [PATCH] apr_make_os_sock()

2000-12-04 Thread Greg Stein
On Sun, Dec 03, 2000 at 11:38:32AM -0800, [EMAIL PROTECTED] wrote: > > > > > Here is enough to look at to make sure I didn't screw anything up. I > > > > added family and type parameters too so that APR doesn't have to bend > > > > over backwards (i.e., use syscalls) to find that out. We don't k