Re: [RELEASE CANDIDATE] libapreq2 2.11
+1 for me (tested on debian). - Original Message From: Issac Goldstand mar...@beamartyr.net To: apreq-dev@httpd.apache.org Cc: d...@httpd.apache.org; modp...@perl.apache.org Sent: Tuesday, January 20, 2009 4:48:30 AM Subject: [RELEASE CANDIDATE] libapreq2 2.11 The apreq developers are planning a maintenance release of libapreq2. This version addresses several bugfixes and includes new features. Changes since the last release version include: - Interactive CGI module [issac] Allow cgi module to interactively prompt for parameters and cookies when running a script from the command line and not from a CGI interface - Perl Glue [joes] Fix the linking of the perl modules to libapreq2 and libapr on Solaris. - Perl Glue [joes] Fix install-time linking issue of the .so modules. Previously they would remain linked against the src library path, not the install path. - C API [joes] Add optional interface for apreq_handle_apache2(). - C API [joes] Clean up buggy apreq_hook_find_param(). - Perl Glue Build [Philip M. Gollucci] config.status format changed format yet again in autoconf 2.62+. - License [Mladen Turk] Add libapreq.rc and generate libapreq.res - Build [Mladen Turk] Add APREQ_DECLARE_EXPORT/APREQ_DECLARE_STATIC in the same way as APR declares so that dllexport/dllimport get correctly handled. - Build [Randy Kobes] Add appropriate manifest command to embed manifest files on Win32 when using VC8 - C API [Andy Grundman, joes] Add missing bytes_read initializer to apreq_handle_custom(). - C API [suggested by Vinay Y S, tested by Steve Hay and Peter Walsham] For Win32, remove the flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK; in apreq_file_cleanup, to avoid problems with file uploads. - C API [joes] Fix leak associated to calling apreq_brigade_fwrite() on an upload brigade. - Build [Philip M. Gollucci] SunOS (Solaris) Users must use gmake not make for building. - Build [Philip M. Gollucci] SunOS (Solaris) Code around bug in libtool (at least in 1.5.18, 1.5.20, 1.5.22) causing mod_apreq2 to be built instead of mod_apreq2.so - C API [Philip M. Gollucci] Fix comparison signed vs unsigned comparison in apreq_fwritev() on SunOS/gcc where iovec.iov_len is a long. - Build [Philip M. Gollucci] SunOS (Solaris) fix duplicate link error to libexpat.so -- by using the one from httpd exclusively now. - Build [Philip M. Gollucci] code around |#_!!_#| autoconf 2.60 bug. Please give the tarball at http://people.apache.org/~issac/libapreq2-2.11.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-...@httpd.apache.org. Thanks, Issac
RE: [RELEASE CANDIDATE] libapreq2 2.11
Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq2-2.11.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-...@httpd.apache.org. I have a build error using VC++ 2005 on Win32 with perl-5.10.0, apache-2.2.10, mod_perl-2.0.4: [...] cl.exe /FoC:\Temp\LIBAPR~1.11\win32\libs\error.obj /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D APREQ_DECLARE_EXPORT /IC:\apache2.2\include /IC:\Temp\LIBAPR~1.11\include /YX /FD /c C:\Temp\LIBAPR~1.11\library\error.c cl : Command line warning D9002 : ignoring unknown option '/YX' error.c NMAKE : fatal error U1073: don't know how to make '.\libapreq.rc' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\bin\nmake.exe' : return code '0x2' Stop.
Re: [RELEASE CANDIDATE] libapreq2 2.11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq2. This version addresses several bugfixes and includes new features. +1 Tested on httpd-2.2.10/perl5.6.10/mp-2.0.4 linux-32bit (debian sarge) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl1psUACgkQ7bEFiW+VIth9HACgn4Wca/yWbDH38xyQKf2930+d dnQAn0083t/2O2RV7utyBd9DhhUIAY+1 =2B7S -END PGP SIGNATURE-
Re: [RELEASE CANDIDATE] libapreq2 2.11
+1 for me (tested on debian). - Original Message From: Issac Goldstand mar...@beamartyr.net To: apreq-...@httpd.apache.org Cc: dev@httpd.apache.org; modp...@perl.apache.org Sent: Tuesday, January 20, 2009 4:48:30 AM Subject: [RELEASE CANDIDATE] libapreq2 2.11 The apreq developers are planning a maintenance release of libapreq2. This version addresses several bugfixes and includes new features. Changes since the last release version include: - Interactive CGI module [issac] Allow cgi module to interactively prompt for parameters and cookies when running a script from the command line and not from a CGI interface - Perl Glue [joes] Fix the linking of the perl modules to libapreq2 and libapr on Solaris. - Perl Glue [joes] Fix install-time linking issue of the .so modules. Previously they would remain linked against the src library path, not the install path. - C API [joes] Add optional interface for apreq_handle_apache2(). - C API [joes] Clean up buggy apreq_hook_find_param(). - Perl Glue Build [Philip M. Gollucci] config.status format changed format yet again in autoconf 2.62+. - License [Mladen Turk] Add libapreq.rc and generate libapreq.res - Build [Mladen Turk] Add APREQ_DECLARE_EXPORT/APREQ_DECLARE_STATIC in the same way as APR declares so that dllexport/dllimport get correctly handled. - Build [Randy Kobes] Add appropriate manifest command to embed manifest files on Win32 when using VC8 - C API [Andy Grundman, joes] Add missing bytes_read initializer to apreq_handle_custom(). - C API [suggested by Vinay Y S, tested by Steve Hay and Peter Walsham] For Win32, remove the flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK; in apreq_file_cleanup, to avoid problems with file uploads. - C API [joes] Fix leak associated to calling apreq_brigade_fwrite() on an upload brigade. - Build [Philip M. Gollucci] SunOS (Solaris) Users must use gmake not make for building. - Build [Philip M. Gollucci] SunOS (Solaris) Code around bug in libtool (at least in 1.5.18, 1.5.20, 1.5.22) causing mod_apreq2 to be built instead of mod_apreq2.so - C API [Philip M. Gollucci] Fix comparison signed vs unsigned comparison in apreq_fwritev() on SunOS/gcc where iovec.iov_len is a long. - Build [Philip M. Gollucci] SunOS (Solaris) fix duplicate link error to libexpat.so -- by using the one from httpd exclusively now. - Build [Philip M. Gollucci] code around |#_!!_#| autoconf 2.60 bug. Please give the tarball at http://people.apache.org/~issac/libapreq2-2.11.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-...@httpd.apache.org. Thanks, Issac
Re: [RELEASE CANDIDATE] libapreq-1.34
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 make, test, install with apache-1.41/perl-5.6.2/mp-1.30 Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-dev@httpd.apache.org Thanks, Issac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklmeXgACgkQ7bEFiW+VItiqDQCfaLWzLlAsp4PhT8kfHtqfp6p6 rKgAn06AYDSMXdEe1poRp5VDHeasu5p4 =qfzS -END PGP SIGNATURE-
Re: [RELEASE CANDIDATE] libapreq-1.34
That's 3 +1s. Uploading to CPAN and announcing... Issac Goldstand wrote: +1 make, test, install with apache-1.41/perl-5.6.2/mp-1.30 Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-dev@httpd.apache.org Thanks, Issac
Re: [RELEASE CANDIDATE] libapreq-1.34
+1, tests and installs cleanly on Debian-testing with apache 1.3.41 and mod_perl 1.30 and perl 5.8.x. - Original Message From: Issac Goldstand mar...@beamartyr.net To: APREQ List apreq-...@httpd.apache.org Sent: Thursday, January 8, 2009 11:35:22 AM Subject: [RELEASE CANDIDATE] libapreq-1.34 The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-...@httpd.apache.org Thanks, Issac
RE: [RELEASE CANDIDATE] libapreq 1.34-RC4
I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? -Original Message- From: Issac Goldstand [mailto:mar...@beamartyr.net] Sent: 07 January 2009 13:24 Cc: APREQ List Subject: Re: [RELEASE CANDIDATE] libapreq 1.34-RC4 *ping* I don't actually see a vote from Steeve - just an advisory that it seems OK. I did vote +1, and am ready to roll (after having a baby boy + getting the flu twice; it's been a busy month ;)) as soon as I see a 3rd binding vote. Since steevehay does seem positive, I'm going to start tagging and rolling, but won't upload or announce until I formally close the vote Issac Philip M. Gollucci wrote: Philip M. Gollucci wrote: Issac Goldstand wrote: http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz Unit tests blow up spectacularly on solaris 2.10 but I don't think we support that and is related to Request.so failing to load. It does compile. I'll get a freebsd test for some sanity in the nearish future here. I wouldn't worry about the solaris blow ups (1.33 doesn't work either) Nothing liked getting pissed off to get things to work. (I believe the only difference I did was -httpd vs -apxs) All tests successful. Files=4, Tests=25, 3 wallclock secs ( 1.22 cusr + 0.17 csys = 1.39 CPU) Solaris 2.10 apache 1.3.41 mod_perl 1.30 perl 5.8.8 so thats a +1 Neither of Steve's changes are to apreq itself so they don't block the release. +1: stevenhay, pgollucci +0: -0: -1: ISSAC did you vote ? if you do we get the required votes. If do the release, make sure you send the e-mails from an @apache.org e-mail.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Steve Hay wrote: I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? You're not ? mumble grumble. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Director IT - RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
- Original Message From: Steve Hay steve...@planit.com To: Issac Goldstand mar...@beamartyr.net Cc: APREQ List apreq-dev@httpd.apache.org Sent: Wednesday, January 7, 2009 8:54:48 AM Subject: RE: [RELEASE CANDIDATE] libapreq 1.34-RC4 I didn't vote because AFAIK I don't actually have a vote. I have commit access, but I'm not a PMC member and therefore have no vote. Is that correct? Everybody gets a vote ;-), but the ones that count towards the release requirements come from the httpd PMC. Here's my +1 for release Issac.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Issac Goldstand wrote: Yay! That makes just a 1.5 year release cycle ;) Me. Thought i might be slow. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Philip M. Gollucci wrote: Issac Goldstand wrote: http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz Unit tests blow up spectacularly on solaris 2.10 but I don't think we support that and is related to Request.so failing to load. It does compile. I'll get a freebsd test for some sanity in the nearish future here. I wouldn't worry about the solaris blow ups (1.33 doesn't work either) Nothing liked getting pissed off to get things to work. (I believe the only difference I did was -httpd vs -apxs) All tests successful. Files=4, Tests=25, 3 wallclock secs ( 1.22 cusr + 0.17 csys = 1.39 CPU) Solaris 2.10 apache 1.3.41 mod_perl 1.30 perl 5.8.8 so thats a +1 Neither of Steve's changes are to apreq itself so they don't block the release. +1: stevenhay, pgollucci +0: -0: -1: ISSAC did you vote ? if you do we get the required votes. If do the release, make sure you send the e-mails from an @apache.org e-mail. -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
RE: [RELEASE CANDIDATE] libapreq2 2.10 RC1
Bojan Smojver wrote: It has been over two years since the latest apreq2 release, so it is time to get some new code out the door. Numerous bugs were fixed (see the full list in the CHANGES file) since the last official release (2.08), so please give us feedback on this release candidate. You can get the tarball, its signature and MD5 checksum from here: http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.asc http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.md5 Please report any problems back to the list: apreq-dev@httpd.apache.org Using Apache-2.2.10, Perl-5.10.0, mod_perl-2.0.4 and VC++ 2005 I get a build failure: cl.exe /FoC:\Temp\LIBAPR~1.10\win32\libs\error.obj /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D APREQ_DECLARE_EXPORT /IC:/apache2210vc8\include /IC:\Temp\LIBAPR~1.10\include /YX /FD /c C:\Temp\LIBAPR~1.10\library\error.c cl : Command line warning D9002 : ignoring unknown option '/YX' error.c NMAKE : fatal error U1073: don't know how to make 'C:\Temp\LIBAPR~1.10\win32\libs\libapreq.res ' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\bin\nmake.exe' : return code '0x2' Stop. The two spaces at the end of the filename that it can't make (libapreq.res ) look suspicious, but I haven't had time to investigate further. (The same environment built 2.08 without any problems. I must have missed 2.09.)
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
Steve Hay wrote: Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-dev@httpd.apache.org not to speak for issac, but looks like we're gonna need -RC5 for 1.x. Issac, I should be able to get a test on FreeBSD today before you roll -RC5. I have lots of faith -RC5 will be the last one. -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
Bojan Smojver wrote: http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz zones.perl.apache.org: sun os 5.10 perl 5.10.0 not threaded httpd 2.2.10 prefork mod_perl 2.0.3 glue/perl/t/apreq/cgi fails all 71 tests, but this is due to 'make' test issues I'd bet. from t/log/error_log: Can't load '$HOME/dev/compile/libapreq2-2.10/glue/perl/t/cgi-bin/../../blib/arch/auto/APR/Request/Request.so' for module APR::Request: ld.so.1: perl: fatal: libapreq2.so.3: open failed: No such file or directory at $P/perl/5.10.0/lib/5.10.0/i86pc-solaris-64int/DynaLoader.pm line 203. That path is wrong, note the cgi-bin dir ./configure --prefix=$P/libapreq2/2.10 --with-perl=$P/perl/5.10.0/bin/perl --with-apache2-apxs=$P/httpd/2.2.10/prefork/bin/apxs --with-expat=$P/expat/2.0.1 --enable-perl-glue its 4:30am and I've not look at this code in a while, the debugging will have to wait. Also, I I'm pretty sure I want to merge 1-2 things from trunk to 2.10 that are low risk but important. stay tuned. -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
On Wed, 2008-11-19 at 04:34 -0500, Philip M. Gollucci wrote: its 4:30am and I've not look at this code in a while, the debugging will have to wait. Also, I I'm pretty sure I want to merge 1-2 things from trunk to 2.10 that are low risk but important. Cool. That's why we have RCs after all :-) -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
Bojan Smojver wrote: It has been over two years since the latest apreq2 release, so it is time to get some new code out the door. Numerous bugs were fixed (see the full list in the CHANGES file) since the last official release (2.08), so please give us feedback on this release candidate. You can get the tarball, its signature and MD5 checksum from here: http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.asc http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.md5 Please report any problems back to the list: apreq-dev@httpd.apache.org All tests passed for me with perl 5.8.8, Apache 2.2.8, mod_perl 2.0.4. I'll try with 2.2.10 later.
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
Bojan Smojver wrote: It has been over two years since the latest apreq2 release, so it is time to get some new code out the door. Numerous bugs were fixed (see the full list in the CHANGES file) since the last official release (2.08), so please give us feedback on this release candidate. You can get the tarball, its signature and MD5 checksum from here: http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.asc http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.md5 Please report any problems back to the list: apreq-dev@httpd.apache.org I'll test shortly. People, please also take the time to test and vote on 1.34 so we can release both of these. Kudos to Bojan for getting us moving on both releases! Issac
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
On Thu, 2008-11-13 at 17:29 +1100, Bojan Smojver wrote: It has been over two years since the latest apreq2 release, so it is time to get some new code out the door. Numerous bugs were fixed (see the full list in the CHANGES file) since the last official release (2.08), so please give us feedback on this release candidate. You can get the tarball, its signature and MD5 checksum from here: http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.asc http://people.apache.org/~bojan/libapreq2-2.10-RC1.tar.gz.md5 Please report any problems back to the list: apreq-dev@httpd.apache.org Could people subscribed to mod_perl and httpd lists please forward this e-mail there. Thanks! -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
Bojan Smojver wrote: Could people subscribed to mod_perl and httpd lists please forward this e-mail there. Thanks! fowarded. -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
On Thu, 2008-11-13 at 02:01 -0500, Philip M. Gollucci wrote: (ahh, you were in unix group httpd, I've just added you) I am not an httpd committer. I only have commit rights to apreq directory. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
Bojan Smojver wrote: On Thu, 2008-11-13 at 02:01 -0500, Philip M. Gollucci wrote: (ahh, you were in unix group httpd, I've just added you) I am not an httpd committer. I only have commit rights to apreq directory. Well it is what it is, subprojects and all.. -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq2 2.10 RC1
Failed a few tests here, perl 5.8.8, apache 2.2.10, mod_perl 2.0.4 prefork, linux. Can look at this more tomorrow. [EMAIL PROTECTED] perl]$ ./t/TEST -verbose t/apreq/upload.t [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t/TEST -verbose 't/apreq/upload.t' /home/phred/sl/httpd2/bin/httpd -d /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t -f /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.10 (prefork MPM) waiting 60 seconds for server to start: .[Wed Nov 12 16:15:21 2008] [warn] PassEnv variable PERL5LIB was undefined . waiting 60 seconds for server to start: ok (waited 0 secs) server localhost.localdomain:8529 started t/apreq/upload 1..80 # Running under perl version 5.008008 for linux # Current time local: Wed Nov 12 16:15:22 2008 # Current time GMT: Thu Nov 13 00:15:22 2008 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.31 request has failed (the response code was: 404) see t/logs/error_log for more details Dubious, test returned 255 (wstat 65280, 0xff00) Failed 80/80 subtests Test Summary Report --- t/apreq/upload (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 80 tests but ran 0. Files=1, Tests=0, 1 wallclock secs ( 0.04 usr 0.01 sys + 0.50 cusr 0.04 csys = 0.59 CPU) Result: FAIL Failed 1/1 test programs. 0/0 subtests failed. [warning] server localhost.localdomain:8529 shutdown [ error] error running tests (please examine t/logs/error_log) [EMAIL PROTECTED] perl]$ cat t/logs/error_log [Wed Nov 12 16:13:29 2008] [notice] Apache/2.2.10 (Unix) mod_apreq2-20051231/2.6.3 mod_perl/2.0.4 Perl/v5.8.8 configured -- resuming normal operations [Wed Nov 12 16:13:29 2008] [info] Server built: Oct 30 2008 05:08:37 Wed Nov 12 16:13:40 2008] [error] [client 127.0.0.1] File does not exist: /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t/htdocs/getfiles-binary-httpd [Wed Nov 12 16:13:40 2008] [info] removed PID file /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t/logs/httpd.pid (pid=17468) [Wed Nov 12 16:13:40 2008] [notice] caught SIGTERM, shutting down [Wed Nov 12 16:15:21 2008] [notice] Apache/2.2.10 (Unix) mod_apreq2-20051231/2.6.3 mod_perl/2.0.4 Perl/v5.8.8 configured -- resuming normal operations [Wed Nov 12 16:15:21 2008] [info] Server built: Oct 30 2008 05:08:37 [Wed Nov 12 16:15:21 2008] [debug] prefork.c(1001): AcceptMutex: sysvsem (default: sysvsem) [Wed Nov 12 16:15:23 2008] [error] [client 127.0.0.1] File does not exist: /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t/htdocs/getfiles-binary-httpd [Wed Nov 12 16:15:23 2008] [info] removed PID file /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t/logs/httpd.pid (pid=17536) [Wed Nov 12 16:15:23 2008] [notice] caught SIGTERM, shutting down --- [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t/TEST -bugreport -verbose=0 /home/phred/sl/httpd2/bin/httpd -d /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t -f /home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.10 (prefork MPM) waiting 60 seconds for server to start: .[Wed Nov 12 16:13:29 2008] [warn] PassEnv variable PERL5LIB was undefined . waiting 60 seconds for server to start: ok (waited 0 secs) server localhost.localdomain:8529 started t/api/cookie.ok t/api/error..ok t/api/module.ok t/api/param..ok t/apreq/big_inputok t/apreq/cgi..skipped: (no reason given) t/apreq/cookie...ok t/apreq/cookie2..ok t/apreq/inherit..ok t/apreq/request..ok t/apreq/upload...request has failed (the response code was: 404) see t/logs/error_log for more details t/apreq/upload... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 80/80 subtests Test Summary Report --- t/apreq/upload (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 80 tests but ran 0. Files=11, Tests=135, 10 wallclock secs ( 1.96 usr 0.03 sys + 6.33 cusr 0.52 csys = 8.84 CPU) Result: FAIL Failed 1/11 test programs. 0/135 subtests failed. [warning] server localhost.localdomain:8529 shutdown [ error] error running tests (please examine t/logs/error_log) make[1]: *** [run_tests] Error 1 make[1]: Leaving directory `/home/phred/sl/SL-CP/src/libapreq2-2.10/glue/perl' make: *** [perl_test] Error 2 [EMAIL PROTECTED] libapreq2-2.10]$ ls t/ On Wed, Nov 12, 2008 at 10:29 PM, Bojan Smojver [EMAIL PROTECTED] wrote: It has been over two years since the latest apreq2 release, so it is time to get some new code out the door. Numerous bugs were fixed (see the full list in the CHANGES file) since the last official release (2.08), so please give
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
Ahem, On that subject, libapreq1 is already a year and a half into it's latest release cycle. We're still waiting for a PMC vote to finish the release... Someone remind me to do a lightning talk about this next time I'm at AC :) Foo JH wrote: Fantastic! Can I assume that libapreq will be compatible with this version? In all likelihood the only way is to try it yourself... Philippe M. Chiasson wrote: The mod_perl 2.0.4 release candidate 1 Works with Perl 5.10 is ready. It can be downloaded here: http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz MD5: 1f0a941e8b5f26b6102126ae67ddbb43 SHA1: 8b2ceede3c783b9b2cc9e0fe63a095b0e4a1f000 Please give it a spin in your favorite configuration and report any problems. Especially needed against Perl-5.10 on Windows. The summary of what has changed since 2.0.3 are (from Changes): Fix $r-location corruption under certain conditions [Gozer] Fix a crash when spawning Perl threads under Perl 5.10 [Gozer] Fix erratic behaviour when filters were used with Perl 5.10 [Gozer] Fix problems with redefinitions of perl_free as free and perl_malloc as malloc on Win32, as described at http://marc.info/?l=apache-modperlm=119896407510526w=2 [Tom Donovan] Fix a crash when running a sub-request from within a filter where mod_perl was not the content handler. [Gozer] Refactor tests to use keepalives instead of same_interp [Gozer, Phred] Apache2::Reload has been moved to an externally maintained CPAN distribution [Fred Moyer [EMAIL PROTECTED]] PerlCleanupHandler are now registered with a subpool of $r-pool, instead of $r-pool itself, ensuring they run _before_ any other $r-pool cleanups [Torsten Foertsch] Fix a bug that would prevent pnotes from being cleaned up properly at the end of the request [Torsten Foertsch] On Win32, embed the manifest file, if present, in mod_perl.so, so as to work with VC 8 [Steve Hay, Randy Kobes] Expose apr_thread_rwlock_t with the APR::ThreadRWLock module [Torsten Foertsch] Don't waste an extra interpreter anymore under threaded MPMs when using a modperl handler [Torsten Foertsch] Fix a bug that could cause a crash when using $r-push_handlers() multiple times for a phase that has no configured handlers [Torsten Foertsch] Catch up with some httpd API changes 2.2.4: The full server version information is now included in the error log at startup as well as server status reports, irrespective of the setting of the ServerTokens directive. ap_get_server_version() is now deprecated, and is replaced by ap_get_server_banner() and ap_get_server_description(). [Jeff Trawick] 2.3.0: ap_get_server_version() has been removed. Third-party modules must now use ap_get_server_banner() or ap_get_server_description(). [Gozer] fixed Apache2::compat Apache2::ServerUtil::server_root() resolution issues [Joshua Hoblitt] *) SECURITY: CVE-2007-1349 (cve.mitre.org) fix unescaped variable interprolation in regular expression [Randal L. Schwartz [EMAIL PROTECTED], Fred Moyer [EMAIL PROTECTED]] Make $r-the_request() writeable [Fred Moyer [EMAIL PROTECTED]] fix ModPerl::RegistryCooker::read_script to handle all possible errors, previously there was a case where Apache2::Const::OK was returned on an error. [Eivind Eklund [EMAIL PROTECTED]] a minor compilation warning resolved in modperl_handler_new_from_sv [Stas] a minor compilation warning resolved in modperl_gtop_size_string [Stas] Prevent direct use of _deprecated_ Apache2::ReadConfig in Perl sections with httpd Alias directives from incorrectly generating 'The Alias directive in x at line y will probably never match' messages. [Philip M. Gollucci [EMAIL PROTECTED]] Prevent Apache2::PerSections::symdump() from returning invalid httpd.conf snippets like 'Alias undef' [Philip M. Gollucci [EMAIL PROTECTED]] Require B-Size 0.9 for Apache2::Status which fixes Can't call method script_name on an undefined value [Philip M. Gollucci [EMAIL PROTECTED]] -march=pentium4 or anything with an = in it in CCFLAGS or @ARGV that gets passed to xs/APR/APR/Makefile.PL broke the @ARGV parsing. I.E. FreeBSD port builds when users had CPUTYPE set in /etc/make.conf. [Philip M. Gollucci [EMAIL PROTECTED]] Fixes to get bleed-ithread (5.9.5+) to comile again. [Philip M. Gollucci [EMAIL PROTECTED]]
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
Issac Goldstand wrote: Ahem, On that subject, libapreq1 is already a year and a half into it's latest release cycle. We're still waiting for a PMC vote to finish the release... Someone remind me to do a lightning talk about this next time I'm at AC :) Time for a FFT presentation - 15 minutes on cutting edge POST handling using apreq? Just give [EMAIL PROTECTED] a title, abstract, presenter and short bio. Bill
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
William A. Rowe, Jr. wrote: Issac Goldstand wrote: Ahem, On that subject, libapreq1 is already a year and a half into it's latest release cycle. We're still waiting for a PMC vote to finish the release... Someone remind me to do a lightning talk about this next time I'm at AC :) Time for a FFT presentation - 15 minutes on cutting edge POST handling using apreq? Just give [EMAIL PROTECTED] a title, abstract, presenter and short bio. Not I - I won't be there. I'm trying to get my wife (and boss, but he's less of an issue if I can talk there) to come around to the idea of AC US 2008. I can do it then.
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Phillip, If it helps you move along better and have more time to review both 1 2, I'll voulenteer to pick up RMing 2.09 in addition to 1.34 so we can get them both out the door. Let me know. Issac Philip M. Gollucci wrote: Are we going to have 2.09 release? It's been quite some time since RC2 actually, i'd like to see an RC3-- there was an issue I kept complaining about that Joe was going to solve thanks to some testing by [EMAIL PROTECTED] -- reference the posting on 2007.05.25 The RC3 was what I meant. what are you doing there, if you don't mind me asking... i noticed that they were hiring ruby people a while back. i feared we lost you. The only and only System Admin (FreeBSD + ruby/rails) and worthless 'windows business' network. The fun comes soon when we move into Equinix.
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Are we going to have 2.09 release? It's been quite some time since RC2 actually, i'd like to see an RC3-- there was an issue I kept complaining about that Joe was going to solve thanks to some testing by [EMAIL PROTECTED] -- reference the posting on 2007.05.25 Supposedly, this is going to lighten up after August when my startup goes lives (Aug 10). congrats! what are you doing there, if you don't mind me asking... i noticed that they were hiring ruby people a while back. i feared we lost you.
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Are we going to have 2.09 release? It's been quite some time since RC2 actually, i'd like to see an RC3-- there was an issue I kept complaining about that Joe was going to solve thanks to some testing by [EMAIL PROTECTED] -- reference the posting on 2007.05.25 The RC3 was what I meant. what are you doing there, if you don't mind me asking... i noticed that they were hiring ruby people a while back. i feared we lost you. The only and only System Admin (FreeBSD + ruby/rails) and worthless 'windows business' network. The fun comes soon when we move into Equinix. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Senior System Admin - Riderway, Inc. http://riderway.com 1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
Issac Goldstand wrote: We're still waiting on a couple of PMC votes to roll. If anyone's got time to make test and vote on this, it'd be great. Issac I remember testing this and giving a +1, and seeing another +1 from Randy Kobes, but I can't seem to track down those emails in the archive. http://marc.info/?l=apache-httpd-devm=118245721026747w=2 There looks like some activity rolling the 2.09 release also, so I thought I would drop a friendly ping here to see if there's anything that needs to be done to roll this one also.
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Are we going to have 2.09 release? It's been quite some time since RC2 went out... -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
On Tue, 7 Aug 2007, Bojan Smojver wrote: Are we going to have 2.09 release? It's been quite some time since RC2 went out... That was the plan whenever I made the branch way long ago. After moving, loosing a datacenter, and being swamped at work, I haven't read a single mailing list since April. Supposedly, this is going to lighten up after August when my startup goes lives (Aug 10). My first order of business though is to vote on the apreq 1 RC so it can go unless I missed it. If I am taking too long and you feel up to it, please feel free to give it a whirl. I'll try to answers questions too if so. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Senior System Admin - Riderway, Inc. http://riderway.com 1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
We're still waiting on a couple of PMC votes to roll. If anyone's got time to make test and vote on this, it'd be great. Issac Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] Thanks, Issac
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
On Mon, 4 Jun 2007, Fred Moyer wrote: Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All tests OK on Fedora Core 5, perl 5.8.8, apache 1.3.37, mod_perl 1.30. +1 +1 All tests OK on Win32 (XP) - perl-5.8.8, apache-1.3.34 and mod_perl-1.29. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All tests OK on Fedora Core 5, perl 5.8.8, apache 1.3.37, mod_perl 1.30. +1
Re: No quadratic allocators (was Re: [RELEASE CANDIDATE] libapreq 1.34-RC2)
After going too long without any tuits, I've gotten around to properly
testing this. Looks ok, although I didn't really do anything
in-depth. - I'm going to commit and roll another RC.
Issac
Joe Schaefer wrote:
Joe Schaefer [EMAIL PROTECTED] writes:
Issac Goldstand [EMAIL PROTECTED] writes:
The apreq developers are planning a maintenance release of
libapreq1. This version primarily addresses an issue noted
with FireFox 2.0 truncating file uploads in SSL mode.
Please give the tarball at
http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz
a try and report comments/problems/etc. to the apreq-dev list
at [EMAIL PROTECTED]
+1, tested on Debian stable i386.
Having looked over some recent literature on memory allocation
attacks, I'm changing my vote to -1. We need to fix the
crappy quadratic allocator in multipart_buffer_read_body.
Here's a first stab at it- completely untested (I didn't even
bother trying to compile it). The strategy here though is to
allocate (more than) twice the amount last allocated, so the
total amount allocated will sum (as a geometric series) to
no more than 2 times the final allocation, which is O(n).
The problem with the current code is that the total amount
allocated is O(n^2), where n is basically the number of packets
received. This is entirely unsafe nowadays, so we should not bless
a new release which contains such code.
Index: c/apache_multipart_buffer.c
===
--- c/apache_multipart_buffer.c (revision 531273)
+++ c/apache_multipart_buffer.c (working copy)
@@ -273,17 +273,25 @@
return len;
}
-/*
- XXX: this is horrible memory-usage-wise, but we only expect
- to do this on small pieces of form data.
-*/
char *multipart_buffer_read_body(multipart_buffer *self)
{
char buf[FILLUNIT], *out = ;
+size_t nalloc = 1, cur_len = 0;
-while(multipart_buffer_read(self, buf, sizeof(buf)))
- out = ap_pstrcat(self-r-pool, out, buf, NULL);
+while(multipart_buffer_read(self, buf, sizeof(buf))) {
+size_t len = strlen(buf);
+if (len + cur_len + 1 nalloc) {
+char *tmp;
+nalloc = 2 * (nalloc + len + 1);
+tmp = ap_palloc(self-r-pool, nalloc);
+strcpy(tmp, out);
+out = tmp;
+}
+strcpy(out + cur_len, buf);
+cur_len += len;
+}
+
#ifdef DEBUG
ap_log_rerror(MPB_ERROR, multipart_buffer_read_body: '%s', out);
#endif
No quadratic allocators (was Re: [RELEASE CANDIDATE] libapreq 1.34-RC2)
Joe Schaefer [EMAIL PROTECTED] writes:
Issac Goldstand [EMAIL PROTECTED] writes:
The apreq developers are planning a maintenance release of
libapreq1. This version primarily addresses an issue noted
with FireFox 2.0 truncating file uploads in SSL mode.
Please give the tarball at
http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz
a try and report comments/problems/etc. to the apreq-dev list
at [EMAIL PROTECTED]
+1, tested on Debian stable i386.
Having looked over some recent literature on memory allocation
attacks, I'm changing my vote to -1. We need to fix the
crappy quadratic allocator in multipart_buffer_read_body.
Here's a first stab at it- completely untested (I didn't even
bother trying to compile it). The strategy here though is to
allocate (more than) twice the amount last allocated, so the
total amount allocated will sum (as a geometric series) to
no more than 2 times the final allocation, which is O(n).
The problem with the current code is that the total amount
allocated is O(n^2), where n is basically the number of packets
received. This is entirely unsafe nowadays, so we should not bless
a new release which contains such code.
Index: c/apache_multipart_buffer.c
===
--- c/apache_multipart_buffer.c (revision 531273)
+++ c/apache_multipart_buffer.c (working copy)
@@ -273,17 +273,25 @@
return len;
}
-/*
- XXX: this is horrible memory-usage-wise, but we only expect
- to do this on small pieces of form data.
-*/
char *multipart_buffer_read_body(multipart_buffer *self)
{
char buf[FILLUNIT], *out = ;
+size_t nalloc = 1, cur_len = 0;
-while(multipart_buffer_read(self, buf, sizeof(buf)))
- out = ap_pstrcat(self-r-pool, out, buf, NULL);
+while(multipart_buffer_read(self, buf, sizeof(buf))) {
+size_t len = strlen(buf);
+if (len + cur_len + 1 nalloc) {
+char *tmp;
+nalloc = 2 * (nalloc + len + 1);
+tmp = ap_palloc(self-r-pool, nalloc);
+strcpy(tmp, out);
+out = tmp;
+}
+strcpy(out + cur_len, buf);
+cur_len += len;
+}
+
#ifdef DEBUG
ap_log_rerror(MPB_ERROR, multipart_buffer_read_body: '%s', out);
#endif
--
Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
On Mon, 30 Apr 2007, Joe Schaefer wrote: Joe Schaefer [EMAIL PROTECTED] writes: Issac Goldstand [EMAIL PROTECTED] writes: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] +1, tested on Debian stable i386. We need a few votes from pmc members before Issac can release. I'm away for the next several days, but will give it a try on Win32 when I return. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
Issac Goldstand [EMAIL PROTECTED] writes: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] +1, tested on Debian stable i386. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All still OK on WinXP/VC6 with perl-5.8.8, apache-1.3.34, mod_perl-1.29. --
Re: [RELEASE CANDIDATE] libapreq 1.34-RC1
Issac Goldstand wrote: Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC1.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] All tests OK on WinXP (VC6) with perl-5.8.8, apache-1.3.34 and mod_perl-1.29. --
Re: [RELEASE CANDIDATE] libapreq 1.34-RC1
Joe Schaefer [EMAIL PROTECTED] writes: Issac Goldstand [EMAIL PROTECTED] writes: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC1.tar.gz +1, tested on Debian stable i386. Oops- the NOTICE file is missing from the MANIFEST and tarball. -- Joe Schaefer
Re: Release of mod_python 3.3.
On 07/12/2006, at 9:14 PM, Graham Dumpleton wrote: Once that is decided I'll roll the tarball, likely tonight. I assume we'll use release-3-3-0b as the tag? Based on past conventions, that tag seems appropriate. If all is okay do we then just retag as 3.0.1? Hmmm, I think you know what I mean, we don't actually want to go backwards. :-) Graham
Re: Release of mod_python 3.3.
Graham Dumpleton wrote: On 07/12/2006, at 12:42 AM, Jim Gallacher wrote: Graham Dumpleton wrote: There were no more comments on basic apache.import_module() documentation so I have tweaked a few last things, committed it and marked as resolved the final issue in JIRA tagged for 3.3. Thus, unless anyone else has got any last minute issues, we should be good to go with a 3.3 release now. Jim, would you like to get the ball rolling when you have some time. Thanks to everyone who has contributed. Graham I do want to change the requirements in the docs. Currently it reads: * Python 2.2.1 or later. Earlier versions of Python will not work. * Apache 2.0.47 or later (For Apache 1.3.x, use mod_python version 2.7.x). We decided to officially bump the Python version requirement to 2.3, Yep. but are we still OK with Apache 2.0.47, or should we bump this to something like 2.0.54 as well? Our last round of testing only used 2.0.54 or later as you know, so saying it has only been tested on that or later is probably reasonable. We can always update it later if we get people with older versions of Apache testing it. Once that is decided I'll roll the tarball, likely tonight. I assume we'll use release-3-3-0b as the tag? Based on past conventions, that tag seems appropriate. If all is okay do we then just retag as 3.0.1? OK. I probably won't get to the tagging and rolling until tonight. (It's morning here now). Jim
Re: Release of mod_python 3.3.
Graham Dumpleton wrote: There were no more comments on basic apache.import_module() documentation so I have tweaked a few last things, committed it and marked as resolved the final issue in JIRA tagged for 3.3. Thus, unless anyone else has got any last minute issues, we should be good to go with a 3.3 release now. Jim, would you like to get the ball rolling when you have some time. Thanks to everyone who has contributed. Graham I do want to change the requirements in the docs. Currently it reads: * Python 2.2.1 or later. Earlier versions of Python will not work. * Apache 2.0.47 or later (For Apache 1.3.x, use mod_python version 2.7.x). We decided to officially bump the Python version requirement to 2.3, but are we still OK with Apache 2.0.47, or should we bump this to something like 2.0.54 as well? Once that is decided I'll roll the tarball, likely tonight. I assume we'll use release-3-3-0b as the tag? Jim
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC3
Steve Hay wrote: Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-rc3 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc3.tar.gz looks good on apache 2.2.2, perl 5.8.8 +1 --Geoff
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC3
PASS Win32 Perl-5.8.8 + Apache 2.2.3 Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-rc3 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc3.tar.gz Please take the time to exercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. Changes Since 1.29-rc2: http://svn.apache.org/viewvc?view=revrev=473808 Required Module::Build 0.18 RT: http://rt.cpan.org/Ticket/Display.html?id=19513 Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F I never had a dream come true 'Til the day that I found you. Even though I pretend that I've moved on You'll always be my baby. I never found the words to say You're the one I think about each day And I know no matter where life takes me to A part of me will always be... A part of me will always be with you.
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC3
Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-rc3 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc3.tar.gz All tests OK on Win32 using perl-5.8.8, apache-1.3.34 and mod_perl-1.29. -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC3
On Sat, 18 Nov 2006, Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-rc3 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc3.tar.gz +1 - tested on linux: Apache/2.0.55 (prefork) Win32: Apache/2.2.3 (winnt) -- best regards, Randy Kobes
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC3
Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-rc3 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc3.tar.gz +1 FreeBSD 6.1-release-p10 gcc 3.4.6 perl 5.8.8, httpd 2.2.3 prefork mpm perl 5.8.8 w/ithreads httpd 2.2.3 worker mpm I think we're at a good point in the RC cycle, so I'd like to able to release/announce Tuesday night; otherwise, it will be after the holiday. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F I never had a dream come true 'Til the day that I found you. Even though I pretend that I've moved on You'll always be my baby. I never found the words to say You're the one I think about each day And I know no matter where life takes me to A part of me will always be... A part of me will always be with you.
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
OK. New fresh builds of Perl 5.8.8, Apache 2.2.3, randy's apxs, mod_perl 2.0.3-rc2, Apache::Test-1.29-rc2, in their own clean tree, using VC6 (and Windows SDK just for building apache, for the ldap stuff) So far so good. mod_perl was detected by Apache-Test this time (so I guess we'll never know why it broke for me last week, since the PC I had it on is now FUBAR) But the 7 CGI tests still break for me The tests numbers are 32, 36-41 (in 2.09-rc2), and they all generate 500 errors I've uploaded the HTTP streams for any masochists (I really don't think there's anything in there more useful than the 500 error, but maybe someone will do me the favor of proving me wrong) to http://www.beamartyr.net/apreq-cgi.xml.bz2 I still say +1 to roll 2.09, since no one else seems to get these errors. Hopefully I'll figure out why I can't seem to get rid of them and fix anything needing fixing in 2.10 Issac
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Philip M. Gollucci wrote: Issac Goldstand wrote: Following up on the FAIL report for win32: Can you post your configuration steps -- I'm the wrong person to ask, but someone else might know. I see Steve H. got passing results. Just perl Makefile.PL, nmake, nmake test Which CGI tests fail ? Erm, my win32 build computer fizzled a bit last night, but I'll try to remember to post this on Sunday. I've already seen the same tests failing on a separate PC with a separate build environment (at work - yesterday's build were on my home office PC); I saw it when I was originally writing the interactive-cgi module (but never found time to chase them down) The new Apache-Test-1.29-RC2 runs the test suite for 2.08 just fine (against mod_perl-2.0.3-RC2). However, here the test suite can't load mod_perl (also mod_perl-2.0.3-RC2) into the server properly: The dection of mod_perl has changed 0 between 1.27-1.29 much less 1.29-rc1 and 1.29-rc2 CGI passes most tests (it fails 7; libapreq-2.08 also fails the same ones lately. That's a separate issue for a separate thread, though), it's just the mod_perl ones that seem to fail. Didn't you just contradict yourself ? I'm probably reading that wrong I don't think so - the CGI (t/apreq/cgi.t) test runs as a normal CGI, so IIRC doesn't go through mod_perl... Deeper probing (t/conf/httpd.conf) shows that: IfModule !mod_perl.c #unable to locate mod_perl.so (could be a static build) /IfModule Yes that would be the problem. (does Apache-Test have the correct path to apxs and is it actually functional?) I believe so; the same Apache-Test detects the same mod_perl just fine on the 2.08 tarball - it's really quite odd... Sunday I'll see if I can reproduce this at work. Giving a path via t/TEST -libmodperl didn't help Unfortunately, httpd-apreq unlike mod_perl does not yet handle this flag. Fixing the path to mod_perl manually in t/conf/httpd.conf did fix it (and all tests but the same 7 from CGI passed). D'oh!
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Following up on the FAIL report for win32: The new Apache-Test-1.29-RC2 runs the test suite for 2.08 just fine (against mod_perl-2.0.3-RC2). However, here the test suite can't load mod_perl (also mod_perl-2.0.3-RC2) into the server properly: E:\cpp\libapreq2-2.09\glue\perlperl t\TEST -clean E:\cpp\libapreq2-2.09\glue\perlperl t\TEST -verbose t\api\cookie.t t\api\erro t t\api\module.t t\api\param.t t\apreq\big_input.t t\apreq\cgi.t t\apreq\cooki t t\apreq\cookie2.t t\apreq\inherit.t t\apreq\upload.t C:/Apache2/bin/httpd.EXE -d E:/cpp/libapreq2-2.09/glue/perl/t -f E:/cpp/libap q2-2.09/glue/perl/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.3 (winnt MPM) waiting 60 seconds for server to start: .[Thu Nov 09 10:21:58 2006] [warn] Pas nv variable PERL5LIB was undefined waiting 60 seconds for server to start: ok (waited 0 secs) server localhost:8529 started t\api\cookie.request has failed (the response code was: 404) see t/logs/error_log for more details dubious Test returned status 9 (wstat 2304, 0x900) t\api\error..request has failed (the response code was: 404) see t/logs/error_log for more details dubious Test returned status 9 (wstat 2304, 0x900) t\api\module.request has failed (the response code was: 404) see t/logs/error_log for more details dubious Test returned status 9 (wstat 2304, 0x900) t\api\param..request has failed (the response code was: 404) see t/logs/error_log for more details dubious Test returned status 9 (wstat 2304, 0x900) t\apreq\big_input1..21 # Running under perl version 5.008008 for MSWin32 # Win32::BuildNumber 819 # Current time local: Thu Nov 9 10:22:04 2006 # Current time GMT: Thu Nov 9 08:22:04 2006 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.29 # # of keys : 5, key_len 5 # Failed test 1 in t\apreq\big_input.t at line 41 # testing : GET long query # expected: 39 # received: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN # htmlhead # title404 Not Found/title # /headbody # h1Not Found/h1 # pThe requested URL /TestApReq__big_input was not found on this server./p # /body/html not ok 1 # # of keys : 15, key_len 5 # Failed test 2 in t\apreq\big_input.t at line 41 fail #2 # testing : GET long query # expected: 119 # received: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN # htmlhead # title404 Not Found/title # /headbody # h1Not Found/h1 # pThe requested URL /TestApReq__big_input was not found on this server./p # /body/html not ok 2 [snip] CGI passes most tests (it fails 7; libapreq-2.08 also fails the same ones lately. That's a separate issue for a separate thread, though), it's just the mod_perl ones that seem to fail. Deeper probing (t/conf/httpd.conf) shows that: IfModule !mod_perl.c #unable to locate mod_perl.so (could be a static build) /IfModule Giving a path via t/TEST -libmodperl didn't help Fixing the path to mod_perl manually in t/conf/httpd.conf did fix it (and all tests but the same 7 from CGI passed). I'll keep poking around, but perhaps someone more intimately involved in Apache-Test can figure this out faster, based on what I've seen so far... Issac
Re: [RELEASE CANDIDATE] Apache-Test-1.27 RC2 + mod_perl2.03-RC2 + apreq 2.09-RC2
Win32 (VS2003) - httpd/2.2.3 - ActivePerl 5.8.8.819 PASS Apache-Test PASS mod_perl FAIL libapreq2 libapreq passed the 2 sets of C-based tests and failed the 3rd set (quite miserably), so it may just be a bug in Apache-Test. I'll look into it and send a proper bug report with details to apreq-dev shortly.
Re: [RELEASE CANDIDATE] Apache-Test-1.27 RC2 + mod_perl2.03-RC2 + apreq 2.09-RC2
Issac Goldstand wrote: Win32 (VS2003) - httpd/2.2.3 - ActivePerl 5.8.8.819 PASS Apache-Test PASS mod_perl FAIL libapreq2 libapreq passed the 2 sets of C-based tests and failed the 3rd set (quite miserably), so it may just be a bug in Apache-Test. I'll look into it and send a proper bug report with details to apreq-dev shortly. More likely the Dynamic Loading foo is busted on Win32 or the mod_perl glue (.pms) weren't in your PERL5LIB path when you ran 'nmake test'. randky will probably chime in. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F I never had a dream come true 'Til the day that I found you. Even though I pretend that I've moved on You'll always be my baby. I never found the words to say You're the one I think about each day And I know no matter where life takes me to A part of me will always be... A part of me will always be with you.
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
All OK on Win32 using apache-2.2.2, perl-5.8.8 and mod_perl-2.0.3-RC2 -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
On Wed, 2006-11-08 at 23:43 -0800, Philip M. Gollucci wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09.tar.gz http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09.tar.gz.asc http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09.tar.gz.md5 Builds for Fedora Extras 6 and development should appear after the new packages have been signed. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Issac Goldstand wrote: Following up on the FAIL report for win32: Can you post your configuration steps -- I'm the wrong person to ask, but someone else might know. I see Steve H. got passing results. Which CGI tests fail ? The new Apache-Test-1.29-RC2 runs the test suite for 2.08 just fine (against mod_perl-2.0.3-RC2). However, here the test suite can't load mod_perl (also mod_perl-2.0.3-RC2) into the server properly: The dection of mod_perl has changed 0 between 1.27-1.29 much less 1.29-rc1 and 1.29-rc2 CGI passes most tests (it fails 7; libapreq-2.08 also fails the same ones lately. That's a separate issue for a separate thread, though), it's just the mod_perl ones that seem to fail. Didn't you just contradict yourself ? I'm probably reading that wrong Deeper probing (t/conf/httpd.conf) shows that: IfModule !mod_perl.c #unable to locate mod_perl.so (could be a static build) /IfModule Yes that would be the problem. (does Apache-Test have the correct path to apxs and is it actually functional?) Giving a path via t/TEST -libmodperl didn't help Unfortunately, httpd-apreq unlike mod_perl does not yet handle this flag. Fixing the path to mod_perl manually in t/conf/httpd.conf did fix it (and all tests but the same 7 from CGI passed). D'oh! -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F I never had a dream come true 'Til the day that I found you. Even though I pretend that I've moved on You'll always be my baby. I never found the words to say You're the one I think about each day And I know no matter where life takes me to A part of me will always be... A part of me will always be with you.
Re: [RELEASE CANDIDATE] Apache-Test-1.29 RC2, [was typo 1.27 RC2]
Hi All, Deepest apologies. The correct version is 1.29-RC2 not 1.27-RC2 which I mistyped in the subject and part of the E-Mail text. The URL and tarball were/are correct as they stand. Again, apologies especially for the SPAM. Philip M. Gollucci wrote: A release candidate for Apache-Test 1.27 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc2.tar.gz Please take the time to exercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. Changes since 1.29-rc1: http://svn.apache.org/viewvc?view=revrevision=469617 Cygwin - Legacy CGYWIN ifs removed http://svn.apache.org/viewvc?view=revrev=470824 Fix http://rt.cpan.org/Ticket/Display.html?id=22748 and related http://svn.apache.org/viewvc?view=revrev=471132 need_module() documenation tweaks http://svn.apache.org/viewvc?view=revrev=471900 License text update per ASF board resolution. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F I never had a dream come true 'Til the day that I found you. Even though I pretend that I've moved on You'll always be my baby. I never found the words to say You're the one I think about each day And I know no matter where life takes me to A part of me will always be... A part of me will always be with you.
Re: [RELEASE CANDIDATES] Status ?
Philip M. Gollucci wrote: Hi all, so it seems I dropped the ball on the releases. I'm about to get back into it. Does anyone know of any issues that are still oustanding from mod_perl-2.0.3-RC1 Apache-Test 1.29-RC1 libapreq2 2.09-RC1 before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be ready with -RC2 for release. mod_perl might need a -RC3. So Fred's issues was foo-bar and I've just committed Nikolay's patch. If I hear nothing else, I'll roll -RC2s Thursday night. Nobody better be working tonight :) -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F When I call your name, Girl, it starts to flame Burning in my heart, Tearing it all apart.. No matter how I try My love I cannot hide
Re: [RELEASE CANDIDATES] Status ?
Issac Goldstand [EMAIL PROTECTED] writes: Philip M. Gollucci wrote: [...] Sadly, I don't think this can go into the 2.x series because of our conversioning rules. New features need new symbols. SVN gets around this by doing: void foo (void) void foo2 (int) Can you elaborate? I didn't understand that bit. The branch changes the behavior of apreq_handle_cgi(). The CGI specs make no guarantee about the existence of a QUERY_STRING env var when the url doesn't contain a ? (you can't assume the webserver is apache), and the docs for apreq_handle_cgi() currently suck: Create an apreq handle which is suitable for a CGI program. It reads input from stdin and writes output to stdout. From the documentation, I have no idea what that the specified behavior is supposed to be, other than to say the symbol should work in any CGI environment. (Not sure even why it claims to write anything to stdout, since we don't bake() cookies anymore). As a user, when I see lame documentation like that for a symbol in a released library, I assume the devs haven't gotten around to docmenting the current behavior- not that they haven't yet decided what the behavior should be. So, IMO the branch has a long way to go before it's suitable for merging into trunk. At a minimum it needs documentation and tests for the new behavior. You also need to decide if this stuff is a 2.x feature, in which case a new module (could bundle with libapreq alongside cgi) might be more appropriate. Or is it a 3.0 feature, in which case changing the behavior of apreq_handle_cgi() is ok? -- Joe Schaefer
Re: [RELEASE CANDIDATES] Status ?
Issac Goldstand [EMAIL PROTECTED] writes: That's what I originally thought when told to do it this way, but its wrong. RFC 3875 section 4.1.7 says The server MUST set this variable; if the Script-URI does not include a query component, the QUERY_STRING MUST be defined as an empty string (). So it does need to be there, and therefore apreq_handle_cgi() won't change the behavior *as long as* the CGI provider is RFC-compliant Why not just use GATEWAY_INTERFACE? That way we don't need to argue about the actual adoption of RFC 3875 (not a standard) vs the original (ambiguous) CGI spec. (you can't assume the webserver is apache), and the docs for apreq_handle_cgi() currently suck: Create an apreq handle which is suitable for a CGI program. It reads input from stdin and writes output to stdout. From the documentation, I have no idea what that the specified behavior is supposed to be, other than to say the symbol should work in any CGI environment. (Not sure even why it claims to write anything to stdout, since we don't bake() cookies anymore). Right. Are those docs generated by anything other than doxygen-ing the source? Maybe I can get some time (and find the patience) to try to spice them up a bit... Yeah, it's all doxygen-generated. The symbol is in apreq_module.h I think. As a user, when I see lame documentation like that for a symbol in a released library, I assume the devs haven't gotten around to docmenting the current behavior- not that they haven't yet decided what the behavior should be. So, IMO the branch has a long way to go before it's suitable for merging into trunk. At a minimum it needs documentation and tests for the new behavior. You also need to decide if this stuff is a 2.x feature, in which case a new module (could bundle with libapreq alongside cgi) might be more appropriate. Or is it a 3.0 feature, in which case changing the behavior of apreq_handle_cgi() is ok In my original post[1], I mentioned that I personally think a separate module (enhanced_cgi?) might be smarter, but I got no response, so continued development the way my boss wanted to have it done in-house, and figured we can always split later. It's your call whether you want to do a new module, writing all the tests, docs and perl glue, or work with the existing cgi module. I think it's possible to work with the existing cgi module and incorporate the changes into the 2.x line, but it'd require *serious* documention work. You'd have to explain how people could get the old behavior back if they wanted it, (eg. by including the GATEWAY_INTERFACE env var for instance). -- Joe Schaefer
Re: [RELEASE CANDIDATES] Status ?
Joe Schaefer [EMAIL PROTECTED] writes: Why not just use GATEWAY_INTERFACE? That way we don't need to argue about the actual adoption of RFC 3875 (not a standard) vs the original (ambiguous) CGI spec. Actually I took a peek around, and I think both IIS and Tomcat support 3875. So as long as it's documented, I don't mind if we rely on this spec as well. -- Joe Schaefer
Re: [RELEASE CANDIDATES] Status ?
Philip M. Gollucci wrote: this one time in band camp Issac Goldstand said on 10/29/06 01:41: If you're planning on rolling libapreq-2.09 soon, maybe we should include the intial work done in /branches/enhanced-cgi/ http://svn.apache.org/repos/asf/httpd/apreq/branches/enhanced-cgi/ It seems stable at the moment. Hi, yes, it looks interesting, but please keep replies on list. Sorry. Hit reply instead of reply-all... Also, you need to update the include/apreq_version.h *_VERSION #defines. [You should do this on _EVERY_ commit] Gotcha. Thanks. I guess this is what comes of work tearing me away from apreq a couple of weeks after getting voted in as a committer :-/ Hopefully, I'll be able to remedy that now that I'm working on Apache-based projects again. Sadly, I don't think this can go into the 2.x series because of our conversioning rules. New features need new symbols. SVN gets around this by doing: void foo (void) void foo2 (int) Can you elaborate? I didn't understand that bit. Issac
Re: [RELEASE CANDIDATES] Status ?
Philip M. Gollucci wrote: Hi all, so it seems I dropped the ball on the releases. I'm about to get back into it. Does anyone know of any issues that are still oustanding from mod_perl-2.0.3-RC1 Apache-Test 1.29-RC1 libapreq2 2.09-RC1 before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be ready with -RC2 for release. mod_perl might need a -RC3. There's one issue I know of with libapreq2 (thread on it earlier today), but I have had one of those bad computer weeks and haven't had enough time to put together a decent report for the list. I'll try to get something to you early this week on it, hopefully with a reproducible test case.
Re: [RELEASE CANDIDATES] Status ?
this one time in band camp Issac Goldstand said on 10/29/06 01:41: If you're planning on rolling libapreq-2.09 soon, maybe we should include the intial work done in /branches/enhanced-cgi/ http://svn.apache.org/repos/asf/httpd/apreq/branches/enhanced-cgi/ It seems stable at the moment. Hi, yes, it looks interesting, but please keep replies on list. Also, you need to update the include/apreq_version.h *_VERSION #defines. [You should do this on _EVERY_ commit] Sadly, I don't think this can go into the 2.x series because of our conversioning rules. New features need new symbols. SVN gets around this by doing: void foo (void) void foo2 (int) I don't know if we wan to go that route, its just one possible path. Issac Philip M. Gollucci wrote: Hi all, so it seems I dropped the ball on the releases. I'm about to get back into it. Does anyone know of any issues that are still oustanding from mod_perl-2.0.3-RC1 Apache-Test 1.29-RC1 libapreq2 2.09-RC1 before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be ready with -RC2 for release. mod_perl might need a -RC3. Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F When I call your name, Girl, it starts to flame Burning in my heart, Tearing it all apart.. No matter how I try My love I cannot hide -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F When I call your name, Girl, it starts to flame Burning in my heart, Tearing it all apart.. No matter how I try My love I cannot hide
Re: [RELEASE CANDIDATES] - Status
Philip M. Gollucci wrote: mod_perl 2.0.3-rc1 NetBSD 3.0 i386 perl 5.8.8 w/o ithreads httpd 2.2.3 -1 pgollucci t/apr-ext fail because of bad LD_LIBRARY_PATH / DynaLoader foo. I believe people have brought this failure up before and even suggested a patch for it. Anyone want to point to these threads ? Also, t/apr/constants.t255 65280?? ?? % ?? t/modperl/post_utf8.t ?? ?? % ?? -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F In all that I've done wrong I know I must have done something right to deserve a hug every morning and butterfly kisses at night. __ ___ ___ __ / |/ /_ __/ __/ __ \/ / / /|_/ / // /\ \/ /_/ / /__ /_/ /_/\_, /___/\___\_\___/ ___/
Re: [RELEASE CANDIDATES] - Status
Philip M. Gollucci wrote: mod_perl 2.0.3-rc1 NetBSD 3.0 i386 perl 5.8.8 w/o ithreads httpd 2.2.3 -1 pgollucci t/apr-ext fail because of bad LD_LIBRARY_PATH / DynaLoader foo. I believe people have brought this failure up before and even suggested a patch for it. Anyone want to point to these threads ? Also, t/apr/constants.t255 65280?? ?? % ?? t/modperl/post_utf8.t ?? ?? % ?? -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F In all that I've done wrong I know I must have done something right to deserve a hug every morning and butterfly kisses at night. __ ___ ___ __ / |/ /_ __/ __/ __ \/ / / /|_/ / // /\ \/ /_/ / /__ /_/ /_/\_, /___/\___\_\___/ ___/
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC1
On Thu, 7 Sep 2006, Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-RC1 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc1.tar.gz +1. Tested on - Win32: Apache/2.2.3 (winnt) - linux: Apache/2.0.55 (prefork) -- best regards, Randy
Re: [RELEASE CANDIDATE]: libapreq2 2.09-RC1
Philip M. Gollucci wrote:
Please download, test, and report back on the following
candidate tarball:
http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09-rc1.tar.gz
All tests OK on Win32 (on a single run, at least--I'm not sure if the
previous problems with upload.t have gone away or not) using perl-5.8.8
and apache-2.2.2.
It took me a while to get it to work, though. It kept falling over part
of the way through the tests complaining that C:\apache2\bin\Apache.exe
could not be found (which is correct!--it is now called
C:\apache2\bin\httpd.exe in 2.2.2).
It turns out that it was getting this old path from an old
Apache/TestConfigData.pm file that was left over in my perl5/site/lib
folder, presumably from some time ago when I was using apache-2.0.x.
I simply blew away the old TestConfigData.pm file, ran the tests again
and all was well (with a new, updated TestConfigData.pm being generated
along the way).
mod_perl-2.0.3-rc1 didn't have this problem when I tested that with the
same old perl5 directory a little earlier today, so I'm not sure what
libapreq's problem was.
Would it be sensible for {mod_perl|Apache-Test|libapreq} (delete as
appropriate!) to delete any old TestConfigData.pm file when installing a
new version of one of those packages?
--
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should check
it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE]: libapreq2 2.09-RC1
Works fine on FC4: Linux xxx 2.6.16-1.2069_FC4smp #1 SMP Tue Mar 28 12:47:32 EST 2006 i686 i686 i386 GNU/Linux On 9/7/06, Philip M. Gollucci [EMAIL PROTECTED] wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09-rc1.tar.gz Changes since 2.08: - Build [Philip M. Gollucci] code around |#_!!_#| autoconf 2.60 bug. Not listed in CHANGES: test suite fixes for cases without LWP installed. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F In all that I've done wrong I know I must have done something right to deserve a hug every morning and butterfly kisses at night. __ ___ ___ __ / |/ /_ __/ __/ __ \/ / / /|_/ / // /\ \/ /_/ / /__ /_/ /_/\_, /___/\___\_\___/ ___/
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC5
Philip M. Gollucci [EMAIL PROTECTED] writes: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC5.tar.gz +1, tested on Debian amd64 and FreeBSD 6.1. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC5
On Sun, 2006-08-06 at 21:40 -0700, Philip M. Gollucci wrote: Can you clue me in on this Fedora stuff and pardon my cluelessness. I'm not really an FE expert, but I'll give it a go :-) Do you test build it first, or just submit it to that service and it does everything ? Normally, I'll run build locally to make sure everything is OK (this is optional, of course). Then, I'll build using the FE build system (this happens on i386, PPC and x86_64). This enables everyone that is subscribed to FE Development to get the new package for testing in the next few days. Or do you test build it afterwards ? The idea is that if there are FC/FE users using libapreq2 out there, they will file bug reports and let me know if the package is broken. Sometimes I'm the guy that hits problems (e.g. -fno-strict-aliasing). And what does it mean exactly if the service says good When the service says good, it means I can build the thing on my build platforms. PS. If you question is does the build run 'make test', the answer is no. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC5
Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC5.tar.gz Changes from RC4: http://svn.apache.org/viewvc?rev=428216view=rev (Win32) http://svn.apache.org/viewvc?rev=428286view=rev http://svn.apache.org/viewvc?rev=428842view=rev http://svn.apache.org/viewvc?rev=428299view=rev Style only: http://svn.apache.org/viewvc?rev=424256view=rev +1 FreeBSD 6.1-stable i386 perl 5.8.8 with and without threads httpd 2.2.3 (prefork, work, event) mod_perl svn trunk -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F In all that I've done wrong I know I must have done something right to deserve a hug every morning and butterfly kisses at night.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC5
On Sun, 2006-08-06 at 19:46 -0700, Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC5.tar.gz Should appear in Fedora Extras soon. -- Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
Sorry this took me so long to get back to - it did catch aprutil-1.lib after using SVN mod_perl. I'll try to build RC4. Issac Randy Kobes wrote: On Wed, 12 Jul 2006, Randy Kobes wrote: On Tue, 11 Jul 2006, Issac Goldstand wrote: I wanted to test the build, since Randy said he couldn't, but ran into troubles compiling mod_perl (my gut feeling is that it's related to all the apr-1.lib files, and the version of apxs, et al, (at least the one I have), seems to be giving the wrong lib names) - and haven't had time to really look at that. It's odd because I don't think libapreq has this issue, as it builds the C library quite nicely. I know that I had trouble with lib names in earlier RC's, but Randy sorted out the problems with changes to various components. Make sure you are using the latest mod_perl sources from SVN and you must get the latest apxs from http://perl.apache.org/dist/win32-bin/ (version 0.4). That helped. It builds cleanly now. First seuite of tests runs OK: C:\Perl\bin\perl.exe -MExtUtils::Command::MM -e test_harness() library\t\cookie.t library\t\parsers.t library\t\params.t library\t\version.t library\t\cookie.ok library\t\params.ok library\t\parsersok library\t\versionok All tests successful. Files=4, Tests=648, 9 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) However, I seem to have another apxs-related issue... mod_apreq_access_test.c seems to be linking against the old APR-0.x libraries: (hope formatting doesn't get too mutilated) C:\apache2\bin\apxs.bat -I../../../apache2 -I../../../../include -lD:\cpp\libapreq2-2.08\win32\libs\libapreq2.lib -lD:\cpp\libapreq2-2.08\win32\libs\mod_apreq2.lib -llibhttpd -D APACHE2 -p -ID:\cpp\libapreq2-2.08\module\t\c-modules -c mod_apreq_access_test.c cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG -IC:\apache2\include /I../../../apache2 /I../../../../include /ID:\cpp\libapreq2-2.08\module\t\c-modules /D APACHE2 /c /Fomod_apreq_access_test.lo mod_apreq_access_test.c mod_apreq_access_test.c link kernel32.lib /nologo /subsystem:windows /dll /machine:I386 /libpath:C:\apache2\lib /out:mod_apreq_access_test.so D:\cpp\libapreq2-2.08\win32\libs\libapreq2.lib D:\cpp\libapreq2-2.08\win32\libs\mod_apreq2.lib libhttpd.lib C:\apache2\ lib\libaprutil.lib C:\apache2\lib\libapr.lib mod_apreq_access_test.lo LINK : fatal error LNK1181: cannot open input file 'C:\apache2\lib\libaprutil.lib' apxs:Error: Command failed with rc=10289152. NMAKE : fatal error U1077: 'C:\apache2\bin\apxs.bat' : return code '0x1' Stop. Will try keep you posted... Issac Thanks for pointing that out - I'll take a look at it early next week, when I get back. That problem (with using the wrong libaprutil.lib name with Apache-2.2) doesn't arise for me. I'm wondering if it's picking up an old Apache installation and/or is getting confused with a previous build? Can you try reinstalling apxs from http://perl.apache.org/dist/win32-bin/, rebuild and reinstall mod_perl2 from the svn sources, and then rebuild libapreq2 from clean sources? Does that help?
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Tue, 25 Jul 2006, Randy Kobes wrote: On Tue, 25 Jul 2006, Steve Hay wrote: Yes, that works for me! I tried the individual test and the whole test suite dozens of times over and didn't get a single failure. I'm not sure how it makes any difference, though, or exactly what it does. I searched the whole of my httpd-2.2.2 folder and only found one use of it (actually, of its new name, APR_FOPEN_SHARELOCK) relating to sdbm files. What am I missing? I'm baffled now, too - as far as I can see too, apr only uses APR_FOPEN_SHARELOCK in sdbm files, and neither mod_perl nor librapreq2 seems to use it. But it does make a difference - although I don't see as many failures as you do, without APR_FOPEN_SHARELOCK I definitely get temp files left over. Is the change safe, or does it introduce any security issues with temporary spool files being shared somehow? That I'm not sure of, especially now that I'm not sure what it's affecting ... I still haven't been able to track down why the use of APR_FOPEN_SHARELOCK works in cleaning up the temp files. I did try a simple C apr-based program that just opens a temp file in the same way as is done within apreq_file_mktemp(), with the registered apreq_file_cleanup(), writes some random text to it, and then closes it - in this the temp files were cleaned up with or without APR_FOPEN_SHARELOCK, and also with or without APR_FILE_NOCLEANUP. So something more complex is involved. Nevertheless, unless someone objects in the next day or so, I'd like to commit this change, as I think leaving temp files lying around is a worse problem. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Nevertheless, unless someone objects in the next day or so, I'd like to commit this change, as I think leaving temp files lying around is a worse problem. No objection here :) -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F It takes a minute to have a crush on someone, an hour to like someone, and a day to love someone, but it takes a lifetime to forget someone...
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Randy Kobes wrote: On Mon, 24 Jul 2006, Steve Hay wrote: Randy Kobes wrote: Also, just to verify that it is the stray temp files left over that are causing the problem, does it help if you change the APR_EXCL flag in the call to apr_file_mktemp on about line 832 of library/util.c to APR_TRUNCATE? Yep, that makes the errors go away: it didn't fail once in about two dozen runs. Does the following help? [...] With the APR_SHARELOCK flag, I don't see any temp files left over after about 50 runs of the upload.t test (without it, but still with APR_FILE_NOCLEANUP, I would have 2-3 left over after 50 runs). Yes, that works for me! I tried the individual test and the whole test suite dozens of times over and didn't get a single failure. I'm not sure how it makes any difference, though, or exactly what it does. I searched the whole of my httpd-2.2.2 folder and only found one use of it (actually, of its new name, APR_FOPEN_SHARELOCK) relating to sdbm files. What am I missing? Is the change safe, or does it introduce any security issues with temporary spool files being shared somehow? -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Tue, 25 Jul 2006, Steve Hay wrote: Yes, that works for me! I tried the individual test and the whole test suite dozens of times over and didn't get a single failure. I'm not sure how it makes any difference, though, or exactly what it does. I searched the whole of my httpd-2.2.2 folder and only found one use of it (actually, of its new name, APR_FOPEN_SHARELOCK) relating to sdbm files. What am I missing? I'm baffled now, too - as far as I can see too, apr only uses APR_FOPEN_SHARELOCK in sdbm files, and neither mod_perl nor librapreq2 seems to use it. But it does make a difference - although I don't see as many failures as you do, without APR_FOPEN_SHARELOCK I definitely get temp files left over. Is the change safe, or does it introduce any security issues with temporary spool files being shared somehow? That I'm not sure of, especially now that I'm not sure what it's affecting ... -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Steve Hay wrote: Sorry, but I'm still seeing quite a few failures. I started with a completely fresh build (with your patch applied) and the top-level nmake test failed a bunch of upload.t tests first time. (So it's not just running the test multiple times that causes the problem.) I then cd'd to perl/glue and ran just the upload.t test a dozen times over and it still failed 2 or 3 times. Is there an equivalent to 'strace' on 'that which you deem to call an OS' :) The 'open,access,stat*' might be useful ? -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F In all that I've done wrong I know I must have done something right to deserve a hug every morning and butterfly kisses at night.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Randy Kobes wrote: On Mon, 24 Jul 2006, Steve Hay wrote: Sorry, but I'm still seeing quite a few failures. I started with a completely fresh build (with your patch applied) and the top-level nmake test failed a bunch of upload.t tests first time. (So it's not just running the test multiple times that causes the problem.) I then cd'd to perl/glue and ran just the upload.t test a dozen times over and it still failed 2 or 3 times. Sigh :) ... One thing I tried (that didn't make a difference for me, but might for you) is in the call to apr_pool_cleanup_register( ...) on about line 829 of library/util.c, change the last arguments apreq_file_cleanup, apreq_file_cleanup to apreq_file_cleanup, apr_pool_cleanup_null Does that change anything? The cleanup in apr_file_open uses this latter form. Makes no difference for me either. I tried it with and without your previous APR_FILE_NOCLEANUP change, but I still see failures either way. Also, just to verify that it is the stray temp files left over that are causing the problem, does it help if you change the APR_EXCL flag in the call to apr_file_mktemp on about line 832 of library/util.c to APR_TRUNCATE? Yep, that makes the errors go away: it didn't fail once in about two dozen runs. -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Mon, 24 Jul 2006, Steve Hay wrote:
Randy Kobes wrote:
Also, just to verify that it is the stray temp files
left over that are causing the problem, does it help
if you change the APR_EXCL flag in the
call to apr_file_mktemp on about line 832 of library/util.c
to APR_TRUNCATE?
Yep, that makes the errors go away: it didn't fail once in about two dozen
runs.
Does the following help?
=
Index: util.c
===
--- util.c (revision 425268)
+++ util.c (working copy)
@@ -811,6 +811,7 @@
apr_status_t rc;
char *tmpl;
struct cleanup_data *data;
+apr_int32_t flag;
if (path == NULL) {
rc = apr_temp_dir_get(path, pool);
@@ -829,9 +830,13 @@
apr_pool_cleanup_register(pool, data,
apreq_file_cleanup,
apreq_file_cleanup);
-rc = apr_file_mktemp(fp, tmpl, /* NO APR_DELONCLOSE!
see comment above */
- APR_CREATE | APR_READ |
APR_WRITE
- | APR_EXCL | APR_BINARY, pool);
+/* NO APR_DELONCLOSE! see comment above */
+flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL |
APR_BINARY;
+/* Win32 needs the following to remove temp files */
+#ifdef WIN32
+flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK;
+#endif
+rc = apr_file_mktemp(fp, tmpl, flag, pool);
if (rc == APR_SUCCESS) {
apr_file_name_get(data-fname, *fp);
With the APR_SHARELOCK flag, I don't see any temp files
left over after about 50 runs of the upload.t test (without
it, but still with APR_FILE_NOCLEANUP, I would have 2-3
left over after 50 runs).
--
best regards,
Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Philip M. Gollucci wrote: Steve Hay wrote: Sorry, but I'm still seeing quite a few failures. I started with a completely fresh build (with your patch applied) and the top-level nmake test failed a bunch of upload.t tests first time. (So it's not just running the test multiple times that causes the problem.) I then cd'd to perl/glue and ran just the upload.t test a dozen times over and it still failed 2 or 3 times. Is there an equivalent to 'strace' on 'that which you deem to call an OS' :) The 'open,access,stat*' might be useful ? I have a Cygwin strace, but it doesn't seem to work trying to trace this. I tried a couple of freeware strace's that I found via Google too, but they were pretty crappy and I couldn't get anything useful out of them either. -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Mon, 24 Jul 2006, Steve Hay wrote: Sorry, but I'm still seeing quite a few failures. I started with a completely fresh build (with your patch applied) and the top-level nmake test failed a bunch of upload.t tests first time. (So it's not just running the test multiple times that causes the problem.) I then cd'd to perl/glue and ran just the upload.t test a dozen times over and it still failed 2 or 3 times. Sigh :) ... One thing I tried (that didn't make a difference for me, but might for you) is in the call to apr_pool_cleanup_register( ...) on about line 829 of library/util.c, change the last arguments apreq_file_cleanup, apreq_file_cleanup to apreq_file_cleanup, apr_pool_cleanup_null Does that change anything? The cleanup in apr_file_open uses this latter form. Also, just to verify that it is the stray temp files left over that are causing the problem, does it help if you change the APR_EXCL flag in the call to apr_file_mktemp on about line 832 of library/util.c to APR_TRUNCATE? -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Fri, 21 Jul 2006, Philip M. Gollucci wrote:
Philip M. Gollucci wrote:
Philip M. Gollucci wrote:
Randy Kobes wrote:
Which means
apr_pool_cleanup_register(pool, data,
apreq_file_cleanup, apreq_file_cleanup);
Contrary to the comment in library/util.c
data = apr_palloc(pool, sizeof *data);
/* cleanups are LIFO, so this one will run just after
the cleanup set by mktemp */
apr_pool_cleanup_register(pool, data,
apreq_file_cleanup, apreq_file_cleanup);
rc = apr_file_mktemp(fp, tmpl, /* NO APR_DELONCLOSE! see comment above */
APR_CREATE | APR_READ | APR_WRITE
| APR_EXCL | APR_BINARY, pool);
Win32 doesn't have mktemp, so thats not *strictly* true.
I think that refers to the cleanup set by apr_file_mktemp,
which in turn comes from apr_file_open (on Win32).
FYI,
http://svn.apache.org/viewvc/apr/apr/trunk/file_io/unix/mktemp.c?r1=62405r2=62404pathrev=62405
The cleanup on Win32 was removed from apr here... I'll bet that's it!
The explicit cleanup was removed there, but replaced by
APR_DELONCLOSE (set by default), which if set would
delete the file on close. But, as the comment explains,
can't be used here ...
But I think you're on the right track, in that the
problem with the temp files sticking around (and
apparently causing the occasional errors when the
upload.t test is run multiple times) comes from the
cleanup set by apr_file_open. I tried this patch:
==
Index: util.c
===
--- util.c (revision 424771)
+++ util.c (working copy)
@@ -811,6 +811,7 @@
apr_status_t rc;
char *tmpl;
struct cleanup_data *data;
+apr_int32_t flag;
if (path == NULL) {
rc = apr_temp_dir_get(path, pool);
@@ -828,11 +829,14 @@
the cleanup set by mktemp */
apr_pool_cleanup_register(pool, data,
apreq_file_cleanup,
apreq_file_cleanup);
+/* NO APR_DELONCLOSE! see comment above */
+flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL |
APR_BINARY;
+/* needed on Win32 to cleanup temp files */
+#ifdef WIN32
+flag |= APR_FILE_NOCLEANUP;
+#endif
+rc = apr_file_mktemp(fp, tmpl, flag, pool);
-rc = apr_file_mktemp(fp, tmpl, /* NO APR_DELONCLOSE!
see comment above */
- APR_CREATE | APR_READ |
APR_WRITE
- | APR_EXCL | APR_BINARY, pool);
-
if (rc == APR_SUCCESS) {
apr_file_name_get(data-fname, *fp);
data-pool = pool;
===
which seems to help - when the upload.t test is run
multiple times, I get far fewer temp files left over
(although the occasional ones do stick around), and
even when they are there, I haven't seen any failures
yet. Steve, does this help you?
--
best regards,
Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Philip M. Gollucci wrote: Randy Kobes wrote: [Thu Jul 20 23:45:45 2006] [error] [client 127.0.0.1] (OS 80)The file exists. : apreq_brigade_concat failed; TempDir problem? which is coming from about line 288 of module/apache2/filter.c. The file exists message I think comes from the fact that, when the test fails, there's old temp files left over from a previous run. So perhaps the cleanup discussed in library/util.c at around line 797 is failing occasionally? You are absolutely correct. I can force duplicate on FBSD. I changed this (dropped the ) so I could predict the temp file name and yanked out all the tests not for tempname in t/apreq/upload.t rc = apr_filepath_merge(tmpl, path, apreq, APR_FILEPATH_NOTRELATIVE, pool); touch /tmp/apreq t/error_log [Fri Jul 21 04:02:42 2006] [error] [client 127.0.0.1] $param-upload_tempname($req): can't make spool bucket at /usr/home/pgollucci/dev/repos/asf/httpd/apreq/trunk/glue/perl/t/response/TestApReq/upload.pm line 33. Which means apr_pool_cleanup_register(pool, data, apreq_file_cleanup, apreq_file_cleanup); which calls apr_file_remove() which on Win32 is way out of my league :( I'm guessing this is failing, but silently. or less likely the cleanup is just not being run ? Question, are you both ASCII or UNICODE ? -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F In all that I've done wrong I know I must have done something right to deserve a hug every morning and butterfly kisses at night.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Philip M. Gollucci wrote: Philip M. Gollucci wrote: Randy Kobes wrote: Which means apr_pool_cleanup_register(pool, data, apreq_file_cleanup, apreq_file_cleanup); Contrary to the comment in library/util.c data = apr_palloc(pool, sizeof *data); /* cleanups are LIFO, so this one will run just after the cleanup set by mktemp */ apr_pool_cleanup_register(pool, data, apreq_file_cleanup, apreq_file_cleanup); rc = apr_file_mktemp(fp, tmpl, /* NO APR_DELONCLOSE! see comment above */ APR_CREATE | APR_READ | APR_WRITE | APR_EXCL | APR_BINARY, pool); Win32 doesn't have mktemp, so thats not *strictly* true. FYI, http://svn.apache.org/viewvc/apr/apr/trunk/file_io/unix/mktemp.c?r1=62405r2=62404pathrev=62405 The cleanup on Win32 was removed from apr here... I'll bet that's it! -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F In all that I've done wrong I know I must have done something right to deserve a hug every morning and butterfly kisses at night.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
On Thu, 20 Jul 2006, Philip M. Gollucci wrote: Steve Hay wrote: repeatedly from the glue/perl sub-directory and see whether or not it ever fails for you. Did you get round to trying that? Just did. 24 times. 100% success. My usual combination of things. Like Steve, I still see this failing occasionally on Win32, but not in a predictable manner. And it's not always the same file that fails in the upload test. I'll try some things to try to make it reproduceable in the next couple of days, but if that doesn't pan out, I wouldn't want this to hold up the release. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Quoting Philip M. Gollucci [EMAIL PROTECTED]: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC4.tar.gz The Fedora Extras package (development) will be available after signing. -- Bojan
Re: release 3.2.10?
I'm +1 on going for 3.2.10. You in Canada probably have it easier - I think we hit 96F/35C at some point today or yesterday (I wouldn't know I'm in the office which has AC sunrise to sunset, I just listen to the news), and unfortunately (or not) due to work pressures I have no time for anything - no frolicking for me this summer :-( Grisha On Sun, 16 Jul 2006, Jim Gallacher wrote: Graham Dumpleton wrote: Jim Gallacher wrote .. Shall we proceed with a 3.2.10 release with the current memory leak fixes, or keep digging for more leaks? Seeing as it's summer for most of us (except for Graham), I get the feeling people don't have a lot of free time to spend on mod_python right now. Just because it is winter down here and I'm freezing my butt off doesn't mean I am any less busy. :-( Oh, I wasn't suggesting you were any less busy - just that folks in the northern hemisphere may well choose to frolic in the summer sun rather that hack away at mod_python in their spare time. :) Jim
Re: release 3.2.10?
On Tue, 18 Jul 2006, Jim Gallacher wrote: For 3.2.9 I called for 2 rounds of testing: one for the release candidate and one for the final tarball. Do folks here feel that is necessary for 3.2.10 or should I just jump right to the 3.2.10 final? That tarball would still be subject to a vote on this list before an official release. Cutting out the first step will save a few days. I think what you term it doesn't matter - if it's voted down, it will be voted down, be it 3.2.10 RC or 3.2.10 Final (we'll just have to make a 3.2.11 then). So just go for it :-) Grisha
Re: release 3.2.10?
Gregory (Grisha) Trubetskoy wrote: (we'll just have to make a 3.2.11 then). Let's call that one the Spinal Tap version. :)
Re: release 3.2.10?
Jim Gallacher wrote: Deron Meranda wrote: Just want some verification because I haven't seen anything official looking Is 3.2.9 now considered a bad release because of its memory leaks, and thus will never be released? It's not so much that it's a bad release, but rather it didn't make sense to officially release 3.2.9 and then turn around and release 3.2.10 a week later. The leak that will be fixed in 3.2.10 is not new in 3.2.9, only newly discovered. Hence 3.2.10 will be the next hopeful stable release after 3.2.8? Basically yes, but if you are already using 3.2.9 there is no harm specific harm. At any rate, I'll roll a 3.2.10 tarball for testing by the list tonight. Best laid plans and all that... For 3.2.9 I called for 2 rounds of testing: one for the release candidate and one for the final tarball. Do folks here feel that is necessary for 3.2.10 or should I just jump right to the 3.2.10 final? That tarball would still be subject to a vote on this list before an official release. Cutting out the first step will save a few days. Jim
Re: release 3.2.10?
Just want some verification because I haven't seen anything official looking Is 3.2.9 now considered a bad release because of its memory leaks, and thus will never be released? Hence 3.2.10 will be the next hopeful stable release after 3.2.8? -- Deron Meranda
Re: release 3.2.10?
Deron Meranda wrote: Just want some verification because I haven't seen anything official looking Is 3.2.9 now considered a bad release because of its memory leaks, and thus will never be released? It's not so much that it's a bad release, but rather it didn't make sense to officially release 3.2.9 and then turn around and release 3.2.10 a week later. The leak that will be fixed in 3.2.10 is not new in 3.2.9, only newly discovered. Hence 3.2.10 will be the next hopeful stable release after 3.2.8? Basically yes, but if you are already using 3.2.9 there is no harm specific harm. At any rate, I'll roll a 3.2.10 tarball for testing by the list tonight. Jim
Re: release 3.2.10?
Graham Dumpleton wrote: Jim Gallacher wrote .. Shall we proceed with a 3.2.10 release with the current memory leak fixes, or keep digging for more leaks? Seeing as it's summer for most of us (except for Graham), I get the feeling people don't have a lot of free time to spend on mod_python right now. Just because it is winter down here and I'm freezing my butt off doesn't mean I am any less busy. :-( Oh, I wasn't suggesting you were any less busy - just that folks in the northern hemisphere may well choose to frolic in the summer sun rather that hack away at mod_python in their spare time. :) Jim
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
Randy Kobes wrote: On Sat, 8 Jul 2006, Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC3.tar.gz [ .. ] I'd like to make the actual release around Wednesday of next week (07/12/2006) I'm away next week on holiday - if someone could test this out on Win32, that'd be great. I still have an intermittent problem with one of the perl glue tests: t\apreq\upload.t (I've mentioned this before when testing previous RC's). It doesn't happen every time, but if I run that test half a dozen times then it almost always goes wrong at least once. When it goes wrong it fails one or more tests, typically towards the end of the 20 tests included in that file. Attached is the console output from running the following command, on an occasion on which it went wrong: C:\Temp\libapreq2-2.08\glue\perlC:\perl5mt\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -verbose=1 t\apreq\upload.t Also attached is the corresponding error_log, which contains three errors, presumably relating to the three tests that failed (15, 16, 17), and the access_log, which shows the three 500 HTTP responses. I'm running perl-5.8.8, apache-2.2.2, mod_perl-2 from svn @ rev 412155. All OK otherwise. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. C:/apache2/bin/httpd.exe -d C:/Temp/libapreq2-2.08/glue/perl/t -f C:/Temp/libapreq2-2.08/glue/perl/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.2 (winnt MPM) waiting 60 seconds for server to start: .[Tue Jul 11 09:39:24 2006] [warn] PassEnv variable PERL5LIB was undefined waiting 60 seconds for server to start: ok (waited 0 secs) server localhost:8529 started t\apreq\upload1..20 # Running under perl version 5.008008 for MSWin32 # Current time local: Tue Jul 11 09:39:25 2006 # Current time GMT: Tue Jul 11 08:39:25 2006 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.29 # testing : fh test for httpd # expected: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e # received: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e ok 1 # testing : io test for httpd # expected: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e # received: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e ok 2 # testing : link test for httpd # expected: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e # received: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e ok 3 # testing : slurp test for httpd # expected: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e # received: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e ok 4 # testing : tempname test for httpd # expected: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e # received: # type: application/octet-stream # size: 20534 # filename: httpd # md5: f321f925f9200139546142a67f69347e ok 5 # testing : fh test for perl # expected: # type: application/octet-stream # size: 20524 # filename: perl # md5: 598d1e4ad0c3b48982423d63ceef6972 # received: # type: application/octet-stream # size: 20524 # filename: perl # md5: 598d1e4ad0c3b48982423d63ceef6972 ok 6 # testing : io test for perl # expected: # type: application/octet-stream # size: 20524 # filename: perl # md5: 598d1e4ad0c3b48982423d63ceef6972 # received: # type: application/octet-stream # size: 20524 # filename: perl # md5: 598d1e4ad0c3b48982423d63ceef6972 ok 7 # testing : link test for perl # expected: # type: application/octet-stream # size: 20524 # filename: perl # md5: 598d1e4ad0c3b48982423d63ceef6972 # received: # type: application/octet-stream # size: 20524 # filename: perl # md5: 598d1e4ad0c3b48982423d63ceef6972 ok 8 # testing : slurp test for perl # expected: # type: application/octet-stream # size: 20524 # filename: perl # md5:
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
It didn't unpack on win32 using 7-zip either... But GNU tar (the native binary from the unixutils project on sf, not under cygwin) worked ok (except for symbolic links, but that shouldn't be so bad). I wanted to test the build, since Randy said he couldn't, but ran into troubles compiling mod_perl (my gut feeling is that it's related to all the apr-1.lib files, and the version of apxs, et al, (at least the one I have), seems to be giving the wrong lib names) - and haven't had time to really look at that. It's odd because I don't think libapreq has this issue, as it builds the C library quite nicely. The ppm mod_perl doesn't seem to put the .h files where libapreq looks (if it even includes headers - does it randy?), and for some odd reason, running Makefile.PL with disable-perl-glue doesn't seem to get passed to win32/Configure.pl... D:\cpp\libapreq2-2.08perl Makefile.PL disable-perl-glue perl: 5.8.8 ok mod_perl2: 2.03 ok Apache::Test: 1.29 ok ExtUtils::MakeMaker: 6.30 ok ExtUtils::XSBuilder: 0.28 ok Test::More: 0.62 ok C:\Perl\bin\perl.exe win32/Configure.pl --with-perl-opts=disable-perl-glue --with-apache2-apxs=C:\Apache2\bin\apxs.bat --with-perl=C:\Perl\bin\perl.exe --with-apache2=C:\Apache2 --enable-perl-glue Unknown option: with-perl-opts Initialize parser scan D:/cpp/libapreq2-2.08/include/apreq.h ... [normal xsbuilder scanning] and running win32/Configure.pl on my own with the --disable-perl-glue option, seems to get ignored. After it builds the C library, it prepares Makefile's for the perl glue and starts building. One thing I did just notice is: writing...xs/APR/Makefile.PL [ info] generating script t/TEST Note (probably harmless): No library found for C:/svn/mp2/src/modules/perl/mod_perl.lib Not sure where that path came from. Anyway, if I have time later, maybe I'll try to look into this further... Issac Philip M. Gollucci wrote: Bojan Smojver wrote: Quoting Bojan Smojver [EMAIL PROTECTED]: OK. I'm off to work now anyway - I'll try unpacking on machines there. Works on Solaris Sparc and RHEL4 x86_64, doesn't on Fedora Core 5 x86_64/i386. Go figure... Its not I did something differnt from previous releases gmake release. scp ball.tar.gz apache.org: Should I roll another one or do you think its just that box ?
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC3
On Sat, 2006-07-08 at 03:39 -0700, Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC3.tar.gz Weird. I'm getting errors when unpacking the tarball: - -rw-r--r-- pgollucci/wheel 5921 2006-07-08 19:36 libapreq2-2.08/win32/libapreq2.mak -rw-r--r-- pgollucci/wheel 4321 2006-07-08 19:36 libapreq2-2.08/win32/mod_apreq2.mak -rw-r--r-- pgollucci/wheel 1516 2006-07-08 19:36 libapreq2-2.08/win32/README -rw-r--r-- pgollucci/wheel 4184 2006-07-08 19:36 libapreq2-2.08/win32/test_cgi.mak -rw-r--r-- pgollucci/wheel977 2006-07-08 19:36 libapreq2-2.08/win32/util.pl tar: Error exit delayed from previous errors - What's the MD5 supposed to be? -- Bojan
