Re: New to Apache
Thanks a lot Marion, II would really appreciate if you could pass on the beginners bug list. On Friday, January 23, 2015, Marion Christophe JAILLET christophe.jail...@wanadoo.fr wrote: Hi, if you don't have any idea yet on what you would like to work on, maybe a good start is to go thrue our bugzilla. Look at subjects you understand or that seem easy. If a patch is already proposed you can try and test it, then report any feedback. If no patch is available, you can propose one yourself. I can give you a list a easy looking subject I have spotted in bugzilla if you wish. Any proposal on memory reduction usage is also welcome. CJ tmaybe Le 23/01/2015 00:31, Paawan Mukker a écrit : Hi everyone I'm new to open source development and Apache and I wanted to contribute to it. Can anyone get me started. PS - I've already had looked on the stuff on the website.
New to Apache
Hi everyone I'm new to open source development and Apache and I wanted to contribute to it. Can anyone get me started. PS - I've already had looked on the stuff on the website.
Re: New to Apache
Hi, if you don't have any idea yet on what you would like to work on, maybe a good start is to go thrue our bugzilla. Look at subjects you understand or that seem easy. If a patch is already proposed you can try and test it, then report any feedback. If no patch is available, you can propose one yourself. I can give you a list a easy looking subject I have spotted in bugzilla if you wish. Any proposal on memory reduction usage is also welcome. CJ tmaybe Le 23/01/2015 00:31, Paawan Mukker a écrit : Hi everyone I'm new to open source development and Apache and I wanted to contribute to it. Can anyone get me started. PS - I've already had looked on the stuff on the website.
new in Apache::Test: t/SMOKE -bug_mode
It all started when I have noticed a few core files after running t/SMOKE on modperl-2.0's top-level test suite. I couldn't figure out which test caused them. So I have decided to rewrite the smoker to provide me that information. In the future we might autoextract the backtrace as well. While working on it, I said, we also have a problem of mapping error_log errors to the tests that caused them. So I've added logic to extract only the relevant (added since the last successful test) part of error_log and access_log and print it out, in addition to the output of the client. This mode also turns the tracing level to -trace=debug, so if the test fails and there were any debug printings in the handlers they will be run as well. This should make bug reports much more useful. However it comes at a price of running much slower than the normal 'make test' would do, until Test::Harness::Straps won't provide the callbacks to be run after each test, eventually we might fold it back to 'make test'. but for now if your 'make test' fails, run 't/SMOKE -bug_report'. Of course the normal t/SMOKE run now reports core files as well, as soon as they happen. You will need to update the current modperl-2.0 cvs to get this functionality. Please report any problems that you may have noticed. So here is how the new log will look: /home/stas/apache.org/portland3 t/SMOKE -bug_mode running t/TEST in the bug report mode apache/add_configok apache/cgihandlerok apache/conftree..ok apache/constants.ok apache/cookieFAILED *** run log *** *** setting ulimit to allow core files ulimit -c unlimited; ./TEST -verbose -run 'apache/cookie.t' apache/cookie1..2 # Running under perl version 5.008001 for linux # Current time local: Thu Sep 11 18:45:28 2003 # Current time GMT: Fri Sep 12 01:45:28 2003 # Using Test.pm version 1.24 request has failed (the response code was: 500) see t/logs/error_log for more details dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-2 Failed 2/2 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- apache/cookie.t 255 65280 24 200.00% 1-2 !!! error running tests (please examine t/logs/error_log) *** /home/stas/apache.org/portland3/t/logs/error_log *** [Thu Sep 11 18:45:28 2003] [error] [client 127.0.0.1] I shouldn't get the cookie at /home/stas/apache.org/portland3/t/response/TestApache/cookie.pm line 16. *** /home/stas/apache.org/portland3/t/logs/access_log *** 127.0.0.1 - - [11/Sep/2003:18:45:28 -0700] GET /TestApache__cookie?header HTTP/1.0 500 536 apache/cookie2...ok apache/post..ok apache/read..FAILED *** run log *** *** setting ulimit to allow core files ulimit -c unlimited; ./TEST -verbose -run 'apache/read.t' apache/readBareword asdfag not allowed while strict subs in use at apache/read.t line 18. Execution of apache/read.t aborted due to compilation errors. dubious Test returned status 255 (wstat 65280, 0xff00) !!! error running tests (please examine t/logs/error_log) apache/scanhdrs..ok apache/scanhdrs2.ok apache/send_cgi_header...ok apache/subprocessok apache/write.FAILED *** run log *** *** setting ulimit to allow core files ulimit -c unlimited; ./TEST -verbose -run 'apache/write.t' apache/writerequest has failed (the response code was: 500) see t/logs/error_log for more details dubious Test returned status 255 (wstat 65280, 0xff00) !!! error running tests (please examine t/logs/error_log) !!! oh nuts, server dumped core !!! for stacktrace, run: gdb /home/stas/httpd/prefork/bin/httpd -core /home/stas/apache.org/portland3/t/core.7604 *** /home/stas/apache.org/portland3/t/logs/error_log *** [Thu Sep 11 18:46:03 2003] [notice] child pid 7604 exit signal Aborted (6), possible coredump in /home/stas/apache.org/portland3/t api/access...ok api/aplogok api/conn_rec.ok api/lookup_uri...ok api/lookup_uri2..ok api/module...ok api/r_subclass...ok api/request_rec..ok api/response.ok api/rflush...ok
Re: new in Apache::Test: t/SMOKE -bug_mode
Rafael Garcia-Suarez wrote: Stas Bekman wrote: It all started when I have noticed a few core files after running t/SMOKE on modperl-2.0's top-level test suite. I couldn't figure out which test caused them. So I have decided to rewrite the smoker to provide me that information. In the future we might autoextract the backtrace as well. Neat. (autoextracting the backtrace automatically is easily done with gdb -x where available.) I didn't know about this option. It doesn't seem to exist on gdb/linux (I have the very latest one 5.3-22mdk). There is also a very old Devel::CoreStack, which doesn't quite work if the gdb takes more than one TTY screen to get to the trace. I couldn't figure out how to circumvent the 'next page' prompt. Instead I wrote (Debug::FaultAutoBT) http://search.cpan.org/search?query=Debug%3A%3AFaultAutoBTmode=module, which traps segfaults and gets the backtrace without needed a core file. However it requires more work as it doesn't always work. It's modeled after the KDE bug-report utility, which pops a bug report window when some KDE-app crashes and shows you the backtrace immediately. This should make bug reports much more useful. However it comes at a price of running much slower than the normal 'make test' would do, until Test::Harness::Straps won't provide the callbacks to be run after each test, Just in case you don't know this already, the latest Test::Harness contains an experimental -- and undocumented -- form of callbacks. If you could post something to perl-qa to explain in a few sentences what you need, I'd be happy to help crafting something. And to reuse it for perl :) That's exactly why I have mentioned Test::Harness::Straps, I have submitted a request for the callback feature, and that's when Andy Lester has mentioned the experimental feature in Test::Harness::Straps. All needed is the ability to install a hook to be run after each test is finished (and purhaps before it). Then one can add various useful procedures to happen between each test (e.g. core file finder). __ 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
Re: new in Apache::Test: t/SMOKE -bug_mode
Stas Bekman wrote: It all started when I have noticed a few core files after running t/SMOKE on modperl-2.0's top-level test suite. I couldn't figure out which test caused them. So I have decided to rewrite the smoker to provide me that information. In the future we might autoextract the backtrace as well. Neat. (autoextracting the backtrace automatically is easily done with gdb -x where available.) This should make bug reports much more useful. However it comes at a price of running much slower than the normal 'make test' would do, until Test::Harness::Straps won't provide the callbacks to be run after each test, Just in case you don't know this already, the latest Test::Harness contains an experimental -- and undocumented -- form of callbacks. If you could post something to perl-qa to explain in a few sentences what you need, I'd be happy to help crafting something. And to reuse it for perl :)
Re: new in Apache::Test: t/SMOKE -bug_mode
Stas Bekman wrote: It all started when I have noticed a few core files after running t/SMOKE on modperl-2.0's top-level test suite. I couldn't figure out which test caused them. So I have decided to rewrite the smoker to provide me that information. In the future we might autoextract the backtrace as well. Neat. (autoextracting the backtrace automatically is easily done with gdb -x where available.) This should make bug reports much more useful. However it comes at a price of running much slower than the normal 'make test' would do, until Test::Harness::Straps won't provide the callbacks to be run after each test, Just in case you don't know this already, the latest Test::Harness contains an experimental -- and undocumented -- form of callbacks. If you could post something to perl-qa to explain in a few sentences what you need, I'd be happy to help crafting something. And to reuse it for perl :)
Re: new in Apache::Test: t/SMOKE -bug_mode
Rafael Garcia-Suarez wrote: Stas Bekman wrote: It all started when I have noticed a few core files after running t/SMOKE on modperl-2.0's top-level test suite. I couldn't figure out which test caused them. So I have decided to rewrite the smoker to provide me that information. In the future we might autoextract the backtrace as well. Neat. (autoextracting the backtrace automatically is easily done with gdb -x where available.) I didn't know about this option. It doesn't seem to exist on gdb/linux (I have the very latest one 5.3-22mdk). There is also a very old Devel::CoreStack, which doesn't quite work if the gdb takes more than one TTY screen to get to the trace. I couldn't figure out how to circumvent the 'next page' prompt. Instead I wrote (Debug::FaultAutoBT) http://search.cpan.org/search?query=Debug%3A%3AFaultAutoBTmode=module, which traps segfaults and gets the backtrace without needed a core file. However it requires more work as it doesn't always work. It's modeled after the KDE bug-report utility, which pops a bug report window when some KDE-app crashes and shows you the backtrace immediately. This should make bug reports much more useful. However it comes at a price of running much slower than the normal 'make test' would do, until Test::Harness::Straps won't provide the callbacks to be run after each test, Just in case you don't know this already, the latest Test::Harness contains an experimental -- and undocumented -- form of callbacks. If you could post something to perl-qa to explain in a few sentences what you need, I'd be happy to help crafting something. And to reuse it for perl :) That's exactly why I have mentioned Test::Harness::Straps, I have submitted a request for the callback feature, and that's when Andy Lester has mentioned the experimental feature in Test::Harness::Straps. All needed is the ability to install a hook to be run after each test is finished (and purhaps before it). Then one can add various useful procedures to happen between each test (e.g. core file finder). __ 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
Re: [Mason] Can't locate object method new viapackage Apache::Request
On Mon, 2003-08-25 at 13:13, Stas Bekman wrote: K Old wrote: On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: On Sun, 24 Aug 2003, K Old wrote: Hello everyone, I've put HTML::Mason on a few servers now and have had problems with Apache::Request and Apache::Test on two of them. My most recent is having the problem and I'm about to go crazy if I don't figure out why installs keep having problems. Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all installed from RPM's. I did a install HTML::Mason from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. [ .. ] Regarding the failure of the tests in these two packages, what happens if you unpack, build, and test these as a non-root user, only becoming root to install them? There's some subtelties running the tests as root. Randy, Ok, yes, this worked...to a point! I pulled down fresh copies of the modules from CPAN, unpacked, build and tested with another user. All tests were successful with Apache::Test with the normal user, but I had to go to root for the tests for libapreq1.2 as my webserver needed the root user to start FrontPage services. Doing the make test for libapreq-1.2 all test fail and I get this in the t/logs/error_log: [Mon Aug 25 08:49:12 2003] [error] Can't load '/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 Compilation failed in require at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. BEGIN failed--compilation aborted at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. Compilation failed in require at (eval 4) line 3. That's a known linking problem. It has been fixed in the cvs, get the cvs instructions from http://httpd.apache.org/apreq/. Joe, may be a new 1.x version should be released? Stas, I've downloaded the CVS, unpacked, built and tested with a not root user, and still received the same errors as before. Here's the syntax I'm using for build, etc: (CVS version) perl Makefile.PL make make test (Module from CPAN) perl Makefile.PL make make test then ./configure --with-apache-includes=/usr/include/apache make make install perl Makefile.PL make make test Is there anything I'm not doing right? I've tried to disable the FrontPage stuff so that the non root user should be able to start apache without the errors, but either by root or non root user I get the same error messages regarding Cookie.so and so forth. Any ideas? Thanks, Kevin -- K Old [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
