You are viewing a plain text version of this content. The canonical link for it is here.
Posted to testers@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2007/09/04 23:29:06 UTC
[VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Available for your testing pleasure, 3, count 'em, 3
Apache HTTP Server release candidate tarballs, located,
as expected at:
http://httpd.apache.org/dev/dist/
This vote will run through Sept 6, 2007 and close
Sept 7, unless otherwise noted...
+/-1 (x == +1)
[ ] apache_1.3.39
[ ] httpd-2.0.61
[ ] httpd-2.2.6
Thanks!!
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
+1 httpd-2.2.6, OS X 10.4.10, gcc 4.0.1
....Roy
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 9/4/2007 at 3:29 PM, in message
<BA...@jaguNET.com>, Jim Jagielski
<ji...@jaguNET.com> wrote:
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
>
> Thanks!!
+1 all Netware
Brad
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> [ ] apache_1.3.39
-0.1
The tarball apache_1.3.39.tar.gz explodes into apache-1.3/, which
isn't exactly conventional.
I'll be happy to continue and check this functionally on win32, but would
be much more enthusiastic if it unpacked to apache_1.3.39/.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> [ ] apache_1.3.39
-0.1
The tarball apache_1.3.39.tar.gz explodes into apache-1.3/, which
isn't exactly conventional.
I'll be happy to continue and check this functionally on win32, but would
be much more enthusiastic if it unpacked to apache_1.3.39/.
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
The site is updated and mirrors are on the final stages of
syncing up.
The announcement will be going out in a coupla hours.
Thanks to all!
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
The site is updated and mirrors are on the final stages of
syncing up.
The announcement will be going out in a coupla hours.
Thanks to all!
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 6, 2007, at 9:48 AM, Jim Jagielski wrote:
>
> So far, I see nothing yet preventing us from releasing
> this tomorrow... assuming that stays the same, I will
> move the files over to the main dist location to allow
> mirrors to start snagging and allow us a real release
> and announcement tomorrow.
>
I'm copying the files to the real dist location as we
speak...
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 6, 2007, at 4:33 PM, The Doctor wrote:
>
> Any chance I can test for bugs on BSD/OS ?
>
> The last time it was major.
>
Well, we are pushing out to mirrors, but that shouldn't
stop people from testing... If something shows up
we have options, the "best" option being determined by
the kind of bug, the severity, etc...
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 6, 2007, at 4:33 PM, The Doctor wrote:
>
> Any chance I can test for bugs on BSD/OS ?
>
> The last time it was major.
>
Well, we are pushing out to mirrors, but that shouldn't
stop people from testing... If something shows up
we have options, the "best" option being determined by
the kind of bug, the severity, etc...
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by The Doctor <do...@doctor.nl2k.ab.ca>.
On Thu, Sep 06, 2007 at 09:48:28AM -0400, Jim Jagielski wrote:
>
> On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote:
>
> >Available for your testing pleasure, 3, count 'em, 3
> >Apache HTTP Server release candidate tarballs, located,
> >as expected at:
> >
> > http://httpd.apache.org/dev/dist/
> >
> >This vote will run through Sept 6, 2007 and close
> >Sept 7, unless otherwise noted...
> >
>
> So far, I see nothing yet preventing us from releasing
> this tomorrow... assuming that stays the same, I will
> move the files over to the main dist location to allow
> mirrors to start snagging and allow us a real release
> and announcement tomorrow.
>
Any chance I can test for bugs on BSD/OS ?
The last time it was major.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
> For additional commands, e-mail: testers-help@httpd.apache.org
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
--
Member - Liberal International
This is doctor@nl2k.ab.ca Ici doctor@nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
PAtriots! MAke your declaration of loyalty!
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by The Doctor <do...@doctor.nl2k.ab.ca>.
On Thu, Sep 06, 2007 at 09:48:28AM -0400, Jim Jagielski wrote:
>
> On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote:
>
> >Available for your testing pleasure, 3, count 'em, 3
> >Apache HTTP Server release candidate tarballs, located,
> >as expected at:
> >
> > http://httpd.apache.org/dev/dist/
> >
> >This vote will run through Sept 6, 2007 and close
> >Sept 7, unless otherwise noted...
> >
>
> So far, I see nothing yet preventing us from releasing
> this tomorrow... assuming that stays the same, I will
> move the files over to the main dist location to allow
> mirrors to start snagging and allow us a real release
> and announcement tomorrow.
>
Any chance I can test for bugs on BSD/OS ?
The last time it was major.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
> For additional commands, e-mail: testers-help@httpd.apache.org
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
--
Member - Liberal International
This is doctor@nl2k.ab.ca Ici doctor@nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
PAtriots! MAke your declaration of loyalty!
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 6, 2007, at 9:48 AM, Jim Jagielski wrote:
>
> So far, I see nothing yet preventing us from releasing
> this tomorrow... assuming that stays the same, I will
> move the files over to the main dist location to allow
> mirrors to start snagging and allow us a real release
> and announcement tomorrow.
>
I'm copying the files to the real dist location as we
speak...
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
On 9/7/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> Jorge Schrauwen wrote:
> > Ok basic example as stated here:
> > http://fastcgi.coremail.cn/configuration.htm#regular%20fastcgi
> >
> > makes the server spit out these again:
> > [Fri Sep 07 17:49:51 2007] [error] [client 192.168.1.4
> > <http://192.168.1.4>] Premature end of script headers: printenv.pl
>
> Unfortunately the drwatson log didn't tell me a whole lot. If you crank
> the loglevel to 'debug' can we get any further hints about the failure?
>
> Does fcgid do any logging itself?
>
Doesn't seem to do any logging itself but setting LogLevel to debug did turn
up this:
[Fri Sep 07 21:18:38 2007] [info] mod_fcgid: server
S:/perl/bin/perl.exe(2312) started
Unrecognized character \x01 at - line 1.
[Fri Sep 07 21:18:44 2007] [info] mod_fcgid: process
S:/perl/bin/perl.exe(2312) exit(communication error), return code 9
funny thing is it works fine when not using mod_fcgid.
I wish I could see what perl is getting from its stdin.
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
> Ok basic example as stated here:
> http://fastcgi.coremail.cn/configuration.htm#regular%20fastcgi
>
> makes the server spit out these again:
> [Fri Sep 07 17:49:51 2007] [error] [client 192.168.1.4
> <http://192.168.1.4>] Premature end of script headers: printenv.pl
Unfortunately the drwatson log didn't tell me a whole lot. If you crank
the loglevel to 'debug' can we get any further hints about the failure?
Does fcgid do any logging itself?
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
Ok basic example as stated here:
http://fastcgi.coremail.cn/configuration.htm#regular%20fastcgi
makes the server spit out these again:
[Fri Sep 07 17:49:51 2007] [error] [client 192.168.1.4] Premature end of
script headers: printenv.pl
if I place the same script outside of the fcgid folder it works fine.
I'm now going to try more complicated examples. If they fail aswel (as I
presume they will)
Try to get you a debug dump... not sure when though busy weekend and then
first week of school.
On 9/7/07, Jorge Schrauwen <jo...@gmail.com> wrote:
>
> I got it to compile via the included projected manually adding aditional
> depedancys on libhttp, libapr-1 and libaprutil-1 did the trick.
> Now I need to find out how it is suposed to work adn see if it works or
> not
>
> On 9/7/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> >
> > Jorge Schrauwen wrote:
> > > Hmmz still getting link errors :(
> > >
> > > ---
> > > S:\source\x86\modules\mod_fcgid.2.1>apxs -llibhttpd -llibapr-1
> > > -llibaprutil-1 -c -i -a mod_fcgid.c
> > > cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG -I"S:\httpd-
> >
> > > 2.2\include" /c /Fomod_fcgid.
> > > lo mod_fcgid.c
> > > mod_fcgid.c
> > > link kernel32.lib /nologo /subsystem:windows /dll /machine:I386
> > > /libpath:"S:\httpd-2.2\lib" /out:mod_fcgid.so libhttpd.lib
> > libapr-1.lib
> > > libaprutil-1.lib mod_fcgid.lo
> > > Creating library mod_fcgid.lib and object mod_fcgid.exp
> > > mod_fcgid.lo : error LNK2001: unresolved external symbol
> > > _merge_fcgid_server_config
> >
> > That's bizare - most any author would set these up as static's within
> > their
> > modules since there is no reason to export them (or attempt to bind to
> > an
> > exported symbol. Either way, I suspect mod_fcgid.c has more source
> > files
> > than the single module source, based on these emits. (Usually it would
> > scream about exported symbol being imported).
> >
> > While on the subject, if this depends on a libfcgid, you probably need
> > to
> > bind to that lib, too.
> >
> >
>
>
> --
> ~Jorge
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
I got it to compile via the included projected manually adding aditional
depedancys on libhttp, libapr-1 and libaprutil-1 did the trick.
Now I need to find out how it is suposed to work adn see if it works or not
On 9/7/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> Jorge Schrauwen wrote:
> > Hmmz still getting link errors :(
> >
> > ---
> > S:\source\x86\modules\mod_fcgid.2.1>apxs -llibhttpd -llibapr-1
> > -llibaprutil-1 -c -i -a mod_fcgid.c
> > cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG -I"S:\httpd-
> > 2.2\include" /c /Fomod_fcgid.
> > lo mod_fcgid.c
> > mod_fcgid.c
> > link kernel32.lib /nologo /subsystem:windows /dll /machine:I386
> > /libpath:"S:\httpd-2.2\lib" /out:mod_fcgid.so libhttpd.lib libapr-1.lib
> > libaprutil-1.lib mod_fcgid.lo
> > Creating library mod_fcgid.lib and object mod_fcgid.exp
> > mod_fcgid.lo : error LNK2001: unresolved external symbol
> > _merge_fcgid_server_config
>
> That's bizare - most any author would set these up as static's within
> their
> modules since there is no reason to export them (or attempt to bind to an
> exported symbol. Either way, I suspect mod_fcgid.c has more source files
> than the single module source, based on these emits. (Usually it would
> scream about exported symbol being imported).
>
> While on the subject, if this depends on a libfcgid, you probably need to
> bind to that lib, too.
>
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
> Hmmz still getting link errors :(
>
> ---
> S:\source\x86\modules\mod_fcgid.2.1>apxs -llibhttpd -llibapr-1
> -llibaprutil-1 -c -i -a mod_fcgid.c
> cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG -I"S:\httpd-
> 2.2\include" /c /Fomod_fcgid.
> lo mod_fcgid.c
> mod_fcgid.c
> link kernel32.lib /nologo /subsystem:windows /dll /machine:I386
> /libpath:"S:\httpd-2.2\lib" /out:mod_fcgid.so libhttpd.lib libapr-1.lib
> libaprutil-1.lib mod_fcgid.lo
> Creating library mod_fcgid.lib and object mod_fcgid.exp
> mod_fcgid.lo : error LNK2001: unresolved external symbol
> _merge_fcgid_server_config
That's bizare - most any author would set these up as static's within their
modules since there is no reason to export them (or attempt to bind to an
exported symbol. Either way, I suspect mod_fcgid.c has more source files
than the single module source, based on these emits. (Usually it would
scream about exported symbol being imported).
While on the subject, if this depends on a libfcgid, you probably need to
bind to that lib, too.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
Hmmz still getting link errors :(
---
S:\source\x86\modules\mod_fcgid.2.1>apxs -llibhttpd -llibapr-1
-llibaprutil-1 -c -i -a mod_fcgid.c
cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG -I"S:\httpd-
2.2\include" /c /Fomod_fcgid.
lo mod_fcgid.c
mod_fcgid.c
link kernel32.lib /nologo /subsystem:windows /dll /machine:I386
/libpath:"S:\httpd-2.2\lib" /out:mod_fcgid.so libhttpd.lib libapr-1.lib
libaprutil-1.lib mod_fcgid.lo
Creating library mod_fcgid.lib and object mod_fcgid.exp
mod_fcgid.lo : error LNK2001: unresolved external symbol
_merge_fcgid_server_config
mod_fcgid.lo : error LNK2001: unresolved external symbol
_create_fcgid_server_config
mod_fcgid.lo : error LNK2001: unresolved external symbol
_create_fcgid_dir_config
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_access_authoritative
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_access_info
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_authorizer_authoritative
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_authorizer_info
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_authenticator_authoritative
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_authenticator_info
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_max_requests_per_process
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_php_fix_pathinfo_enable
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_wrapper_config
mod_fcgid.lo : error LNK2001: unresolved external symbol
_add_default_env_vars
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_ipc_comm_timeout
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_ipc_connect_timeout
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_output_buffersize
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_min_class_process
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_max_class_process
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_max_process
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_termination_score
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_spawn_score
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_spawnscore_uplimit
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_shmpath
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_socketpath
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_proc_lifetime
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_zombie_scan_interval
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_error_scan_interval
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_busy_scan_interval
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_busy_timeout
mod_fcgid.lo : error LNK2001: unresolved external symbol
_set_idle_scan_interval
mod_fcgid.lo : error LNK2001: unresolved external symbol _set_idle_timeout
mod_fcgid.lo : error LNK2019: unresolved external symbol _bridge_request
referenced in function _fcgid_handler
mod_fcgid.lo : error LNK2019: unresolved external symbol _get_wrapper_info
referenced in function _fcgid_handler
mod_fcgid.lo : error LNK2019: unresolved external symbol
_get_authenticator_info referenced in function _mod_fcgid_authenticator
mod_fcgid.lo : error LNK2019: unresolved external symbol
_get_authorizer_info referenced in function _mod_fcgid_authorizer
mod_fcgid.lo : error LNK2019: unresolved external symbol _get_access_info
referenced in function _mod_fcgid_check_access
mod_fcgid.lo : error LNK2019: unresolved external symbol _procmgr_child_init
referenced in function_initialize_child
mod_fcgid.lo : error LNK2019: unresolved external symbol
_proctable_child_init referenced in function _initialize_child
mod_fcgid.lo : error LNK2019: unresolved external symbol
_procmgr_post_config referenced in function _fcgid_init
mod_fcgid.lo : error LNK2019: unresolved external symbol
_proctable_post_config referenced in function _fcgid_init
mod_fcgid.lo : error LNK2019: unresolved external symbol
_get_php_fix_pathinfo_enable referenced in function _fcgid_init
mod_fcgid.lo : error LNK2019: unresolved external symbol _fcgid_filter
referenced in function _register_hooks
mod_fcgid.so : fatal error LNK1120: 42 unresolved externals
apxs:Error: Command failed with rc=6291456
---
Oh well, I gave it my best.
On 9/7/07, Issac Goldstand <ma...@beamartyr.net> wrote:
>
> Pass "-llibhttpd -llibapr-1 -llibaprutil-1" before "-c mod_fgid.c ..."
>
> Jorge Schrauwen wrote:
> > Any more info how you got it to work with apxs?
> >
> > ~ Jorge
> >
> > On 9/7/07, *Issac Goldstand* <margol@beamartyr.net
> > <ma...@beamartyr.net>> wrote:
> >
> > win32/vc8 +1 (not that it makes much of a difference at this point
> :))
> > I've gotten mod_fcgid built against it (though apxs-win32-0.6 is
> still
> > not doing -llibhttpd -llibapr-1 and -llibaprutil-1 by default) I'm
> not
> > quite sure what the original issue is there, and I've no clue how to
> > actually use it, but if someone wants to spoonfeed me instructions
> on
> > how to make it crash, I'd be happy to take a look (or at least post
> a
> > backtrace, if I don't have time to investigate myself)
> >
> > Issac
> >
> > Issac Goldstand wrote:
> > > I'll try it as soon as it shows up.
> > >
> > > William A. Rowe, Jr. wrote:
> > >> Issac Goldstand wrote:
> > >>> Uh. Maybe I've lost it, but where's the source for apr-iconv in
> > >>> http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
> > >>>
> > >>> All I get is an .rc file and a couple of .deps and .maks
> > >> I just pulled an "OH SHIT" moment myself building on x86_64
> > windows...
> > >>
> > >> ... there are -r2.zip packages up now, and I just updated the
> > site svn,
> > >> but I presume Jim hadn't pulled that site update to live so I'm
> > leaving
> > >> it for him.
> > >>
> > >> C.f.
> http://www.apache.org/dist/httpd/httpd-2.2.6-win32-src-r2.zip
> > >>
> > >> ...not quite arrived from our staging to live server yet.
> > >>
> > >> Bill
> >
> >
> >
> >
> > --
> > ~Jorge
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
> Yeah I figured it out a bit later and it indeed seems broke. Not sure
> whats wrong though I posted a debug log + user dump yesterday.
The debug log was unfortunately not very interesting, since it wasn't doing
anything out of the ordinary at the time you interrupted the process. It's
also not quite decipherable, you would have to build at minimum with /Oy-
and ideally with /Zi for your compile flags, /debug (to create pdb's also
for third party modules) to the linker. And to let Dr Watson dig through
all the particularities of your system libraries, you can use WinDbg (a free
download from MS) which has a very nice feature; you set up a local SymStore
that can suck down the .pdb's of almost any Microsoft shipped .dll through
an envvar that looks like;
_NT_SYMBOL_PATH=srv*G:\symstore*http://msdl.microsoft.com/download/symbols
...like magic your crash dumps will include all backtraces through the
win32 dll's and nt kernel.
We do know something more about this flaw at this point; you'll find most
of the details at
http://issues.apache.org/bugzilla/show_bug.cgi?id=43329
Thankfully Tom's created this incident after (correctly) diagnosing what
libfcgid does on Win32. It's trivial to solve, as Tom noted and I had
further corrected in that incident, however it reverts to existing broken
behavior with respect to APR.
Apparently mod_fcgid has long assumed that invalid handles are it's clue
that it should run. Foolish Win32-ish assumption; and the way it behaves
when compiled under VC6 and VC8 seem to significantly disagree. This
might be because VC8 tries to be more clever about "repairing" broken
stdhandles for console applications.
The bottom lines are these; the APR library exists to keep applications
consistent - the basic behavior is that fd's 0, 1, 2 (Win32's STD HANDLE
values) inherit the parent's pipes if not explicitly defined; some apps
fail miserably when runing in a service context with a sub-par set of
handles (e.g. cmd.exe for one, while on unix a program will open a file
only to discover that fd occupies slot 0, 1, or 2 and becomes corrupted).
So the question becomes; fix libfcgid? And/or; add an explicit and very
platform independent feature to NOT inherit undefined handles from the
parent to child process? If this feature were added, it would be possible
to say NO_PIPE to all three handles, and on unix have fd's 0/1/2 all
unused, on windows have them all contain INVALID_HANDLE_VALUE's. I'm
sure there is a valid use case for this across platforms.
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
Yeah I figured it out a bit later and it indeed seems broke. Not sure whats
wrong though I posted a debug log + user dump yesterday.
On 9/8/07, Randy Kobes <ra...@theoryx5.uwinnipeg.ca> wrote:
>
> On Fri, 7 Sep 2007, Jorge Schrauwen wrote:
>
> > Any more info how you got it to work with apxs?
>
> This works for me:
>
> C:\> C:\Apache2\bin\apxs -llibhttpd -D APACHE2 -p
> -IC:\Temp\mod_fcgid.2.1 -o mod_fcgid.so -c mod_fcgid.c
> fcgid_bridge.c fcgid_conf.c fcgid_pm_main.c
> arch\win32\fcgid_pm_win.c arch\win32\fcgid_proc_win.c
> arch\win32\fcgid_proctbl_win.c fcgid_protocol.c
> fcgid_spawn_ctl.c fcgid_bucket.c fcgid_filter.c
>
> (all on one line).
>
> --
> best regards,
> Randy
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 7 Sep 2007, Jorge Schrauwen wrote:
> Any more info how you got it to work with apxs?
This works for me:
C:\> C:\Apache2\bin\apxs -llibhttpd -D APACHE2 -p
-IC:\Temp\mod_fcgid.2.1 -o mod_fcgid.so -c mod_fcgid.c
fcgid_bridge.c fcgid_conf.c fcgid_pm_main.c
arch\win32\fcgid_pm_win.c arch\win32\fcgid_proc_win.c
arch\win32\fcgid_proctbl_win.c fcgid_protocol.c
fcgid_spawn_ctl.c fcgid_bucket.c fcgid_filter.c
(all on one line).
--
best regards,
Randy
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by Issac Goldstand <ma...@beamartyr.net>.
Pass "-llibhttpd -llibapr-1 -llibaprutil-1" before "-c mod_fgid.c ..."
Jorge Schrauwen wrote:
> Any more info how you got it to work with apxs?
>
> ~ Jorge
>
> On 9/7/07, *Issac Goldstand* <margol@beamartyr.net
> <ma...@beamartyr.net>> wrote:
>
> win32/vc8 +1 (not that it makes much of a difference at this point :))
> I've gotten mod_fcgid built against it (though apxs-win32-0.6 is still
> not doing -llibhttpd -llibapr-1 and -llibaprutil-1 by default) I'm not
> quite sure what the original issue is there, and I've no clue how to
> actually use it, but if someone wants to spoonfeed me instructions on
> how to make it crash, I'd be happy to take a look (or at least post a
> backtrace, if I don't have time to investigate myself)
>
> Issac
>
> Issac Goldstand wrote:
> > I'll try it as soon as it shows up.
> >
> > William A. Rowe, Jr. wrote:
> >> Issac Goldstand wrote:
> >>> Uh. Maybe I've lost it, but where's the source for apr-iconv in
> >>> http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
> >>>
> >>> All I get is an .rc file and a couple of .deps and .maks
> >> I just pulled an "OH SHIT" moment myself building on x86_64
> windows...
> >>
> >> ... there are -r2.zip packages up now, and I just updated the
> site svn,
> >> but I presume Jim hadn't pulled that site update to live so I'm
> leaving
> >> it for him.
> >>
> >> C.f. http://www.apache.org/dist/httpd/httpd-2.2.6-win32-src-r2.zip
> >>
> >> ...not quite arrived from our staging to live server yet.
> >>
> >> Bill
>
>
>
>
> --
> ~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
Any more info how you got it to work with apxs?
~ Jorge
On 9/7/07, Issac Goldstand <ma...@beamartyr.net> wrote:
>
> win32/vc8 +1 (not that it makes much of a difference at this point :))
> I've gotten mod_fcgid built against it (though apxs-win32-0.6 is still
> not doing -llibhttpd -llibapr-1 and -llibaprutil-1 by default) I'm not
> quite sure what the original issue is there, and I've no clue how to
> actually use it, but if someone wants to spoonfeed me instructions on
> how to make it crash, I'd be happy to take a look (or at least post a
> backtrace, if I don't have time to investigate myself)
>
> Issac
>
> Issac Goldstand wrote:
> > I'll try it as soon as it shows up.
> >
> > William A. Rowe, Jr. wrote:
> >> Issac Goldstand wrote:
> >>> Uh. Maybe I've lost it, but where's the source for apr-iconv in
> >>> http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
> >>>
> >>> All I get is an .rc file and a couple of .deps and .maks
> >> I just pulled an "OH SHIT" moment myself building on x86_64 windows...
> >>
> >> ... there are -r2.zip packages up now, and I just updated the site svn,
> >> but I presume Jim hadn't pulled that site update to live so I'm leaving
> >> it for him.
> >>
> >> C.f. http://www.apache.org/dist/httpd/httpd-2.2.6-win32-src-r2.zip
> >>
> >> ...not quite arrived from our staging to live server yet.
> >>
> >> Bill
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
> Didn't even notice... I usually take the tar.gz source and add in
> apr-iconv myself then run lineends.pl that is included in
> srclib/apr/build/, I also run cvtdsp.pl -2005 on there before I start.
>
> I didn't even seen a - win32-src.zip at that time.
Bingo - that's how I do it. In fact the httpd-* win32-src files start
out their existence as unix httpd*.tar.gz unix targets.
In this case, I had moved apr-iconv to srclib/ in my builds, but not in
the package, and that's what exploded 2.2.6. When I xcopy /s/v *.mak
etc, it just added iconv build foo with no source foo.
Fortunately, I (and Issac) caught this even before Jim took things live,
so no bother.
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
Didn't even notice... I usually take the tar.gz source and add in apr-iconv
myself then run lineends.pl that is included in srclib/apr/build/, I also
run cvtdsp.pl -2005 on there before I start.
I didn't even seen a -win32-src.zip at that time.
On 9/7/07, Issac Goldstand <ma...@beamartyr.net> wrote:
>
> And Jorge, yeah. I was wondering if I was just getting a really really
> oddly maimed ZIP :-)
>
> William A. Rowe, Jr. wrote:
> > Issac Goldstand wrote:
> >> Uh. Maybe I've lost it, but where's the source for apr-iconv in
> >> http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
> >>
> >> All I get is an .rc file and a couple of .deps and .maks
> >
> > and /me wonders what Steffan thinks he built ROFL
> >
> > Bill
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
Several 2rd-party modules (mod_fcgid, mod_fastcgi, mod_perl, mod_watch etc.)
are given issues with 2.2.6 on Windows.
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>
Sent: Thursday, 06 September, 2007 22:20
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
> Ummm hrmm:
>
> "A hurry backport is causing this and there is hardly
> tested in real live. Hopefully ASF comes with a patch soon. "
>
> So you know what's causing this? Please point out the exact
> "hurry backport" so we can look there.
>
> And again, WHAT OTHER 3rd party modules are having problems??
> Can you provide ANY FURTHER information other than cryptic "its
> not working" messages followed by "ASF hates Windows users"
> comments??
>
> If we *knew* what the problems were, we'd try like heck to fix
> 'em. I know Bill looked hard and long, but had no luck,
> mostly because the amount of real concrete data was woefully
> lacking.
>
> On Sep 6, 2007, at 4:08 PM, Steffen wrote:
>
>> Better we stop this thread.
>>
>> See the post at: http://www.apachelounge.com/forum/viewtopic.php? p=8691
>> , please do not reply to that post.
>>
>> Steffen
>>
>> ----- Original Message ----- From: "Jim Jagielski" <ji...@jaguNET.com>
>> To: <de...@httpd.apache.org>
>> Sent: Thursday, 06 September, 2007 21:47
>> Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
>> tarballs for review
>>
>>
>>>
>>> On Sep 6, 2007, at 3:25 PM, Steffen wrote:
>>>
>>>>>
>>>>> I'm assuming the "we" is you, right?
>>>>>
>>>>
>>>> It is not just me. We are a team and of course the users. Just as an
>>>> example
>>>> the other post from me here which is a report from an other
>>>> webmaster. I
>>>> report here test results from the Apache Windows Community from the
>>>> Apache
>>>> Lounge, mostly I receive them by mail.
>>>>
>>>
>>> You said that "we" need to:
>>> "advise the users not to use 2.2.6 because is not compatible with
>>> some mods"
>>>
>>> which, afaik, is not the case. You reported issues with mod_fcgid,
>>> which
>>> may be true, but that hasn't been confirmed by anyone else, nor do
>>> I see reports to support the "some mods" statement as well.
>>> Unless, of course, the cryptic phrase "An other report"
>>> actually means "The below is a report from someone else
>>> who is also seeing an issue" instead of "Oh, by the way, I
>>> also tried this personally and I see that mod_cgi is working OK
>>> for me..."...
>>>
>>> With all this being the case, I can't see holding up a release nor
>>> can I see us ("us" being the ASF) making some blanket statement that
>>> Win32 users should not use 2.2.6 because it is not compatible with
>>> some mods... If we had some more supporting data for that, then
>>> maybe...
>>>
>>>> Maybe we have to patch 2.2.6 to get it error-free.
>>>
>>> Well, there is the patches directory that, if we discover
>>> a bug, allows people to download the patch and rebuild. Of
>>> course, this all means tracking down and discovering the
>>> bug with some detailed debugging info rather than a "it
>>> doesn't work" :)
>>>
>>
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
I am a typical Windows user and not a developer. Yes I can build with VC and
can do little adjustments in C++
Sorry I cannot give more info, it is just not working with no signs in the
Apache logs.
As I told, the authors are looking at it, had to wait when they have more
info.
Maybe I am thinking to simple, 2.2.6 contains some backports over 2.2.5 so a
big change that one of lines in the change log must cause this.
Oh btw, we/I do not hate ASF at all, we Windows users sometimes crying for a
little more attention. This is the main reason that the Apache Lounge is
started.
Can we stop now this discussion ?
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>
Sent: Thursday, 06 September, 2007 22:20
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
> Ummm hrmm:
>
> "A hurry backport is causing this and there is hardly
> tested in real live. Hopefully ASF comes with a patch soon. "
>
> So you know what's causing this? Please point out the exact
> "hurry backport" so we can look there.
>
> And again, WHAT OTHER 3rd party modules are having problems??
> Can you provide ANY FURTHER information other than cryptic "its
> not working" messages followed by "ASF hates Windows users"
> comments??
>
> If we *knew* what the problems were, we'd try like heck to fix
> 'em. I know Bill looked hard and long, but had no luck,
> mostly because the amount of real concrete data was woefully
> lacking.
>
> On Sep 6, 2007, at 4:08 PM, Steffen wrote:
>
>> Better we stop this thread.
>>
>> See the post at: http://www.apachelounge.com/forum/viewtopic.php? p=8691
>> , please do not reply to that post.
>>
>> Steffen
>>
>> ----- Original Message ----- From: "Jim Jagielski" <ji...@jaguNET.com>
>> To: <de...@httpd.apache.org>
>> Sent: Thursday, 06 September, 2007 21:47
>> Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
>> tarballs for review
>>
>>
>>>
>>> On Sep 6, 2007, at 3:25 PM, Steffen wrote:
>>>
>>>>>
>>>>> I'm assuming the "we" is you, right?
>>>>>
>>>>
>>>> It is not just me. We are a team and of course the users. Just as an
>>>> example
>>>> the other post from me here which is a report from an other
>>>> webmaster. I
>>>> report here test results from the Apache Windows Community from the
>>>> Apache
>>>> Lounge, mostly I receive them by mail.
>>>>
>>>
>>> You said that "we" need to:
>>> "advise the users not to use 2.2.6 because is not compatible with
>>> some mods"
>>>
>>> which, afaik, is not the case. You reported issues with mod_fcgid,
>>> which
>>> may be true, but that hasn't been confirmed by anyone else, nor do
>>> I see reports to support the "some mods" statement as well.
>>> Unless, of course, the cryptic phrase "An other report"
>>> actually means "The below is a report from someone else
>>> who is also seeing an issue" instead of "Oh, by the way, I
>>> also tried this personally and I see that mod_cgi is working OK
>>> for me..."...
>>>
>>> With all this being the case, I can't see holding up a release nor
>>> can I see us ("us" being the ASF) making some blanket statement that
>>> Win32 users should not use 2.2.6 because it is not compatible with
>>> some mods... If we had some more supporting data for that, then
>>> maybe...
>>>
>>>> Maybe we have to patch 2.2.6 to get it error-free.
>>>
>>> Well, there is the patches directory that, if we discover
>>> a bug, allows people to download the patch and rebuild. Of
>>> course, this all means tracking down and discovering the
>>> bug with some detailed debugging info rather than a "it
>>> doesn't work" :)
>>>
>>
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by Issac Goldstand <ma...@beamartyr.net>.
win32/vc8 +1 (not that it makes much of a difference at this point :))
I've gotten mod_fcgid built against it (though apxs-win32-0.6 is still
not doing -llibhttpd -llibapr-1 and -llibaprutil-1 by default) I'm not
quite sure what the original issue is there, and I've no clue how to
actually use it, but if someone wants to spoonfeed me instructions on
how to make it crash, I'd be happy to take a look (or at least post a
backtrace, if I don't have time to investigate myself)
Issac
Issac Goldstand wrote:
> I'll try it as soon as it shows up.
>
> William A. Rowe, Jr. wrote:
>> Issac Goldstand wrote:
>>> Uh. Maybe I've lost it, but where's the source for apr-iconv in
>>> http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
>>>
>>> All I get is an .rc file and a couple of .deps and .maks
>> I just pulled an "OH SHIT" moment myself building on x86_64 windows...
>>
>> ... there are -r2.zip packages up now, and I just updated the site svn,
>> but I presume Jim hadn't pulled that site update to live so I'm leaving
>> it for him.
>>
>> C.f. http://www.apache.org/dist/httpd/httpd-2.2.6-win32-src-r2.zip
>>
>> ...not quite arrived from our staging to live server yet.
>>
>> Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by Issac Goldstand <ma...@beamartyr.net>.
I'll try it as soon as it shows up.
William A. Rowe, Jr. wrote:
> Issac Goldstand wrote:
>> Uh. Maybe I've lost it, but where's the source for apr-iconv in
>> http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
>>
>> All I get is an .rc file and a couple of .deps and .maks
>
> I just pulled an "OH SHIT" moment myself building on x86_64 windows...
>
> ... there are -r2.zip packages up now, and I just updated the site svn,
> but I presume Jim hadn't pulled that site update to live so I'm leaving
> it for him.
>
> C.f. http://www.apache.org/dist/httpd/httpd-2.2.6-win32-src-r2.zip
>
> ...not quite arrived from our staging to live server yet.
>
> Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Issac Goldstand wrote:
> Uh. Maybe I've lost it, but where's the source for apr-iconv in
> http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
>
> All I get is an .rc file and a couple of .deps and .maks
I just pulled an "OH SHIT" moment myself building on x86_64 windows...
... there are -r2.zip packages up now, and I just updated the site svn,
but I presume Jim hadn't pulled that site update to live so I'm leaving
it for him.
C.f. http://www.apache.org/dist/httpd/httpd-2.2.6-win32-src-r2.zip
...not quite arrived from our staging to live server yet.
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by Issac Goldstand <ma...@beamartyr.net>.
And Jorge, yeah. I was wondering if I was just getting a really really
oddly maimed ZIP :-)
William A. Rowe, Jr. wrote:
> Issac Goldstand wrote:
>> Uh. Maybe I've lost it, but where's the source for apr-iconv in
>> http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
>>
>> All I get is an .rc file and a couple of .deps and .maks
>
> and /me wonders what Steffan thinks he built ROFL
>
> Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by Issac Goldstand <ma...@beamartyr.net>.
Uh. Maybe I've lost it, but where's the source for apr-iconv in
http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip?
All I get is an .rc file and a couple of .deps and .maks
Issac
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
>
> Windows users (my self included) usually go like:
> Dudez XYZ is broken, Fix it, Fix it, Fix it. When the dev's look at it
> and ask for more information they usually don't get it. So it isn't
> fixed at all or as fast as a linux bug would be.
You know, you hit the nail on the head.
http://httpd.apache.org/dev/debugging.html
has some great information, presuming the distributor of your win32 binaries
actually provides the .pdb debugging context files that are required to emit
a legible backtrace.
(Ok, not strictly required, a significantly less helpful backtrace is emitted
without .pdb's, no arguments from the call stack for example, but only if the
recommended /Oy- flag is passed to the compiler. OpenSSL doesn't enable this
flag by default, so a crash behind an openssl callback from a stock build of
openssl will produce an entirely illegible backtrace.)
I'm going to rip section 2 of that document in two, one for live backtraces,
and a second for JIT/postmortem backtraces, since these seem shrouded in
mystery from many users/developers (and they shouldn't be).
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
On 9/6/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
> "ASF hates Windows users"
> comments??
>
>
I usually prefure not to poke my nose into other peoples discussions but...
my experience with the ASF is that they threat windows users equally than
linux/unix/whatever users.
The problem is windows users generally don't compile things them selfs and
let others do it. So they don't know the code as wel or at all compared to
other users who report bugs on linux.
Windows users (my self included) usually go like:
Dudez XYZ is broken, Fix it, Fix it, Fix it. When the dev's look at it and
ask for more information they usually don't get it. So it isn't fixed at all
or as fast as a linux bug would be.
While people having bugs or minor problems on unix/linux/bsd/... sometimes
provide a ready cooked patch that with a few tweaks can be imported into the
source tree and the problem is gone.
Note: I'm in no way accusing steffen of not providing or trying to provide
more information. I myself can't usually can't. I remember me spamming
wrowe's inbox for x64 fixed.
After lots of attempts I did manged to get it working.
I'll try to see if I can find out why mod_fcgid isn't working but like so
many windows users I don't the programing language used. I can read tiny
bits of it with my experience in other language but thats about it.
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
Ummm hrmm:
"A hurry backport is causing this and there is hardly
tested in real live. Hopefully ASF comes with a patch soon. "
So you know what's causing this? Please point out the exact
"hurry backport" so we can look there.
And again, WHAT OTHER 3rd party modules are having problems??
Can you provide ANY FURTHER information other than cryptic "its
not working" messages followed by "ASF hates Windows users"
comments??
If we *knew* what the problems were, we'd try like heck to fix
'em. I know Bill looked hard and long, but had no luck,
mostly because the amount of real concrete data was woefully
lacking.
On Sep 6, 2007, at 4:08 PM, Steffen wrote:
> Better we stop this thread.
>
> See the post at: http://www.apachelounge.com/forum/viewtopic.php?
> p=8691 , please do not reply to that post.
>
> Steffen
>
> ----- Original Message ----- From: "Jim Jagielski" <ji...@jaguNET.com>
> To: <de...@httpd.apache.org>
> Sent: Thursday, 06 September, 2007 21:47
> Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release
> candidate tarballs for review
>
>
>>
>> On Sep 6, 2007, at 3:25 PM, Steffen wrote:
>>
>>>>
>>>> I'm assuming the "we" is you, right?
>>>>
>>>
>>> It is not just me. We are a team and of course the users. Just
>>> as an example
>>> the other post from me here which is a report from an other
>>> webmaster. I
>>> report here test results from the Apache Windows Community from
>>> the Apache
>>> Lounge, mostly I receive them by mail.
>>>
>>
>> You said that "we" need to:
>> "advise the users not to use 2.2.6 because is not compatible
>> with some mods"
>>
>> which, afaik, is not the case. You reported issues with mod_fcgid,
>> which
>> may be true, but that hasn't been confirmed by anyone else, nor do
>> I see reports to support the "some mods" statement as well.
>> Unless, of course, the cryptic phrase "An other report"
>> actually means "The below is a report from someone else
>> who is also seeing an issue" instead of "Oh, by the way, I
>> also tried this personally and I see that mod_cgi is working OK
>> for me..."...
>>
>> With all this being the case, I can't see holding up a release nor
>> can I see us ("us" being the ASF) making some blanket statement that
>> Win32 users should not use 2.2.6 because it is not compatible with
>> some mods... If we had some more supporting data for that, then
>> maybe...
>>
>>> Maybe we have to patch 2.2.6 to get it error-free.
>>
>> Well, there is the patches directory that, if we discover
>> a bug, allows people to download the patch and rebuild. Of
>> course, this all means tracking down and discovering the
>> bug with some detailed debugging info rather than a "it
>> doesn't work" :)
>>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
Better we stop this thread.
See the post at: http://www.apachelounge.com/forum/viewtopic.php?p=8691 ,
please do not reply to that post.
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>
Sent: Thursday, 06 September, 2007 21:47
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
>
> On Sep 6, 2007, at 3:25 PM, Steffen wrote:
>
>>>
>>> I'm assuming the "we" is you, right?
>>>
>>
>> It is not just me. We are a team and of course the users. Just as an
>> example
>> the other post from me here which is a report from an other webmaster. I
>> report here test results from the Apache Windows Community from the
>> Apache
>> Lounge, mostly I receive them by mail.
>>
>
> You said that "we" need to:
> "advise the users not to use 2.2.6 because is not compatible with some
> mods"
>
> which, afaik, is not the case. You reported issues with mod_fcgid, which
> may be true, but that hasn't been confirmed by anyone else, nor do
> I see reports to support the "some mods" statement as well.
> Unless, of course, the cryptic phrase "An other report"
> actually means "The below is a report from someone else
> who is also seeing an issue" instead of "Oh, by the way, I
> also tried this personally and I see that mod_cgi is working OK
> for me..."...
>
> With all this being the case, I can't see holding up a release nor
> can I see us ("us" being the ASF) making some blanket statement that
> Win32 users should not use 2.2.6 because it is not compatible with
> some mods... If we had some more supporting data for that, then
> maybe...
>
>> Maybe we have to patch 2.2.6 to get it error-free.
>
> Well, there is the patches directory that, if we discover
> a bug, allows people to download the patch and rebuild. Of
> course, this all means tracking down and discovering the
> bug with some detailed debugging info rather than a "it
> doesn't work" :)
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 6, 2007, at 3:25 PM, Steffen wrote:
>>
>> I'm assuming the "we" is you, right?
>>
>
> It is not just me. We are a team and of course the users. Just as
> an example
> the other post from me here which is a report from an other
> webmaster. I
> report here test results from the Apache Windows Community from the
> Apache
> Lounge, mostly I receive them by mail.
>
You said that "we" need to:
"advise the users not to use 2.2.6 because is not compatible with
some mods"
which, afaik, is not the case. You reported issues with mod_fcgid, which
may be true, but that hasn't been confirmed by anyone else, nor do
I see reports to support the "some mods" statement as well.
Unless, of course, the cryptic phrase "An other report"
actually means "The below is a report from someone else
who is also seeing an issue" instead of "Oh, by the way, I
also tried this personally and I see that mod_cgi is working OK
for me..."...
With all this being the case, I can't see holding up a release nor
can I see us ("us" being the ASF) making some blanket statement that
Win32 users should not use 2.2.6 because it is not compatible with
some mods... If we had some more supporting data for that, then
maybe...
> Maybe we have to patch 2.2.6 to get it error-free.
Well, there is the patches directory that, if we discover
a bug, allows people to download the patch and rebuild. Of
course, this all means tracking down and discovering the
bug with some detailed debugging info rather than a "it
doesn't work" :)
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
>
> I'm assuming the "we" is you, right?
>
It is not just me. We are a team and of course the users. Just as an example
the other post from me here which is a report from an other webmaster. I
report here test results from the Apache Windows Community from the Apache
Lounge, mostly I receive them by mail.
To give an idea, there are almost 80.000 thousand downloads 2.2.4 from the
two primary sites of the Apache Lounge. I have no figures from the mirrors
and others who are making it available, I think an extra few thousand.
I respect that you want to release. But it is a pity that we have leave them
in the dark with 2.2.6 . But on the other hand, for me, 2.2.6 has minor
changes over 2.2.5. Maybe we have to patch 2.2.6 to get it error-free.
Yes we all aware that 2.2.5 is not released and when they download they are
informed that it is/was a test-release. Don't worry too much, not a lot
windows users are posting on the lists. I shall put a an extra note that
they cannot expect response on the lists.
Btw.
The authors of the modules are investigating the issues right now. I do not
expect that they are coming soon with solutions.
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>
Sent: Thursday, 06 September, 2007 17:52
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
>
> On Sep 6, 2007, at 11:05 AM, Steffen wrote:
>
>> k
>>
>> I the meantime we have to advise the users not to use 2.2.6 because is
>> not compatible with some mods (not just mod_fcgid). We shall advise to
>> stay on 2.2.4 or 2.2.5 RC.
>>
>
> What other mods is it not compatible with? So far, I haven't
> heard anyone else confirm your reports. Also, as you
> know, there was no 2.2.5 released, so make sure that if they
> do bother to use that, not to post anything on the user or
> dev lists saying "I'm using 2.2.5 and..." because it is
> likely they will be ignored :)
>
> I'm assuming the "we" is you, right?
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 6, 2007, at 11:05 AM, Steffen wrote:
> k
>
> I the meantime we have to advise the users not to use 2.2.6
> because is not compatible with some mods (not just mod_fcgid). We
> shall advise to stay on 2.2.4 or 2.2.5 RC.
>
What other mods is it not compatible with? So far, I haven't
heard anyone else confirm your reports. Also, as you
know, there was no 2.2.5 released, so make sure that if they
do bother to use that, not to post anything on the user or
dev lists saying "I'm using 2.2.5 and..." because it is
likely they will be ignored :)
I'm assuming the "we" is you, right?
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Steffen wrote:
>
> Oh, btw: mod_perl (also build with VC8) is not working with 2.2.6, with
> 2.2.5 RC no single issue.
Perl, mod_perl, httpd and apr all built with VC8? Or is this AS perl or
some other?
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
On 9/6/07, Steffen <in...@apachelounge.com> wrote:
>
> The later post was a report of an other tester, sorry no answer I have.
>
> Yes, I dicusssed it with the maintainer of mod_fcgid today. He is puzzling
> now an as I told before, we have to wait.
>
> Oh, btw: mod_perl (also build with VC8) is not working with 2.2.6, with
> 2.2.5 RC no single issue.
Odd works fine with my limited setup over here.
I you want to try my binary?
Steffen
>
> ----- Original Message -----
> From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> To: <de...@httpd.apache.org>
> Sent: Thursday, 06 September, 2007 23:22
> Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
> tarballs for review
>
>
> > Steffen wrote:
> >>
> >> I the meantime we have to advise the users not to use 2.2.6 because is
> >> not compatible with some mods (not just mod_fcgid). We shall advise to
> >> stay on 2.2.4 or 2.2.5 RC.
> >
> > If you would like to clear up FUD ("some mods") with "explicit mods"
> that
> > would be productive. It would also be productive to discuss your
> concern
> > with the mod_fcgid maintainers, as the apr behavior is not likely to be
> > regressed to the previous behavior of leaking file handles (which I
> > suspect
> > mod_fcgid had leveraged).
> >
> > If I understand your later post;
> >
> >> mod_fcgid is not working for me, either with Perl or with my own FCGI
> >> test program.
> >
> > your issues with mod_perl were in conjunction -with- mod_fcgid? Just
> > trying
> > to narrow down the focus.
> >
> > Bill
> >
>
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Steffen wrote:
> The later post was a report of an other tester, sorry no answer I have.
>
> Yes, I dicusssed it with the maintainer of mod_fcgid today. He is
> puzzling now an as I told before, we have to wait.
Before he puzzles too long, you might want to ensure you have a full
rebuild of mod_fcgid against apr-1.2.11, that is the one bundled in the
new httpd-2.2.6. If it *did* use include/arch/win32/*.h files (which
does *not* following the versioning rules, because those entries are
strictly private to the library) --- there's a good chance that a new
module build is required. It occurred to me that since the authors do
probably delve into the win32 internals, you might want to check this out.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
The later post was a report of an other tester, sorry no answer I have.
Yes, I dicusssed it with the maintainer of mod_fcgid today. He is puzzling
now an as I told before, we have to wait.
Oh, btw: mod_perl (also build with VC8) is not working with 2.2.6, with
2.2.5 RC no single issue.
Steffen
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@httpd.apache.org>
Sent: Thursday, 06 September, 2007 23:22
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
> Steffen wrote:
>>
>> I the meantime we have to advise the users not to use 2.2.6 because is
>> not compatible with some mods (not just mod_fcgid). We shall advise to
>> stay on 2.2.4 or 2.2.5 RC.
>
> If you would like to clear up FUD ("some mods") with "explicit mods" that
> would be productive. It would also be productive to discuss your concern
> with the mod_fcgid maintainers, as the apr behavior is not likely to be
> regressed to the previous behavior of leaking file handles (which I
> suspect
> mod_fcgid had leveraged).
>
> If I understand your later post;
>
>> mod_fcgid is not working for me, either with Perl or with my own FCGI
>> test program.
>
> your issues with mod_perl were in conjunction -with- mod_fcgid? Just
> trying
> to narrow down the focus.
>
> Bill
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
On 9/6/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> Jorge Schrauwen wrote:
> > I tried to compiled mod_fcgid myself to see if I can replicate the
> problem.
> > I can't even compiled it against 2.2.6.
> > I get a lot of link errors agains APR.
>
> Silly question, did you add libapr-1.lib, libaprutil-1.lib libhttpd.lib to
> the link command?
I have no idea... I update all the paths for via the project properties so
the pointed to my httpd-2.2.6 source dir since that what it seems to want.
Usually thats enough to get it to compile and run fine. Any ideas to where
to look? (providing the sln, vcproj etc help?)
http://dev.blackdot.be/mod_fcgid.2.1.zip This should be online untill I head
of to bed in 2h if you want to have a look.
note: I have my httpd-2.2(.6) folder located 2 directories above the current
one.
httpd-2.2
modules/mod_fcgid
modules/mod_perl
modules/blabla
Once/if I get it to compile and it doesn't work I'll try to provide you with
a back trace... all I need to do is rebuild my httpd and not delete the
*.pdb's this time round.
So I definitely have them available
(Worse, if you did add apr-1.lib aprutil-1.lib, those are static libraries
> and wouldn't even interface into the running instance of the libraries in
> a running httpd process).
>
> Bill
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
> I tried to compiled mod_fcgid myself to see if I can replicate the problem.
> I can't even compiled it against 2.2.6.
> I get a lot of link errors agains APR.
Silly question, did you add libapr-1.lib, libaprutil-1.lib libhttpd.lib to
the link command?
(Worse, if you did add apr-1.lib aprutil-1.lib, those are static libraries
and wouldn't even interface into the running instance of the libraries in
a running httpd process).
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
I tried to compiled mod_fcgid myself to see if I can replicate the problem.
I can't even compiled it against 2.2.6.
I get a lot of link errors agains APR.
--- complete buildlog availble on request but nothing odd until this ---
1>fcgid_spawn_ctl.obj : error LNK2019: unresolved external symbol
__imp__ap_log_error referenced in function _spawn_control_init
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_pm_win.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_proctbl_win.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_protocol.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_bridge.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_bucket.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_filter.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_pm_main.obj : error LNK2001: unresolved external symbol
__imp__ap_log_error
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_time_now@0 referenced in function _bucket_ctx_cleanup
1>fcgid_pm_main.obj : error LNK2001: unresolved external symbol
__imp__apr_time_now@0
1>fcgid_spawn_ctl.obj : error LNK2001: unresolved external symbol
__imp__apr_time_now@0
1>fcgid_bridge.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_type_immortal
1>fcgid_filter.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_type_immortal
1>fcgid_bridge.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_type_eos
1>fcgid_filter.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_type_eos
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_bucket_type_eos referenced in function _proc_spawn_process
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__ap_pass_brigade@8 referenced in function _handle_request
1>fcgid_filter.obj : error LNK2001: unresolved external symbol
__imp__ap_pass_brigade@8
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__ap_internal_redirect_handler@8 referenced in function _handle_request
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_table_unset@8 referenced in function _handle_request
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__apr_table_unset@8
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_pstrdup@8 referenced in function _handle_request
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_table_get@8 referenced in function _handle_request
1>fcgid_conf.obj : error LNK2001: unresolved external symbol
__imp__apr_table_get@8
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__apr_table_get@8
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__ap_scan_script_header_err_core@16 referenced in function
_handle_request
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_brigade_create@8 referenced in function _handle_request
1>fcgid_filter.obj : error LNK2001: unresolved external symbol
__imp__apr_brigade_create@8
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_sleep@8 referenced in function _handle_request
1>fcgid_pm_main.obj : error LNK2001: unresolved external symbol
__imp__apr_sleep@8
1>fcgid_pm_win.obj : error LNK2001: unresolved external symbol
__imp__apr_sleep@8
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_pool_cleanup_register@16 referenced in function _handle_request
1>fcgid_pm_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_cleanup_register@16
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_cleanup_register@16
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_cleanup_null
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_cleanup_null
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_pool_cleanup_null referenced in function _handle_request
1>fcgid_conf.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_cleanup_null
1>fcgid_pm_main.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_cleanup_null
1>fcgid_pm_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_cleanup_null
1>fcgid_spawn_ctl.obj : error LNK2001: unresolved external symbol
__imp__apr_palloc@8
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__apr_palloc@8
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_palloc@8 referenced in function _handle_request
1>fcgid_conf.obj : error LNK2001: unresolved external symbol
__imp__apr_palloc@8
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_palloc@8
1>fcgid_proctbl_win.obj : error LNK2001: unresolved external symbol
__imp__apr_palloc@8
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_bucket_eos_create@4 referenced in function _bridge_request
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_brigade_destroy@4 referenced in function _bridge_request
1>fcgid_bridge.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_type_heap
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_bucket_heap_create@16 referenced in function _bridge_request
1>fcgid_bucket.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_heap_create@16
1>fcgid_protocol.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_heap_create@16
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_bucket_free referenced in function _bridge_request
1>fcgid_bucket.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_free
1>fcgid_protocol.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_free
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__apr_bucket_alloc referenced in function _bridge_request
1>fcgid_bucket.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_alloc
1>fcgid_protocol.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_alloc
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__ap_get_brigade@24 referenced in function _bridge_request
1>fcgid_bridge.obj : error LNK2019: unresolved external symbol
__imp__ap_create_environment@8 referenced in function _bridge_request
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__ap_create_environment@8
1>fcgid_bucket.obj : error LNK2001: unresolved external symbol
_apr_bucket_copy_notimpl
1>fcgid_bucket.obj : error LNK2001: unresolved external symbol
_apr_bucket_split_notimpl
1>fcgid_bucket.obj : error LNK2001: unresolved external symbol
_apr_bucket_setaside_notimpl
1>fcgid_bucket.obj : error LNK2001: unresolved external symbol
_apr_bucket_destroy_noop
1>fcgid_bucket.obj : error LNK2019: unresolved external symbol
__imp__apr_bucket_immortal_make@12 referenced in function
_fcgid_header_bucket_read
1>fcgid_bucket.obj : error LNK2019: unresolved external symbol
__imp__apr_pool_cleanup_run@12 referenced in function
_fcgid_header_bucket_read
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_cleanup_run@12
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__ap_server_root_relative@8 referenced in function
_create_fcgid_server_config
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_table_make@8 referenced in function _create_fcgid_server_config
1>fcgid_pm_main.obj : error LNK2001: unresolved external symbol
__imp__apr_table_make@8
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_table_set@12 referenced in function _merge_fcgid_server_config
1>fcgid_pm_main.obj : error LNK2001: unresolved external symbol
__imp__apr_table_set@12
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_table_elts@4 referenced in function _merge_fcgid_server_config
1>fcgid_pm_win.obj : error LNK2001: unresolved external symbol
__imp__apr_table_elts@4
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_hash_make@4 referenced in function _create_fcgid_dir_config
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_psprintf referenced in function _set_authenticator_info
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_psprintf
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_stat@16 referenced in function _set_authenticator_info
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__apr_stat@16
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__ap_getword_white@8 referenced in function _set_wrapper_config
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__ap_getword_white@8
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_hash_set@16 referenced in function _set_wrapper_config
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_hash_get@12 referenced in function _set_wrapper_config
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_pool_userdata_set@16 referenced in function _set_wrapper_config
1>fcgid_pm_main.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_userdata_set@16
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_userdata_set@16
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_userdata_set@16
1>fcgid_conf.obj : error LNK2019: unresolved external symbol
__imp__apr_pool_userdata_get@12 referenced in function _set_wrapper_config
1>fcgid_pm_main.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_userdata_get@12
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_userdata_get@12
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_userdata_get@12
1>fcgid_filter.obj : error LNK2019: unresolved external symbol
__imp__ap_remove_output_filter@4 referenced in function _fcgid_filter
1>fcgid_filter.obj : error LNK2019: unresolved external symbol
__imp__apr_bucket_flush_create@4 referenced in function _fcgid_filter
1>fcgid_pm_main.obj : error LNK2019: unresolved external symbol
__imp__apr_proc_wait@16 referenced in function _kill_all_subprocess
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_proc_wait@16
1>fcgid_pm_main.obj : error LNK2019: unresolved external symbol
__imp__apr_pool_destroy@4 referenced in function _kill_all_subprocess
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_destroy@4
1>fcgid_pm_main.obj : error LNK2019: unresolved external symbol
__imp__apr_pool_create_ex@16 referenced in function _fastcgi_spawn
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_create_ex@16
1>fcgid_spawn_ctl.obj : error LNK2001: unresolved external symbol
__imp__apr_pool_create_ex@16
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_queue_trypush@8 referenced in function _wakeup_thread@8
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_thread_create@20 referenced in function _procmgr_post_config
1>fcgid_pm_win.obj : error LNK2001: unresolved external symbol
__imp__ap_real_exit_code
1>fcgid_proctbl_win.obj : error LNK2019: unresolved external symbol
__imp__ap_real_exit_code referenced in function _proctable_lock_table
1>fcgid_spawn_ctl.obj : error LNK2001: unresolved external symbol
__imp__ap_real_exit_code
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_thread_mutex_create@12 referenced in function
_procmgr_post_config
1>fcgid_proctbl_win.obj : error LNK2001: unresolved external symbol
__imp__apr_thread_mutex_create@12
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_queue_create@12 referenced in function _procmgr_post_config
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_queue_pop@8 referenced in function _procmgr_post_spawn_cmd
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_thread_mutex_unlock@4 referenced in function
_procmgr_post_spawn_cmd
1>fcgid_proctbl_win.obj : error LNK2001: unresolved external symbol
__imp__apr_thread_mutex_unlock@4
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_queue_push@8 referenced in function _procmgr_post_spawn_cmd
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_thread_mutex_lock@4 referenced in function
_procmgr_post_spawn_cmd
1>fcgid_proctbl_win.obj : error LNK2001: unresolved external symbol
__imp__apr_thread_mutex_lock@4
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_queue_trypop@8 referenced in function _procmgr_stop_procmgr
1>fcgid_pm_win.obj : error LNK2019: unresolved external symbol
__imp__apr_thread_join@8 referenced in function _procmgr_stop_procmgr
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_proc_create@24 referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_procattr_child_in_set@12 referenced in function
_proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_os_file_put@16 referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_procattr_detach_set@8 referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_procattr_cmdtype_set@8 referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_procattr_dir_set@8 referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__ap_make_dirstr_parent@8 referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_procattr_create@8 referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_snprintf referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_table_setn@12 referenced in function _proc_spawn_process
1>mod_fcgid.obj : error LNK2001: unresolved external symbol
__imp__apr_table_setn@12
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_ltoa@8 referenced in function _proc_spawn_process
1>fcgid_proc_win.obj : error LNK2019: unresolved external symbol
__imp__apr_proc_kill@8 referenced in function _proc_kill_force
1>fcgid_proc_win.obj : error LNK2001: unresolved external symbol
__imp__apr_bucket_type_flush
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_escape_shell_cmd@8 referenced in function _default_build_command
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_unescape_url@4 referenced in function _default_build_command
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_getword_nulls@12 referenced in function _default_build_command
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__apr_filepath_merge@20 referenced in function _fcgid_add_cgi_vars
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_add_output_filter_handle@16 referenced in function _fcgid_handler
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_add_cgi_vars@4 referenced in function _fcgid_handler
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_add_common_vars@4 referenced in function _fcgid_handler
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_log_rerror referenced in function _fcgid_handler
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_allow_options@4 referenced in function _fcgid_handler
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_note_basic_auth_failure@4 referenced in function
_mod_fcgid_authenticator
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__apr_table_do referenced in function _mod_fcgid_authenticator
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__apr_table_copy@8 referenced in function _mod_fcgid_authenticator
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_get_basic_auth_pw@8 referenced in function
_mod_fcgid_authenticator
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__apr_dynamic_fn_retrieve@4 referenced in function _fcgid_init
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_register_output_filter@16 referenced in function _register_hooks
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_hook_access_checker@16 referenced in function _register_hooks
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_hook_auth_checker@16 referenced in function _register_hooks
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_hook_check_user_id@16 referenced in function _register_hooks
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_hook_handler@16 referenced in function _register_hooks
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_hook_child_init@16 referenced in function _register_hooks
1>mod_fcgid.obj : error LNK2019: unresolved external symbol
__imp__ap_hook_post_config@16 referenced in function _register_hooks
--- end of snip ---
I'm not sure if this is helpful but I do vaguely remember wrowe doing
something in apr related to log_error.
I can provide my vc8 project that I converted and modified from the older
dsp.
~ Jorge
On 9/6/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> Steffen wrote:
> >
> > I the meantime we have to advise the users not to use 2.2.6 because is
> > not compatible with some mods (not just mod_fcgid). We shall advise to
> > stay on 2.2.4 or 2.2.5 RC.
>
> If you would like to clear up FUD ("some mods") with "explicit mods" that
> would be productive. It would also be productive to discuss your concern
> with the mod_fcgid maintainers, as the apr behavior is not likely to be
> regressed to the previous behavior of leaking file handles (which I
> suspect
> mod_fcgid had leveraged).
>
> If I understand your later post;
>
> > mod_fcgid is not working for me, either with Perl or with my own FCGI
> > test program.
>
> your issues with mod_perl were in conjunction -with- mod_fcgid? Just
> trying
> to narrow down the focus.
>
> Bill
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Steffen wrote:
>
> I the meantime we have to advise the users not to use 2.2.6 because is
> not compatible with some mods (not just mod_fcgid). We shall advise to
> stay on 2.2.4 or 2.2.5 RC.
If you would like to clear up FUD ("some mods") with "explicit mods" that
would be productive. It would also be productive to discuss your concern
with the mod_fcgid maintainers, as the apr behavior is not likely to be
regressed to the previous behavior of leaking file handles (which I suspect
mod_fcgid had leveraged).
If I understand your later post;
> mod_fcgid is not working for me, either with Perl or with my own FCGI
> test program.
your issues with mod_perl were in conjunction -with- mod_fcgid? Just trying
to narrow down the focus.
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
k
I the meantime we have to advise the users not to use 2.2.6 because is not
compatible with some mods (not just mod_fcgid). We shall advise to stay on
2.2.4 or 2.2.5 RC.
Steffen
www.apachelounge.com
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>
Cc: <te...@httpd.apache.org>
Sent: Thursday, 06 September, 2007 15:48
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
>
> On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote:
>
>> Available for your testing pleasure, 3, count 'em, 3
>> Apache HTTP Server release candidate tarballs, located,
>> as expected at:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> This vote will run through Sept 6, 2007 and close
>> Sept 7, unless otherwise noted...
>>
>
> So far, I see nothing yet preventing us from releasing
> this tomorrow... assuming that stays the same, I will
> move the files over to the main dist location to allow
> mirrors to start snagging and allow us a real release
> and announcement tomorrow.
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
I did, not sure the guy from the report below did.
The author(s) of mod_fcgid looking at the issue right now. Do not expect
that there is a solution from them soon.
I do not now how many users are affected by the bug(s) in 2.2.6 . I guess
there are thousands users running mod-fcgid , special heavy loaded sites.
The guess is based on the ~80.000 downloads of 2.2.4 from the
www.apachelounge.com . And also now a days quite some users Win 32 building
Apache.
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>
Sent: Thursday, 06 September, 2007 17:53
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
> Did you rebuild mod_fcgid?
>
> On Sep 6, 2007, at 11:08 AM, Steffen wrote:
>
>> An other report:
>>
>> mod_cgi is working OK for me with the Apache 2.2.6 RC, which I built
>> with VC6 - not VC8, on Win2k sp4.
>>
>> I can run the Apache-provided /cgi-bin/printenv.pl test Perl program
>> with no problems.
>>
>> mod_fcgid is not working for me, either with Perl or with my own FCGI
>> test program.
>>
>> Steffen
>>
>> ----- Original Message ----- From: "Jim Jagielski" <ji...@jaguNET.com>
>> To: <de...@httpd.apache.org>
>> Cc: <te...@httpd.apache.org>
>> Sent: Thursday, 06 September, 2007 15:48
>> Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
>> tarballs for review
>>
>>
>>>
>>> On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote:
>>>
>>>> Available for your testing pleasure, 3, count 'em, 3
>>>> Apache HTTP Server release candidate tarballs, located,
>>>> as expected at:
>>>>
>>>> http://httpd.apache.org/dev/dist/
>>>>
>>>> This vote will run through Sept 6, 2007 and close
>>>> Sept 7, unless otherwise noted...
>>>>
>>>
>>> So far, I see nothing yet preventing us from releasing
>>> this tomorrow... assuming that stays the same, I will
>>> move the files over to the main dist location to allow
>>> mirrors to start snagging and allow us a real release
>>> and announcement tomorrow.
>>>
>>
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
Did you rebuild mod_fcgid?
On Sep 6, 2007, at 11:08 AM, Steffen wrote:
> An other report:
>
> mod_cgi is working OK for me with the Apache 2.2.6 RC, which I built
> with VC6 - not VC8, on Win2k sp4.
>
> I can run the Apache-provided /cgi-bin/printenv.pl test Perl program
> with no problems.
>
> mod_fcgid is not working for me, either with Perl or with my own FCGI
> test program.
>
> Steffen
>
> ----- Original Message ----- From: "Jim Jagielski" <ji...@jaguNET.com>
> To: <de...@httpd.apache.org>
> Cc: <te...@httpd.apache.org>
> Sent: Thursday, 06 September, 2007 15:48
> Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release
> candidate tarballs for review
>
>
>>
>> On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote:
>>
>>> Available for your testing pleasure, 3, count 'em, 3
>>> Apache HTTP Server release candidate tarballs, located,
>>> as expected at:
>>>
>>> http://httpd.apache.org/dev/dist/
>>>
>>> This vote will run through Sept 6, 2007 and close
>>> Sept 7, unless otherwise noted...
>>>
>>
>> So far, I see nothing yet preventing us from releasing
>> this tomorrow... assuming that stays the same, I will
>> move the files over to the main dist location to allow
>> mirrors to start snagging and allow us a real release
>> and announcement tomorrow.
>>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
An other report:
mod_cgi is working OK for me with the Apache 2.2.6 RC, which I built
with VC6 - not VC8, on Win2k sp4.
I can run the Apache-provided /cgi-bin/printenv.pl test Perl program
with no problems.
mod_fcgid is not working for me, either with Perl or with my own FCGI
test program.
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>
Cc: <te...@httpd.apache.org>
Sent: Thursday, 06 September, 2007 15:48
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
>
> On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote:
>
>> Available for your testing pleasure, 3, count 'em, 3
>> Apache HTTP Server release candidate tarballs, located,
>> as expected at:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> This vote will run through Sept 6, 2007 and close
>> Sept 7, unless otherwise noted...
>>
>
> So far, I see nothing yet preventing us from releasing
> this tomorrow... assuming that stays the same, I will
> move the files over to the main dist location to allow
> mirrors to start snagging and allow us a real release
> and announcement tomorrow.
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote:
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
So far, I see nothing yet preventing us from releasing
this tomorrow... assuming that stays the same, I will
move the files over to the main dist location to allow
mirrors to start snagging and allow us a real release
and announcement tomorrow.
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 9/4/2007 at 3:29 PM, in message
<BA...@jaguNET.com>, Jim Jagielski
<ji...@jaguNET.com> wrote:
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
>
> Thanks!!
+1 all Netware
Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Steffen wrote:
> I have no zlib1.dll on my box and mod_deflate works fine. It's
> included/static in mod-deflate.so.
>
> Next time I shall ship it too, does not harm.
FYI - I haven't dug into the theory, but I'd presumed a possible race
and certainly suboptimal behavior if you go with OpenSSL's 'zlib-dynamic'
win32 implementation (actually any zlib-dynamic for a server application,
no matter which platform). The optimal behavior is to enable-zlib to
openssl so it's simply present upon first-use of compressed TLS streams.
This is how I've configured openssl-0.9.8.
If you were to link static to both openssl and mod_deflate on win32, of
course that also works (and is also a redundancy ;-)
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
I have no zlib1.dll on my box and mod_deflate works fine. It's
included/static in mod-deflate.so.
Next time I shall ship it too, does not harm.
Steffen
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@httpd.apache.org>
Sent: Wednesday, 05 September, 2007 21:40
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
> Steffen wrote:
>> little things:
>>
>> mod_bucketeer.so is not build out of the box with Win32 gui-build.
>
> Not necessary (except for testers). Trivial for the developer to
> create (along with many similar testing modules - instead of building
> the BuildBin target, use BuildAll target.
>
>> zlib1.dll is now copied to /bin , seems to me not necessary.
>
> zlib1.dll doesn't come from Microsoft, it's quite necessary. (I can't
> imagine you don't ship it?!?) It's used by mod_deflate, and also by
> openssl 0.9.8 - we anticipate most 2.2 users to use that version as it
> was current when Apache 2.2.0 was first released.
>
> In 2.0 we anticipated 0.9.7 which doesn't enable zlib by default, and
> we had compiled the required zlib 1.1.x sources into mod_deflate.
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Steffen wrote:
> little things:
>
> mod_bucketeer.so is not build out of the box with Win32 gui-build.
Not necessary (except for testers). Trivial for the developer to
create (along with many similar testing modules - instead of building
the BuildBin target, use BuildAll target.
> zlib1.dll is now copied to /bin , seems to me not necessary.
zlib1.dll doesn't come from Microsoft, it's quite necessary. (I can't
imagine you don't ship it?!?) It's used by mod_deflate, and also by
openssl 0.9.8 - we anticipate most 2.2 users to use that version as it
was current when Apache 2.2.0 was first released.
In 2.0 we anticipated 0.9.7 which doesn't enable zlib by default, and
we had compiled the required zlib 1.1.x sources into mod_deflate.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
little things:
mod_bucketeer.so is not build out of the box with Win32 gui-build.
zlib1.dll is now copied to /bin , seems to me not necessary.
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
Sent: Tuesday, 04 September, 2007 23:29
Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
>
> Thanks!!
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
On 9/5/07, Jorge Schrauwen <jo...@gmail.com> wrote:
>
>
>
> On 9/4/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > Available for your testing pleasure, 3, count 'em, 3
> > Apache HTTP Server release candidate tarballs, located,
> > as expected at:
> >
> > http://httpd.apache.org/dev/dist/
> >
> > This vote will run through Sept 6, 2007 and close
> > Sept 7, unless otherwise noted...
> >
> > +/-1 (x == +1)
> >
> > [ ] apache_1.3.39
> > [ ] httpd-2.0.61
> > [X] httpd-2.2.6
> >
> > Thanks!!
> >
> >
> I know I'm not allowed to vote but I'll do it anyway.
> It compiles and run fine on my server (gentoo linux). Been stable for
> about 30min now and all seems to work. Also recompiled mod_macro & mod_perl
> against it. Fine too.
>
> I'll give it a shot under windows tomorrow (32-bit and 64-bit) so expect
> to hear from me again soon. At that time I'll also give an update on how it
> is doing on my live server.
>
> --
> ~Jorge
I didn't have time to do a 64-bit build. But the normal 32-bit build went
fine. Live server still doing great.
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
On 9/4/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [X] httpd-2.2.6
>
> Thanks!!
>
>
I know I'm not allowed to vote but I'll do it anyway.
It compiles and run fine on my server (gentoo linux). Been stable for about
30min now and all seems to work. Also recompiled mod_macro & mod_perl
against it. Fine too.
I'll give it a shot under windows tomorrow (32-bit and 64-bit) so expect to
hear from me again soon. At that time I'll also give an update on how it is
doing on my live server.
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
> Available for your testing pleasure, 3, count 'em, 3
>
> [+1] apache_1.3.39
> [+1] httpd-2.0.61
> [+1] httpd-2.2.6
>
> Thanks!!
No, thank YOU :)
Small chaos today as some reports contradicted my earlier testing, but
I see no regressions, with the exception possibly of mod_fcgid which is
playing with some internals of apr. Apparently mod_perl/mod_cgi do
work as expected (better, in the case of mod_cgi).
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
> What exectly is not working in mod_perl? my limited mod_perl config is
> working fine.
>
> On 9/5/07, *Steffen* <info@apachelounge.com
> <ma...@apachelounge.com>> wrote:
>
> Also mod_perl is not working here with Win32. No indication in the
> logs.
FWIW;
I believe I know why mod_perl is not as verbose on Win32 (oh DUH moment)...
this is not a regression, but when we clip in the Event logger pipe we
actually plug the FD into the faux-posix/stdio FILE emulation API for
Win32. With the error log, we never have (in the past).
I can certainly work up a fix so that stdin/out/err and faux-fd 0, 1, 2
behave as expected from APR when not using apr file io.
But this will also more tightly bind to a specific MSVC version, and those
binaries built across multiple MSVC versions (e.g. AS perl built on VC 6,
AS python built on VC 7.1, Apache+mods built with VS8) will be even more
likely to implode :)
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
What exectly is not working in mod_perl? my limited mod_perl config is
working fine.
On 9/5/07, Steffen <in...@apachelounge.com> wrote:
>
> Also mod_perl is not working here with Win32. No indication in the logs.
>
> Steffen
>
> ----- Original Message -----
> From: "Jim Jagielski" <ji...@jaguNET.com>
> To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
> Sent: Tuesday, 04 September, 2007 23:29
> Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
> for review
>
>
> > Available for your testing pleasure, 3, count 'em, 3
> > Apache HTTP Server release candidate tarballs, located,
> > as expected at:
> >
> > http://httpd.apache.org/dev/dist/
> >
> > This vote will run through Sept 6, 2007 and close
> > Sept 7, unless otherwise noted...
> >
> > +/-1 (x == +1)
> >
> > [ ] apache_1.3.39
> > [ ] httpd-2.0.61
> > [ ] httpd-2.2.6
> >
> > Thanks!!
> >
> >
>
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
Also mod_perl is not working here with Win32. No indication in the logs.
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
Sent: Tuesday, 04 September, 2007 23:29
Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
>
> Thanks!!
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
> Available for your testing pleasure, 3, count 'em, 3
>
> [+1] apache_1.3.39
> [+1] httpd-2.0.61
> [+1] httpd-2.2.6
>
> Thanks!!
No, thank YOU :)
Small chaos today as some reports contradicted my earlier testing, but
I see no regressions, with the exception possibly of mod_fcgid which is
playing with some internals of apr. Apparently mod_perl/mod_cgi do
work as expected (better, in the case of mod_cgi).
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by David McCreedy <Mc...@msn.com>.
Jim Jagielski wrote on Tuesday, September 04, 2007:
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
> +/-1 (x == +1)
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
+1 for Apache_1.3.39 on TPF
(TPF doesn't support Apache 2 yet so no vote on those.)
-David
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Oden Eriksson <oe...@mandriva.com>.
tisdagen den 4 september 2007 skrev Jim Jagielski:
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
>
> Thanks!!
2.2.6 works for me on Mandriva Linux Cooker, Mandriva Linux Corporate Server
4, Mandriva Linux 2007.1 (x86_32 and x86_64), all tests passed with
perl-framework. Good job guys!
--
Regards // Oden Eriksson
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
Nope, was not running mod_fcgid.
Steffen
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <de...@httpd.apache.org>
Sent: Wednesday, 05 September, 2007 21:44
Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
tarballs for review
> Steffen wrote:
>> I get this kind off error too when stopping.
>> Never seen before:
>>
>> Failed to dup STDIN: Bad file descriptor.
>> Error in my_thread_global_end(): 251 threads didn't exit
>
> I expect you are talking about mod_fcgid again?
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Steffen wrote:
> I get this kind off error too when stopping.
> Never seen before:
>
> Failed to dup STDIN: Bad file descriptor.
> Error in my_thread_global_end(): 251 threads didn't exit
I expect you are talking about mod_fcgid again?
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
I get this kind off error too when stopping.
Never seen before:
Failed to dup STDIN: Bad file descriptor.
Error in my_thread_global_end(): 251 threads didn't exit
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
Sent: Tuesday, 04 September, 2007 23:29
Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
>
> Thanks!!
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote:
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
So far, I see nothing yet preventing us from releasing
this tomorrow... assuming that stays the same, I will
move the files over to the main dist location to allow
mirrors to start snagging and allow us a real release
and announcement tomorrow.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Steffen wrote:
> With 2.2.6 third party mod mod_fcgid (Fast cgi) is broken.
>
> With 2.2.5 RC it was all fine.
>
> mod_fcgid is widely used in the community with php.
I guess my puzzlement is that the fastcgi model I understand;
fork...
instantiate child
spining cgid listener - on accept...
fork
run
with only a single instantiated child ready to be forked off in multiple
copies simply doesn't work on win32. You can emulate the behavior, but
you either end up exec'ing each time, or you end up recycling the same
process leading to a less secure process separation model.
In any case, the changes to Win32 now mirror the OS2 model, so one expects
if mod_fcgid is broken on Win32, its been broken on OS2.
So it's likely you'll need to ask the maintainers of the win32 port
of mod_fcgid what is going on, and advise them that process inheritance
has been changed to inhibit the leaking of pipes on the win32 platform,
a problem that the PHP community brought to us long ago with respect to
the unix platform (and was resolved with close_for_exec logic in the
httpd pool model, a concept that doesn't translate to win32.)
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
On 9/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> William A. Rowe, Jr. wrote:
> > Jorge Schrauwen wrote:
> >> I don't have any cgi scripts so I tried to get the printenv test-cgi
> >> file to work.
> >> I get 500 and error_log has this.
> >>
> >> [Wed Sep 05 20:44:36 2007] [error] [client 87.66.74.14
> >> <http://87.66.74.14>] Premature end of script headers: printenv.pl
> >> [Wed Sep 05 20:50:24 2007] [error] [client 87.66.74.14
> >> <http://87.66.74.14>] Premature end of script headers: test.cgi
> >
> > Researching! Would you share which version of Windows?
Well, not windows apparently, on win32 we only install printenv.pl
> (presuming no /bin/sh on that platform to 'test.cgi'). Without perl,
> of course printenv.pl won't run either (and you may need to tweak the
> shebang line appropriately after install). If you have a faux-unix
> shell, you can try out test.cgi after you tweak its shebang line.
>
> AND /cgi-bin/printenv.pl is working, no hassle for me, here with 2.2.6.
> (Were you testing that, or 2.0.61, or 1.3.39?)
Yes printenv.pl is working on windows... I was testing it on mod_cgid on my
gentoo box though.
On unix, we don't set these as executable out of the box. Toggle the
> perms to 755 and tell us what happens.
I'll give it a try....
Yep that did the trick. So mod_cgid seems to be working fine.
Sry for the false alarm... I don't usage much cgi so I have rather limited
experience with them.
All such scripts are inherently xss-able with bullshit utf-7 auto-detection
> by our least favorite, most anamorphic user agent, so it actually isn't
> a good idea to enable them by default for a production server.
>
> Bill
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Jorge Schrauwen wrote:
>> I don't have any cgi scripts so I tried to get the printenv test-cgi
>> file to work.
>> I get 500 and error_log has this.
>>
>> [Wed Sep 05 20:44:36 2007] [error] [client 87.66.74.14
>> <http://87.66.74.14>] Premature end of script headers: printenv.pl
>> [Wed Sep 05 20:50:24 2007] [error] [client 87.66.74.14
>> <http://87.66.74.14>] Premature end of script headers: test.cgi
>
> Researching! Would you share which version of Windows?
Well, not windows apparently, on win32 we only install printenv.pl
(presuming no /bin/sh on that platform to 'test.cgi'). Without perl,
of course printenv.pl won't run either (and you may need to tweak the
shebang line appropriately after install). If you have a faux-unix
shell, you can try out test.cgi after you tweak its shebang line.
AND /cgi-bin/printenv.pl is working, no hassle for me, here with 2.2.6.
(Were you testing that, or 2.0.61, or 1.3.39?)
On unix, we don't set these as executable out of the box. Toggle the
perms to 755 and tell us what happens.
All such scripts are inherently xss-able with bullshit utf-7 auto-detection
by our least favorite, most anamorphic user agent, so it actually isn't
a good idea to enable them by default for a production server.
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
> I don't have any cgi scripts so I tried to get the printenv test-cgi
> file to work.
> I get 500 and error_log has this.
>
> [Wed Sep 05 20:44:36 2007] [error] [client 87.66.74.14
> <http://87.66.74.14>] Premature end of script headers: printenv.pl
> [Wed Sep 05 20:50:24 2007] [error] [client 87.66.74.14
> <http://87.66.74.14>] Premature end of script headers: test.cgi
Researching! Would you share which version of Windows?
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
Is this Win32?
On Sep 5, 2007, at 2:52 PM, Jorge Schrauwen wrote:
> I don't have any cgi scripts so I tried to get the printenv test-
> cgi file to work.
> I get 500 and error_log has this.
>
> [Wed Sep 05 20:44:36 2007] [error] [client 87.66.74.14] Premature
> end of script headers: printenv.pl
> [Wed Sep 05 20:50:24 2007] [error] [client 87.66.74.14] Premature
> end of script headers: test.cgi
>
> scripts works fine when ran from console.
>
> I know its not a config error because I know they used to work fine.
>
> On 9/5/07, Jim Jagielski <ji...@jagunet.com> wrote: As a rough guess,
> I'm assuming it may have something to
> do with the stderr/stdout stuff...
>
> Anyone testing with mod_cgid?
>
> On Sep 5, 2007, at 1:54 PM, Jim Jagielski wrote:
>
> > Any indication on *how* it is broken?
> >
> > On Sep 5, 2007, at 1:07 PM, Steffen wrote:
> >
> >> Sorry, it is on Win32
> >>
> >> With 2.2.6 third party mod mod_fcgid (Fast cgi) is broken.
> >>
> >> With 2.2.5 RC it was all fine.
> >>
> >> mod_fcgid is widely used in the community with php.
> >>
> >> For me a big -1
> >>
> >> Steffen
> >>
> >>
> >>> ----- Original Message ----- From: "Jim Jagielski" <
> jim@jaguNET.com>
> >>> To: <de...@httpd.apache.org>; <testers@httpd.apache.org >
> >>> Sent: Tuesday, 04 September, 2007 23:29
> >>> Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
> >>> tarballs for review
> >>>
> >>>
> >>>> Available for your testing pleasure, 3, count 'em, 3
> >>>> Apache HTTP Server release candidate tarballs, located,
> >>>> as expected at:
> >>>>
> >>>> http://httpd.apache.org/dev/dist/
> >>>>
> >>>> This vote will run through Sept 6, 2007 and close
> >>>> Sept 7, unless otherwise noted...
> >>>>
> >>>> +/-1 (x == +1)
> >>>>
> >>>> [ ] apache_1.3.39
> >>>> [ ] httpd-2.0.61
> >>>> [ ] httpd-2.2.6
> >>>>
> >>>> Thanks!!
> >>>>
> >>>>
> >>>
> >>
> >
>
>
>
>
> --
> ~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jorge Schrauwen <jo...@gmail.com>.
I don't have any cgi scripts so I tried to get the printenv test-cgi file to
work.
I get 500 and error_log has this.
[Wed Sep 05 20:44:36 2007] [error] [client 87.66.74.14] Premature end of
script headers: printenv.pl
[Wed Sep 05 20:50:24 2007] [error] [client 87.66.74.14] Premature end of
script headers: test.cgi
scripts works fine when ran from console.
I know its not a config error because I know they used to work fine.
On 9/5/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
> As a rough guess, I'm assuming it may have something to
> do with the stderr/stdout stuff...
>
> Anyone testing with mod_cgid?
>
> On Sep 5, 2007, at 1:54 PM, Jim Jagielski wrote:
>
> > Any indication on *how* it is broken?
> >
> > On Sep 5, 2007, at 1:07 PM, Steffen wrote:
> >
> >> Sorry, it is on Win32
> >>
> >> With 2.2.6 third party mod mod_fcgid (Fast cgi) is broken.
> >>
> >> With 2.2.5 RC it was all fine.
> >>
> >> mod_fcgid is widely used in the community with php.
> >>
> >> For me a big -1
> >>
> >> Steffen
> >>
> >>
> >>> ----- Original Message ----- From: "Jim Jagielski" <ji...@jaguNET.com>
> >>> To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
> >>> Sent: Tuesday, 04 September, 2007 23:29
> >>> Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
> >>> tarballs for review
> >>>
> >>>
> >>>> Available for your testing pleasure, 3, count 'em, 3
> >>>> Apache HTTP Server release candidate tarballs, located,
> >>>> as expected at:
> >>>>
> >>>> http://httpd.apache.org/dev/dist/
> >>>>
> >>>> This vote will run through Sept 6, 2007 and close
> >>>> Sept 7, unless otherwise noted...
> >>>>
> >>>> +/-1 (x == +1)
> >>>>
> >>>> [ ] apache_1.3.39
> >>>> [ ] httpd-2.0.61
> >>>> [ ] httpd-2.2.6
> >>>>
> >>>> Thanks!!
> >>>>
> >>>>
> >>>
> >>
> >
>
>
--
~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
As a rough guess, I'm assuming it may have something to
do with the stderr/stdout stuff...
Anyone testing with mod_cgid?
On Sep 5, 2007, at 1:54 PM, Jim Jagielski wrote:
> Any indication on *how* it is broken?
>
> On Sep 5, 2007, at 1:07 PM, Steffen wrote:
>
>> Sorry, it is on Win32
>>
>> With 2.2.6 third party mod mod_fcgid (Fast cgi) is broken.
>>
>> With 2.2.5 RC it was all fine.
>>
>> mod_fcgid is widely used in the community with php.
>>
>> For me a big -1
>>
>> Steffen
>>
>>
>>> ----- Original Message ----- From: "Jim Jagielski" <ji...@jaguNET.com>
>>> To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
>>> Sent: Tuesday, 04 September, 2007 23:29
>>> Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
>>> tarballs for review
>>>
>>>
>>>> Available for your testing pleasure, 3, count 'em, 3
>>>> Apache HTTP Server release candidate tarballs, located,
>>>> as expected at:
>>>>
>>>> http://httpd.apache.org/dev/dist/
>>>>
>>>> This vote will run through Sept 6, 2007 and close
>>>> Sept 7, unless otherwise noted...
>>>>
>>>> +/-1 (x == +1)
>>>>
>>>> [ ] apache_1.3.39
>>>> [ ] httpd-2.0.61
>>>> [ ] httpd-2.2.6
>>>>
>>>> Thanks!!
>>>>
>>>>
>>>
>>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
Any indication on *how* it is broken?
On Sep 5, 2007, at 1:07 PM, Steffen wrote:
> Sorry, it is on Win32
>
> With 2.2.6 third party mod mod_fcgid (Fast cgi) is broken.
>
> With 2.2.5 RC it was all fine.
>
> mod_fcgid is widely used in the community with php.
>
> For me a big -1
>
> Steffen
>
>
>> ----- Original Message ----- From: "Jim Jagielski" <ji...@jaguNET.com>
>> To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
>> Sent: Tuesday, 04 September, 2007 23:29
>> Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate
>> tarballs for review
>>
>>
>>> Available for your testing pleasure, 3, count 'em, 3
>>> Apache HTTP Server release candidate tarballs, located,
>>> as expected at:
>>>
>>> http://httpd.apache.org/dev/dist/
>>>
>>> This vote will run through Sept 6, 2007 and close
>>> Sept 7, unless otherwise noted...
>>>
>>> +/-1 (x == +1)
>>>
>>> [ ] apache_1.3.39
>>> [ ] httpd-2.0.61
>>> [ ] httpd-2.2.6
>>>
>>> Thanks!!
>>>
>>>
>>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
Sorry, it is on Win32
With 2.2.6 third party mod mod_fcgid (Fast cgi) is broken.
With 2.2.5 RC it was all fine.
mod_fcgid is widely used in the community with php.
For me a big -1
Steffen
> ----- Original Message -----
> From: "Jim Jagielski" <ji...@jaguNET.com>
> To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
> Sent: Tuesday, 04 September, 2007 23:29
> Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
> for review
>
>
>> Available for your testing pleasure, 3, count 'em, 3
>> Apache HTTP Server release candidate tarballs, located,
>> as expected at:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> This vote will run through Sept 6, 2007 and close
>> Sept 7, unless otherwise noted...
>>
>> +/-1 (x == +1)
>>
>> [ ] apache_1.3.39
>> [ ] httpd-2.0.61
>> [ ] httpd-2.2.6
>>
>> Thanks!!
>>
>>
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Steffen <in...@apachelounge.com>.
With 2.2.6 third party mod mod_fcgid (Fast cgi) is broken.
With 2.2.5 RC it was all fine.
mod_fcgid is widely used in the community with php.
For me a big -1
Steffen
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <de...@httpd.apache.org>; <te...@httpd.apache.org>
Sent: Tuesday, 04 September, 2007 23:29
Subject: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
>
> Thanks!!
>
>
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
+1:1.3.39
Builds with nothing except for signedness warnings on Win32 (mostly
related to goofy FD_SET declarations by MS). So no adverse symptoms.
Jim Jagielski wrote:
>
> On Sep 4, 2007, at 8:15 PM, William A. Rowe, Jr. wrote:
>
>> Jim Jagielski wrote:
>>>
>>> Hmmm... yeah, bummer. If that's it though, I'm +1 on keeping
>>> as is... we can document this. Or, we could *gasp* just reroll :/
>>
>> Or we can repack the same files. This is a packaging artifact, not
>> an artifact of source control.
>
> repackaged and uploaded. Should sync in a coupla hours.
Sigs look great, package contents (adjusted to new path) check out.
> I should really spend some cycles and update release.sh for 1.3 :)
Considering how often that might be used again (perhaps never?) - knock
yourself out. That's the real spirit of scratching our own itches :)
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 4, 2007, at 8:15 PM, William A. Rowe, Jr. wrote:
> Jim Jagielski wrote:
>>
>> Hmmm... yeah, bummer. If that's it though, I'm +1 on keeping
>> as is... we can document this. Or, we could *gasp* just reroll :/
>
> Or we can repack the same files. This is a packaging artifact, not
> an artifact of source control.
>
repackaged and uploaded. Should sync in a coupla hours.
I should really spend some cycles and update release.sh for 1.3 :)
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
>
> Hmmm... yeah, bummer. If that's it though, I'm +1 on keeping
> as is... we can document this. Or, we could *gasp* just reroll :/
Or we can repack the same files. This is a packaging artifact, not
an artifact of source control.
Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Jim Jagielski <ji...@jaguNET.com>.
Erik Abele wrote:
>
> On 04.09.2007, at 23:29, Jim Jagielski wrote:
>
> > Available for your testing pleasure, 3, count 'em, 3
> > Apache HTTP Server release candidate tarballs, located,
> > as expected at:
> >
> > http://httpd.apache.org/dev/dist/
> >
> > This vote will run through Sept 6, 2007 and close
> > Sept 7, unless otherwise noted...
> >
> > +/-1 (x == +1)
> >
> > [ ] apache_1.3.39
>
> Well, probably not a real blocker but the tarball (and therefore all
> compressed archives: Z, bz2, gz) for 1.3.39 expands to "apache-1.3"
> instead of "apache_1.3.39" as the name might suggest - this didn't
> happen for any other release yet and might overwrite something else
> (which just happened for me).
>
Hmmm... yeah, bummer. If that's it though, I'm +1 on keeping
as is... we can document this. Or, we could *gasp* just reroll :/
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Erik Abele <er...@codefaktor.de>.
On 04.09.2007, at 23:29, Jim Jagielski wrote:
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
Well, probably not a real blocker but the tarball (and therefore all
compressed archives: Z, bz2, gz) for 1.3.39 expands to "apache-1.3"
instead of "apache_1.3.39" as the name might suggest - this didn't
happen for any other release yet and might overwrite something else
(which just happened for me).
Also the NOTICE file in there still says 2006 :(
Cheers,
Erik
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs
for review
Posted by Ruediger Pluem <rp...@apache.org>.
On 09/05/2007 04:29 PM, Plüm wrote:
>
>> -----Ursprüngliche Nachricht-----
>> Von: Jim Jagielski
>> Gesendet: Dienstag, 4. September 2007 23:29
>> An: dev@httpd.apache.org; testers@httpd.apache.org
>> Betreff: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release
>> candidate tarballs for review
>>
>>
>> Available for your testing pleasure, 3, count 'em, 3
>> Apache HTTP Server release candidate tarballs, located,
>> as expected at:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> This vote will run through Sept 6, 2007 and close
>> Sept 7, unless otherwise noted...
>>
>> +/-1 (x == +1)
>>
>> [ ] apache_1.3.39
>> [ ] httpd-2.0.61
>> [ ] httpd-2.2.6
>
> Results for 2.0.61 / 2.2.6:
>
> md5 / signature ok for .tar.gz / .tar.bz2.
>
> Solaris 9:
>
> 5.9 Generic_122300-05 sun4u sparc SUNW,UltraSPARC-IIi-cEngine Solaris
> gcc (GCC) 3.3.2
>
> No regressions in the perl framework tests that can run on my box compared to 2.2.4 / 2.0.59.
>
> 2.0.61: Failed 6/63 test scripts, 90.48% okay. 21/1569 subtests failed, 98.66% okay.
> 2.2.6 : Failed 6/63 test scripts, 90.48% okay. 2/1579 subtests failed, 99.87% okay.
>
> Solaris 8:
>
> 5.8 Generic_117350-46 sun4u sparc SUNW,UltraSPARC-IIi-cEngine Solaris
> gcc (GCC) 3.3.2
>
> Compiles and starts up fine (did not run the perl framework).
>
> Linux tests will follow with my votes.
No regression on SuSE Linux 10.2 (32 bit). So
+1 from me on 2.2.6 and 2.0.61
Regards
Rüdiger
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski
> Gesendet: Dienstag, 4. September 2007 23:29
> An: dev@httpd.apache.org; testers@httpd.apache.org
> Betreff: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release
> candidate tarballs for review
>
>
> Available for your testing pleasure, 3, count 'em, 3
> Apache HTTP Server release candidate tarballs, located,
> as expected at:
>
> http://httpd.apache.org/dev/dist/
>
> This vote will run through Sept 6, 2007 and close
> Sept 7, unless otherwise noted...
>
> +/-1 (x == +1)
>
> [ ] apache_1.3.39
> [ ] httpd-2.0.61
> [ ] httpd-2.2.6
Results for 2.0.61 / 2.2.6:
md5 / signature ok for .tar.gz / .tar.bz2.
Solaris 9:
5.9 Generic_122300-05 sun4u sparc SUNW,UltraSPARC-IIi-cEngine Solaris
gcc (GCC) 3.3.2
No regressions in the perl framework tests that can run on my box compared to 2.2.4 / 2.0.59.
2.0.61: Failed 6/63 test scripts, 90.48% okay. 21/1569 subtests failed, 98.66% okay.
2.2.6 : Failed 6/63 test scripts, 90.48% okay. 2/1579 subtests failed, 99.87% okay.
Solaris 8:
5.8 Generic_117350-46 sun4u sparc SUNW,UltraSPARC-IIi-cEngine Solaris
gcc (GCC) 3.3.2
Compiles and starts up fine (did not run the perl framework).
Linux tests will follow with my votes.
Regards
Rüdiger