Re: Workaround (maybe) for getting Apache::Test 1.13 tested on a stock OpenBSD system
When I unpack the tarball by hand, set APACHE_TEST_HTTPD=/usr/sbin/httpdu, and run perl Makefile.PL; make; make test, everything passes. This is true whether or not I am executing the commands as root. How can we programmatically figure out when to add the -u flag? If we can't then we can add APACHE_TEST_HTTPD_OPTIONS env var, which you can set to -u. we already have APACHE_TEST_EXTRA_ARGS which will do this :) --Geoff
Re: Workaround (maybe) for getting Apache::Test 1.13 tested on a stock OpenBSD system
Geoffrey Young wrote: When I unpack the tarball by hand, set APACHE_TEST_HTTPD=/usr/sbin/httpdu, and run perl Makefile.PL; make; make test, everything passes. This is true whether or not I am executing the commands as root. How can we programmatically figure out when to add the -u flag? If we can't then we can add APACHE_TEST_HTTPD_OPTIONS env var, which you can set to -u. we already have APACHE_TEST_EXTRA_ARGS which will do this :) rats... sorry, APACHE_TEST_EXTRA_ARGS is for A-T, not invoking httpd. eesh :) while it doesn't solve problems for anyone running A-T for the first time (such as when installing via CPAN), +1 to supporting this option as well, just in case people find it useful. time to shutdown the computer for the weekend... --Geoff
Workaround (maybe) for getting Apache::Test 1.13 tested on a stock OpenBSD system
There was a message sent to this list on June 29, reporting that Apache::Test failed make test on an i386 OpenBSD 3.5 machine. I got the same result on a G4 running OpenBSD 3.5. The error log is: [quote] # cat t/logs/error_log [Fri Sep 24 12:56:40 2004] [notice] Initializing etag from /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/logs/etag-state [Fri Sep 24 12:56:40 2004] [crit] (1)Operation not permitted: could not chown /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/logs/etag-state [unquote] The version of Apache that is distributed with OpenBSD will chroot to the ServerRoot by default. To run httpd in unsecure mode, you need to pass it the -u command-line switch. I suspected that Apache::Test was failing because it didn't pass that switch on to Apache, so I tried creating a /usr/sbin/httpdu file, with the same ownership and permissions as /usr/sbin/httpd, that said this: [quote] #!/bin/sh exec /usr/sbin/httpd -u $@ [unquote] When I unpack the tarball by hand, set APACHE_TEST_HTTPD=/usr/sbin/httpdu, and run perl Makefile.PL; make; make test, everything passes. This is true whether or not I am executing the commands as root. But when I try installing the module through the CPANPLUS shell with the same environment variable setting, I get this: [quote] waiting 60 seconds for server to start: . waiting 60 seconds for server to start: ok (waited 0 secs) server localhost.ropine.com:8529 started still waiting for server to warm up: . the server is down, giving up after 61 secs +-+ | To report problems please refer to the SUPPORT file | +-+ [ error] failed to start server! (please examine t/logs/error_log) *** Error code 1 [unquote] ...with nothing appended to t/logs/error_log that might indicate the source of this problem. I'm not sure whether or not the modules that depend on Apache::Test for their own testing will still be able to run with this workaround. Even if they can, I would appreciate a patch that will allow Apache::Test to insert the -u option when it starts up the server, so I don't have to rely on this weirdness. (Or is there some easier solution to the problem that I missed?) adTHANKSvance, -- Remember that freedom is not just a word. It is a squishy, concept-lite word which invokes positive feelings. --Fafblog // seth gordon // [EMAIL PROTECTED] // http://dynamic.ropine.com/yo/ //
Re: Workaround (maybe) for getting Apache::Test 1.13 tested on a stock OpenBSD system
Seth Gordon wrote: There was a message sent to this list on June 29, reporting that Apache::Test failed make test on an i386 OpenBSD 3.5 machine. I got the same result on a G4 running OpenBSD 3.5. The error log is: [quote] # cat t/logs/error_log [Fri Sep 24 12:56:40 2004] [notice] Initializing etag from /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/logs/etag-state [Fri Sep 24 12:56:40 2004] [crit] (1)Operation not permitted: could not chown /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/logs/etag-state [unquote] The version of Apache that is distributed with OpenBSD will chroot to the ServerRoot by default. To run httpd in unsecure mode, you need to pass it the -u command-line switch. I suspected that Apache::Test was failing because it didn't pass that switch on to Apache, so I tried creating a /usr/sbin/httpdu file, with the same ownership and permissions as /usr/sbin/httpd, that said this: [quote] #!/bin/sh exec /usr/sbin/httpd -u $@ [unquote] When I unpack the tarball by hand, set APACHE_TEST_HTTPD=/usr/sbin/httpdu, and run perl Makefile.PL; make; make test, everything passes. This is true whether or not I am executing the commands as root. How can we programmatically figure out when to add the -u flag? If we can't then we can add APACHE_TEST_HTTPD_OPTIONS env var, which you can set to -u. But when I try installing the module through the CPANPLUS shell with the same environment variable setting, I get this: [quote] waiting 60 seconds for server to start: . waiting 60 seconds for server to start: ok (waited 0 secs) server localhost.ropine.com:8529 started still waiting for server to warm up: . the server is down, giving up after 61 secs +-+ | To report problems please refer to the SUPPORT file | +-+ [ error] failed to start server! (please examine t/logs/error_log) *** Error code 1 [unquote] ...with nothing appended to t/logs/error_log that might indicate the source of this problem. Try to run the program under strace or its equivalent, ans see what's going wrong. I'm not sure whether or not the modules that depend on Apache::Test for their own testing will still be able to run with this workaround. Even if they can, I would appreciate a patch that will allow Apache::Test to insert the -u option when it starts up the server, so I don't have to rely on this weirdness. (Or is there some easier solution to the problem that I missed?) You are the first one to ever mention this problem, so please help us to solve it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
