Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
On 9/6/2017 10:23 AM, Steve Hay wrote: > On 19 January 2017 at 14:25, Issac Goldstand <mar...@beamartyr.net> wrote: >> That release was canceled due to lack of votes, but regardless there was >> very little effective difference between that and 2.13 - mostly around >> tests, docs and build scripts. 2.13 should run just fine on 2.4 > > Somehow, it only came to my attention yesterday that 2.14 never > officially got released. That's a great shame because 2.13 doesn't > build out-of-the-box on Windows, at least not with httpd-2.4, whereas > 2.14 does. > > Is there any chance of resurrecting it, or else just going for a new > release numbered 2.15? > Moving to the apreq-dev list, and we can follow-up on the modperl list thread if it makes sense later :) I don't see why not, but I'd like to informally ping the dev list and see whether we have other PMC members who'd be willing to vote. Otherwise, we'd be making a lot of useless noise in prepping a release. Issac >> >> Issac >> >> On 1/19/2017 6:30 AM, Jie Gao wrote: >>> >>> There was a new release candidate over a month ago, and it is available at >>> https://home.apache.org/~issac/libapreq2-2.14.tar.gz . >>> >>> Regards, >>> >>> >>> Jie >>> >>> >>> >>> * JW <gav...@yahoo.com> wrote: >>> >>>> Date: Wed, 18 Jan 2017 20:06:41 + >>>> From: JW <gav...@yahoo.com> >>>> To: "modp...@perl.apache.org" <modp...@perl.apache.org> >>>> Subject: Question about Apache 2.4 and libapreq2 (Apache2::Request) >>>> >>>> >>>> Hi, >>>> >>>> I currently use Apache 2.2, mod_perl and libapreq2 (for Apache2::Request >>>> and Apache2::Cookie). I did a test installation of Apache 2.4 (yum), >>>> mod_perl (source) and libapreq2-2.13 (source). and it seems to work fine. >>>> >>>> The last update of libapreq2 was in 2010. I'm aware that not every >>>> library has to be updated and frankly I'm pleased that it still works. >>>> However, before I make a permanent switch to Apache 2.4, I was wondering if >>>> anyone doing a similar upgrade experienced problems using libapreq2 and >>>> what >>>> alternative(s) they chose. >>>> >>>> Thank you. >>>> >>>> John >>>> >>>> >>>> >>> >>
Re: [RELEASE CANDIDATE] libapreq2-2.14 RC
Builds and passes all tests on linux x64 with: Perl/5.18 Apache/2.2.31 mod_perl/2.10 Perl/5.24 Apache/2.4.23 mod_perl/2.10 I'm +1 on release On 12/5/2016 5:58 PM, Issac Goldstand wrote: > After (almost) 6 years, the apreq team would like to release version > 2.14 of libapreq. Please test and vote on the following tarball: > > https://home.apache.org/~issac/libapreq2-2.14.tar.gz > https://home.apache.org/~issac/libapreq2-2.14.tar.gz.asc > https://home.apache.org/~issac/libapreq2-2.14.tar.gz.md5 > > Thanks, > Issac >
[RELEASE CANDIDATE] libapreq2-2.14 RC
After (almost) 6 years, the apreq team would like to release version 2.14 of libapreq. Please test and vote on the following tarball: https://home.apache.org/~issac/libapreq2-2.14.tar.gz https://home.apache.org/~issac/libapreq2-2.14.tar.gz.asc https://home.apache.org/~issac/libapreq2-2.14.tar.gz.md5 Thanks, Issac signature.asc Description: OpenPGP digital signature
Re: apreq release
Honestly, I've no clue. The plan is just to add a few checks with mod_version (if available) to deal with the 2.2/2.4 config syntax changes, and the changes so far seem to only be in the test suite. I haven't hit any changes in libapreq itself yet. I don't have any connection with the Debian maintainers, but if someone on these lists does and has interest, they're welcome to update following the ANNOUNCE message post-release. On 11/15/2016 9:17 PM, Mark Hedges wrote: > Any chance this is what keeps me from running the Apache::Test tests for > Apache2::Controller under Apache 2.4? > > Will this be packaged and released to Debian Stretch before it goes > stable, or can you advise the package maintainers to update? > > Thanks. > Mark > > On Tue, Nov 15, 2016 at 1:26 AM, Issac Goldstand <mar...@beamartyr.net > <mailto:mar...@beamartyr.net>> wrote: > > Hi all, > > Someone (finally) noticed that apreq's test suite isn't compatible with > Apache 2.4 and requested a change. Given that we haven't released an > updated apreq in nearly 6 years, I'm inclined to make/test the changes > to the test suite and immediately go to a release cycle. > > Does anyone want time to add anything else to libapreq-2.14 before I > start tarring and voting (in the next few days, I hope)? > >
Re: Was there any concrete decision on apreq?
I think nothing. Most mod_perl users (I think) install apreq via Apache2::Request. That can continue to be maintained on CPAN, as is, linking against httpd instead of mod_apreq Or do you forsee a problem here? On 2/24/2015 9:56 AM, Steve Hay wrote: What would this mean for mod_perl users? I, and I assume many others(?), still use the perl glue part of libapreq in mod_perl software. I only just spotted this thread, and just wondered how such mod_perl users will be affected, if at all. On 24 February 2015 at 03:24, Joseph Schaefer joe_schae...@yahoo.com wrote: I still want to do that just lacking tuits Sent from my iPhone On Feb 23, 2015, at 3:56 PM, Eric Covener cove...@gmail.com wrote: On Mon, Feb 23, 2015 at 3:45 PM, Gregg Smith g...@gknw.net wrote: Am I missing something? Did I miss a boatload of email where any firm decision was made? I don't think you have missed anything. I assume very few people have any clue how it's integrated/used today. The last thing I have in my mail archive is joes proposal to pull the library part back out and make it available in a way similar to mod_ldap.
Re: error in Apache::TestSSLCA, cannot build libapreq
I'll try to get to look at this in the next few days. I'm incredibly
low on time this week, so feel free to prod me (off-list, please) if you
don't see it soon.
Issac
On 24/06/2014 00:57, Mark Hedges wrote:
Use of each() on hash after insertion without resetting hash iterator
results in undefined behavior, Perl interpreter: 0xf2e8010 at
/ntfhome/local/lib/perl5/site_perl/5.20.0/x86_64-linux-thread-multi-ld/Apache/TestSSLCA.pm
line 103.
Compilation failed in require at
/ntfhome/local/lib/perl5/site_perl/5.20.0/x86_64-linux-thread-multi-ld/Apache/TestConfig.pm
line 1474.
Apparently in 5.20.0 adding elements to a hash while in an each statement
does not work.
This patch fixes the problem and the rest of libapreq builds without issues.
Cross-reported to CPAN RT under # 95805. HTH. -Mark
---
/ntfhome/local/lib/perl5/site_perl/5.20.0/x86_64-linux-thread-multi-ld/Apache/TestSSLCA.pm.orig2014-06-23
14:49:44.712628000 -0700
+++
/ntfhome/local/lib/perl5/site_perl/5.20.0/x86_64-linux-thread-multi-ld/Apache/TestSSLCA.pm
2014-06-23 14:51:24.685043000 -0700
@@ -100,10 +100,10 @@
};
#generate DSA versions of the server certs/keys
-while (my($key, $val) = each %$cert_dn) {
+for my $key (keys %$cert_dn) {
next unless $key =~ /^server/;
my $name = join '_', $key, 'dsa';
-$cert_dn-{$name} = { %$val }; #copy
+$cert_dn-{$name} = { %{$cert_dn-{$key}} }; #copy
$cert_dn-{$name}-{OU} =~ s/rsa/dsa/;
}
2014-06-23 14:42:46 Mon $ t/TEST -clean
[ debug] unlink
/ntfhome/local/src/libapreq/libapreq2-2.13/module/t/logs/apache_runtime_status.sem:
No such file or directory
[ debug] unlink
/ntfhome/local/src/libapreq/libapreq2-2.13/module/t/conf/apache_test_config.pm
s...@tst1.ntf.cftdev1 /ntfhome/local/src/libapreq/libapreq2-2.13/module
2014-06-23 14:42:53 Mon $ t/TEST -verbose
[ debug] configuring httpd
[ debug] Using httpd: /ntfhome/local/sbin/httpd
[ debug] isolated httpd_info VERSION = Apache/2.2.27 (Unix)
[ debug] isolated httpd_info BUILT = Jun 23 2014 13:18:07
[ debug] isolated httpd_info MODULE_MAGIC_NUMBER = 20051115:33
[ debug] isolated httpd_info SERVER_MPM = Event
[ debug] isolated httpd_defines APACHE_MPM_DIR =
server/mpm/experimental/event
[ debug] isolated httpd_defines APR_HAS_SENDFILE = 1
[ debug] isolated httpd_defines APR_HAS_MMAP = 1
[ debug] isolated httpd_defines APR_HAVE_IPV6 (IPv4-mapped addresses
enabled) = 1
[ debug] isolated httpd_defines APR_USE_SYSVSEM_SERIALIZE = 1
[ debug] isolated httpd_defines APR_USE_PTHREAD_SERIALIZE = 1
[ debug] isolated httpd_defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT = 1
[ debug] isolated httpd_defines APR_HAS_OTHER_CHILD = 1
[ debug] isolated httpd_defines AP_HAVE_RELIABLE_PIPED_LOGS = 1
[ debug] isolated httpd_defines DYNAMIC_MODULE_LIMIT = 128
[ debug] isolated httpd_defines HTTPD_ROOT = /ntfhome/local
[ debug] isolated httpd_defines SUEXEC_BIN = /ntfhome/local/bin/suexec
[ debug] isolated httpd_defines DEFAULT_SCOREBOARD =
logs/apache_runtime_status
[ debug] isolated httpd_defines DEFAULT_ERRORLOG = logs/error_log
[ debug] isolated httpd_defines AP_TYPES_CONFIG_FILE = /etc/httpd/mime.types
[ debug] isolated httpd_defines SERVER_CONFIG_FILE = /etc/httpd/httpd.conf
[ debug] inheriting config file: /etc/httpd/httpd.conf
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_file.so
[ debug] libexec/httpd/mod_authn_file.so successfully resolved to existing
file /ntfhome/local/libexec/httpd/mod_authn_file.so
[ debug] Found: authn_file_module = mod_authn_file.c
[ debug] LoadModule authn_file_module mod_authn_file.c
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_dbm.so
[ debug] libexec/httpd/mod_authn_dbm.so successfully resolved to existing
file /ntfhome/local/libexec/httpd/mod_authn_dbm.so
[ debug] Found: authn_dbm_module = mod_authn_dbm.c
[ debug] LoadModule authn_dbm_module mod_authn_dbm.c
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_anon.so
[ debug] libexec/httpd/mod_authn_anon.so successfully resolved to existing
file /ntfhome/local/libexec/httpd/mod_authn_anon.so
[ debug] Found: authn_anon_module = mod_authn_anon.c
[ debug] LoadModule authn_anon_module mod_authn_anon.c
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_dbd.so
[ debug] libexec/httpd/mod_authn_dbd.so successfully resolved to existing
file /ntfhome/local/libexec/httpd/mod_authn_dbd.so
[ debug] Found: authn_dbd_module = mod_authn_dbd.c
[ debug] LoadModule authn_dbd_module mod_authn_dbd.c
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_default.so
[ debug] libexec/httpd/mod_authn_default.so
Re: error in Apache::TestSSLCA, cannot build libapreq
Awesome!
Are the other anomalies that Mark reported yesterday also
Apache::Test-land?
Issac
On 24/06/2014 10:48, Steve Hay wrote:
I just closed the CPAN ticket as this is fixed in (Apache-Test's) trunk
already.
On 24 June 2014 08:46, Issac Goldstand mar...@beamartyr.net wrote:
I'll try to get to look at this in the next few days. I'm incredibly
low on time this week, so feel free to prod me (off-list, please) if you
don't see it soon.
Issac
On 24/06/2014 00:57, Mark Hedges wrote:
Use of each() on hash after insertion without resetting hash iterator
results in undefined behavior, Perl interpreter: 0xf2e8010 at
/ntfhome/local/lib/perl5/site_perl/5.20.0/x86_64-linux-thread-multi-ld/Apache/TestSSLCA.pm
line 103.
Compilation failed in require at
/ntfhome/local/lib/perl5/site_perl/5.20.0/x86_64-linux-thread-multi-ld/Apache/TestConfig.pm
line 1474.
Apparently in 5.20.0 adding elements to a hash while in an each statement
does not work.
This patch fixes the problem and the rest of libapreq builds without
issues. Cross-reported to CPAN RT under # 95805. HTH. -Mark
---
/ntfhome/local/lib/perl5/site_perl/5.20.0/x86_64-linux-thread-multi-ld/Apache/TestSSLCA.pm.orig2014-06-23
14:49:44.712628000 -0700
+++
/ntfhome/local/lib/perl5/site_perl/5.20.0/x86_64-linux-thread-multi-ld/Apache/TestSSLCA.pm
2014-06-23 14:51:24.685043000 -0700
@@ -100,10 +100,10 @@
};
#generate DSA versions of the server certs/keys
-while (my($key, $val) = each %$cert_dn) {
+for my $key (keys %$cert_dn) {
next unless $key =~ /^server/;
my $name = join '_', $key, 'dsa';
-$cert_dn-{$name} = { %$val }; #copy
+$cert_dn-{$name} = { %{$cert_dn-{$key}} }; #copy
$cert_dn-{$name}-{OU} =~ s/rsa/dsa/;
}
2014-06-23 14:42:46 Mon $ t/TEST -clean
[ debug] unlink
/ntfhome/local/src/libapreq/libapreq2-2.13/module/t/logs/apache_runtime_status.sem:
No such file or directory
[ debug] unlink
/ntfhome/local/src/libapreq/libapreq2-2.13/module/t/conf/apache_test_config.pm
s...@tst1.ntf.cftdev1 /ntfhome/local/src/libapreq/libapreq2-2.13/module
2014-06-23 14:42:53 Mon $ t/TEST -verbose
[ debug] configuring httpd
[ debug] Using httpd: /ntfhome/local/sbin/httpd
[ debug] isolated httpd_info VERSION = Apache/2.2.27 (Unix)
[ debug] isolated httpd_info BUILT = Jun 23 2014 13:18:07
[ debug] isolated httpd_info MODULE_MAGIC_NUMBER = 20051115:33
[ debug] isolated httpd_info SERVER_MPM = Event
[ debug] isolated httpd_defines APACHE_MPM_DIR =
server/mpm/experimental/event
[ debug] isolated httpd_defines APR_HAS_SENDFILE = 1
[ debug] isolated httpd_defines APR_HAS_MMAP = 1
[ debug] isolated httpd_defines APR_HAVE_IPV6 (IPv4-mapped addresses
enabled) = 1
[ debug] isolated httpd_defines APR_USE_SYSVSEM_SERIALIZE = 1
[ debug] isolated httpd_defines APR_USE_PTHREAD_SERIALIZE = 1
[ debug] isolated httpd_defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT = 1
[ debug] isolated httpd_defines APR_HAS_OTHER_CHILD = 1
[ debug] isolated httpd_defines AP_HAVE_RELIABLE_PIPED_LOGS = 1
[ debug] isolated httpd_defines DYNAMIC_MODULE_LIMIT = 128
[ debug] isolated httpd_defines HTTPD_ROOT = /ntfhome/local
[ debug] isolated httpd_defines SUEXEC_BIN = /ntfhome/local/bin/suexec
[ debug] isolated httpd_defines DEFAULT_SCOREBOARD =
logs/apache_runtime_status
[ debug] isolated httpd_defines DEFAULT_ERRORLOG = logs/error_log
[ debug] isolated httpd_defines AP_TYPES_CONFIG_FILE =
/etc/httpd/mime.types
[ debug] isolated httpd_defines SERVER_CONFIG_FILE = /etc/httpd/httpd.conf
[ debug] inheriting config file: /etc/httpd/httpd.conf
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_file.so
[ debug] libexec/httpd/mod_authn_file.so successfully resolved to existing
file /ntfhome/local/libexec/httpd/mod_authn_file.so
[ debug] Found: authn_file_module = mod_authn_file.c
[ debug] LoadModule authn_file_module mod_authn_file.c
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_dbm.so
[ debug] libexec/httpd/mod_authn_dbm.so successfully resolved to existing
file /ntfhome/local/libexec/httpd/mod_authn_dbm.so
[ debug] Found: authn_dbm_module = mod_authn_dbm.c
[ debug] LoadModule authn_dbm_module mod_authn_dbm.c
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_anon.so
[ debug] libexec/httpd/mod_authn_anon.so successfully resolved to existing
file /ntfhome/local/libexec/httpd/mod_authn_anon.so
[ debug] Found: authn_anon_module = mod_authn_anon.c
[ debug] LoadModule authn_anon_module mod_authn_anon.c
[ debug] using httpd.conf inherited ServerRoot to resolve
libexec/httpd/mod_authn_dbd.so
[ debug] libexec/httpd/mod_authn_dbd.so successfully resolved to existing
file /ntfhome/local/libexec/httpd/mod_authn_dbd.so
[ debug] Found
VOTE: Retire libapreq-1.34?
While cleaning up our distribution area, I came across libapreq-1.34 Following the end-of-life of Apache 1.3, do we want to? [ ] Remove libapreq-1.34 immediately from www.apache.org/dist/ and CPAN remove it from the download.html page and add a sentence stating that the 1.3 line of releases is at archives.a.o and backpan [ ] Leave libapreq-1.34 in place, but mark it as (deprecated) on the download page (don't touch CPAN) [ ] Leave it alone (don't touch CPAN) Issac
Re: VOTE: Retire libapreq-1.34?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/04/2011 15:31, Issac Goldstand wrote: [+1] Remove libapreq-1.34 immediately from www.apache.org/dist/ and CPAN remove it from the download.html page and add a sentence stating that the 1.3 line of releases is at archives.a.o and backpan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk24DVQACgkQ7bEFiW+VIthtuQCgpriVeIu2vhIr77KAbyu3N0Hz lIgAoK63v/K2e0QMP/r6X8MOKG26mpNf =GTuK -END PGP SIGNATURE-
Re: Would like to apply 2008 libapreq2 patch
On 15/11/2010 20:11, Robert Stone wrote: On Fri, Nov 12, 2010 at 07:12:35PM -0800, Joe Schaefer wrote: As one of the devs on the libapreq2 project I came across your patch for HttpOnly cookie support submitted to Debian in 2008: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490862 It looks great, and we'd like to apply it to the upstream package at Apache. Would you mind following up to this post with your permission to apply the patch? That would be great. Thank you for reviewing the work. Just to be explicit, feel free to release this code under the same license as the rest of libapreq2. Thanks, Robert Stone Great! Thanks, Robert!
Re: HttpOnly + [VOTE] TR libapreq-2.13
On 09/11/2010 06:16, Adam Prime wrote: I had some time to kill tonight and after some screwing around produced the attached patch which may or may not be useful. It's for the C API (I'm assuming anyway) and does pass on my laptop with the debian patch applied. I am not familiar with httpd or libapreq internals, and basically made this up as I was going along, stealing what was already there, so any feedback would be appreciated. Adam On 08/11/10 10:09 AM, Joe Schaefer wrote: The patch looks good to me too. I'd been planning to implement this feature some weekend and the patch is pretty much how I'd do it, so I'd +1 it once the corresponding tests are written. - Original Message From: Issac Goldstand mar...@beamartyr.net To: apreq-dev@httpd.apache.org Sent: Mon, November 8, 2010 8:17:31 AM Subject: Re: HttpOnly On 08/11/2010 12:48, Clinton Gormley wrote: Hi all Any plans on adding support to Apache2::Cookie for the HttpOnly flag? I see a patch in Debian which does this: http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg543361.html thanks Clint The patch looks ok to me at first glance. If you're willing to write the unit test(s) for this, I'd be happy to help push this . All looks good. Waiting for someone with more legal knowledge than I to confirm that we can re-use the patch, and I'll commit to trunk. We may also want to do a release. With the small amount of development, it could be years until this sees the light of day if we wait to package more stuff into it :) 2.12 was released March, 2009, so I'd like to call a vote to TR 2.13. [ ] Release 2.13 with the new HttpOnly cookie feature (once committed) [ ] Don't release 2.13 yet Thanks, Issac
Re: HttpOnly + [VOTE] TR libapreq-2.13
[X] Release 2.13 with the new HttpOnly cookie feature (once committed) [ ] Don't release 2.13 yet Issac
Re: HttpOnly
On 08/11/2010 12:48, Clinton Gormley wrote: Hi all Any plans on adding support to Apache2::Cookie for the HttpOnly flag? I see a patch in Debian which does this: http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg543361.html thanks Clint The patch looks ok to me at first glance. If you're willing to write the unit test(s) for this, I'd be happy to help push this .
Re: HttpOnly
On 08/11/2010 15:25, Clinton Gormley wrote: I see a patch in Debian which does this: http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg543361.html thanks Clint The patch looks ok to me at first glance. If you're willing to write the unit test(s) for this, I'd be happy to help push this . thanks Issac - I'll commit to doing this - may take a little time to find the tuits ta clint That's why I didn't do it meself :D If I find some before you, though, I'll try to hack on the tests too. Issac
Re: [RELEASE CANDIDATE] libapreq2 2.11
Philip M. Gollucci wrote: Steve Hay wrote: Randy Kobes wrote: Issac Goldstand wrote: Steve Hay wrote: Issac Goldstand wrote: Vote results show only 2 +1s (issac,joes) and no -1s. We're still a +1 short of release. creating mod_apreq2.la (cd .libs rm -f mod_apreq2.la ln -s ../mod_apreq2.la mod_apreq2.la) make: don't know how to make all-local. Stop *** Error code 1 Stop in libapreq2-2.11/module. *** Error code 1 So thats build errors on centos and FreeBSD -- yes, I used the tgz for these and not SVN. Anyway, I think joes traced most of this to issac having rolled the tgz with ancient/old auto tools. Issac, want to try again with a current set ? I'm in a position to give it a whirl too. Sorry I'm so slow. umteen jobs and all. P.S. I have no free weekends between now and March 20th. Yeah, let's go for it. Since that's gonna be a vastly different tarball due to autotools and the windows resource that Randy mentioned, I'm all for calling 2.11 a dud and restarting with 2.12 I'll try to get to it later in the week, unless someone beats me to RM. Issac
Re: [RELEASE CANDIDATE] libapreq2 2.11
Vote results show only 2 +1s (issac,joes) and no -1s. We're still a +1 short of release. Issac Issac Goldstand wrote: 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: svn commit: r734232 - /httpd/apreq/trunk/library/module_cgi.c
Joe Schaefer wrote: - Original Message From: Issac Goldstand mar...@beamartyr.net To: Joe Schaefer joe_schae...@yahoo.com Cc: apreq-dev@httpd.apache.org Sent: Tuesday, January 13, 2009 3:53:53 PM Subject: Re: svn commit: r734232 - /httpd/apreq/trunk/library/module_cgi.c A null char. As I mentioned in the commit message to deal with this, I'm not quite sure why I went through such pains to store a null character and couldn't just use NULL or (char) 0 in the code where it was needed. All I remember is some foggy issue with wide characters on win32, but I don't remember exactly what (and no longer have the original development environment for it) In any case, it passes on maintainer mode now, and I hope to get a testbed up for win32/vc6 and win32/vc9 (bill, if you're listening, do you generally test against vc8 or vc9?), and maybe even sparc solaris 10, sunstudio 12 (if I can figure out how to set that up in the next few days - I need such a compilation environment for work anyway, so may as well test out new features there :)) Sorry for the messy commit :-/ Issac PS, a basic test of the patch is running modules/test_cgi after make test. If someone can think of a clever way to test this (which needs stdin input) from Test::More, Apache::Test and friends, I can try to get better unit-testing in place, too I like it already, cool how it prompts exactly for the desired params. Yeah, but it's still full of bugs, like how to tell it to not have a param (esp if I add the API for setting default values for params)
Re: svn commit: r734260 - /httpd/apreq/trunk/library/module_cgi.c
Right. IIRC, that was one of the patches that we needed to fix for maintainer mode last night. I knew it was complicated to begin with for a reason :) j...@apache.org wrote: Author: joes Date: Tue Jan 13 14:30:23 2009 New Revision: 734260 URL: http://svn.apache.org/viewvc?rev=734260view=rev Log: without this patch we get segfaults if we enter an empty line at the prompts Modified: httpd/apreq/trunk/library/module_cgi.c Modified: httpd/apreq/trunk/library/module_cgi.c URL: http://svn.apache.org/viewvc/httpd/apreq/trunk/library/module_cgi.c?rev=734260r1=734259r2=734260view=diff == --- httpd/apreq/trunk/library/module_cgi.c (original) +++ httpd/apreq/trunk/library/module_cgi.c Tue Jan 13 14:30:23 2009 @@ -249,7 +249,7 @@ /*return NULL; */ } -if (strcmp(defval, nullstr)) +if (defval != nullstr) return apr_pstrdup(handle-pool, defval); return NULL;
Re: svn commit: r734289 - /httpd/apreq/branches/1.x/RELEASE
j...@apache.org wrote: - If any -1s are received, the release is rejected. Edit the ./STATUS file - and modify the line + If more -1's than +1's are received, or less than 3 +1's are received, + the release is rejected. Edit the ./STATUS file and modify the line What?!? You can release an artifact with even a single veto?
Re: svn commit: r734289 - /httpd/apreq/branches/1.x/RELEASE
William A. Rowe, Jr. wrote: Issac Goldstand wrote: j...@apache.org wrote: - If any -1s are received, the release is rejected. Edit the ./STATUS file - and modify the line + If more -1's than +1's are received, or less than 3 +1's are received, + the release is rejected. Edit the ./STATUS file and modify the line What?!? You can release an artifact with even a single veto? Distinction. If someone has vetoed a code change that code change must be reverted or the code branched to exclude the objectionable change. But nobody can veto a release. OK. Good to know, since I thought otherwise.
Re: RANT: what a dead project looks like
Without diminishing your point (because it's valid, and you're right), let's also consider how many of us are in development-centric (or at least httpd-centric) jobs as compared to the rest of the httpd project developers... I think there are substantially less of us working jobs around apreq as there are httpd developers around httpd. (There also isn't much advancement of the project feature-wise lately either; we should release faster, but there's not much to release lately) PMC members should, however, at least put more effort into making time to test releases and vote. Issac Joe Schaefer wrote: Dead projects typically have a bus-factor of 1, where committers have all gotten into the habit of waiting for one another to come along for the ride. It's true that somebody has to drive the bus, but the driver should rotate (and is named RM). The only person allowed to set a schedule for a healthy project is an RM, everyone else is only allowed to block progress by using their voting rights. This bs we tell each other about things we all plan to do soon needs to come to a close if we're ever going to be able to handle the support load httpd may be asking us to take on.
Re: svn commit: r734094 - /httpd/apreq/branches/1.x/RELEASE
I'd like this to get good review, so posting here so even folks who aren't on the commit mailing-list can comment. Please take a look at the 1.x/RELEASE file and comment. Thanks, Issac is...@apache.org wrote: Author: issac Date: Tue Jan 13 02:35:02 2009 New Revision: 734094 URL: http://svn.apache.org/viewvc?rev=734094view=rev Log: revamp the RM instructions for apreq-1 Modified: httpd/apreq/branches/1.x/RELEASE Modified: httpd/apreq/branches/1.x/RELEASE [snip]
Re: svn commit: r734094 - /httpd/apreq/branches/1.x/RELEASE
Adam Prime wrote: Issac Goldstand wrote: I'd like this to get good review, so posting here so even folks who aren't on the commit mailing-list can comment. Please take a look at the 1.x/RELEASE file and comment. Thanks, Issac This revision still mentions crosspointing to modperl@, is that still to be taken out? I don't think so. It would help to get some modperl folks to test it, even if they can't cast a binding vote. Given the problems with md5, should that hashing algorithm still be used? I imagine that it's problems, coupled with the fact that the file has to actually untar too would probably mitigate md5's problems significantly, but i still thought i'd mention it. Well, gpg is there to securely provide integrity. I've always seen MD5 as a quick glance way of seeing if things look ok. Just being a bystander on this list, i don't know how you tell the difference between who's a committer and who's on the PMC. I imagine this isn't a problem for people that have been one or the other for a while, but it wouldn't hurt to point to a list of PMC members or something. I actually don't know if there's such a list. Anyone? Section 8 also confuses me a bit because it says that if there is a majority consensus (three +1 and more +1s than -1s) among the httpd PMC members, the RM may proceed with the release. But then goes on to say that If any -1s are received, the release is rejected. So which is it? (i presume the last one) Good point. 3 +1s and no -1s
Re: svn commit: r734232 - /httpd/apreq/trunk/library/module_cgi.c
A null char. As I mentioned in the commit message to deal with this,
I'm not quite sure why I went through such pains to store a null
character and couldn't just use NULL or (char) 0 in the code where it
was needed.
All I remember is some foggy issue with wide characters on win32, but I
don't remember exactly what (and no longer have the original development
environment for it)
In any case, it passes on maintainer mode now, and I hope to get a
testbed up for win32/vc6 and win32/vc9 (bill, if you're listening, do
you generally test against vc8 or vc9?), and maybe even sparc solaris
10, sunstudio 12 (if I can figure out how to set that up in the next few
days - I need such a compilation environment for work anyway, so may as
well test out new features there :))
Sorry for the messy commit :-/
Issac
PS, a basic test of the patch is running modules/test_cgi after make
test. If someone can think of a clever way to test this (which needs
stdin input) from Test::More, Apache::Test and friends, I can try to get
better unit-testing in place, too
Joe Schaefer wrote:
After this commit all I'm left with is the following issue
that prevents compilation on my machine:
% make
...
gcc -DHAVE_CONFIG_H -I. -I. -I../include
-I/home/joe/httpd/trunk/prefork/include/apr-1 -DLINUX=2 -D_REENTRANT
-D_GNU_SOURCE -g -O2 -fno-strict-aliasing -Werror -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Wwrite-strings -Wcast-qual
-Wfloat-equal -Wshadow -Wpointer-arith -Wbad-function-cast -Wsign-compare
-Waggregate-return -Wmissing-noreturn -Wmissing-format-attribute -Wpacked
-Wredundant-decls -Wnested-externs -Wdisabled-optimization -Wno-long-long
-Wendif-labels -Wcast-align -c module_cgi.c -MT module_cgi.lo -MD -MP -MF
.deps/module_cgi.TPlo -fPIC -DPIC -o .libs/module_cgi.o
cc1: warnings being treated as errors
module_cgi.c: In function 'apreq_handle_cgi':
module_cgi.c:1005: warning: reading through null pointer (argument 3)
module_cgi.c:1005: warning: format '%s' expects type 'char *', but argument 3
has type 'void *'
make[2]: *** [module_cgi.lo] Error 1
line 1005 has: sprintf(buf, %s, NULL);
which can't be right, can it? What do you really
want to write to buf, Issac?
- Original Message
From: j...@apache.org j...@apache.org
To: apreq-...@httpd.apache.org
Sent: Tuesday, January 13, 2009 3:31:53 PM
Subject: svn commit: r734232 - /httpd/apreq/trunk/library/module_cgi.c
Author: joes
Date: Tue Jan 13 12:31:48 2009
New Revision: 734232
URL: http://svn.apache.org/viewvc?rev=734232view=rev
Log:
more gcc warnings evaded
Modified:
httpd/apreq/trunk/library/module_cgi.c
Modified: httpd/apreq/trunk/library/module_cgi.c
URL:
http://svn.apache.org/viewvc/httpd/apreq/trunk/library/module_cgi.c?rev=734232r1=734231r2=734232view=diff
==
--- httpd/apreq/trunk/library/module_cgi.c (original)
+++ httpd/apreq/trunk/library/module_cgi.c Tue Jan 13 12:31:48 2009
@@ -230,7 +230,7 @@
}
case '\\': /* Check next character for escape sequence
* (just ignore it for now) */
-*cprompt++;
+(void)*cprompt++;
/* Fallthrough */
default:
@@ -243,7 +243,7 @@
apr_file_printf(req-sout, %s, buf[0]);
apr_file_gets(buf[0], MAX_BUFFER_SIZE, req-sin);
chomp(buf[0]);
-if (stricmp(buf[0], )) {
+if (strcmp(buf[0], )) {
/*if (strcmp(buf[0], nullstr)) */
return apr_pstrdup(handle-pool, buf[0]);
/*return NULL; */
@@ -597,7 +597,7 @@
else
t = req-jar;
-val = (char *)apr_table_get(t, name);
+val = apr_table_get(t, name);
if (val == NULL) {
if (!req-interactive_mode) {
return NULL;
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Joe Schaefer wrote: - Original Message From: Bojan Smojver bo...@rexursive.com To: Joe Schaefer joe_schae...@yahoo.com Cc: Issac Goldstand mar...@beamartyr.net; apreq-dev@httpd.apache.org Sent: Monday, January 12, 2009 11:09:23 AM Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote: Are you planning to pursue 2.10 as RM or should we be moving on to 2.11? The only outstanding issue I am aware of is pgollucci's claim that the perl modules aren't linking correctly to libapreq2 on Solaris. While that would be nice to fix, I don't consider it a showstopper either. I'm kinda waiting for the outcome of that discussion on the list before we go ahead. From what I can see, current decision is to have 2.11 released, right? If so, let's roll that (I'm not attached to version numbers in any way). I've looked over pgollucci's build tree on the perl zone and confirmed that the perl .so modules cannot locate either libapreq2 nor libapr. We may need to add more rpath-related stuff to our linking flags. With respect to 2.10 or 2.11, it all depends on what we wanna do with that v2_10 branch. It's current now, and I don't mind keeping it synced with trunk if someone's planning to release from it this week. But if not, I think we should move on to 2.11. Regardless of that, I'd like to merge in the enhanced-cgi stuff later in the week. So we can either do 2 consecutive releases or get 2.10 out the door now and re-vote on 2.11 in another week or so.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Shouldn't we *not* be doing this type of backport? We really don't need release branches any more if we're going to be voting directly on release artifacts, since there are no changes that can be made to them anyway. I'm -0.9 for 2.10 if this looks like a showstopper for building with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run into the same issues we just had with the 1.34-RC4 vote. Issac j...@apache.org wrote: Author: joes Date: Fri Jan 9 17:42:05 2009 New Revision: 733221 URL: http://svn.apache.org/viewvc?rev=733221view=rev Log: backport r733216 to v2_10 branch
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Joe Schaefer wrote: - Original Message From: Issac Goldstand mar...@beamartyr.net To: apreq-dev@httpd.apache.org Sent: Saturday, January 10, 2009 10:51:57 AM Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c Shouldn't we *not* be doing this type of backport? We really don't need release branches any more if we're going to be voting directly on release artifacts, since there are no changes that can be made to them anyway. I think that's up to the RM. Roy's point is that we should be voting on a final (signed) tarball, not something that's going to be modified and rolled again post-vote. On EVERY release we do it takes several rounds of voting for us to come to consensus that we're actually going to approve a tarball. If the RM wants to handle that process by labelling the tarballs with an RC marker, or wants to bump the package version number each time (which is something of a pain here), it makes no difference to me. Fair enough. The release docs for apreq-1 are totally wrong and should be brought up to speed with the release docs for apreq2. +1 - I'll get to that this week, I hope (and improve the 2.0 docs a bit too, based on recent issues discovered during the 1.34 release). Will also try to make some easier version bumping tools (though that actually was really simple and pretty accurate in RELEASE, unless I missed something) I'm -0.9 for 2.10 if this looks like a showstopper for building with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run into the same issues we just had with the 1.34-RC4 vote. Actually it turns out that the problem I was having at first was related to Bojan's prior -fno-strict-aliasing removal. If you try building trunk with maintainer-mode set, the build will fail badly without the flag. As I said earlier, I'm still for a new RC at the least. Issac
Re: svn commit: r733288 - in /httpd/apreq/trunk: CHANGES module/apache2/apreq_module_apache2.h module/apache2/filter.c module/t/c-modules/apreq_access_test/mod_apreq_access_test.c
Joe Schaefer wrote: - Original Message From: Issac Goldstand mar...@beamartyr.net To: apreq-dev@httpd.apache.org Sent: Saturday, January 10, 2009 11:01:42 AM Subject: Re: svn commit: r733288 - in /httpd/apreq/trunk: CHANGES module/apache2/apreq_module_apache2.h module/apache2/filter.c module/t/c-modules/apreq_access_test/mod_apreq_access_test.c Out of curiosity, what sort of use-cases did you have in mind with this? It certainly looks interesting, but I can't really see when we'd use it... Issac The point of the optional interface is to eliminate problems arising from module loading order. Without the optional interface, C modules which depend on mod_apreq2 must be loaded by apache AFTER mod_apreq2 gets loaded. With the optional interface, the load order does not matter. It's just one less headache for users to not have to worry about the order of their LoadModule directives in httpd.conf. Ahhh... Cute.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Joe Schaefer wrote: - Original Message From: Issac Goldstand mar...@beamartyr.net To: Joe Schaefer joe_schae...@yahoo.com Cc: apreq-dev@httpd.apache.org Sent: Saturday, January 10, 2009 11:11:28 AM Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c Joe Schaefer wrote: - Original Message From: Issac Goldstand To: apreq-dev@httpd.apache.org Sent: Saturday, January 10, 2009 10:51:57 AM Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c Shouldn't we *not* be doing this type of backport? We really don't need release branches any more if we're going to be voting directly on release artifacts, since there are no changes that can be made to them anyway. I think that's up to the RM. Roy's point is that we should be voting on a final (signed) tarball, not something that's going to be modified and rolled again post-vote. On EVERY release we do it takes several rounds of voting for us to come to consensus that we're actually going to approve a tarball. If the RM wants to handle that process by labelling the tarballs with an RC marker, or wants to bump the package version number each time (which is something of a pain here), it makes no difference to me. Fair enough. OTOH it is something of a PITA to keep patching trunk and the release branch, which means we should either release 2.10 soon or abandon that version and make a fresh 2.11 branch of trunk. Which is kinda what I was hinting at in the first place... +1 The release docs for apreq-1 are totally wrong and should be brought up to speed with the release docs for apreq2. +1 - I'll get to that this week, I hope (and improve the 2.0 docs a bit too, based on recent issues discovered during the 1.34 release). Will also try to make some easier version bumping tools (though that actually was really simple and pretty accurate in RELEASE, unless I missed something) I'm -0.9 for 2.10 if this looks like a showstopper for building with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run into the same issues we just had with the 1.34-RC4 vote. Thanks! What I'd really like to see us get in the habit of doing is discussing the gpg signatures as well. IMO the RM should post the sig alongside the tarball so other devs can test that too, and we devs should offer our +1's with our *own* signature of the tarball attached to the vote message. I've been trying to do that anyway. Remind me to add an @apache.org subkey and get it signed at the next ApacheCon keysigning party to make my sigs nicer :) Hopefully I'll make it this March. We then can collect *all* the sigs and put them into the final .asc file for the released tarball. If we really want to adopt gpg sigs, we should really also adopt Module::Signature for the perl glue, at least. Actually it turns out that the problem I was having at first was related to Bojan's prior -fno-strict-aliasing removal. If you try building trunk with maintainer-mode set, the build will fail badly without the flag. As I said earlier, I'm still for a new RC at the least. I think what we need now is someone to volunteer for RM'ing a new release candidate of the 2.10 branch. -0.9 again - numbers are admittedly cheap but I just don't like the idea of seeing minor bumps and significant changes between RCs, but I'll happily voulenteer to do 2.11 I'd also still like to see the interactive-mode patch for the CGI module merged in, merging changes back is a pain in the ass, and there are several folks out there using it already... 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] 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: libapreq-1.34 (RC) issues
Issac Goldstand wrote: Philip M. Gollucci wrote: Issac Goldstand wrote: Request.xs: In function `upload_hook': Request.xs:250: error: syntax error before fwrite make[1]: *** [Request.o] Error 1 make[1]: Leaving directory `/home/issac/asf/svn/apreq1/Request' make: *** [subdirs] Error 2 IS your perl using stdio or perlio ? perl -V says useperlio=define d_sfio=undef I *think* I also tried a stdio, but don't recall. Issac Success. Will post to http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz shortly and I'll call for a vote
[RELEASE CANDIDATE] libapreq 1.34-RC4
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 Thanks, Issac
[VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
After reviewing the RELEASE files for 1.x and 2.x, I'd like to propose that we clean them up a bit (though I don't forsee any more 1.3 releases, we may as well get it in at the same time as 2.x) I won't summarize the current orders of operation (see [1] and [2]), but here's what I'd like to see happen: 1) Create a release branch 1.x/2.x in /branches/ 2) In trunk, modify the CHANGES and STATUS files to reflect a new dev cycle 3) From the branch, prep the release for CPAN (don't forget to #undef the APREQ_VERSION_IS_DEV macro definition). Test. Upload. Vote. Repeat if needed. 4) AFTER the release is approved by the PMC, modify the RELEASE and STATUS files on branch + commit. Modify in trunk + commit. 5) Tag release from branch (svn mv .../branches/xxx .../tags/xxx) 6) Upload (release) Let me know what you think: [ ] Leave everything alone [ ] Change 1.x RELEASE file [ ] Change 2.x RELEASE file (if you agree to changing both, please +1 both of the bottom two options) Issac [1] http://svn.apache.org/repos/asf/httpd/apreq/trunk/build/RELEASE [2] http://svn.apache.org/repos/asf/httpd/apreq/branches/1.x/RELEASE
libapreq-1.34 (RC) issues
(resending to apreq-dev as my mail server is acting up and gmail's giving me a different FROM address) Here's the error I'm seeing - perl 5.6.2, apache 1.3.41, mp 1.30 [EMAIL PROTECTED]:~/asf/svn/apreq1$ make cp libapreq.pod blib/lib/libapreq.pod cp lib/Apache/libapreq.pm blib/lib/Apache/libapreq.pm make[1]: Entering directory `/home/issac/asf/svn/apreq1/c' cc -c -I/home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/include -I/home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/include/modules/perl -I/home/issac/asf/apache13/include -I/home/issac/asf/apache13/include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DVERSION=\\ -DXS_VERSION=\\ -fpic -I/home/issac/asf/perl56/lib/5.6.2/i686-linux-thread-multi-ld/CORE apache_request.c cc -c -I/home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/include -I/home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/include/modules/perl -I/home/issac/asf/apache13/include -I/home/issac/asf/apache13/include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DVERSION=\\ -DXS_VERSION=\\ -fpic -I/home/issac/asf/perl56/lib/5.6.2/i686-linux-thread-multi-ld/CORE apache_cookie.c cc -c -I/home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/include -I/home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/include/modules/perl -I/home/issac/asf/apache13/include -I/home/issac/asf/apache13/include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DVERSION=\\ -DXS_VERSION=\\ -fpic -I/home/issac/asf/perl56/lib/5.6.2/i686-linux-thread-multi-ld/CORE apache_multipart_buffer.c rm -rf ../blib/arch/auto/libapreq/libapreq.a /usr/bin/ar cr ../blib/arch/auto/libapreq/libapreq.a apache_request.o apache_cookie.o apache_multipart_buffer.o : ../blib/arch/auto/libapreq/libapreq.a chmod 755 ../blib/arch/auto/libapreq/libapreq.a cp apache_cookie.h ../blib/arch/auto/libapreq/include/apache_cookie.h cp apache_multipart_buffer.h ../blib/arch/auto/libapreq/include/apache_multipart_buffer.h cp apache_request.h ../blib/arch/auto/libapreq/include/apache_request.h make[1]: Leaving directory `/home/issac/asf/svn/apreq1/c' make[1]: Entering directory `/home/issac/asf/svn/apreq1/Request' cp Request.pm ../blib/lib/Apache/Request.pm /home/issac/asf/perl56/bin/perl /home/issac/asf/perl56/lib/5.6.2/ExtUtils/xsubpp -typemap /home/issac/asf/perl56/lib/5.6.2/ExtUtils/typemap -typemap /home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/typemap Request.xs Request.xsc mv Request.xsc Request.c cc -c -I../c -I/home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/include -I/home/issac/asf/perl56/lib/site_perl/5.6.2/i686-linux-thread-multi-ld/auto/Apache/include/modules/perl -I/home/issac/asf/apache13/include -I/home/issac/asf/apache13/include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DVERSION=\1.34\ -DXS_VERSION=\1.34\ -fpic -I/home/issac/asf/perl56/lib/5.6.2/i686-linux-thread-multi-ld/CORE Request.c Request.xs: In function `upload_hook': Request.xs:250: error: syntax error before fwrite make[1]: *** [Request.o] Error 1 make[1]: Leaving directory `/home/issac/asf/svn/apreq1/Request' make: *** [subdirs] Error 2 Now, the funny thing is that I'm getting this on apreq-1.33 (release), too, so I think it's something somewhere in the external libraries (perl/XS, apache, mp) that's made the issue, not our code. CC-ing the [EMAIL PROTECTED] list in case someone there has insight. Issac
Re: libapreq-1.34 (RC) issues
Philip M. Gollucci wrote: Issac Goldstand wrote: Request.xs: In function `upload_hook': Request.xs:250: error: syntax error before fwrite make[1]: *** [Request.o] Error 1 make[1]: Leaving directory `/home/issac/asf/svn/apreq1/Request' make: *** [subdirs] Error 2 IS your perl using stdio or perlio ? perl -V says useperlio=define d_sfio=undef I *think* I also tried a stdio, but don't recall. Issac
Re: Should we release 2.10?
I want to finish with the 1.3 release and then I can try to take a look Bojan Smojver wrote: On Tue, 2008-11-11 at 15:54 +1100, Bojan Smojver wrote: On Mon, 2008-11-10 at 23:46 -0500, Philip M. Gollucci wrote: Is that with $ make test TEST_VERBOSE=1 Fails in exactly the same way as make release_test. BTW, 2.08 and 2.09-rc2 fail exactly the same on my box. Something must be screwed in my setup...
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
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: 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
[RELEASE CANDIDATE] libapreq 1.34-RC3
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: Possible bug in libapreq
I took a peek at this. Basically, Joseph and the folks at Mozilla found that some odd quirk in FireFox is causing the bytestream to be sent with funny packet payloads of, mostly, 1 byte, 4095 bytes, 1 byte, 4095 bytes, etc. That seems to be a client issue. What's happening is that occasionally, we get a 0 byte payload (as can be seen in a log Joseph posted at http://staging.sr.admission.net/joetemp/libapreq_debug_ff20_win32_https.txt). Once that happens, multipart_buffer_read returns 0 and ApacheRequest_parse_multipart breaks out of the data-reading loop for that parameter and starts reading line-by-line looking for the next boundary/header (which it may or may not find since we're treating binary data as text, so all bets are off). I'm not sure how we can hack around that (nor should we if it can be fixed) and my personal opinion is this is still FireFox's problem; not ours. I'll CC this to the bug report at rt.cpan.org and Mozilla's bugzilla. Issac Joseph Huckaby wrote: Hey libapreq dev team, I recently logged a bug for Firefox 2.0 which results in corrupted file uploads over HTTPS (Firefox 2.0 Win32 only). However, further research seems indicate libapreq may be involved (I cannot reproduce it outside libareq, for instance using PHP or the Perl CGI module). If you have a moment can you take a look and see what you think? Here is the Firefox bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=356470 Thanks! I use your excellent Apache::Request module extensively in my company's core software (Apache 1.3.x, libapreq 1.33), and we're not sure what to do about Firefox 2.0. The bug appears to have to do with the way libapreq reads bytes off the incoming socket. With Firefox 2.0 Win32 HTTPS occasionally it reads 0 bytes, and then drops out of the loop and discards up to 200K from the file being uploaded. It's all detailed out in the FF bug report. - Joe Joseph Huckaby Lead Software Engineer AdMission Corporation http://www.admissioncorp.com
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] 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: NEW httpd.apache.org/apreq site layout RFC
Having utterly no idea what it was you said on IRC yesterday, I can only comment that it looks much less cluttered, at the cost of losing most upward links to the parent httpd project (and it takes a few moments to consider clicking on the banner to do so)... Maybe breadcrumbs on top (like those in the docs pages) or some other obvious way up? All in all, I personally like it :-) Issac Philip M. Gollucci wrote: Hi, http://libapreq2.p6m7g8.net/apreq/ In response to my rants on IRC yesterday, I whipped up a quick new layout. I'm looking for comments before I go add some 'juice' to the content. I don't think any content or section for the original site is not represented. Someone is going to have to help me out with the anakia/velocity fu to get apreq/docs/1.3/index.html to render with our xsl style and not the default one. Love is not the one you can picture yourself marrying, but the one you can't picture the rest of your life without. 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... Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com
