Subject says it all, unix tarballs at the usual location,
http://apr.apache.org/dev/dist/ (not for distribution), and
votes start now for 48 hours or until we register sufficient
+1's for release.
My vote and win32-src.zip files arriving tomorrow.
William A. Rowe, Jr. wrote:
>
> Tagged and rolled, but it will take an hr for the sync to occur, then I'll
> posit a vote thread.
That is the theory, at least, once an hour on the hour.
Two hours and twenty minutes later I'm going to bed. G'night y'all.
Bill
Jeff Trawick wrote:
> On Tue, Jun 30, 2009 at 12:12 PM, William A. Rowe, Jr.
> mailto:wr...@rowe-clan.net>> wrote:
>
> Bojan Smojver wrote:
> > On Tue, 2009-06-30 at 07:55 -0400, Jeff Trawick wrote:
> >> We didn't get any further than this on the db build compatibility
> >> issue,
On Wed, 2009-07-01 at 20:35 -0400, Jeff Trawick wrote:
> not a -1; just something to think about in the future
OK, thanks.
--
Bojan
On Wed, Jul 1, 2009 at 5:38 PM, Bojan Smojver wrote:
> On Wed, 2009-07-01 at 08:31 -0400, Jeff Trawick wrote:
> > IMO the better way to handle this would have been
> >
> > int ret, tmpret;
> >
> > and using tmpret when the function-wide ret shouldn't be touched
> >
> > Overloading "ret" and the s
Hi,
I just upgraded to apr 1.3.5 and was trying then to upgrade to apr-util
1.3.7
My previous configure line for apr-util 1.3.4 (w/apr 1.3.3) had been:
./configure --prefix=/opt/apps/apr --with-apr=/opt/apps/apr
--enable-threads --enable-nonportable-atomics
With 1.3.7 though this throws:
On Wed, 2009-07-01 at 08:31 -0400, Jeff Trawick wrote:
> IMO the better way to handle this would have been
>
> int ret, tmpret;
>
> and using tmpret when the function-wide ret shouldn't be touched
>
> Overloading "ret" and the semi-hidden setting of the function-wide ret
> make this code less cl
2009/6/30
> Author: bojan
> Date: Tue Jun 30 21:35:27 2009
> New Revision: 789965
>
> URL: http://svn.apache.org/viewvc?rev=789965&view=rev
> Log:
> Use locally scoped variables to avoid stomping on return codes.
> PR 47431.
> Patch by Wayne Jensen .
IMO the better way to handle this would have
On Tue, Jun 30, 2009 at 12:12 PM, William A. Rowe, Jr.
wrote:
> Bojan Smojver wrote:
> > On Tue, 2009-06-30 at 07:55 -0400, Jeff Trawick wrote:
> >> We didn't get any further than this on the db build compatibility
> >> issue, right?
> >
> > The --avoid-dbm options is now in. Meaning, by default,
