You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Colm MacCarthaigh <co...@stdlib.net> on 2006/01/23 04:42:03 UTC
Time for 2.0.56 ?
I've been extremely busy for the last month, and it doesn't look like
I'll have much time for coding in the next few weeks. If anyone wants to
work on execd stuff fire away, most of what I have uncommitted is a mash
of things I have to clean up.
If anyone is waiting on it as a dependency for fcgi, using the apr API
should be safe, because an execd api can mimic that relatively easily
and I can port it later if noone beats me to it.
In the last two days, I hit two problems with 2.0.55 which have commited
patches for them (mod_proxy_ftp href and the mod_cgid OPTIONS bugs). So
I'm volunteering to RM 2.0.56.
The rate of change on 2.0.x is slowing down quite a lot lately, but it's
coming up to 6 months and there's a lot sitting there.. If I'm hitting
repeat bugs, others must be too. Unless anyone tells me I'm crazy, a
roll to vote on would be in around a week from now.
One patch which hasn't gotten review which I'm keen to get backported is
the mod_cgid suexec fix, if anyone has some time to look at it, it would
be appreciated, if I can help anyone with that - just say so. If what it
does is not clear, I can attempt to document it better. Upstream
maintainers are already asking for it and don't want it to slide too
much.
Another stalled cgid patch is the solaris autoconf patch. It would be
nice to get the newer one in (It's referenced in STATUS). So I'd like to
remove Justin's original patch proposal and put in a new one. Any
objections?
In a similar situation Adam Retter posted a cleaned-up backport of the
reverse-proxy cookie fixes to this list a few days ago too, so it would
be nice to reset the clock on that vote too - with the updated patch.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Jan 23, 2006 at 08:33:54AM +0100, Ruediger Pluem wrote:
> Are you talking about PR 34264? If yes, you have my vote if we use Justins
> second patch I referred in the STATUS. Proposed that Justins and your vote
> on this are still valid in this case we would have the needed votes.
What SVN rev are we talking about here? If it's the Solaris mod_cgid
thread check in modules/generators/config.m4, then yes, I believe I have a
+1 to 2.0.x; if not, well, here you go: +1. =) -- justin
Re: Time for 2.0.56 ?
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/23/2006 04:42 AM, Colm MacCarthaigh wrote:
[..cut..]
>
> In the last two days, I hit two problems with 2.0.55 which have commited
> patches for them (mod_proxy_ftp href and the mod_cgid OPTIONS bugs). So
> I'm volunteering to RM 2.0.56.
Thanks for volunteering. I just added a showstopper as I think that
PR37145 (data loss with httpd-2.0.55 reverse proxy method=post) needs to
fixed prior to releasing 2.0.56.
Furthermore I think PR37791 (CVEID: CAN-2005-3357) should be fixed as it
has a CVEID number assigned. It misses only one vote. Maybe Joe can help
here as he worked with me on the trunk version of the patch.
>
> Another stalled cgid patch is the solaris autoconf patch. It would be
> nice to get the newer one in (It's referenced in STATUS). So I'd like to
> remove Justin's original patch proposal and put in a new one. Any
> objections?
Are you talking about PR 34264? If yes, you have my vote if we use Justins
second patch I referred in the STATUS. Proposed that Justins and your vote
on this are still valid in this case we would have the needed votes.
Regards
Rüdiger
Re: Time for 2.0.56 ?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jan 22, 2006, at 10:42 PM, Colm MacCarthaigh wrote:
> So
> I'm volunteering to RM 2.0.56.
>
+1
>
> Another stalled cgid patch is the solaris autoconf patch. It would be
> nice to get the newer one in (It's referenced in STATUS). So I'd
> like to
> remove Justin's original patch proposal and put in a new one. Any
> objections?
>
+1 on both; STATUS updated to reflect :)
Re: Time for 2.0.56 ?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Mon, Jan 30, 2006 at 09:58:17AM +0000, Joe Orton wrote:
> The C++/AP_INIT_* problem was specific to 2.2 and does not affect 2.0,
> please file a PR for whatever problem you are having with 2.0.
Excellent, I'm not crazy! No wonder I wouldn't repeat it :)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Brandon Fosdick <bf...@bfoz.net>.
Joe Orton wrote:
> The C++/AP_INIT_* problem was specific to 2.2 and does not affect 2.0,
> please file a PR for whatever problem you are having with 2.0.
Is there some way to file a PR without creating yet another user account?
Looking back at the original problem, I'm not sure if they're the same or not. The compiler errors are different, but it's the same part of the same macro that's causing the problems. And both problems are amenable to the same solution. Here are the details in case someone can figure it out.
uname -a output:
FreeBSD dvr.bfoz.net 6.0-STABLE FreeBSD 6.0-STABLE #0: Sat Jan 21 14:57:20 PST 2006 bfoz@dvr.bfoz.net:/usr/obj/usr/src/sys/DVR i386
Here's a post to ports@freebsd.org from November:
http://lists.freebsd.org/pipermail/freebsd-ports/2005-November/027507.html
Below is the compile output from a few minutes ago. I cvsup'd ports immediately before starting the build. The offending lines in prefork.c are all uses of AP_INIT_TAKE1.
-----
19:01 bfoz@dvr/usr/ports/www/apache20#make clean distclean
<snip>
19:01 bfoz@dvr/usr/ports/www/apache20#make build
<snip>
Making all in server
Making all in mpm
Making all in prefork
/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/srclib/apr/libtool --silent --mode=compile cc -O2 -fno-strict-aliasing -pipe -march=athlon-xp -D_REENTRANT -D_THREAD_SAFE -DAP_HAVE_DESIGNATED_INITIALIZER -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/srclib/apr/include -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/srclib/apr-util/include -I/usr/local/include -I. -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/os/unix -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/server/mpm/prefork -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/modules/http -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/modules/filters -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/modules/proxy -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/include -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/modules/generators -I/usr/include/openssl -I/usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/modules/dav/main -prefer-non-pic -static -c prefork.c && touch prefork.
lo
prefork.c:1332: error: initializer element is not constant
prefork.c:1332: error: (near initialization for `prefork_cmds[3].name')
prefork.c:1332: warning: initialization from incompatible pointer type
prefork.c:1332: error: extra brace group at end of initializer
prefork.c:1332: error: (near initialization for `prefork_cmds[3].func')
prefork.c:1332: warning: excess elements in union initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].func')
prefork.c:1332: warning: excess elements in union initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].func')
prefork.c:1332: warning: excess elements in union initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].func')
prefork.c:1332: warning: excess elements in union initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].func')
prefork.c:1332: warning: excess elements in union initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].func')
prefork.c:1332: error: initializer element is not constant
prefork.c:1332: error: (near initialization for `prefork_cmds[3].func')
prefork.c:1332: warning: braces around scalar initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].cmd_data')
prefork.c:1332: warning: braces around scalar initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].cmd_data')
prefork.c:1332: error: field name not in record or union initializer
prefork.c:1332: error: (near initialization for `prefork_cmds[3].cmd_data')
prefork.c:1332: warning: excess elements in scalar initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].cmd_data')
prefork.c:1332: warning: excess elements in scalar initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].cmd_data')
prefork.c:1332: warning: excess elements in scalar initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].cmd_data')
prefork.c:1332: warning: excess elements in scalar initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].cmd_data')
prefork.c:1332: warning: excess elements in scalar initializer
prefork.c:1332: warning: (near initialization for `prefork_cmds[3].cmd_data')
prefork.c:1333: warning: braces around scalar initializer
prefork.c:1333: warning: (near initialization for `prefork_cmds[3].req_override')
prefork.c:1333: warning: initialization makes integer from pointer without a cast
prefork.c:1333: warning: braces around scalar initializer
prefork.c:1333: warning: (near initialization for `prefork_cmds[3].req_override')
prefork.c:1333: error: field name not in record or union initializer
prefork.c:1333: error: (near initialization for `prefork_cmds[3].req_override')
prefork.c:1333: warning: initialization makes integer from pointer without a cast
prefork.c:1333: warning: excess elements in scalar initializer
prefork.c:1333: warning: (near initialization for `prefork_cmds[3].req_override')
prefork.c:1333: warning: excess elements in scalar initializer
prefork.c:1333: warning: (near initialization for `prefork_cmds[3].req_override')
prefork.c:1333: warning: excess elements in scalar initializer
prefork.c:1333: warning: (near initialization for `prefork_cmds[3].req_override')
prefork.c:1333: warning: excess elements in scalar initializer
prefork.c:1333: warning: (near initialization for `prefork_cmds[3].req_override')
prefork.c:1333: warning: excess elements in scalar initializer
prefork.c:1333: warning: (near initialization for `prefork_cmds[3].req_override')
prefork.c:1335: warning: braces around scalar initializer
prefork.c:1335: warning: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: error: incompatible types in initialization
prefork.c:1335: error: initializer element is not constant
prefork.c:1335: error: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: warning: braces around scalar initializer
prefork.c:1335: warning: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: error: field name not in record or union initializer
prefork.c:1335: error: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: error: incompatible types in initialization
prefork.c:1335: error: initializer element is not constant
prefork.c:1335: error: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: warning: excess elements in scalar initializer
prefork.c:1335: warning: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: warning: excess elements in scalar initializer
prefork.c:1335: warning: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: warning: excess elements in scalar initializer
prefork.c:1335: warning: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: warning: excess elements in scalar initializer
prefork.c:1335: warning: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: warning: excess elements in scalar initializer
prefork.c:1335: warning: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1335: error: initializer element is not constant
prefork.c:1335: error: (near initialization for `prefork_cmds[3].args_how')
prefork.c:1337: warning: braces around scalar initializer
prefork.c:1337: warning: (near initialization for `prefork_cmds[3].errmsg')
prefork.c:1337: warning: braces around scalar initializer
prefork.c:1337: warning: (near initialization for `prefork_cmds[3].errmsg')
prefork.c:1337: error: field name not in record or union initializer
prefork.c:1337: error: (near initialization for `prefork_cmds[3].errmsg')
prefork.c:1337: warning: initialization from incompatible pointer type
prefork.c:1337: warning: excess elements in scalar initializer
prefork.c:1337: warning: (near initialization for `prefork_cmds[3].errmsg')
prefork.c:1337: warning: excess elements in scalar initializer
prefork.c:1337: warning: (near initialization for `prefork_cmds[3].errmsg')
prefork.c:1337: warning: excess elements in scalar initializer
prefork.c:1337: warning: (near initialization for `prefork_cmds[3].errmsg')
prefork.c:1337: warning: excess elements in scalar initializer
prefork.c:1337: warning: (near initialization for `prefork_cmds[3].errmsg')
prefork.c:1337: warning: excess elements in scalar initializer
prefork.c:1337: warning: (near initialization for `prefork_cmds[3].errmsg')
prefork.c:1339: error: initializer element is not constant
prefork.c:1339: error: (near initialization for `prefork_cmds[3]')
prefork.c:1339: error: initializer element is not constant
prefork.c:1339: error: (near initialization for `prefork_cmds[4].func')
prefork.c:1339: error: initializer element is not constant
prefork.c:1339: error: (near initialization for `prefork_cmds[4]')
prefork.c:1341: error: initializer element is not constant
prefork.c:1341: error: (near initialization for `prefork_cmds[5].func')
prefork.c:1341: error: initializer element is not constant
prefork.c:1341: error: (near initialization for `prefork_cmds[5]')
prefork.c:1343: error: initializer element is not constant
prefork.c:1343: error: (near initialization for `prefork_cmds[6]')
*** Error code 1
Stop in /usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/server/mpm/prefork.
*** Error code 1
Stop in /usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/server/mpm/prefork.
*** Error code 1
Stop in /usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/server/mpm.
*** Error code 1
Stop in /usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55/server.
*** Error code 1
Stop in /usr/tmp/usr/ports/www/apache20/work/httpd-2.0.55.
*** Error code 1
Stop in /usr/ports/www/apache20.
19:05 bfoz@dvr/usr/ports/www/apache20#
-----
Re: Time for 2.0.56 ?
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Jan 27, 2006 at 09:58:28AM -0800, Brandon Fosdick wrote:
> Colm MacCarthaigh wrote:
> >On Thu, Jan 26, 2006 at 10:50:05PM -0800, Brandon Fosdick wrote:
> >>In December, Joe Orton posted a patch to ap_config.h that took care of
> >>some problems with AP_INIT_TAKE1. Is there any chance this patch will be
> >>included in 2.0.56?
> >
> >Wasn't that problem specific to 2.2?
> >
>
> Unfortunately no, it's preventing me from compiling 2.0.55 on a
> FreeBSD6/Sempron box. For now I can either use the patch or delete the
> offending half of the #ifdef, but it would be nice if it Just Worked.
The C++/AP_INIT_* problem was specific to 2.2 and does not affect 2.0,
please file a PR for whatever problem you are having with 2.0.
Regards,
joe
Re: Time for 2.0.56 ?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Jan 27, 2006 at 09:58:28AM -0800, Brandon Fosdick wrote:
> Unfortunately no, it's preventing me from compiling 2.0.55 on a
> FreeBSD6/Sempron box. For now I can either use the patch or delete the
> offending half of the #ifdef, but it would be nice if it Just Worked.
O.k., I'll add this later too. Since it looks like some APR releases
are imminent, it's no harm delaying 2.0.56 by a few days, which will
give this a chance also.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Brandon Fosdick <bf...@bfoz.net>.
Colm MacCarthaigh wrote:
> On Thu, Jan 26, 2006 at 10:50:05PM -0800, Brandon Fosdick wrote:
>> In December, Joe Orton posted a patch to ap_config.h that took care of
>> some problems with AP_INIT_TAKE1. Is there any chance this patch will be
>> included in 2.0.56?
>
> Wasn't that problem specific to 2.2?
>
Unfortunately no, it's preventing me from compiling 2.0.55 on a
FreeBSD6/Sempron box. For now I can either use the patch or delete the
offending half of the #ifdef, but it would be nice if it Just Worked.
Re: Time for 2.0.56 ?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Thu, Jan 26, 2006 at 10:50:05PM -0800, Brandon Fosdick wrote:
> In December, Joe Orton posted a patch to ap_config.h that took care of
> some problems with AP_INIT_TAKE1. Is there any chance this patch will be
> included in 2.0.56?
Wasn't that problem specific to 2.2?
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Brandon Fosdick <bf...@bfoz.net>.
Colm MacCarthaigh wrote:
> I've been extremely busy for the last month, and it doesn't look like
> I'll have much time for coding in the next few weeks. If anyone wants to
> work on execd stuff fire away, most of what I have uncommitted is a mash
> of things I have to clean up.
<snip>
In December, Joe Orton posted a patch to ap_config.h that took care of
some problems with AP_INIT_TAKE1. Is there any chance this patch will be
included in 2.0.56?
Re: Time for 2.0.56 ?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
/bin/bash: line 1: roff: command not found
> Any idea of a time frame for 2.0.56? I was about to begin a large
> upgrade to 2.0.55 and don't want to finish it the day before 2.0.56
> comes out :)
The current release schedule is:
Friday: Integrate patches with at least 3 +1's and no
vetoes
Saturday: Allow to simmer (I'll be half way up the highest
mountain in Germany, in an igloo, so won't be
online).
Sunday: Roll and start the first vote
Monday: Pester infra to see if there's anywhere they'd
like to run 2.0.x for a few days for testing.
This might or might not happen, 1.3 doesn't get
tested like this, and downgrading to 2.0 for
a.o might give a bad impression externally.
Start crafting an announcement.
Wednesday: Upload to a.o
Thursday: Release
If a new apr release happens, we'll decide to integrate it or not too,
and if 2.2.1 comes close to syncing with the above timeline, we can
delay the release.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
/bin/bash: line 1: roff: command not found
> Any idea of a time frame for 2.0.56? I was about to begin a large
> upgrade to 2.0.55 and don't want to finish it the day before 2.0.56
> comes out :)
The current release schedule is:
Friday: Integrate patches with at least 3 +1's and no
vetoes
Saturday: Allow to simmer (I'll be half way up the highest
mountain in Germany, in an igloo, so won't be
online).
Sunday: Roll and start the first vote
Monday: Pester infra to see if there's anywhere they'd
like to run 2.0.x for a few days for testing.
This might or might not happen, 1.3 doesn't get
tested like this, and downgrading to 2.0 for
a.o might give a bad impression externally.
Start crafting an announcement.
Wednesday: Upload to a.o
Thursday: Release
If a new apr release happens, we'll decide to integrate it or not too,
and if 2.2.1 comes close to syncing with the above timeline, we can
delay the release.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Brian Akins <br...@turner.com>.
Any idea of a time frame for 2.0.56? I was about to begin a large
upgrade to 2.0.55 and don't want to finish it the day before 2.0.56
comes out :)
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: Time for 2.0.56 ?
Posted by Nick Kew <ni...@webthing.com>.
On Wednesday 25 January 2006 15:29, Colm MacCarthaigh wrote:
> On Wed, Jan 25, 2006 at 02:56:26PM +0000, Adam Retter wrote:
> > Excellent, I wasnt sure if anyone had picked it up :-/
> > Is it likely that it will get committed?
>
> I'll add a new vote today.
Bug me on IRC if I haven't voted by then. I've been meaning to
find a round tuit since you first mentioned a .56.
--
Nick Kew
Re: Time for 2.0.56 ?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Jan 25, 2006 at 02:56:26PM +0000, Adam Retter wrote:
> Excellent, I wasnt sure if anyone had picked it up :-/
> Is it likely that it will get committed?
I'll add a new vote today. Depending on when/if APR gets a release, I
think a roll by Sunday evening, with a release on February 2nd or so is
how things will work out roughly.
That might give us a change to syncronise a 2.2.x release too, and if
they get close, we can have on wait on the other if neccessary, but only
by a week at maximum.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Adam Retter <ad...@devon.gov.uk>.
On Mon, 2006-01-23 at 03:42 +0000, Colm MacCarthaigh wrote:
> I've been extremely busy for the last month, and it doesn't look like
> I'll have much time for coding in the next few weeks. If anyone wants to
> work on execd stuff fire away, most of what I have uncommitted is a mash
> of things I have to clean up.
>
> If anyone is waiting on it as a dependency for fcgi, using the apr API
> should be safe, because an execd api can mimic that relatively easily
> and I can port it later if noone beats me to it.
>
> In the last two days, I hit two problems with 2.0.55 which have commited
> patches for them (mod_proxy_ftp href and the mod_cgid OPTIONS bugs). So
> I'm volunteering to RM 2.0.56.
>
> The rate of change on 2.0.x is slowing down quite a lot lately, but it's
> coming up to 6 months and there's a lot sitting there.. If I'm hitting
> repeat bugs, others must be too. Unless anyone tells me I'm crazy, a
> roll to vote on would be in around a week from now.
>
> One patch which hasn't gotten review which I'm keen to get backported is
> the mod_cgid suexec fix, if anyone has some time to look at it, it would
> be appreciated, if I can help anyone with that - just say so. If what it
> does is not clear, I can attempt to document it better. Upstream
> maintainers are already asking for it and don't want it to slide too
> much.
>
> Another stalled cgid patch is the solaris autoconf patch. It would be
> nice to get the newer one in (It's referenced in STATUS). So I'd like to
> remove Justin's original patch proposal and put in a new one. Any
> objections?
>
> In a similar situation Adam Retter posted a cleaned-up backport of the
> reverse-proxy cookie fixes to this list a few days ago too, so it would
> be nice to reset the clock on that vote too - with the updated patch.
Excellent, I wasnt sure if anyone had picked it up :-/
Is it likely that it will get committed?
Thanks
--
Adam Retter
Devon Portal Developer
Devon Portal Project
County Hall
Exeter
Devon
EX11 1PU
t: 01392 38 3683
f: 01392 38 2966
e: adam.retter@devon.gov.uk
w: http://www.devonline.gov.uk
Re: Time for 2.0.56 ?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Mon, Jan 23, 2006 at 03:29:53PM -0500, Jim Jagielski wrote:
> On Jan 22, 2006, at 10:42 PM, Colm MacCarthaigh wrote:
> >I'll have much time for coding in the next few weeks. If anyone
> >wants to
> >work on execd stuff fire away, most of what I have uncommitted is a
> >mash
> >of things I have to clean up.
>
> Where is it?
There's an execd-dev branch, where there is very very little. The
attached mod_exec.h should give an idea of the API I'm aiming for, but
my environment died and I have a new datacentre to build, so it'll be a
while before I recover from the mess!
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jan 22, 2006, at 10:42 PM, Colm MacCarthaigh wrote:
>
> I've been extremely busy for the last month, and it doesn't look like
> I'll have much time for coding in the next few weeks. If anyone
> wants to
> work on execd stuff fire away, most of what I have uncommitted is a
> mash
> of things I have to clean up.
>
Where is it?
Re: Time for 2.0.56 ?
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Jan 27, 2006 at 04:44:50PM +0900, Masanari Iida wrote:
> Will you include following patch into 2.0 series?
> http://svn.apache.org/viewcvs?rev=370692&view=rev
I'll add a proposal, and we'll see if it gets review in time :)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Time for 2.0.56 ?
Posted by Masanari Iida <st...@gmail.com>.
Hello,
Will you include following patch into 2.0 series?
http://svn.apache.org/viewcvs?rev=370692&view=rev
It was discussed in
http://issues.apache.org/bugzilla/show_bug.cgi?id=38070
Thanks
Masanari