Re: [RELEASE CANDIDATE] Apache-Test-1.31 RC3
On 2010-02-12, at 11:13 PM, Fred Moyer wrote:
Third release candidate, a couple of small fixes from Gozer. So far
we've got positive results across the board. Please take this for a
spin if you haven't tried one of the previous release candidates.
http://people.apache.org/~phred/Apache-Test-1.31-rc3.tar.gz
Modify need_cgi so that it looks for cgi.c instead of cgi. This is a fix
for the case insensitive filesystem correction listed below.
[Phillipe M. Chiasson]
t/next_available_port.t doesn't need mod_cgid, use need_cgi instead
of need_module('mod_cgi.c')
[Philippe M. Chiasson]
Passes all tests on OSX/10.6 Apache/2.2.13/prefork perl-5.10.
+1
--
best regards,
Randy
Re: libapreq 1.34 on cpan is an ** UNAUTHORIZED RELEASE **
On Fri, Apr 17, 2009 at 9:32 AM, Geoffrey Young ge...@modperlcookbook.org wrote: Adam Prime wrote: I'm guessing that Isaac needs to be added as a co-maintainer for libapreq or something, since the latest apreq1 release shows up as being unauthorized. http://search.cpan.org/~isaac/libapreq/ Also, because of this problem (i think) the link on http://httpd.apache.org/apreq/ to CPAN (http://search.cpan.org/search?mode=modulequery=libapreq) still finds 1.33, not 1.34. I've done all I can about this: isaac is already co-maintainer of Apache::Request and Apache::Cookie. and while the official libapreq release falls under my pause id, there is no listing for libapreq Apache::libapreq that I can find in any of the places where I own or co-maintain things. I suspect that stas or doug still is still the official owner of those. It seems to be fixed now, at least in the CPAN indices: cpan d /libapreq/ Distribution id = I/IS/ISAAC/libapreq-1.34.tar.gz CPAN_USERID ISAAC (Issac Goldstand is...@cpan.org) CPAN_VERSION 1.34 CONTAINSMODS Apache::Cookie Apache::Request However, search.cpan.org still indicates http://search.cpan.org/~isaac/libapreq-1.34/ is an unauthorized release (perhaps this just needs updating). -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2
On Fri, Mar 6, 2009 at 5:54 PM, Bojan Smojver bo...@rexursive.com wrote: On Sat, 2009-03-07 at 10:34 +1100, Bojan Smojver wrote: On Fri, 2009-03-06 at 15:25 -0800, Joe Schaefer wrote: Is that a +1 to release, or not yet? I'll try to build some RPMs from it first and report back. +1. Builds OK as RPM on F-10 and F-11. +1 Tests pass on - linux, Apache/2.2.8 (prefork), perl-5.10, latest mod_perl - win32, Apache/2.2.8 (winnt), perl-5.10, latest mod_perl, VC++ 6 -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.11
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. Has anyone else tested on Win32 yet? I reported a build error which hasn't been addressed yet: http://marc.info/?l=apreq-devm=123244555902865w=2 This is because libapreq.rc in the svn sources wasn't included in the release candidate tarball. -- best regards, Randy
Re: [PATCH] Fix more build issues
On Mon, 2008-05-19 at 22:10 +0300, Nikolay Ananiev wrote: (i've sent this earlier but seems like it didn't reach the list) [ ... ] Thanks very much for this, and your two earlier patches - these have been committed to the svn sources. -- best regards, Randy
Re: apxs on Win32?
On Thu, 21 Feb 2008, William A. Rowe, Jr. wrote: Guenter Knauf wrote: Hi (Bill?), another dev just asked me privately about apxs for Win32 does this meanwhile work on Win32? And if so can we perhaps ship it with future distros? I think that would make sense since the include and lib dir is already included Dunno if Randy's package has been updated for trunk, 2.2 etc, but it's been mentioned several times that this should be incorporated back into httpd. (It was dropped with 2.0, after I solved it for 1.3, given the additional complexity behind the autocrap/libfool stuff we introduced into httpd 2.0). So maybe it's time to get cracking ;-) Bill The apxs win32 package does work for 2.2. I'm not sure the best way to incorporate this into the httpd build; as a first step, I've placed at http://people.apache.org/~randyk/ an install_win32_apxs.zip which can be used as nmake -f install_win32_apxs.mak INSTDIR=C:\Path\to\Apache2.x to install apxs, apr-config, and apu-config. This assumes a point in the installation when Apache has been installed (eg, towards the end of httpd's Makefile.win). Compared to the apxs utility at http://perl.apache.org/dist/win32-bin/ this version is more minimalistic (no user prompts, etc.); the modules used are included with modern versions of Perl. One thing it does assume is that Perl is in the PATH; I'm not sure how to check for this in the Makefile. -- best regards, Randy
Re: apxs on Win32?
On Thu, 21 Feb 2008, Guenter Knauf wrote: Hi (Bill?), another dev just asked me privately about apxs for Win32 does this meanwhile work on Win32? And if so can we perhaps ship it with future distros? I think that would make sense since the include and lib dir is already included Guenter. There's a perl script that emulates apxs on Win32 available in apxs_win32.tar.gz at http://perl.apache.org/dist/win32-bin/ Right now this is installed assuming an already-installed Apache; if there's interest, I could look at incorporating this into the build of Apache itself. -- best regards, Randy Kobes
Re: Solution to apr stdio/msvc crt/service handles and logging
On Thu, 27 Sep 2007, William A. Rowe, Jr. wrote: Randy Kobes wrote: I'm currently rebuilding everything with VC 8 (the free version), and will report on that later. Yea - I discovered it's quite impossible to get msvcrt-linked activestate to cooperate with openssl compiled against msvcr80, and probably not against httpd+mod_perl against msvcr80. Even errors silently ignored before cause segfaults now when activestate tries to touch pseudo-posix files and visa versa because msvcr80 has all of the additional parameter checking. Really, building exclusively against either msvcr80 or msvcrt is the only way to go, and that includes all the bits. I found that too, so for testing with VC 8 (the free version), I built both perl and apache with it. mod_perl builds and works, although a handful of its tests fail (using VC 6, all the mp2 tests passed). However, these are most likely problems on the perl/mp2 side - there were a few of the Perl tests that failed when I built Perl. I'll look into these and report on the mp2 list. -- best regards, Randy
Re: Solution to apr stdio/msvc crt/service handles and logging
On Thu, 27 Sep 2007, William A. Rowe, Jr. wrote: http://people.apache.org/~wrowe/apr-1.x-win32-nohandle.patch FYI - that one does not apply cleanly to apr-1.2 (it's trunk) if you want the easily applied flavor, that would be; http://people.apache.org/~wrowe/apr-1.2-win32-nohandle.patch The httpd patch applies with little pain. The patched version built fine, and with the svn mod_perl2 sources, and perl-5.8.8 (ActivePerl 822), all the mp2 tests passed using VC++ 6. Great work! I'm currently rebuilding everything with VC 8 (the free version), and will report on that later. -- best regards, Randy
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On Fri, 7 Sep 2007, Jorge Schrauwen wrote: Any more info how you got it to work with apxs? This works for me: C:\ C:\Apache2\bin\apxs -llibhttpd -D APACHE2 -p -IC:\Temp\mod_fcgid.2.1 -o mod_fcgid.so -c mod_fcgid.c fcgid_bridge.c fcgid_conf.c fcgid_pm_main.c arch\win32\fcgid_pm_win.c arch\win32\fcgid_proc_win.c arch\win32\fcgid_proctbl_win.c fcgid_protocol.c fcgid_spawn_ctl.c fcgid_bucket.c fcgid_filter.c (all on one line). -- best regards, Randy
Re: [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-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: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Sun, 11 Mar 2007, Vinay Y S wrote: Actually, either my earlier patch which adds a apr_file_close in apreq_file_cleanup or just removing the APR_FILE_NOCLEANUP from the flags(patch attached) is enough. Both together isn't required. (but it's safe as the cleanup handler installed by apr would get uninstalled when you do apr_file_close). I favor doing just one of them, preferably, removing the APR_FILE_NOCLEANUP flag. This makes the WIN32 code identical to other platforms(where it's already working fine, so no change for them). Patch for the same against the svn source is given below. Please try this on win32 systems. Removing the APR_FILE_NOCLEANUP would, I think, bring us back to the problem described at http://marc.theaimsgroup.com/?t=11533762941r=1w=2 for which this was introduced, in that some Win32 systems have occasional stray temp files lingering around. -- best regards, Randy
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
On Sat, 10 Mar 2007, Vinay Y S wrote: On 3/9/07, Joe Schaefer [EMAIL PROTECTED] wrote: flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL | APR_BINARY; /* Win32 needs the following to remove temp files. * XXX: figure out why the APR_SHARELOCK flag works; * a grep through the httpd sources seems to indicate * it's only used in sdbm files?? */ #ifdef WIN32 flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK; #endif rc = apr_file_mktemp(fp, tmpl, flag, pool); Randy, do you know why we use the APR_FILE_NOCLEANUP flag? Maybe we should just remove that and see if it fixes the problem Vinay is seeing. Yes, removing APR_FILE_NOCLEANUP does exactly the same thing as my patch. Rather, we can remove the whole #ifdef WIN32 as APR_SHARELOCK isn't used for anything in file_io on win32 today. I'll have to look at this - there's a discussion at http://marc.theaimsgroup.com/?t=11533762941r=1w=2 of why this was introduced. I remember that this was a frustrating issue, as something that worked on one system in removing temp files didn't work on another (at least between Steve and myself). What was committed seemed to work most of the time for most systems, at least at that time. -- best regards, Randy
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
Win32 ppm packages
I'd like to get a sense from Win32 ppm users of mod_perl and/or libapreq2 about the following. Right now in our http://theoryx5.uwinnipeg.ca/ppms/ ppm repository, there's ppm packages for mod_perl and libapreq2. The ones compatible with Apache/2.0 are called mod_perl and libapreq2, respectively, while those for Apache/2.2 are mod_perl-2.2 and libapreq2-2.2, respectively. What I'm wondering is, if Apache/2.2 is by now mostly used, should I switch the names: mod_perl and libapreq2 for Apache/2.2, and mod_perl-2.0 and libapreq-2.0 for Apache/2.0? Thoughts? -- best regards, Randy Kobes
Re: Loading libapreq2.dll fails on windows
On Wed, 11 Oct 2006, Franky Braem wrote: I always get the following error: C:\development\xampp\apache\binapache apache: Syntax error on line 143 of C:/development/xampp/apache/conf/httpd.conf: Cannot load bin/libapreq2.dll into server: The specified module could not be found. It seems that the dll msvcr80.dll can't be found. I've tried to put this dll in the same folder, but it can't load it. How do I solve this? If you have msvcr80.dll, does adding a LoadFile /Path/to/msvcr80.dll directive in httpd.conf, before you load librapreq2.dll, help? If not, it may be a compatibility issue with different versions of VC++ being used to build the different components involved with apreq. Did you build (or get binaries of) apreq, Apache, and Perl (if you're using the Perl modules for apreq) using the same version of VC++? -- best regards, Randy Kobes
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: How to detect the mpm used via apxs?
On Sat, 19 Aug 2006, Guy Hulbert wrote: On Sat, 2006-19-08 at 10:18 -0300, Davi Arnaut wrote: Em 19/08/2006, �s 07:55, Mladen Turk escreveu: Anyone knows how to detect the mpm used so that module can be build with/without threading code depending if the mpm is prefork or any other threaded one like worker by using apxs? /path/to/apxs -q MPM_NAME -- best regards, Randy Kobes
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
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
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
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
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-RC3
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. -- best regards, Randy
testing Apache/2.2 on Win32
For those Win32 users using ActivePerl 8xx, I've placed at http://theoryx5.uwinnipeg.ca/ppms/ ppm packages suitable for use with Apache/2.2: mod_perl-2.2, for mod_perl-2, and libapreq-2.2, for libapreq2 (Apache2::Request and friends). Note that if you're using Apache/2.2 you should use these packages; the mod_perl and libapreq2 packages also available in this repository were compiled against Apache/2.0, which aren't compatible with Apache/2.2. -- best regards, Randy Kobes
Re: svn commit: r408136 - /httpd/apreq/trunk/build/version_check.pl
On Sun, 21 May 2006, Philip M. Gollucci wrote: I'd prefer that no version of Archive::Tar be specified for Win32, or perhaps even no such prerequisite at all; it's a core module in ActivePerl, and has a history of some instability on Win32 - an upgrade may break things on the local system. I was trying to address this from Steven Hay's post: - When I ran perl Makefile.PL --with-apache2=C:/apache2 I got an error from win32/Configure.pl about Archive-Tar being missing, but this is not mentioned in the PREREQUISITES file and was not checked by test_prereq in Makefile.PL before calling this script. It's a trade-off - Steve builds his own perl, so having Archive::Tar as a prerequisite makes sense, but especially requiring a particular version may mess up an ActivePerl with an older version. So I think requiring version 0 may be safest. I'm fine with whatever you say is best... I'm not a MS guy. I guess people on cygwin using the cygwin perl shouldn't be using the win32/Configure.pl. (I don't think Steven is) That's right, on both counts. -- best regards, Randy
Re: svn commit: r408136 - /httpd/apreq/trunk/build/version_check.pl
On Sun, 21 May 2006, [EMAIL PROTECTED] wrote: Author: pgollucci Date: Sat May 20 22:36:08 2006 New Revision: 408136 URL: http://svn.apache.org/viewvc?rev=408136view=rev Log: Add pre of Archive::Tar (only for win32) Using v1.29 as thats what I have installed. I'd prefer that no version of Archive::Tar be specified for Win32, or perhaps even no such prerequisite at all; it's a core module in ActivePerl, and has a history of some instability on Win32 - an upgrade may break things on the local system. -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
On Thu, 18 May 2006, Philip M. Gollucci wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC1.tar.gz Does this compile with Apache/2.2 on unix? I've been working on 2.2 support for Win32, but will need a few days, and am just wondering if I should rush it. Thanks. -- best regards, Randy
Re: File upload
On Sat, 25 Feb 2006, Franky Braem wrote: Try instead LoadFile C:/Path/to/Apache2/bin/libarpeq2.dll LoadModule apreq_module modules/mod_apreq2.so I get the following now: C:\Program Files\apachefriends\xampp\apache\binapache Syntax error on line 177 of C:/Program Files/apachefriends/xampp/apache/conf/httpd.conf: Cannot load libapreq2.dll into server: The specified module could not be found. The directive LoadFile C:/Path/to/Apache2/bin/libapreq2.dll should specify the absolute location where the libapreq2.dll library resides. -- best regards, Randy
Re: File upload
On Fri, 24 Feb 2006, Franky Braem wrote: Randy Kobes wrote: It should be possible - is that what you're using? If you are, you should ensure everything else (httpd, apr, ...) was also built with the same compiler - there are known problems mixing, for example, things compiled with VC++ 7 with those of VC++ 6. I've got the following in my httpd.conf: LoadFile modules/mod_apreq2.so Try instead LoadFile C:/Path/to/Apache2/bin/libarpeq2.dll LoadModule apreq_module modules/mod_apreq2.so -- best regards, Randy
Re: File upload
On Fri, 24 Feb 2006, Franky Braem wrote: Joe Schaefer wrote: Franky Braem [EMAIL PROTECTED] writes: Is there a step by step tutorial on how to implement a file upload in an Apache module with apreq2? I'm trying to write mod_wxjs (JavaScript and wxWidgets as server side script, more info on wxjs.sourceforge.net) and I want to add a file upload functionality (something like php). Something like this: [ ... ] I'm trying to integrate apreq2 into wxJS, but I get the following crash when trying to handle a request: apreq2.dll!apreq_filter_relocate(ap_filter_t * f=0x) Line 48 + 0x3 bytes C apreq2.dll!get_apreq_filter(apreq_handle_t * handle=0x05b20938) Line 45 + 0xc bytes C apreq2.dll!apreq_handle_apache2(request_rec * r=0x015aaad0) Line 435 + 0x9 bytes C mod_wxjs.dll!wxjs_handler(request_rec * r=0x015aaad0) Line 287 + 0x9 bytes C++ [EMAIL PROTECTED]() + 0x1f bytes Is it possible to build libapreq2 with Visual Studio Express 2005? It should be possible - is that what you're using? If you are, you should ensure everything else (httpd, apr, ...) was also built with the same compiler - there are known problems mixing, for example, things compiled with VC++ 7 with those of VC++ 6. -- best regards, Randy
Re: towards a 2.07 release
On Tue, 8 Nov 2005, Joe Schaefer wrote: [ ... ] What's the consensus of the group on this issue? Introducing another prereq, possibly on CPAN itself, seems like a bad idea to me. I like the fact that the current build system is cpan- friendly, but I also appreciate the simplicity of having the build fail immediately on an unsatisfied prereq. So I don't know how to proceed at this point. We could either 1) leave things as-is, which allows the cpan client to sift through the generated Makefile in order to pursue unsatisfied prereqs, or 2) change back the warn calls to die, which will confuse the cpan client, but will allow human users to figure out exactly what needs to be done in order for the build to continue. Opinions? There are good arguments for both ways, but if I were to choose, I'd go for leaving things as they are - I think, currently, one could install libapreq2 entirely through the CPAN/CPANPLUS shells, including installing any prerequisites (except for mod_perl, probably, as this can't easily be done through the CPAN/CPANPLUS shell). This feature might prove quite useful to many. The fact that the build process doesn't die for manual installations in cases of unsatisfied prerequisites is no different than the usual CPAN distribution, so users who do things manually should be used to catching the warnings about unsatisfied prerequisites and following them up by hand. -- best regards, randy
Re: 2.07-rc3 (was Re: 2.07-rc2)
On Sun, 16 Oct 2005, Joe Schaefer wrote: Ok, please test rc3 instead: http://people.apache.org/~joes/libapreq2-2.07-rc3.tar.gz Builds and passes all tests, including the perl glue, on - Win32 (ActivePerl 813: perl-5.8.7), mp 2.0.2 (rc2), Apache/2.0.54 (winnt) - linux (perl-5.8.7), mp 2.0.1, Apache/2.0.54 (prefork) There is a warning on Win32 at the perl Makefile.PL stage about an unitialized value being used for the --with-apache2-apxs option, if this is not specified; this has been fixed in the current svn sources. -- best regards, randy
Re: Problem with cookies in mod_perl
On Mon, 17 Oct 2005, Philip W. Dalrymple III wrote:
I am have a tough time getting cookies read from a request header. I am
using:
FC4 (updated to best current)
httpd (apache) 2.0.54-10.2 (rpm from fedora)
apr 0.9.6-3.1 (rpm from fedora)
mod_perl 2.0.1-1.fc4 (again rpm from fedora)
Most current Apache2 and APR modules updated from CPAN.
I can set the cookie without problems and see it in the browser as the
correct string (the cookie is a simple string with only hex digits and
one dash for example 35-4b3b65c6539f170cfd46168c5). when I use the code
my $sess = 'Not Set';
my $chash = APR::Request::Apache2-handle($r)-jar();
if($chash-{ipm_s_$db}) {
$sess = $chash-{ipm_s_$db};
}
to get the cookie from the session ($db is correct) I get, in the
error log
/usr/sbin/httpd: symbol lookup
error:
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi/auto/APR/Request/Apache2/Apache2.so:
undefined symbol: apreq_handle_apache2
Can someone give me a pointer to what I am doing wrong here.
Do you have a
LoadModule apreq_module modules/mod_apreq2.so
in your httpd.conf? Note that the 2 in mod_apreq2.so.
--
best regards,
randy kobes
Re: 2.07-rc2 (was Re: towards a 2.07 release)
On Fri, 14 Oct 2005, Ville Skytt� wrote: On Fri, 2005-10-14 at 00:40 -0500, Randy Kobes wrote: On Thu, 13 Oct 2005, Ville Skytt wrote: On Thu, 2005-10-13 at 13:06 -0400, Joe Schaefer wrote: Note this is our second non-dev candidate, so please give it the extra scrutiny it deserves. Release Candidate #2 - None of the Apache2/*.pm files get installed with 2.07-rc2 here, but the Apache2::*.3 man pages do. In 2.06-dev, all the *.pm (and man pages) were installed as expected. I also find that - I think the following should fix this: [...] +PMLIBDIRS = ['lib'], Unfortunately it doesn't seem to, the problem persists and I didn't notice the above changing anything. It works for me in installing the Apache2::* modules. You might have to do a make clean; first, and then rerun make; so that the changed Makefile.PL will regenerate the new Makefile. If this still doesn't work, do the Apache2::* modules appear beneath glue/perl/blib/? -- best regards, randy
Re: 2.07-rc2 (was Re: towards a 2.07 release)
On Thu, 13 Oct 2005, Ville Skytt� wrote:
On Thu, 2005-10-13 at 13:06 -0400, Joe Schaefer wrote:
Note this is our second non-dev candidate, so please give it the
extra scrutiny it deserves. Release Candidate #2 -
None of the Apache2/*.pm files get installed with 2.07-rc2 here, but the
Apache2::*.3 man pages do. In 2.06-dev, all the *.pm (and man pages)
were installed as expected.
I also find that - I think the following should fix this:
=
--- glue/perl/Makefile.PL~ 2005-10-14 00:25:15.0 -0500
+++ glue/perl/Makefile.PL 2005-10-14 00:29:46.0 -0500
@@ -162,6 +162,7 @@
my %opts = (
NAME = 'libapreq2',
DIR = [qw(xs)],
+PMLIBDIRS = ['lib'],
clean = { FILES = xs t/logs t/TEST @scripts },
realclean = { FILES = xsbuilder/tables },
);
=
--
best regards,
randy kobes
Re: 2.07-rc2 (was Re: towards a 2.07 release)
On Thu, 13 Oct 2005, Joe Schaefer wrote: Note this is our second non-dev candidate, so please give it the extra scrutiny it deserves. Release Candidate #2 - http://people.apache.org/~joes/libapreq2-2.07-rc2.tar.gz Thanks! There seems to be a problem (reported in another thread by Ville Skytta) with the perl glue, in that the Apache2::* modules don't get copied over to blib, and subsequently won't get installed. Also, there's a minor annoyance on Win32 with a warning about a non-existent configuration option in the top-level Makefile.PL - I'll fix this as soon as the svn server gets back up. However, all tests, including those of the perl glue, passed for me: - linux: Apache/2.0.54 (prefork), perl-5.8.7, mod_perl 2.0.1 - win32: Apache/2.0.54 (winnt), perl-5.8.7 (ActivePerl 813), (RC2 of mod_perl 2.0.2) -- best regards, randy
Re: [RELEASE CANDIDATE] Apache-Test-1.27 RC2
On Wed, 12 Oct 2005, Philip M. Gollucci wrote: A release candidate for Apache-Test 1.27 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.27-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. Builds and tests fine on - linux: Apache/2.0.54 (prefork) - win32: Apache/2.0.54 (winnt) -- best regards, randy
Re: Win32 binary distributions 2.1.9-beta and onwards
On Tue, 11 Oct 2005, William A. Rowe, Jr. wrote: Question; I'm looking for input what version of visual c++ we should build apr 1.x and httpd 2.1.x and onwards with. As most are aware, discrepancies in the clib mean that mismatched posix open()/close(), malloc()/free() can all cause serious problems, so a single version is vastly preferable. Open to comments... One aspect worth considering is the interaction with Perl, and the fact that the dominant Win32 binary distribution from ActiveState is compiled with VC++ 6. I would expect there to be problems with the mod_perl module if one uses ActiveState's Perl and an Apache compiled with something other than VC++ 6. Might there be problems using such a Perl in a cgi script with a non-VC++ 6 Apache? Of course, one is not restricted to using ActiveState's Perl, but could instead use some other freely available binary. However, ActiveState supplies with their ActivePerl some proprietary tools (ppm, for installing binary packages, and some related tools for managing html docs), which users have come to heavily rely on. Having said that, within the Perl world there is also pressure to migrate to a binary based on a freely available, and more recent, VC++ (but, hopefully, not tied to a particular msvcr dll version). It would be ideal if Apache and ActiveState could coordinate such a migration; however, from ActiveState's point of view, this might not be a consideration until the next major release of perl (5.10), as this most likely won't be binary-comaptible with the current (5.8) version. -- best regards, randy kobes
Re: towards a 2.07 release
On Wed, 5 Oct 2005, Steve Hay wrote: Joe Schaefer wrote: [ ... ] IMO submit a tested patch to libapreq's Param.xs that does this (where MY_PLATFORM is suitably defined to match the above): #ifdef MY_PLATFORM #undef PerlLIO_link #define PerlLIO_link(oldname, newname) win32_link(oldname, newname) #endif OK, patch attached does exactly that. With this patch in place libapreq2-2.07-rc1 now builds without error, and all tests pass too. (This is using perl-5.8.7, apache-2.0.54 and mod_perl-2.0.1 on WinXP with VC++ 6.) Thanks, Steve! Applied to apreq as 306508. -- best regards, randy
Re: towards a 2.07 release
On Mon, 3 Oct 2005, Philip M. Gollucci wrote: Randy Kobes wrote: On Sun, 2 Oct 2005, Joe Schaefer wrote: Note this is our first non-dev candidate, so please give it the extra scrutiny it deserves. Release Candidate #1 - http://people.apache.org/~joes/libapreq2-2.07-rc1.tar.gz Thanks! Nice work, Joe! All tests, including those of the perl glue, pass for me on linux: Apache/2.0.54 prefork, perl-5.8.7, mp 2.0.1 Win32: Apache/2.0.54 winnt, perl-5.8.7, mp 2.0.1 It may be worth while to wait a couple days. I'm going to release the first mod_perl-2.0.2-RC1 tonight. Or we should test against SVN (to be 2.0.2) Regarding the mp-2.0.2-RC1 (and assuming an Apache-Test rc), did you see a patch I proposed for Apache-Test yesterday (to the test-dev list)? It would be nice if this, or some variant, went in the Apache-Test rc, as without it, Apache-Test doesn't get the right system config file under some circumstances. -- best regards, randy
Re: [PATCH] add ldd/otool output to bug reports
On Mon, 12 Sep 2005, Philip M. Gollucci wrote:
If this point was reached, it would break Win32, plus
any other system which didn't have an ldd in the PATH.
Perhaps Apache::TestConfig::which() could be used to
see if an ldd() [or otool()] is present, and skip this
part if it's not found?
I guess qx{} is different on win32 ?
Take from example on my FBSD box which does not have 'otool'
% perl -e 'my $command = otool -L /bin/ls; qx{$command}; print \ndone.\n'
done.
I don't think it matters, but at rate, Apache::TestConfig::which() will
better find ldd/otool.
I think the use of which() is better - what would have
happened before is that a message:
'ldd' is not recognized as an internal or external
command, operable program, or batch file.
would appear with Win32, which would be confusing.
Does win32 have an equivalent?
There are utilities on Win32 that give extra information
like this; I'll take a look later at them to see which
might be useful. But for now, I'd suggest doing it without
Win32, as you have it. Thanks.
--
best regards,
randy
Re: [PATCH] add ldd/otool output to bug reports
On Fri, 9 Sep 2005, Philip M. Gollucci wrote:
For both mp2bug and A-T
Question, why does A-T call it OSX and mp2 call it DARWIN ... should we sync
one way or the other ?
Index: lib/ModPerl/Config.pm
===
--- lib/ModPerl/Config.pm (revision 279736)
+++ lib/ModPerl/Config.pm (working copy)
@@ -18,9 +18,11 @@
use Apache2::Build ();
use Apache::TestConfig ();
+use Apache::TestConfigData ();
use File::Spec ();
use constant WIN32 = Apache2::Build::WIN32;
+use constant DARWIN = Apache2::Build::WIN32;
sub as_string {
my $build = Apache2::Build-build_config;
@@ -53,8 +55,19 @@
$command = $httpd -V;
$cfg .= \n\n*** $command\n;
$cfg .= qx{$command};
-}
-else {
+
+# Add the dynamic link information
+# For now, assume its in our path... its there a better way ?
+if (DARWIN) {
+$command = otool $httpd;
+}
+else {
+$command = ldd $httpd;
+}
+
+$cfg .= \n*** $command\n;
+$cfg .= qx{$command};
+} else {
$cfg .= \n\n*** The httpd binary was not found\n;
}
Index: Apache-Test/lib/Apache/TestConfig.pm
===
--- Apache-Test/lib/Apache/TestConfig.pm(revision 279734)
+++ Apache-Test/lib/Apache/TestConfig.pm(working copy)
@@ -1837,7 +1837,19 @@
$command = $httpd -V;
$cfg .= \n*** $command\n;
$cfg .= qx{$command};
-}
+
+# Add the dynamic link information
+# For now, assume its in our path... its there a better way ?
+if (OSX) {
+$command = otool $httpd;
+}
+else {
+$command = ldd $httpd;
+}
+
+$cfg .= \n*** $command\n;
+$cfg .= qx{$command};
+}
else {
$cfg .= \n\n*** The httpd binary was not found\n;
}
If this point was reached, it would break Win32, plus
any other system which didn't have an ldd in the PATH.
Perhaps Apache::TestConfig::which() could be used to
see if an ldd() [or otool()] is present, and skip this
part if it's not found?
--
best regards,
randy
Re: ApacheCon BOF about Module Repository
On Tue, 6 Sep 2005, Sander Temme wrote: Folks, I have been meaning to follow up on this ever since that BOF, and am deeply annoyed that it has taken me this long. As a matter of fact, my memory of that BOF session has now faded to a considerable extent and I don't feel comfortable even giving a list of attendees because I would leave people out. I have pinned to my office wall the flip-over sheet with notes I took during the session and will now transcribe those. If anyone present at the event notices I'm leaving something out, please speak up. Building on my original message below, we discussed what should be implemented and how. [ ... ] We discussed CPAN, from which a lot of people blindly and trustingly download module upon module, as root. How did this get so trusted? Who is responsible for the code? We hear that nobody owns CPAN, and there is no identifiable target for any legal action anyone might want to bring. This obviously wouldn't fly for the ASF. Jarkko Hietaniemi, the CPAN Master Librarian, wrote up some thoughts on CPAN-like archives at http://www.cpan.org/misc/ZCAN.html Most (but not all) activity in CPAN is connected with Perl modules; for this, PAUSE (http://pause.perl.org/) is the means by which authors can upload and manage submissions. The code for PAUSE is available: ftp://pause.perl.org/pub/PAUSE/PAUSE-code/ Every module uploaded to the network would come with metadata, including (but not limited to): [ ... ] In the Perl world, metadata now comes in the form of a META.yml file: http://module-build.sourceforge.net/META-spec.html which is based on YAML: http://www.yaml.org/ This is one area that the CPAN/PAUSE maintainers emphasize as being crucial in being able to index and search effectively. -- best regards, randy kobes
Re: [APREQ1] Compile error on Win32
On Tue, 12 Jul 2005, Nikolay Ananiev wrote:
The latest svn of apreq 1.33 fails to compile on win32
ActivePerl 5.8.7, VisualStudio .NET, Apache 1.33
[ .. ]
I'm not sure what's been changed with the most recent
ActivePerl, but try the following patch:
=
Index: Makefile.PL
===
--- Makefile.PL (revision 226567)
+++ Makefile.PL (working copy)
@@ -106,6 +106,7 @@
VERSION = $myVERSION,
DIR = [qw(c Request Cookie)],
PREREQ_PM = \%require,
+DEFINE= '-D_INC_MALLOC -D_INC_SIGNAL',
clean = {
FILES = @{ clean_files() },
},
==
--
best regards,
randy kobes
Re: [APREQ1] Compile error on Win32
On Sun, 31 Jul 2005, Nikolay Ananiev wrote: Compiles without problems but apreq/request.t segfaults The error_log is empty E:\Downloads\httpd-apreqE:\Sites\Perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -verbose apreq/request.t e:/sites/servers/apache/apache.exe -d E:/Downloads/httpd-apreq/t -f E:/Download s/httpd-apreq/t/conf/httpd.conf -D APACHE1 -D PERL_USEITHREADS using Apache/1.3.33 waiting 60 seconds for server to start: .WARNING: StartServers has no effect on Win32 waiting 60 seconds for server to start: ok (waited 0 secs) server ananiev.discussion-works.com:8529 started Apache/1.3.33 (Win32) mod_perl/1.29_01-dev running... t\apreq\request1..2 # Running under perl version 5.008007 for MSWin32 # Win32::BuildNumber 813 # Current time local: Sun Jul 31 00:15:28 2005 # Current time GMT: Sat Jul 30 21:15:28 2005 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.27 # testing : basic param # expected: 42.5 # received: 42.5 ok 1 # Failed test 2 in t\apreq\request.t at line 26 # testing : basic upload # expected: data upload # received: 500 Unknown error not ok 2 FAILED test 2 Failed 1/2 tests, 50.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t\apreq\request.t21 50.00% 2 Failed 1/1 test scripts, 0.00% okay. 1/2 subtests failed, 50.00% okay. [ error] error running tests (please examine t\logs\error_log) Did you build mod_perl (and Perl) on your own? VC++ 7 (the .NET framework), which you're using, has some incompatibilities, in principle, with VC++ 6, which is what ActivePerl is compiled with. -- best regards, randy
Re: Unable to run t/ssl tests.
On Fri, 22 Jul 2005, William A. Rowe, Jr. wrote: Well now; rm -rf t , and svn up, gives me the original error attempting to create 'serial', a 'serial.old' lingers during the config phase. Just as a couple of checks: - does perl t/TEST -clean clean out the t\conf\ssl\ca directory completely? - is openssl writing things to the t\conf\ssl\ca\asf directory? -- best regards, randy
Re: Unable to run t/ssl tests.
On Fri, 22 Jul 2005, William A. Rowe, Jr. wrote: On Win32... Using openssl 0.9.8, httpd 2.1-dev (current) and perl-framework (current)... and I end up in a loop between running t/TEST -clean and t/TEST -apxs g:/path/to/apxs with this error, every time; The Subject's Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :PRINTABLE:'California' localityName :PRINTABLE:'San Francisco' organizationName :PRINTABLE:'ASF' organizationalUnitName:PRINTABLE:'httpd-test/dsa-des3-test' commonName:PRINTABLE:'localhost' emailAddress :IA5STRING:'test-dev@httpd.apache.org' Certificate is to be certified until Jul 22 21:36:28 2006 GMT (365 days) Write out database with 1 new entries unable to rename serial to serial.old reason: File exists [ error] configure() has failed: system ca -policy policy_anything -in csr/server_des3_dsa.csr -out certs/server_ des3_dsa.crt -passin pass:httpd -config conf/server_des3_dsa.cnf -batch extensions comment failed (exit status=1) at G:\built\perl-framework\blib\lib/Apache/TestSSLCA.pm line 172. [warning] forcing Apache::TestConfig object save [warning] run 't/TEST -clean' to clean up before continuing Does this look familiar to anyone? That does seem vaguely familiar, but I just tried the perl-framework on Win32 with openssl-0.9.7g and Apache/2.0.54, and the certificates got generated OK, and all the t/ssl/ tests passed. I'll try upgrading openssl to see if there's any change. -- best regards, randy
Re: AT_skip
On Tue, 19 Jul 2005, Joe Schaefer wrote: Joe Schaefer [EMAIL PROTECTED] writes: Randy Kobes [EMAIL PROTECTED] writes: Should AT_skip() print ok ..., rather than not ok ...? If I change this to do so, then the tests are reported as all pass; however, the message that these tests have been skipped aren't seen. +1 to dropping the not. Please apply that patch soonish, so I can roll rc4 and subject it to a vote. OK - thanks, that's been applied. -- best regards, randy
Problem with Apache::Cookie destroys Set-Cookie header (fwd)
This is a forwarded message from someone with a problem with Apache::Cookie of mod_perl-1 but who cannot subscribe easily to the mailing list. If anyone has seen this and/or knows what the problem is, could you include [EMAIL PROTECTED] in the reply? Thanks. best regards, randy -- Forwarded message -- Date: Wed, 29 Jun 2005 10:11:28 +0200 From: Lilo (GwenDragon) [EMAIL PROTECTED] To: Randy Kobes [EMAIL PROTECTED] Subject: Problem with Apache::Cookie destroys Set-Cookie header Hello Mr. Kobes, I'm running for compatibility issues a apache 1.3.33 on win32 under mod_perl. Yesterday i found an annyoing problem with current Apache::Cookie from your repository (libapreq-1 [1.2] and mod_perl-eapi-1 [1.29_01-dev]) Using relative values for -expires destructs the header in Apaches request! My simple code is appended in apachecookie.pl * Please exchange line 16 with line 17 and see the result! Header scanned with perls HEAD. * Destructed Header in header-notok.txt * Header with working Apache::Cookie -expires in header-ok.txt May be this can help. Thanks. -- Kind regards Lilo mailto:[EMAIL PROTECTED]200 OK Connection: close Date: Wed, 29 Jun 2005 07:50:50 GMT Server: Apache/1.3.33 (Win32) mod_ssl/2.8.22 OpenSSL/0.9.7f DAV/1.0.3-dev mod_perl/1.29_01-dev mod_jk/1.2.8 Content-Type: text/plain Client-Date: Wed, 29 Jun 2005 07:50:50 GMT Client-Peer: 192.168.0.11:80 Client-Response-Num: 1 Set-Cookie: foo=bar; domain=.capricorn.com; path=/cgi-bin/database; [EMAIL PROTECTED]@[EMAIL PROTECTED] DT [EMAIL PROTECTED] HTu?h, 27-$ Àu9DT~.ÿ DT [EMAIL PROTECTED] HTu?h-2005 07:50:50 GMT; secure 200 OK Connection: close Date: Wed, 29 Jun 2005 07:52:05 GMT Server: Apache/1.3.33 (Win32) mod_ssl/2.8.22 OpenSSL/0.9.7f DAV/1.0.3-dev mod_perl/1.29_01-dev mod_jk/1.2.8 Content-Type: text/plain Client-Date: Wed, 29 Jun 2005 07:52:05 GMT Client-Peer: 192.168.0.11:80 Client-Response-Num: 1 Set-Cookie: foo=bar; domain=.capricorn.com; path=/cgi-bin/database; expires=Sat, 30-Apr-2005 01:00:00 GMT; secure apachecookie.pl Description: Binary data
Re: expat install libapreq2-2.0.5-dev
On Mon, 23 May 2005, Philip M. Gollucci wrote: Marc Lambrichs wrote: [ ... ] But wait, there's more. In file included from Apache2.xs:39 /home/mlambrichs/libapreq2-2.05-dev/glue/perl/xsbuilder/apreq_xs_postperl.h:21:34: modperl_unembed.h: No such file or directory Somehow I'm under the impression that the Makefile isn't fit for my system. That's strange - glue/perl/xsbuilder/apreq_xs_postperl.h of my copy is including modperl_perl_unembed.h, not modperl_unembed.h. Was this a cut-n-paste error, or is it really trying to include modperl_unembed.h? Also, do you have modperl_perl_unembed.h under your Apache2 include/ subdirectory? It should get installed there upon installing mod_perl-2. -- best regards, randy kobes
Re: Massive leak in Apache2::Upload?
On Thu, 19 May 2005, Joe Schaefer wrote: Ville Skytt [EMAIL PROTECTED] writes: $r-discard_request_body() fixes it here too. Ok, here's what I'd like you (or Markus) to do. 1) grab our svn trunk and apply the attached patch to it. 2) make clean; make 3) cd module; make test 4) ls -l /tmp When the tests finish, they should leave three temporary files in /tmp: % ls -l /tmp total 1493 -rw--- 1 joe joe 500024 May 19 22:32 apreqStetos -rw--- 1 joe joe 500039 May 19 22:32 apreqT5oOq1 -rw--- 1 joe joe 500039 May 19 22:32 apreqs16lOA We need to figure out which side the leak is happening on (writing to the spool file or reading from it). The presence/absense of these files on your box should help us make that determination, so let us know what you see. On Win32, I get those 3 files in the analagous /tmp, with the same sizes. -- best regards, randy
Re: Modifying Win32 default optimizations?
On Thu, 12 May 2005, Branko ^Libej wrote: William A. Rowe, Jr. wrote: [ ... ] Yes - I see Python 2.3 / Mod Perl 5.8 / Apache 2.0 / APR 0.9 / etc all in the same 'generation' of code. Do you want the ASF to be a leader of this 'breakage' as the Python project was? This is why the push back. And I hope for Python 2.4 / Apache 2.2 / APR 2.0 / etc to all be of the next 'generation', finally adopting msvcr70. Seem rational? I can live with that. That sounds great, but one consideration from the point of view of Perl (eg, mod_perl) is that the dominant Win32 Perl binary, from ActiveState, uses VC 6 to compile, and they don't have any plans soon of changing that. But that might change by the next generation. -- best regards, randy kobes
Re: Apache 2.0.53/Win32/.msi+.exe installers
On Sun, 13 Feb 2005, William A. Rowe, Jr. wrote: Dearest testing community; at http://httpd.apache.org/dev/dist/ you will find new Win32 installers for the apache_2.0.53 release, and the new Win32 source tarball (buildable from command line on VC5+ with nmake -f makefile.win). Please validate and report, before I push this out live. Mea Culpa this is running behind, we have both the svn change which I had to contend with, an incomplete apr-iconv release which had to be completed, and this is the *first* release of 2.0.x using the InstallShield X product (previous releases were created with InstallShield for Windows Installer.) As with most 'automatic conversions' not everything that is converted magically becomes magically correct. Although it seems this installer is stable, wider testing is needed due to the changeover. Please cc: me in all replies to avoid moderation. Thanks! Bill For me, both the .msi installer and the build from the sources (using VC++ 6) worked fine. -- best regards, randy kobes
Re: apxs calls on Win32
On Tue, 7 Dec 2004, Stas Bekman wrote:
As soon as you see dup like this, think refactoring :) e.g. add
untaint_path(), that does the work and call it:
local $ENV{PATH}) = untaint_path($ENV{PATH});
Otherwise +1.
And of course this wrapper should probably used in open_cmd too!
Here's a patch that does that:
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 56)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1045,12 +1045,8 @@
my($self, $cmd) = @_;
# untaint some %ENV fields
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+local $ENV{PATH} = untaint_path($ENV{PATH});
-# Temporarily untaint PATH
-(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
-# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
-
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1663,7 +1659,8 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+local $ENV{PATH} = untaint_path($ENV{PATH});
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
@@ -1684,6 +1681,17 @@
$self-{_apxs}{$q};
}
+# Temporarily untaint PATH
+sub untaint_path {
+my $path = shift;
+($path) = ( $path =~ /(.*)/ );
+# win32 uses ';' for a path separator, assume others use ':'
+my $sep = WIN32 ? ';' : ':';
+# -T disallows relative directories in the PATH
+$path = join $sep, grep !/^\./, split /$sep/, $path;
+return $path;
+}
+
sub pop_dir {
my $dir = shift;
==
I tried committing it, but was denied access (I ensured I
did a co with https); perhaps some permissions need
adjusting (I did have commit access under cvs).
--
best regards,
randy
Re: apxs calls on Win32
On Sun, 5 Dec 2004, Stas Bekman wrote:
Randy Kobes wrote:
If apxs is installed on Win32, it is usually specified as a
.bat file. In querying apxs in apxs() of Apache::TestConfig,
however, Win32 needs both the path to cmd.exe (for running a
.bat command) and to Perl (in order to run apxs.bat) in
order to get something from
$val = qx($apxs -q $q 2$devnull);
This diff:
If it's only win32 case then +1 but if other platforms may have the same
problem, may be it's better to blindly launder $ENV{PATH} like we do in a
few other places (in which case there will be no need for this change, as
the right paths will be there already, correct?)
That's right - what about the following, copied from
the open_cmd sub of Apache::Build (for Win32, this needs
to use the ';' as the directory separator within $ENV{PATH},
rather than ':'.
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 110064)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1043,7 +1043,8 @@
# Temporarily untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1657,7 +1658,12 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+# Temporarily untaint PATH
+(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
+# -T disallows relative directories in the PATH
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
=
--
best regards,
randy
Re: apxs calls on Win32
On Tue, 7 Dec 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 110064)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1043,7 +1043,8 @@
# Temporarily untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1657,7 +1658,12 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+# Temporarily untaint PATH
+(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
+# -T disallows relative directories in the PATH
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
As soon as you see dup like this, think refactoring :) e.g. add
untaint_path(), that does the work and call it:
local $ENV{PATH}) = untaint_path($ENV{PATH});
Otherwise +1.
And of course this wrapper should probably used in open_cmd too!
OK, I'll do that - thanks!
Also is there some File::Spec thingy that defines record
separator in paths?
I looked through there - there's not one specifically
defined. There are special cases for various platforms:
Mac = uses ',', but needs $ENV{Commands}, not $ENV{PATH}
OS2 = uses ';', but also translates '\' to '/'
VMS = uses a different $ENV variable
So some of these (eg, Mac and VMS) would require special
handling just to get at the equivalent of $ENV{PATH}.
Is leaving it just as is OK for the moment (using ';' for
WIN32, ':' otherwise), and if someone has problems with it,
we can fix it then?
Also, I haven't tried it yet, but just to make sure the
email messages go to the right place - can one do a commit
to Apache-Test from within modperl-2.0 svn (from within
the Apache-Test subdirectory)?
--
best regards,
randy
apxs calls on Win32
If apxs is installed on Win32, it is usually specified as a
.bat file. In querying apxs in apxs() of Apache::TestConfig,
however, Win32 needs both the path to cmd.exe (for running a
.bat command) and to Perl (in order to run apxs.bat) in
order to get something from
$val = qx($apxs -q $q 2$devnull);
This diff:
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 109825)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1658,6 +1658,12 @@
my $val;
unless (exists $self-{_apxs}{$q}) {
local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+# need path to Perl and to cmd.exe on Win32
+if (WIN32) {
+$ENV{PATH} = sprintf(%s;%s,
+ dirname($ENV{COMSPEC}),
+ dirname($self-{vars}-{perl}));
+}
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
=
populates $ENV{PATH} with the needed paths so that these
calls succeeed.
--
best regards,
randy
Re: httpd-test pages need to be updated to point to svn not cvs
On Tue, 30 Nov 2004, Stas Bekman wrote: http://httpd.apache.org/test/ is outdated (s/cvs/svn/)... thanks. I just changed, via svn, the site/docs/test/index.html and site/xdocs/test/index.xml pages to reflect this. However, I just wanted to verify that, to get the changes on the site itself, one must $ ssh cvs.apache.org $ cd /www/httpd.apache.org/test $ svn up Thanks. -- best regards, randy
Re: apxs/apr-config/apu-config on Win32
On Mon, 29 Nov 2004, William A. Rowe, Jr. wrote: At 11:51 AM 11/29/2004, Stas Bekman wrote: Randy Kobes wrote: I've been testing out some perl scripts to emulate apxs/apr-config/apu-config on Win32 (under Apache/2.0.x), and was wondering if there was any interest in developing them within the appropriate httpd/apr sources. At present they can be installed via a perl script http://perl.apache.org/dist/win32-bin/install_apxs This assumes an installed Apache binary with the associated apr/aprutil libs, but it would be possible to separate out the apxs from the apr/apu config utilties. In their present form they're intended for building modules outside of the httpd sources; they've been tested out on the c-modules within the perl-framework under httpd-test, as well as those under env/ of httpd-apreq-2, and they seem to work OK. +1 Randy is a long time committer to the mod_perl project, so I'm sure that if the proposed scripts are integrated with apr/httpd, Randy will be able to maintain those, once the right karma is added. There are very few brave folks who handle the win32 world, so let's make it easier for them to help the disadventaged win32 users. ++1 - this is a wonderful thing. One note - I'd like to see this stripped to the point where you don't have a ton of dependencies on additional modules. Would be nice to distribute without the need to use Makemaker. Is this possible? (Putting necessary .pm stubs in the same tree as apxs and letting it run out-of-the-box?) Yes, it's possible to strip it down, and in particular, do away with MakeMaker. This is done in the version at http://www.apache.org/~randyk/apxs.zip When unpacked, running, eg, perl apxs_install.pl D:\Path\to\installed\Apache2 will configure and install apxs, apr-config, and apu-config. Here, D:\Path\to\installed\Apache2 is the top-level Apache2 installation directory, and it is assumed that things have already been installed there (in order to get some version information and library names). However, if desired, this information could be extracted from files within the sources instead, prior to installation. This smaller version does away with some of the checks and possible user prompting of the earlier version, by assuming that the specified D:\Path\to\installed\Apache2 is the right one. So it might be suitable to be invoked from httpd-2.0.x/Makefile.win, using the $(INSTDIR) defined there. Note that there's a few variables, such as in the installed $APACHE2/build/config_vars.mk, which I left blank, either because I didn't know what the Win32 versions were, or because they seemed Unix-specific. These can be easily changed, though. -- best regards, randy
apxs/apr-config/apu-config on Win32
I've been testing out some perl scripts to emulate apxs/apr-config/apu-config on Win32 (under Apache/2.0.x), and was wondering if there was any interest in developing them within the appropriate httpd/apr sources. At present they can be installed via a perl script http://perl.apache.org/dist/win32-bin/install_apxs This assumes an installed Apache binary with the associated apr/aprutil libs, but it would be possible to separate out the apxs from the apr/apu config utilties. In their present form they're intended for building modules outside of the httpd sources; they've been tested out on the c-modules within the perl-framework under httpd-test, as well as those under env/ of httpd-apreq-2, and they seem to work OK. -- best regards, randy kobes
Re: Apache-Test module skeletons
On Fri, 9 Jul 2004, David Wheeler wrote:
On Jul 9, 2004, at 1:09 PM, Stas Bekman wrote:
There is no Apache.pm in mp2. You probably wanted to say:
requires = { 'mod_perl' = 0,
Right. In fact, it should probably be
requires = { 'mod_perl' = '1.0',
in the MP1 example, and
requires = { 'mod_perl' = '1.99',
in the MP2 example, yes?
Assuming this is for the benefit of CPAN/CPANPLUS to install
dependencies, doesn't this run into a couple of problems
that, in particular, Stas has raised:
- CPAN doesn't yet support multiple module versions, only
the latest (which currently is mp1, as mp2 is marked as
a development version);
- if someone had mp2 installed in an Apache2/ subdirectory,
CPAN/CPANPLUS wouldn't see it unless somehow 'use Apache2'
was invoked to adjust @INC;
What about requiring 'Apache' for mp1-related modules (since
'Apache' doesn't exist within mp2), and for mp2 modules,
requiring 'Apache2' (which doesn't exist within mp1)?
--
best regards,
randy
Re: Apache-Test module skeletons
On Fri, 9 Jul 2004, David Wheeler wrote:
On Jul 9, 2004, at 1:45 PM, David Wheeler wrote:
use 5.00503;
use Apache::TestMB;
Apache::TestMB-new(
module_name= 'Apache::Test::Skeleton',
license= 'perl',
requires = { 'mod_perl' = = 1.0, 1.99,
},
build_requires = { Test::More = 0,
},
)-create_build_script;
Oh, and FWIW, CPANPLUS should soon have the ability to check such a
spec. Not sure that CPAN.pm ever will, though.
Regards,
David
But won't the CPAN indices (which are used by both CPAN.pm
and CPANPLUS.pm) still just recognize one version of
mod_perl.pm? Either the current one associated with mp1, or,
when mp2 is out of development, that associated with mp2
(assuming mod_perl.pm of mp2 has a higher version compared
to that of mp1). Or will CPANPLUS go beyond the CPAN
indices?
One (qualitatively similar) example is the GD module, for
which there's two major (incompatible) versions, 1 and 2.
Currently CPAN.pm reports GD as being version 2.12, and so
to install an earlier version 1.x, you have to tell CPAN.pm
explicitly which distribution you want to install.
--
best regards,
randy
Re: Trying to test current apreq2 CVS
On Fri, 2 Jul 2004, Markus Wichitill wrote:
Hi,
I tried to compile the latest apreq2 CVS on Linux to test $upload-fh/size.
First I tried to compile it for mod_perl 1.99_14 (Apache
2.0.50 Worker, Perl 5.8.3), which failed since that
version doesn't contain the required
modperl_common_util.h. Maybe that's correct, but I thought
I'll mention it since the docs still say that _09 is
required.
So I compiled the current mod_perl CVS first, which copied
modperl_common_util.h into apache2/include. However only
after I manually copied modperl_common_types.h into
apache2/include did apreq's Perl glue compile and test ok.
The following patch to the mod_perl 2 cvs sources should
include modperl_common_types in the list of header files
to install in apache2/include:
Index: lib/ModPerl/Code.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.124
diff -u -r1.124 Code.pm
--- lib/ModPerl/Code.pm 28 Jun 2004 02:10:02 - 1.124
+++ lib/ModPerl/Code.pm 2 Jul 2004 18:44:28 -
@@ -655,7 +655,7 @@
largefiles);
my @h_names = (@c_names, map { modperl_$_ } @h_src_names,
qw(types time apache_includes perl_includes apr_includes
- common_includes));
+ common_includes common_types));
sub h_files { [map { $_.h } @h_names, @g_h_names] }
sub clean_files {
==
--
best regards,
randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error running apache test
On Tue, 22 Jun 2004, Abhishek Khandelwal wrote: I am getting another strange problem. I compile and install apache 2.0.49 for both fedora core 1 and red-hat linux. Everything seems okay, and installs properly. When I start httpd manually, it start running and when I do wget using http://localhost It works fine in both the machines. But, when I run the test provided my perl-test-framework. And try to run the server using t/TEST -httpd-start, the server starts perfectly on Fedora core but it dies immediately with exit code 255 on Red-hat machine. Looking at the error log, in t/log/error_log directory, I see the error: [error] (38)Function not implemented: Cannot create SSLMutex In the ssl portion of your system httpd.conf, if the SSLMutex directive is not given as SSLMutex default does changing it to that help? -- best regards, randy kobes
Re: Error running apache test
On Tue, 22 Jun 2004, Abhishek Khandelwal wrote: Where exactly I put this? In the conf file generated by test, which is in t/conf/httpd.conf or even before compiling and building test, I change the original httpd.conf? Try changing the original first - I think Apache-Test should pick up this setting. Also, where exactly do I put this SSLMutex default? When installing Apache, assuming a fresh install, this directive probably appears somewhere in a sample ssl configuration file. -- best regards, randy
Re: Error running apache test
On Tue, 22 Jun 2004, Abhishek Khandelwal wrote: I changed original ssl.conf to the SSLMutex default as shown below. # Semaphore: # Configure the path to the mutual exclusion semaphore the # SSL engine uses internally for inter-process synchronization. #SSLMutex file:/opt/oss/var/apache2/run/ssl_mutex SSLMutex default Then I rebuild the test and try to run the test. But still my error log shows SSLMutex not created error. Does the above change to SSLMutex also appear in the config file generated by Apache-Text beneath t/conf/? If not, try doing a make clean to clean out the old stuff, and then rebuilding. -- best regards, randy
Re: [NOMINATE] commit access for david wheeler
On Wed, 23 Jun 2004, Geoffrey Young wrote: hi all... as suggested by stas in a recent thread, it's about time we gave david commit access to the perl-framework - he has been actively helping with the project for as long as I can remember, from mac-specific stuff to lots of great work on the (often thin) docs. and now he is working feverishly on integrating Module::Build support into Apache-Test, which is in itself a noble effort worthy of commit rights. so, here is my +1. +1 - great idea! -- best regards, randy
Re: Apache::TestMB
On Mon, 21 Jun 2004, David Wheeler wrote: [ ... ] * This isn't commented in the code I sent you, but I'll note it: I didn't implement cmodules or cmodules_clean actions. They appear simple, but they seem to depend on `make` rather than Module::Build. Stas, are these just that simple? Should I expect that there'd be a Makefile in the cmodules directory? Or might it be Module::Build-based? I guess the real question is, where does that Makefile come from? Right now the Makefile is generated by methods within Apache/TestConfigC.pm, which generally consists of calling the apxs utility to compile the module (as well as implementing a 'clean' target). In principle I think this could be done via Module::Build with an appropriate Build.PL and the corresponding changes within Apache/TestConfigC.pm to call it. -- best regards, randy kobes
Re: [Module::Build] Re: Apache::TestMB
On Tue, 22 Jun 2004, David Wheeler wrote: On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote: Right now the Makefile is generated by methods within Apache/TestConfigC.pm, which generally consists of calling the apxs utility to compile the module (as well as implementing a 'clean' target). In principle I think this could be done via Module::Build with an appropriate Build.PL and the corresponding changes within Apache/TestConfigC.pm to call it. Okay. I've put in some placeholder methods for this; Randy, can you add the necessary code? Sure, it should be relatively straightforward ... But I'd like to get, especially, Stas' opinion on this - adding this in will necessarily introduce a few branches in the Apache/TestConfigC.pm code related to, first of all, whether to write a Makefile.PL or a Build.PL (and the ensuing different syntax), and then secondly, how to use them. -- best regards, randy
Re: [mp2 patch] getting APR to work w/o modperl
On Sat, 15 May 2004, Stas Bekman wrote:
Randy Kobes wrote:
On Mon, 10 May 2004, Stas Bekman wrote:
How about a quick workaround as follows: For windows only,
link APR.so statically with all APR/Foo.o and the required
modperl_foo.o and arrange for the bootstrap not to call it
for windows if APR.so is loaded?
That sounds good ...
So can you try to tackle that? I guess my latest patch
won't apply against the current cvs and I'll need to
re-sync it and resolve collisions.
I'll give it a go ... So as I'll be current, could you
re-sync it, if it's not too difficult? Alternatively,
if the patch is OK on others (apart from Win32, and
perhaps aix), is it ready to apply, and we'll work
from there?
I guess all you need to do is to change
xs/APR/APR/Makefile.PL to collect all .o files from under
xs/APR and a few selected src/modules/perl/modperl_xxx.o
and link them statically with APR.so if under win32. (and
may be some other platforms too (aix comes to mind)).
Just so I understand correctly, in this approach we'll have
one (big) APR.so that has collected all the functionality of
the individual APR::* modules (as well as the old APR.so
itself and selected symbols from modperl_xxx.o)? Or does APR
stay essentially the same (with the added symbols from
selected modperl_xxx.o), and then one links each APR::* with
APR.so?
It should be relatively straightforward to do the latter (as
long as APR.so is built before APR::*). However, with the
former, there'd be problems building the individual APR::*
modules first, to be used as components in building APR.so,
for the same reason that exists now - to build APR::*, one
has to specify the library where the symbols are found, and
one can't specify a library (APR.so) that hasn't been built
yet. This could be resolved in some cases by linking APR::*
against the relevant modperl_xxx.o files; however, for those
that require some functionality within APR.so itself, there
might be a problem ...
The only alternative I was able
to come up with is to use LoadLibrary/GetProcAddress
to set a function pointer to that of a function
within a dll. I tried to cut this down to the
minimal needed, and came up with something along
the lines of, generically,
typdef ... /* delare the function pointers */
HINSTANCE hlib;
if (GetProcAddresses(hlib, Some.dll,
fn_1, func_1,
fn_2, func_2,
...) {
/* the functions are available */
}
if (hlib != NULL) FreeLibrary(hlib);
where GetProcAddresses() is a simple (generic) routine that
associates, from Some.dll, func_1, func_2, ... with fn_1,
fn_2, ... So, in this approach, for each APR::* as
appropriate, necessary function pointers must be declared,
GetProcAddresses() is invoked, and finally, if necessary,
FreeLibrary() called at the end.
However, I don't have enough experience with the build
system to compare if the above would be easier or harder to
set up and maintain, compared to linking against the
appropriate .so files.
The biggest problem I see here, is that we won't be able
to test whether things still work on windows, every time
we change or add something. So I'd prefer not to use it.
If this can be done automatically, without touching the
existing code, then i guess it's OK. But I'm not quite
sure this is possible.
That's certainly a concern ... If this is ever
attempted, I think some (most?) of it could be
done somewhat automatically, but maybe it'd be
better to explore the above approach first.
--
best regards,
randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 patch] getting APR to work w/o modperl
On Sun, 16 May 2004, Stas Bekman wrote: On Sun, 16 May 2004, Randy Kobes wrote: [ .. ] Well, I don't want to destabilize the tree, we should make a new release pretty soon. I think while you are playing with various solutions you could just check the cvs tree for the day I've posted my second patch and it should apply just fine. Your work is going to be in the xs/APR/APR area, not really touching anything else. If you think it's a problem I'll then try to post an up-to-date patch, but it may quickly become out-of-date in a few days. Sounds good ... I guess all you need to do is to change xs/APR/APR/Makefile.PL to collect all .o files from under xs/APR and a few selected src/modules/perl/modperl_xxx.o and link them statically with APR.so if under win32. (and may be some other platforms too (aix comes to mind)). Just so I understand correctly, in this approach we'll have one (big) APR.so that has collected all the functionality of the individual APR::* modules (as well as the old APR.so itself and selected symbols from modperl_xxx.o)? Or does APR stay essentially the same (with the added symbols from selected modperl_xxx.o), and then one links each APR::* with APR.so? I was talking about the former, where APR.so will include all objects in Wrap/APR/*/.o (not .so) and some of src/modules/perl/modperl_xxx.o. OK, that makes sense ... I'm not sure how can you go with the latter idea. I mean, I'll work perfectly fine without mod_perl. But how is it going to work under mod_perl, when both mod_perl.so and APR.so will have the same symbols, and according to your suggestion, both will be loaded (since APR/Foo.so will be linked against APR.so). In this approach I don't there's a problem on Windows with linking against libraries with the same symbols; depending on the order of the libraries in the link command, VC++ will resolve the symbols not found in the object files in the 1st library file it finds that has them (which then registers the corresponding .so, if it's a shared library), so any identical symbols in a later library used in the link command are ignored. Thus, you could in principle build an application linked against two dlls that have the same symbols in them and there shouldn't be a conflict, as the application knows, from how it was linked, which dll each symbol comes from. However, this also means that no symbols can be resolved through mod_perl.lib, as this would require loading mod_perl.so (unless one used the -delayload link option, to load the dll only if a symbol is invoked). It would have worked perfectly if we could also link mod_perl.so against APR.so and not include those symbols in mod_perl.so. Which is probably the best solution possible. The problem is that the loaded will somehow have to find APR.so when trying to load mod_perl.so. This could have been done by installing APR.so along with libapr.so I suppose. In that case we will have APR a totally autonomous systems and mod_perl will use it. May be it makes perfect sense, but I haven't thought of the implications for users. It should be relatively straightforward to do the latter (as long as APR.so is built before APR::*). However, with the former, there'd be problems building the individual APR::* modules first, to be used as components in building APR.so, for the same reason that exists now - to build APR::*, one has to specify the library where the symbols are found, and one can't specify a library (APR.so) that hasn't been built yet. But I was talking about building .o objects, not shared libs. and linking those .o objects with APR.so. Will that be a problem too? AFAIK you never need to provide information about shared libs, during compilation time. Is that different on windows? No, you're right - resolving all symbols only is required at link time, so this could be done by just compiling (with -c) the APR::* files to build the object files, and skip building the associated APR::* dlls, as is done now. I think things are becoming clearer to me - thanks. It looks like most of this can be done by fiddling with the compiling/linking commands, without the need (hopefully) of any source code modifications. I'll try it and see. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 patch] getting APR to work w/o modperl
On Sun, 9 May 2004, Stas Bekman wrote:
Yes, that sounds like a much better idea. There should be
a way to tell the application that certain symbols will be
resolved at run-time, and no matter who will provide them
(application, another library or else). On AIX the linker
is just as picky, but lets you shut up itself by telling
it that the missing symbols will be resolved at run time
and that it shouldn't worry about it. using the -brtl
option (see lib/Apache/Build.pm).
There is a link option on VC++ 6, -delayload:some.dll, which
delays the loading of a dll until a function inside it is
actually called by an application. But this is used in
situations like
if (some_condition_is_true) {
call_the_dll_function();
}
else {
do_something_else();
}
where the dll may not be available on some target machine.
What seems different on Windows compared to Unix, even with
this delayload thing (which still requires you to link
against the .lib file corresponding to the relevant .dll),
is that when you link against a .lib file which resolves
symbols, information about those symbols appears in the
result which contains references to the specific dll where
those symbols appear. What Jan suggested, in some sense, is
to try to fool Win32 by building, eg, APR.so, in a way to
make it go by the name of mod_perl.so, by using the same
.def file for both (and specifying a library name). But this
doesn't seem to quite work, at least in a simple way.
--
best regards,
randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: more on the perl-framework on windows
On Fri, 26 Mar 2004, Rodent of Unusual Size wrote: Geoffrey Young wrote: if apxs is being invoked but isn't available you may have a leftover TestConfigData.pm sitting around which you can safely remove. or you didn't explicitly pass -httpd or something like that, which you ought to be able to do via t/TEST -conf -httpd /path/to/httpd as well. the problem is that there *is* an apxs.pl, but no development tools. apxs came with the installation; the server wasn't built on this system. i have built the c modules and i'm trying to put them in place so the framework will use them without trying to frickin' build them. however, it apparently wants to run apxs even though the module binaries exist. what's triggering that? why won't it use what's there without trying to create them itself? If you put the compiled modules in place, and then run 'nmake test', is the problem that things get cleaned out first (erasing the binaries), or that it just tries to recompile things? On my system (which has VC++), 'nmake test' first cleans things out, which erases previously built modules. -- best regards, randy
Re: testing apache 1.3 on windows
On Tue, 16 Mar 2004, Rodent of Unusual Size wrote: and a 'perl t\TEST -config' blowes up trying to build mod_random_chunk (unresolved symbols _random and _srandom). I couldn't find the _random or _srandom symbols in a system library, but changing these to rand() and srand() in mod_random_chunk.c seems to work OK. -- best regards, randy
Re: testing apache 1.3 on windows
On Wed, 17 Mar 2004, Rodent of Unusual Size wrote: Randy Kobes wrote: I couldn't find the _random or _srandom symbols in a system library, but changing these to rand() and srand() in mod_random_chunk.c seems to work OK. mm. i've ifdef'd those for WIN32 and will commit it; if anyone cares to verify that s/rand() are universally suitable replacements for s/random(), the ifdef can go. thanks, randy! I found this in the rand man page on Linux: The versions of rand() and srand() in the Linux C Library use the same random number generator as random() and srandom(), so the lower-order bits should be as random as the higher-order bits. However, on older rand() implementations, the lower-order bits are much less random than the higher-order bits. So it looks like they're not equivalent on older implementations. -- best regards, randy
Re: testing apache 1.3 on windows
On Tue, 16 Mar 2004, Rodent of Unusual Size wrote: Randy Kobes wrote: There is an alpha port of apxs for Win32 for Apache/2.0; grab the script http://perl.apache.org/dist/win32-bin/install_apxs and run it, which will fetch, configure, and install it on your system. beauty. except a) i had to add 'use File::Spec;' to Configure.pl, Sorry about that - I'll fix that. and a 'perl t\TEST -config' blowes up trying to build mod_random_chunk (unresolved symbols _random and _srandom). I noticed that too - I guess it needs linking against some system library; I'll try to find out which one. but it's a whole lot better than before! do things of the form 'open($fh, link foo |);' not work well on windows? because i'm wondering if the giant .bat file could be replaced with a perl script that used that construct to do the linking.. Things like that do work in general, and that's a good idea. I was going to clean the script up (in it's present form it was a hacked port from the unix version), and I'll look at doing something like that. Thanks. -- best regards, randy
Re: testing apache 1.3 on windows
On Mon, 15 Mar 2004, Rodent of Unusual Size wrote: also, there apparently is no longer an apxs.pl for 2.0 windows -- so what's the magic Makefile.PL argument to let the test modules be built? There is an alpha port of apxs for Win32 for Apache/2.0; grab the script http://perl.apache.org/dist/win32-bin/install_apxs and run it, which will fetch, configure, and install it on your system. in case there was any question, i hate development on windows, i hate libtool, and i think i've discovered a special subtype of 'male pattern baldness' -- call it 'hacker pattern baldness,' comes from pulling your hair out. :) -- best regards, randy kobes
Re: testing apache 1.3 on windows
On Mon, 15 Mar 2004, William A. Rowe, Jr. wrote: At 02:51 PM 3/15/2004, you wrote: On Mon, 15 Mar 2004, Rodent of Unusual Size wrote: also, there apparently is no longer an apxs.pl for 2.0 windows -- so what's the magic Makefile.PL argument to let the test modules be built? There is an alpha port of apxs for Win32 for Apache/2.0; grab the script http://perl.apache.org/dist/win32-bin/install_apxs and run it, which will fetch, configure, and install it on your system. Randy ... ready to make a go of integrating into httpd-2.0 build? Bill Sure, Bill - I'd be happy to ... Right now it seems to work OK for external modules (although some cleanup is warranted), but it would need work to be useable within httpd-2.0 itself. -- best regards, randy
Re: Sticky preferences in Windows
On Sat, 13 Mar 2004, William McKee wrote: Hi Stas, I'm running into the sticky preferences problem now as well. I decided the quickest way to get my tests running in the Windows environment would be to install mod_perl. The install notes suggested that the path be c:\apache2 which means the default path of c:\program files\apache2 is no good. I uninstalled apache and reinstalled into c:\. No problems. However, now that I'm trying to rebuild my module to run my tests, the TestConfigParse.pm module is still finding the old path. I've searched my drive manually and with the built-in search tools as well as in the registry but cannot figure out where A::T has squirelled away this setting. Could you give me a pointer? This is WinXP if that makes any difference. I don't think being on Windows makes a difference in this particular case - I think where it gets the info from is C:\Perl\site\lib\Apache\BuildConfig.pm which is generated by Apache::Build. -- best regards, randy kobes
Re: in-place edit in TestRun.pm
On Wed, 10 Mar 2004, Stas Bekman wrote:
Randy Kobes wrote:
Hi,
A recent change in Apache-Test/lib/Apache/TestRun.pm
involves an in-place edit, at around line 765:
[ .. ]
Unfortunately, Win32 can't do such in-place edits:
[ ... ]
why not doing:
local $^I = .bak; # windows can't do inplace edit
local @ARGV = $config_file;
while( ) {
s/old/new/;
print;
}
unlink $config_file.bak;
much simpler.
Very true ... I'll make that change - thanks!
--
best regards,
randy
Re: time for a new A-T release?
On Thu, 19 Feb 2004, Stas Bekman wrote: I'd like to get a new A-T out of the door. There were a *lot* of tweaks and new features added since the last release. It'd be nice to see whether users are happy with them, before we get a new mp2 release out. Hi Stas, Regarding that patch we just discussed about fixing directories with spaces on Win32, I'm away for about a week, but will work on it when I get back. -- best regards, randy
Re: Apache::TestMM::generate_script vs. Win32 Paths
On Tue, 17 Feb 2004, Stas Bekman wrote:
Randy Kobes wrote:
On Tue, 3 Feb 2004, Christopher H. Laco wrote:
I've installed Apache::Test 1.07 on ActiveState perl 5.6.1
build 630 and am trying to make test scripts for a pile of
pages in a package I'm workin on.
If I pass in an -httpd path that has spaces in the path,
it fails.
use ExtUtils::MakeMaker;
use Apache::TestMM qw(test clean);
push @ARGV, '-httpd', 'C:\Program Files\Apache Group\Apache\Apache.exe';
[ .. ]
Is this an Apache::Test problem, or possible an nmake issue?
This case should be handled I'd think on the Apache::Test
side. Does
my $exe = 'C:\Program Files\Apache Group\Apache\Apache.exe';
$exe = Win32::GetShortPathName($exe);
push @ARGV, '-httpd', $exe;
work? If so, I'll look at seeing where this could be added
within Apache::Test.
This patch should probably take care of it. It's untested.
Thanks, Stas - it looks good (applied manually, and
informally tested, as I don't have Perl in a place with
spaces in the directory name). A couple of comments below:
Index: lib/Apache/TestConfig.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.205
diff -u -r1.205 TestConfig.pm
--- lib/Apache/TestConfig.pm 18 Feb 2004 00:30:57 - 1.205
+++ lib/Apache/TestConfig.pm 18 Feb 2004 04:40:21 -
@@ -67,6 +67,16 @@
(map { $_ . '_module_name', $_ module name} qw(cgi ssl thread access
auth)),
);
+my %filepath_conf_opts = map { $_ = 1 }
+qw(top_dir t_dir t_conf t_logs t_conf_file src_dir serverroot
+ documentroot bindir sbindir httpd apxs httpd_conf perlpod sslca
+ libmodperl);
+
+sub conf_opt_is_a_filepath {
+my $opt = shift;
+$opt exists $filepath_conf_opts{$opt};
+}
+
sub usage {
for my $hash (\%Usage) {
for (sort keys %$hash){
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.149
diff -u -r1.149 TestRun.pm
--- lib/Apache/TestRun.pm 18 Feb 2004 04:09:08 - 1.149
+++ lib/Apache/TestRun.pm 18 Feb 2004 04:40:21 -
@@ -238,6 +238,15 @@
push @argv, $val;
}
+# fixup the filepath options on win32 (spaces, short names, etc.)
+if (Apache::TestConfig::WIN32) {
+require Win32::GetShortPathName;
The require isn't required, as Win32::GetShortPathName is
a core function.
+for my $key (keys %conf_opts) {
+next unless Apache::TestConfig::conf_opt_is_a_filepath($key);
+$conf_opts{$key} = Win32::GetShortPathName($conf_opts{$key});
^^^
I think if one calls Win32::GetShortPathName
on something that has no short path name, then
nothing is returned. For example,
==
use strict;
use warnings;
for ('C:\Program Files', 'C:\ProgramFiles') {
my $x = Win32::GetShortPathName($_);
if ($x) {
print $_ has a short name of $x\n;
}
else {
print $_ has no short name\n;
}
}
===
prints
===
C:\Program Files has a short name of C:\PROGRA~1
C:\ProgramFiles has no short name
Thus, the above should probably include
+for my $key (keys %conf_opts) {
+next unless Apache::TestConfig::conf_opt_is_a_filepath($key);
+ + next unless $conf_opts{$key} =~ / /;
+$conf_opts{$key} = Win32::GetShortPathName($conf_opts{$key});
--
best regards,
randy
Re: Apache::TestMM::generate_script vs. Win32 Paths
On Tue, 3 Feb 2004, Christopher H. Laco wrote: I've installed Apache::Test 1.07 on ActiveState perl 5.6.1 build 630 and am trying to make test scripts for a pile of pages in a package I'm workin on. If I pass in an -httpd path that has spaces in the path, it fails. use ExtUtils::MakeMaker; use Apache::TestMM qw(test clean); push @ARGV, '-httpd', 'C:\Program Files\Apache Group\Apache\Apache.exe'; [ .. ] Is this an Apache::Test problem, or possible an nmake issue? This case should be handled I'd think on the Apache::Test side. Does my $exe = 'C:\Program Files\Apache Group\Apache\Apache.exe'; $exe = Win32::GetShortPathName($exe); push @ARGV, '-httpd', $exe; work? If so, I'll look at seeing where this could be added within Apache::Test. -- best regards, randy kobes
Re: sticky preferences in Apache-Test
On Sat, 17 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: [ ... ] I don't have an ~/.apache-test/, and yes, using the perl with the CPAN A-T installed to build the cvs A-T is fine. Where I run into problems in not seeing the configuration dialogue is using the perl with the cvs A-T installed in building the cvs A-T, even if I delete the installed TestConfigData.pm. That's the correct behavior at the moment, because you have mp2 installed. If mp2 is found it has Apache/BuildConfig.pm which tells A-T where httpd is. And A-T will save that value in the global Apache/TestConfigData.pm if it can write to it, or in ~/.apache-test/.' Of course we can change that behavior, but I think it's cool as mp2 users will never see that interactive dialog. That is neat - I was just wondering where A-T was finding this information from. I'd leave that as is - thanks. -- best regards, randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sun, 11 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
my Apache is D:\Apache2\bin\Apache.exe, which would
get reported as d:\apache2\bin\apache.exe. If there isn't
an easy way to preserve the case yet still remove such
duplicates, I'll do that - it's not a big deal.
Randy, you are the expert on win32 ;) I have no idea what
method to use to get a consistent case on case-insenstive
file systems. Really I think it's time to extend
File::Spec to handle that and not solve this problem every
time we need to read a filename.
This is an annoyance, for sure ... However, in a sense we
(Apache-Test) have some control over this problem. In
another section we're looking for 'Apache', and then in
TestRun.pm we also look for 'apache'. So both get reported
as being present. However, on Win32, looking for 'apache' is
somewhat misleading, as the default installation (either
binary or source) results in 'Apache'. What about the
following:
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.138
diff -u -r1.138 TestRun.pm
--- lib/Apache/TestRun.pm 11 Jan 2004 15:25:12 - 1.138
+++ lib/Apache/TestRun.pm 13 Jan 2004 14:36:41 -
@@ -1343,11 +1343,13 @@
{
my %choices = ();
+my @tries = Apache::TestConfig::WIN32 ?
+qw(Apache httpd Apache2 httpd2) :
+qw(apache httpd apache2 httpd2);
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, $ENV{APACHE2}, map {which($_)} @tries) {
$choices{$_}++ if -e $_ -x _;
}
my $optional = 0;
--
best regards,
randy
Re: sticky preferences in Apache-Test
On Tue, 13 Jan 2004, Stas Bekman wrote: Geoffrey Young wrote: [ ... ] what I do know, however, is that my nightly builds start with 2.1 then move to 2.0, issuing 'make realclean' between each. for the past few nights, the 2.0 tests don't run because it's loading TestConfigData.pm from my global @INC. at that point, TestConfigData.pm is from the last install, which is a 2.1 install. this seems wrong to me - I have no remedy short of removing TestDataConfig.pm between builds - at I think it would affect users that upgrade as well. Are you sure that your not problem is elsewhere? I see this issue too though with non-mp2 build, just didn't have a chance to work on it yet. How do you build your mp2? It should ignore the custom config already, there must be some glitch. I haven't worked through this yet, but I find a similar problem ... I have two Perls, both of which have mp2 installed, but one has the CPAN Apache-Test and the other has the cvs Apache-Test installed. In building the cvs Apache-Test, I get the first-time dialogue with the perl with the CPAN Apache-Test installed, but don't get the dialogue with the perl with the cvs Apache-Test installed. I'm a bit baffled as to why, as this occurs even if I delete the system TestConfigData.pm. -- best regards, randy
Re: sticky preferences in Apache-Test
On Tue, 13 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: I haven't worked through this yet, but I find a similar problem ... I have two Perls, both of which have mp2 installed, but one has the CPAN Apache-Test and the other has the cvs Apache-Test installed. In building the cvs Apache-Test, I get the first-time dialogue with the perl with the CPAN Apache-Test installed, but don't get the dialogue with the perl with the cvs Apache-Test installed. I'm a bit baffled as to why, as this occurs even if I delete the system TestConfigData.pm. But CPAN A-T doesn't have this feature, so you must have installed mp2-cvs on top of it. Also check that you don't have ~/.apache-test/. I don't have an ~/.apache-test/, and yes, using the perl with the CPAN A-T installed to build the cvs A-T is fine. Where I run into problems in not seeing the configuration dialogue is using the perl with the cvs A-T installed in building the cvs A-T, even if I delete the installed TestConfigData.pm. -- best regards, randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sat, 10 Jan 2004, Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
randyk 2004/01/10 14:07:17
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestRun.pm
Log:
On Win32, multiple options for Apache.exe can be returned which differ
only by the case of the .exe extension or by the directory separator.
These changes bring things into line with what is returned from which().
[...]
1.136 +2 -2
httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm
Index: TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- TestRun.pm8 Jan 2004 04:54:06 - 1.135
+++ TestRun.pm10 Jan 2004 22:07:17 - 1.136
@@ -1346,8 +1346,8 @@
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir
bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('Apache'), which('httpd'),
+ $ENV{APACHE2}, which('Apache2'), which('httpd2')) {
$choices{$_}++ if -e $_ -x _;
}
my $optional = 0;
yes, but we need which('apache') too for unix. so please:
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('apache'), which('Apache'),
which('httpd'),
+ $ENV{APACHE2}, which('apache2'), which('Apache2'),
which('httpd2')) {
Sorry about that - I'll revert that change (I just tried,
but got an error message about insufficient space left on a
device). Actually, looking for both 'apache' and 'Apache'
leads back to the same problem on Win32 that, when the list
of Apache binaries is reported, both 'apache' and 'Apache'
are listed (with the same paths), so a different approach is
needed.
--
best regards,
randy
Re: rerunning original_command
On Sat, 10 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
Hi,
With the current Apache-Test cvs, after the initial
dialogue asking which Apache binary you want is completed,
the original command is rerun with the desired configuration
options. However, this original command is reproduced as
't/TEST ', and on Win32 't/TEST' isn't recognized as a
command. This diff
===
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.136
diff -u -r1.136 TestRun.pm
--- lib/Apache/TestRun.pm 10 Jan 2004 22:07:17 - 1.136
+++ lib/Apache/TestRun.pm 10 Jan 2004 22:26:57 -
@@ -630,7 +630,7 @@
# reconstruct argv, preserve multiwords args, eg 'PerlTrace all'
my $argv = join , map { /^-/ ? $_ : qq['$_'] } @ARGV;
-$original_command = $0 $argv;
+$original_command = $^X $0 $argv;
$orig_cwd = Cwd::cwd();
$self-set_ulimit;
$self-set_env; #make sure these are always set
=
prepends the Perl binary to this command, which can then
be run.
I'm wondering, though - might there be circumstances where
$original_command contains the Perl binary already?
I think it's pretty safe:
% perl -le 'print $0'
-e
'perl' is not in $0. Is it different on windows?
No, it's the same - I just wanted to be sure that the
Perl binary didn't creep in from somewhere else. Thanks.
--
best regards,
randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sun, 11 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: [ .. ] Sorry about that - I'll revert that change (I just tried, but got an error message about insufficient space left on a device). Actually, looking for both 'apache' and 'Apache' leads back to the same problem on Win32 that, when the list of Apache binaries is reported, both 'apache' and 'Apache' are listed (with the same paths), so a different approach is needed. So check that the path and lowercased filename match and exclude those on win32? Yes, that would work, but it looks a bit funny - for example, my Apache is D:\Apache2\bin\Apache.exe, which would get reported as d:\apache2\bin\apache.exe. If there isn't an easy way to preserve the case yet still remove such duplicates, I'll do that - it's not a big deal. -- best regards, randy
Re: win32_fetch_apxs in Apache-Test?
On Sun, 11 Jan 2004, Stas Bekman wrote: Yes, yes, what I was saying is that how the interactive config should know whether it's Apache 1 or Apache 2 that the user is after? or did you want to suggest it after user has specified the value for httpd and then if you figure out that it's for Apache2 and there is no apxs, you'd suggest to install it? I think that sounds like a working solution. Yes, the latter is what I was thinking - I'll make up something for that and pass it along. Thanks. -- best regards, randy
rerunning original_command
Hi,
With the current Apache-Test cvs, after the initial
dialogue asking which Apache binary you want is completed,
the original command is rerun with the desired configuration
options. However, this original command is reproduced as
't/TEST ', and on Win32 't/TEST' isn't recognized as a
command. This diff
===
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.136
diff -u -r1.136 TestRun.pm
--- lib/Apache/TestRun.pm 10 Jan 2004 22:07:17 - 1.136
+++ lib/Apache/TestRun.pm 10 Jan 2004 22:26:57 -
@@ -630,7 +630,7 @@
# reconstruct argv, preserve multiwords args, eg 'PerlTrace all'
my $argv = join , map { /^-/ ? $_ : qq['$_'] } @ARGV;
-$original_command = $0 $argv;
+$original_command = $^X $0 $argv;
$orig_cwd = Cwd::cwd();
$self-set_ulimit;
$self-set_env; #make sure these are always set
=
prepends the Perl binary to this command, which can then
be run.
I'm wondering, though - might there be circumstances where
$original_command contains the Perl binary already?
--
best regards,
randy
win32_fetch_apxs in Apache-Test?
Hi, The current Apache-Test cvs, as well as looking for an Apache binary, will also search for apxs, which doesn't come with Apache-2 on Win32. Within the mod_perl 2 distribution Makefile.PL will offer to run a script on Win32 to fetch and install an apxs - might it be an idea to do the same for Apache-Test, or perhaps within the perl-framework Makefile.PL? -- best regards, randy
Re: sticky preferences in Apache-Test
On Wed, 24 Sep 2003, Randy Kobes wrote:
Hi,
Below is a modified diff to allow for preferences
to be saved to an Apache::TestConfigData for later use
within Apache::Test. In this version, a user can create
a $HOME/.apache-test/Apache/TestConfigData.pm to specify
the preferences; this will be used, if it exists, before
a system Apache::TestConfigData. The diff is applied
against the cvs Apache-Test sources; as well, an
empty Apache-Test/lib/Apache/TestConfigData.pm file
should be created:
===
package Apache::TestConfigData;
use strict;
use warnings;
use vars qw($vars);
$vars = {
};
1;
=head1 NAME
Apache::TestConfigData - Configuration file for Apache::Test
=cut
The intent of how this is supposed to work is in the pod
of Apache::TestRun.
Sorry - I forgot to include the diff to Apache::TestUtil -
a complete diff appears below.
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.114
diff -u -r1.114 TestRun.pm
--- lib/Apache/TestRun.pm 12 Sep 2003 02:21:32 - 1.114
+++ lib/Apache/TestRun.pm 25 Sep 2003 06:25:56 -
@@ -10,20 +10,24 @@
use Apache::TestRequest ();
use Apache::TestHarness ();
use Apache::TestTrace;
+use Apache::TestUtil qw(expand_path);
+use Cwd;
use File::Find qw(finddepth);
-use File::Spec::Functions qw(catfile);
+use File::Spec::Functions qw(catfile catdir);
use Getopt::Long qw(GetOptions);
+use File::Basename qw(dirname);
use Config;
use constant STARTUP_TIMEOUT = 300; # secs (good for extreme debug cases)
+
use subs qw(exit_shell exit_perl);
my %core_files = ();
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose configure clean help ssl http11);
+my @others = qw(verbose configure clean help ssl http11 save);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order trace);
my @ostring_opts = qw(proxy ping);
@@ -55,9 +59,22 @@
'ssl' = 'run tests through ssl',
'proxy' = 'proxy requests (default proxy is localhost)',
'trace=T' = 'change tracing default to: warning, notice, info,
debug, ...',
+ 'save'= 'save test paramaters into Apache::TestConfigData',
(map { $_, \U$_\E url } @request_opts),
);
+# variables stored in $Apache::TestConfigData::vars
+my @data_vars = qw(httpd port user group apxs);
+# mapping from $Apache::TestConfigData::vars to $ENV settings
+my %vars_to_env = (httpd = 'APACHE',
+ user = 'APACHE_USER',
+ group = 'APACHE_GROUP',
+ apxs = 'APXS',
+ port = 'APACHE_PORT',
+ );
+my $IN_APACHE_TEST = in_apache_test();
+my $CONFIG_DATA = config_data();
+
sub fixup {
#make sure we use an absolute path to perl
#else Test::Harness uses the perl in our PATH
@@ -407,6 +424,8 @@
$test_config-cmodules_configure;
$test_config-generate_httpd_conf;
$test_config-save;
+$self-write_config() if
+($IN_APACHE_TEST or $self-{opts}-{save});
}
sub try_exit_opts {
@@ -509,6 +528,10 @@
sub new_test_config {
my $self = shift;
+for (@data_vars) {
+next unless $Apache::TestConfigData::vars-{$_};
+$self-{conf_opts}-{$_} ||= $Apache::TestConfigData::vars-{$_};
+}
Apache::TestConfig-new($self-{conf_opts});
}
@@ -953,6 +976,102 @@
CORE::exit $_[0];
}
+# Are we building things within Apache-Test?
+sub in_apache_test {
+my $cwd = expand_path(cwd);
+return ($cwd =~ m{Apache-Test}) ? 1 : 0;
+}
+
+# routine to determine where the configuration file
+# Apache::TestConfigData lives. The order searched is
+# 1) a path within Apache-Test, if we are building things there
+# 2) an $ENV{HOME}/.apache-test/ directory;
+# 3) somewhere in @INC, other than a path within Apache-Test.
+sub config_data {
+my $config;
+my $file = 'TestConfigData.pm';
+# XXX $ENV{HOME} isn't propagated in mod_perl
+unshift @INC, catdir($ENV{HOME}, '.apache-test') if $ENV{HOME};
+for (@INC) {
+my $candidate = catfile($_, 'Apache', $file);
+if (-e $candidate) {
+eval {require $candidate};
+next if $@;
+if (config_has_data()) {
+$config = $candidate;
+last;
+}
+}
+}
+unless ($IN_APACHE_TEST) {
+die 'Could not find a valid Apache::TestConfigData'
+unless config_has_data();
+}
+shift @INC if $ENV{HOME};
+# preferentially use environment variables
+for (@data_vars) {
+next unless my $value = $ENV{$vars_to_env{$_}};
+$Apache::TestConfigData
sticky preferences in Apache-Test
Hi,
Below is a modified diff to allow for preferences
to be saved to an Apache::TestConfigData for later use
within Apache::Test. In this version, a user can create
a $HOME/.apache-test/Apache/TestConfigData.pm to specify
the preferences; this will be used, if it exists, before
a system Apache::TestConfigData. The diff is applied
against the cvs Apache-Test sources; as well, an
empty Apache-Test/lib/Apache/TestConfigData.pm file
should be created:
===
package Apache::TestConfigData;
use strict;
use warnings;
use vars qw($vars);
$vars = {
};
1;
=head1 NAME
Apache::TestConfigData - Configuration file for Apache::Test
=cut
The intent of how this is supposed to work is in the pod
of Apache::TestRun.
===
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.114
diff -u -r1.114 TestRun.pm
--- lib/Apache/TestRun.pm 12 Sep 2003 02:21:32 - 1.114
+++ lib/Apache/TestRun.pm 24 Sep 2003 21:52:08 -
@@ -10,20 +10,24 @@
use Apache::TestRequest ();
use Apache::TestHarness ();
use Apache::TestTrace;
+use Apache::TestUtil qw(expand_path);
+use Cwd;
use File::Find qw(finddepth);
-use File::Spec::Functions qw(catfile);
+use File::Spec::Functions qw(catfile catdir);
use Getopt::Long qw(GetOptions);
+use File::Basename qw(dirname);
use Config;
use constant STARTUP_TIMEOUT = 300; # secs (good for extreme debug cases)
+
use subs qw(exit_shell exit_perl);
my %core_files = ();
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose configure clean help ssl http11);
+my @others = qw(verbose configure clean help ssl http11 save);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order trace);
my @ostring_opts = qw(proxy ping);
@@ -55,9 +59,22 @@
'ssl' = 'run tests through ssl',
'proxy' = 'proxy requests (default proxy is localhost)',
'trace=T' = 'change tracing default to: warning, notice, info,
debug, ...',
+ 'save'= 'save test paramaters into Apache::TestConfigData',
(map { $_, \U$_\E url } @request_opts),
);
+# variables stored in $Apache::TestConfigData::vars
+my @data_vars = qw(httpd port user group apxs);
+# mapping from $Apache::TestConfigData::vars to $ENV settings
+my %vars_to_env = (httpd = 'APACHE',
+ user = 'APACHE_USER',
+ group = 'APACHE_GROUP',
+ apxs = 'APXS',
+ port = 'APACHE_PORT',
+ );
+my $IN_APACHE_TEST = in_apache_test();
+my $CONFIG_DATA = config_data();
+
sub fixup {
#make sure we use an absolute path to perl
#else Test::Harness uses the perl in our PATH
@@ -407,6 +424,8 @@
$test_config-cmodules_configure;
$test_config-generate_httpd_conf;
$test_config-save;
+$self-write_config() if
+($IN_APACHE_TEST or $self-{opts}-{save});
}
sub try_exit_opts {
@@ -509,6 +528,10 @@
sub new_test_config {
my $self = shift;
+for (@data_vars) {
+next unless $Apache::TestConfigData::vars-{$_};
+$self-{conf_opts}-{$_} ||= $Apache::TestConfigData::vars-{$_};
+}
Apache::TestConfig-new($self-{conf_opts});
}
@@ -953,6 +976,102 @@
CORE::exit $_[0];
}
+# Are we building things within Apache-Test?
+sub in_apache_test {
+my $cwd = expand_path(cwd);
+return ($cwd =~ m{Apache-Test}) ? 1 : 0;
+}
+
+# routine to determine where the configuration file
+# Apache::TestConfigData lives. The order searched is
+# 1) a path within Apache-Test, if we are building things there
+# 2) an $ENV{HOME}/.apache-test/ directory;
+# 3) somewhere in @INC, other than a path within Apache-Test.
+sub config_data {
+my $config;
+my $file = 'TestConfigData.pm';
+# XXX $ENV{HOME} isn't propagated in mod_perl
+unshift @INC, catdir($ENV{HOME}, '.apache-test') if $ENV{HOME};
+for (@INC) {
+my $candidate = catfile($_, 'Apache', $file);
+if (-e $candidate) {
+eval {require $candidate};
+next if $@;
+if (config_has_data()) {
+$config = $candidate;
+last;
+}
+}
+}
+unless ($IN_APACHE_TEST) {
+die 'Could not find a valid Apache::TestConfigData'
+unless config_has_data();
+}
+shift @INC if $ENV{HOME};
+# preferentially use environment variables
+for (@data_vars) {
+next unless my $value = $ENV{$vars_to_env{$_}};
+$Apache::TestConfigData::vars-{$_} = $value;
+}
+
+return $config;
+}
+
+sub config_has_data {
+return ($Apache::TestConfigData::vars and
+
Re: need help to add per-user config to Apache::Test
On Sat, 6 Sep 2003, Stas Bekman wrote:
Randy Kobes wrote:
On Thu, 4 Sep 2003, Stas Bekman wrote:
In the effort to remove some of the Win32 noise, I was
thinking that we can write a generic function which gets a
path as an argument and figures out internally if it needs
to keep the argument as passed or mangle it. So it'll do
something like:
my $cwd = Apache::TestUtil::path(cwd);
probably need a more intuitive name for this function.
That'd be nice - a version that does this appears below.
I named it win32_long_path - it'll just return what was
passed into it if not on Win32.
But my idea was to eliminate any os-specific words win32. I think it should
just be long_path... Think of it as File::Spec function.
OK, I'll do that. I put in the win32_ to indicate that it'll
do something for Win32, and otherwise just return what was
passed in.
I'm still not quite happy about the naming of the function, what exactly
GetLongPathName($file) does?
can this be done using some File::Spec function?
I haven't found an equivalent one in File::Spec ... The
problem here is that cwd (or any file/directory name) on
Win32 has two representations - a long path name (that can
include spaces) and a short path name, limited to 6
characters (this is a holdout from early days), plus 3 if an
extension is present. Here we want to match cwd to
/Apache-Test/, but cwd may return the short path name (eg,
Apache~1.0), depending on if, for example, you have
different Apache-Test* directories at the same level. So
GetLongPathName can be used to get the full long path name.
The thing with naming it, eg, just long_path, is that
Unix users (the majority) wouldn't know what it does.
+require File::Spec;
+my $candidate = File::Spec-catfile($_, 'Apache', $file);
we import catfile in all other Apache::Test files, can do
that here as well... will make code simpler
Good point - thanks.
+if (-e $candidate) {
+$sys_config = $candidate;
+last;
+}
+}
+if ($sys_config) {
+eval {require $sys_config};
+return $sys_config if (not $@ and IN_APACHE_TEST);
+$sys_config = undef if $@;
+}
Hmm, I thought we agreed that eval {require $sys_config} will always succeed,
since that file is always available. so this code should be needed:
+ die 'Could not find a suitable Apache::TestConfigData'
+unless defined CONFIG_DATA;
I was thinking here if someone, after installation, had
mis-edited Apache::TestConfigData, either the system one or
one found in some path in @INC being added thru, eg, use
lib). But this might be overkill - not worrying about this
at this time will simplify things here.
One more problem is TestRun.pm's layout: subs should go
after the declarations (uses/constants/etc). use 'use
subs' if you need to predeclare them.
OK - thanks.
Another issue, is in_apache_test. Since a user may get it
with modperl-2.0 or separately it should return true in
either case.
I forgot about that - thanks.
+sub write_config {
+my $self = shift;
+my $fh = Symbol::gensym();
+my $vars = $self-{test_config}-{vars};
+my $conf_opts = $self-{conf_opts};
+my $file = IN_APACHE_TEST ?
+catfile($vars-{top_dir}, CONFIG_DATA) :
+CONFIG_DATA;
it's easier to parse when written as:
my $file = IN_APACHE_TEST
? catfile($vars-{top_dir}, CONFIG_DATA)
: CONFIG_DATA;
+my $pkg = EOC;
+package Apache::TestConfigData;
better have it strict, to avoid misterious errors (same in the pod below)
use strict;
use warnings;
use vars (\$Apache::TestConfigData);
Thanks - I'll add that.
I was also thinking about the problem of $ENV{HOME} not
being available in mod_perl. As Apache::TestConfigData is
being loaded in order to configure things, shouldn't
this not be a problem, because at this point one isn't
yet in a mod_perl environment?
--
best regards,
randy
Re: need help to add per-user config to Apache::Test
On Wed, 3 Sep 2003, Stas Bekman wrote:
Randy Kobes wrote:
On Tue, 2 Sep 2003, Stas Bekman wrote:
[ .. ]
It should work during 'make test' as well, since it already runs t/TEST
-config. And also whenever you provide any options to t/TEST it reconfigures,
so I believe the normal run will do the same:
t/TEST -save -httpd /usr/local/httpd/bin/httpd
I haven't tested that though.
I've checked that (with the diff below), and it seems to
work now as you say, both within Apache-Test and for a 3rd
party package. Without the -save the new -httpd is used,
but not saved into Apache::TestConfigData.
[ .. ]
Good idea - that's much simpler. The following assumes
that an empty Apache/TestConfigData.pm is present, and
then, as you say, 'make install' will pick up any changes
that have been made to it.
If I remember correctly 'make install' will complain about
the mismatch in sizes since 'make' has already put the
files into blib? Did it work for you just fine? Purhaps we
do need to update the two.
On linux, I tried installing Apache-Test, and then changing
the settings via
t/TEST -save -httpd /path/to/some/other/httpd
This wrote a new lib/Apache/TestConfigData.pm, and
make install
did recognize the change, copied it over to blib/, and
installed the new copy.
The diff below also includes a change to better get the
location of Apache::TestConfigData.
==
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.113
diff -u -r1.113 TestRun.pm
--- lib/Apache/TestRun.pm 22 Jul 2003 11:21:36 - 1.113
+++ lib/Apache/TestRun.pm 4 Sep 2003 21:02:44 -
@@ -11,19 +11,69 @@
use Apache::TestHarness ();
use Apache::TestTrace;
+use constant WIN32 = Apache::TestConfig::WIN32;
+require Win32 if WIN32;
+
+use Cwd;
+# Are we building things within Apache-Test?
+sub in_apache_test {
+my $cwd = WIN32 ? Win32::GetLongPathName(cwd) : cwd;
+return ($cwd =~ m{Apache-Test}) ? 1 : 0;
+}
+use constant IN_APACHE_TEST = in_apache_test();
+
+require File::Spec;
+# routine to determine where the configuration file
+# Apache::TestConfigData lives. The order searched is
+# 1) a path within Apache-Test, if we are building things there
+# 2) an $ENV{HOME}/.apache-test/ directory;
+# 3) somewhere in @INC, other than a path within Apache-Test.
+sub config_data {
+my $sys_config;
+my $file = 'TestConfigData.pm';
+for (@INC) {
+ my $candidate = File::Spec-catfile($_, 'Apache', $file);
+ if (-e $candidate) {
+ $sys_config = $candidate;
+ last;
+ }
+}
+if ($sys_config) {
+ eval {require $sys_config};
+ return $sys_config if (not $@ and IN_APACHE_TEST);
+ $sys_config = undef if $@;
+}
+# XXX $ENV{HOME} isn't propagated in mod_perl
+if ($ENV{HOME}) {
+ my $priv_config = File::Spec-catfile($ENV{HOME},
+ '.apache-test',
+ $file);
+eval {require $priv_config};
+ return $priv_config unless $@;
+}
+return $sys_config ? $sys_config : undef;
+}
+
+use constant CONFIG_DATA = config_data();
+
use File::Find qw(finddepth);
-use File::Spec::Functions qw(catfile);
+use File::Spec::Functions qw(catfile catdir);
use Getopt::Long qw(GetOptions);
+use File::Basename;
use Config;
+use Symbol;
use constant STARTUP_TIMEOUT = 300; # secs (good for extreme debug cases)
use subs qw(exit_shell exit_perl);
+die 'Could not find a suitable Apache::TestConfigData'
+unless defined CONFIG_DATA;
+
my %core_files = ();
my %original_t_perms = ();
my @std_run = qw(start-httpd run-tests stop-httpd);
-my @others = qw(verbose configure clean help ssl http11);
+my @others = qw(verbose configure clean help ssl http11 save);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order trace);
my @ostring_opts = qw(proxy ping);
@@ -55,6 +105,7 @@
'ssl' = 'run tests through ssl',
'proxy' = 'proxy requests (default proxy is localhost)',
'trace=T' = 'change tracing default to: warning, notice, info,
debug, ...',
+ 'save'= 'save test paramaters into Apache::TestConfigData',
(map { $_, \U$_\E url } @request_opts),
);
@@ -407,6 +458,8 @@
$test_config-cmodules_configure;
$test_config-generate_httpd_conf;
$test_config-save;
+$self-write_config() if
+(not %{$Apache::TestConfigData} or $self-{opts}-{save});
}
sub try_exit_opts {
@@ -509,6 +562,10 @@
sub new_test_config {
my $self = shift;
+for (qw(httpd port user group apxs)) {
+next unless $Apache::TestConfigData-{$_};
+$self-{conf_opts}-{$_} ||= $Apache::TestConfigData-{$_};
+}
Apache::TestConfig-new($self-{conf_opts
