You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Reid <da...@jetnet.co.uk> on 2004/08/09 13:36:02 UTC
RC5
So, apart from the complaints about apr-util, are people happy that apr
RC5 is OK?
Are those who wanted the ldap code yanked now happy that it can be added
back in?
david
Re: RC5
Posted by Graham Leggett <mi...@sharp.fm>.
David Reid wrote:
> Are those who wanted the ldap code yanked now happy that it can be added
> back in?
The majority of the fooness on the LDAP stuff was caused by the attempt
to support the now archaic LDAP v2.0 C SDK, using macros. All the macros
are now gone.
Please speak up if there is anything else with the API that must not go
out the door.
Regards,
Graham
--
Re: RC5
Posted by Mladen Turk <mt...@apache.org>.
David Reid wrote:
> So, apart from the complaints about apr-util, are people happy that
> apr RC5 is OK?
>
> Are those who wanted the ldap code yanked now happy that it can be
> added back in?
>
> david
>
Here is what I'm getting trying to compile the latest HEAD on WIN32:
Creating apr_ldap.h from apr_ldap.hw
Compiling...
apr_ldap_url.c
ldap\apr_ldap_url.c(286) : warning C4013: 'apr_pstrdup' undefined;
assuming extern returning int
ldap\apr_ldap_url.c(672) : warning C4013: 'apr_strtok' undefined;
assuming extern returning int
apr_ldap_init.c
ldap\apr_ldap_init.c(199) : warning C4090: 'function' : different
'const' qualifiers
ldap\apr_ldap_init.c(222) : warning C4013: 'const_cast' undefined;
assuming extern returning int
ldap\apr_ldap_init.c(222) : error C2065: 'ldc' : undeclared identifier
ldap\apr_ldap_init.c(222) : error C2223: left of '->host' must point to
struct/union
ldap\apr_ldap_init.c(222) : warning C4047: 'function' : 'PCHAR' differs
in levels of indirection from 'int'
ldap\apr_ldap_init.c(222) : error C2223: left of '->port' must point to
struct/union
ldap\apr_ldap_init.c(222) : error C2198: 'ldap_sslinit' : too few
arguments for call through pointer-to-function
So, if the latest ldap sources are going to be in the 1.0, then they
need some fixes.
Regards,
MT.
Re: RC5
Posted by Paul Querna <ch...@force-elite.com>.
On Wed, 2004-08-18 at 09:04 -0700, Paul Querna wrote:
> On Wed, 2004-08-18 at 16:46 +0100, Joe Orton wrote:
> > On Wed, Aug 18, 2004 at 08:18:51AM -0700, Paul Querna wrote:
> > > On Wed, 2004-08-18 at 16:05 +0100, Joe Orton wrote:
> > > > On Mon, Aug 09, 2004 at 12:36:02PM +0100, David Reid wrote:
> > > > > So, apart from the complaints about apr-util, are people happy that apr
> > > > > RC5 is OK?
> > > >
> > > > +1, RC5 looks good to me. testall passes in both apr and apr-util on
> > > > RHEL3/{amd64,i686,ppc}, {RHEL2.1,FC1}/x86. If you roll an RC6 then
> > > > please pick up apr/test/testpoll.c:r1.34 which is needed to get the
> > > > tests to pass with the epoll-based poll backend on a 2.6 kernel.
> > >
> > > I thought the apr_pollset changes that add EPoll and KQueue support were
> > > not part of 1.0?
> >
> > Hmmm, well, they are in there, but CHANGES is out of synch, so one of
> > those things should be changed, I've no particular preference which.
> > Having CHANGES list 1.1 changes in the 1.0.0 tarball looks a bit odd
> > still.
> >
> > joe
>
> Hmm. It looks like the changes were picked up in RC5 only. RC4 did not
> have the pollset changes. Is this okay to release 1.0 with the pollset
> changes?
>
> -Paul Querna
Nevermind, David did mention adding it to RC5, I just didn't notice it
in his RC5 is Available Message.
-Paul
Re: RC5
Posted by Paul Querna <ch...@force-elite.com>.
On Wed, 2004-08-18 at 16:46 +0100, Joe Orton wrote:
> On Wed, Aug 18, 2004 at 08:18:51AM -0700, Paul Querna wrote:
> > On Wed, 2004-08-18 at 16:05 +0100, Joe Orton wrote:
> > > On Mon, Aug 09, 2004 at 12:36:02PM +0100, David Reid wrote:
> > > > So, apart from the complaints about apr-util, are people happy that apr
> > > > RC5 is OK?
> > >
> > > +1, RC5 looks good to me. testall passes in both apr and apr-util on
> > > RHEL3/{amd64,i686,ppc}, {RHEL2.1,FC1}/x86. If you roll an RC6 then
> > > please pick up apr/test/testpoll.c:r1.34 which is needed to get the
> > > tests to pass with the epoll-based poll backend on a 2.6 kernel.
> >
> > I thought the apr_pollset changes that add EPoll and KQueue support were
> > not part of 1.0?
>
> Hmmm, well, they are in there, but CHANGES is out of synch, so one of
> those things should be changed, I've no particular preference which.
> Having CHANGES list 1.1 changes in the 1.0.0 tarball looks a bit odd
> still.
>
> joe
Hmm. It looks like the changes were picked up in RC5 only. RC4 did not
have the pollset changes. Is this okay to release 1.0 with the pollset
changes?
-Paul Querna
Re: RC5
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Aug 18, 2004 at 08:18:51AM -0700, Paul Querna wrote:
> On Wed, 2004-08-18 at 16:05 +0100, Joe Orton wrote:
> > On Mon, Aug 09, 2004 at 12:36:02PM +0100, David Reid wrote:
> > > So, apart from the complaints about apr-util, are people happy that apr
> > > RC5 is OK?
> >
> > +1, RC5 looks good to me. testall passes in both apr and apr-util on
> > RHEL3/{amd64,i686,ppc}, {RHEL2.1,FC1}/x86. If you roll an RC6 then
> > please pick up apr/test/testpoll.c:r1.34 which is needed to get the
> > tests to pass with the epoll-based poll backend on a 2.6 kernel.
>
> I thought the apr_pollset changes that add EPoll and KQueue support were
> not part of 1.0?
Hmmm, well, they are in there, but CHANGES is out of synch, so one of
those things should be changed, I've no particular preference which.
Having CHANGES list 1.1 changes in the 1.0.0 tarball looks a bit odd
still.
joe
Re: RC5
Posted by Paul Querna <ch...@force-elite.com>.
On Wed, 2004-08-18 at 16:05 +0100, Joe Orton wrote:
> On Mon, Aug 09, 2004 at 12:36:02PM +0100, David Reid wrote:
> > So, apart from the complaints about apr-util, are people happy that apr
> > RC5 is OK?
>
> +1, RC5 looks good to me. testall passes in both apr and apr-util on
> RHEL3/{amd64,i686,ppc}, {RHEL2.1,FC1}/x86. If you roll an RC6 then
> please pick up apr/test/testpoll.c:r1.34 which is needed to get the
> tests to pass with the epoll-based poll backend on a 2.6 kernel.
>
I thought the apr_pollset changes that add EPoll and KQueue support were
not part of 1.0?
Re: RC5
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Aug 09, 2004 at 12:36:02PM +0100, David Reid wrote:
> So, apart from the complaints about apr-util, are people happy that apr
> RC5 is OK?
+1, RC5 looks good to me. testall passes in both apr and apr-util on
RHEL3/{amd64,i686,ppc}, {RHEL2.1,FC1}/x86. If you roll an RC6 then
please pick up apr/test/testpoll.c:r1.34 which is needed to get the
tests to pass with the epoll-based poll backend on a 2.6 kernel.
joe
Re: RC5
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, August 9, 2004 5:46 PM +0100 David Reid <da...@jetnet.co.uk>
wrote:
>> patch - but users of the tarball won't likely be running buildconf. [If
>> you wanted, you could include the new find_apr.m4 in 1.0 - your call.]
>
> OK. Which version is the one I should be including?
I *believe* r1.16 of build/find_apr.m4 should be okay. However, I'd like to
see some other people verify that it works now. (It worked here with autoconf
2.13.)
> Well, the way things are going I'd suggest that getting those changes into
> apr-util should be a priority. I'd look but haven't been too involved with
> it all.
I'll *try* to take a look later today...
> I debated that, but to be honest once we release 1.0.0 any momentum we have
> (what very little there remains) will dissipate very quickly - so let's go
> for all on the same day.
Understood. -- justin
Re: RC5
Posted by David Reid <da...@jetnet.co.uk>.
Justin Erenkrantz wrote:
> --On Monday, August 9, 2004 12:36 PM +0100 David Reid
> <da...@jetnet.co.uk> wrote:
>
>> So, apart from the complaints about apr-util, are people happy that
>> apr RC5
>> is OK?
>
>
> Releasing 1.0 with the known fact that autoconf-2.13 doesn't work with
> find_apr.m4 seems fine by me. We can release the latest find_apr.m4 in
> 1.0.1. Probably should document as such, or even point people at the
> patch - but users of the tarball won't likely be running buildconf. [If
> you wanted, you could include the new find_apr.m4 in 1.0 - your call.]
OK. Which version is the one I should be including?
> My only concern is that apr-util still isn't 'fixed' wrt apu-config. I
> don't know if I'll have time to port those changes over soon.
Well, the way things are going I'd suggest that getting those changes
into apr-util should be a priority. I'd look but haven't been too
involved with it all.
>
> Perhaps we can go make APR 1.0 gold and then turn our focus on wrapping
> up APR-util (and APR-iconv)? -- justin
I debated that, but to be honest once we release 1.0.0 any momentum we
have (what very little there remains) will dissipate very quickly - so
let's go for all on the same day.
Can we please have some folks looking at this stuff??
david
Re: RC5
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, August 9, 2004 8:34 PM +0100 Max Bowsher <ma...@ukf.net> wrote:
> Justin Erenkrantz wrote:
>> My only concern is that apr-util still isn't 'fixed' wrt apu-config. I
> don't
>> know if I'll have time to port those changes over soon.
>
> I've already posted a patch!
Oh, wow, you did. ;-) I'll take a look tonight at it then.
Thanks. -- justin
Re: RC5
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> My only concern is that apr-util still isn't 'fixed' wrt apu-config. I
don't
> know if I'll have time to port those changes over soon.
I've already posted a patch!
Max.
Re: RC5
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, August 9, 2004 12:36 PM +0100 David Reid <da...@jetnet.co.uk>
wrote:
> So, apart from the complaints about apr-util, are people happy that apr RC5
> is OK?
Releasing 1.0 with the known fact that autoconf-2.13 doesn't work with
find_apr.m4 seems fine by me. We can release the latest find_apr.m4 in 1.0.1.
Probably should document as such, or even point people at the patch - but
users of the tarball won't likely be running buildconf. [If you wanted, you
could include the new find_apr.m4 in 1.0 - your call.]
My only concern is that apr-util still isn't 'fixed' wrt apu-config. I don't
know if I'll have time to port those changes over soon.
Perhaps we can go make APR 1.0 gold and then turn our focus on wrapping up
APR-util (and APR-iconv)? -- justin