This will be of interest to the resident Gentoo mod_perl experts. The ebuild for mod_perl-1.99.08 has "make test" commented out. I believe this stems from the fact that the tests never ran properly. apache would start up but would find unknown directives in the test config file and then quit rapidly. I traced that to: a) the mod_perl test source used for configuration could never find the system-wide /etc/apache2/conf/apache2.conf to inherit from b) therefore, all the standard DSO modules were absent from the test httpd.conf file, hence making it impossible for apache to run. Hence total test failure. Well, I have made some progress in this regard. With the patch mod_perl-1.99-gentoo-enable-make-test.diff the test configuration is able to grab the correct apache2.conf file and hence "does the right thing". After applying the patch, followed by a "perl Makefile.PL (rest of the params from the .ebuild)" "make" and "make test" I get 100% test passing average with mod_perl-1.99_08.tar.gz sources. Here's the modified .ebuild diff (added epatch line and uncommented make test): --- /usr/portage/dev-perl/mod_perl/mod_perl-1.99.08.ebuild 2003-04-25 12:08:24.000000000 -0400 +++ ./mod_perl-1.99.08.ebuild 2003-04-25 12:09:31.000000000 -0400 @@ -15,6 +15,7 @@ SLOT="1" src_compile() { + epatch ${FILESDIR}/mod_perl-1.99-gentoo-enable-make-test.diff perl Makefile.PL \ PREFIX=${D}/usr \ MP_TRACE=1 \ @@ -27,7 +28,7 @@ INSTALLDIRS=vendor </dev/null || die emake || die - #make test + make test } src_install() { The only problem is that when I use portage to do these steps apache does start up during the tests but I get all kinds of failures while running the actual tests. This is where I need someone expert in portage and familiar with mod_perl. If I build mod_perl manually by extracting the sources, applying the patch, issuing perl Makefile, make and make test, I get 100% passed tests. So, what's so different about portage doing the build, versus me doing the build manually. Ideas? On another note, I have been in touch with Stas Bekman (one of the lead developers of mod_perl) and he expressed lots of indignation at the presence of the CCFLAGS="${CFLAGS} -fPIC" line in the .ebuild. According to him, it wasn't necessary. Anyone care to comment on that?
Created attachment 11133 [details, diff] Enable make test
I have been in touch with Stas Bekman again. He came up with a minimalist patch which solves the Gentoo "make test" problem as follows: Index: ./Apache-Test/lib/Apache/TestConfigParse.pm =================================================================== RCS file: /home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestC onfigParse.pm,v retrieving revision 1.32 diff -u -r1.32 TestConfigParse.pm --- ./Apache-Test/lib/Apache/TestConfigParse.pm 23 Apr 2003 02:24:16 -0000 1.32 +++ ./Apache-Test/lib/Apache/TestConfigParse.pm 25 Apr 2003 16:03:20 -0000 @@ -225,6 +225,8 @@ my $default_conf = $self->{httpd_defines}->{SERVER_CONFIG_FILE}; $default_conf ||= catfile qw(conf httpd.conf); $file = catfile $base, $default_conf; + # SERVER_CONFIG_FILE might be an absolute path + $file = $default_conf if !-e $file and -e $default_conf; } } To summarize again, the above patch in the mod_perl sources combined with the patch for the ebuild, allows the make test to proceed further. apache does come up but all the tests don't run properly. This is probably something to do with portage since if I patch the file manually and issue "perl Makefile.PL...." and "make" and "make test" manually, I get a 100% success rate.
Thanks for your work on this. Do I understand correctly that the second patch to TestConfigParse.pm obsoletes the first one? Also, if you talk with Stas Bekman again, could you please find out (a) what is so problematic about enabling PIC? (b) is it possible that this might be necessary on some CPU architectures?
Hi there, You are understood correctly that the second patch obviates the first one. Secondly, I am not too clued in on the -fPIC issue. We have had no reported problems related to the use of this flag. I would say use your best judgement. If interested, you can follow the e-mail thread between myself and Stas at: http://mathforum.org/epigone/modperl/phingronhal and especially the e-mail at: http://mathforum.org/epigone/modperl/phingronhal/3EA727AE.5020009@stason.org Thirdly, mod_perl-1.99_09.tar.gz is out. I will be testing with that as well.
So, I tested with mod_perl-1.99_09. The above-mentioned patches are already included so no need to patch. Just enable "make tests" in the ebuild. 100% success on tests when compiling manually. However, while building under portage, I get lots of skipped tests and failures. First error from /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/t/logs/error_log is as follows: [Mon Apr 28 10:02:38 2003] [error] failed to resolve handler `TestHooks::trans' [Mon Apr 28 10:02:38 2003] [error] [client 127.0.0.1] Can't locate TestHooks/tra ns.pm in @INC (@INC contains: Apache-Test/lib /var/tmp/portage/mod_perl-1.99.09/ work/mod_perl-1.99_09/blib/lib/Apache2 /var/tmp/portage/mod_perl-1.99.09/work/mo d_perl-1.99_09/blib/arch/Apache2 /usr/lib/perl5/vendor_perl/5.8.0/i686-linux/Apa che2 /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/Apache-Test/lib /va r/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/lib /var/tmp/portage/mod_pe rl-1.99.09/work/mod_perl-1.99_09/blib/lib /var/tmp/portage/mod_perl-1.99.09/work /mod_perl-1.99_09/blib/arch /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99 _09/t/response /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/t/protoco l /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/t/preconnection /var/t mp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/t/hooks /var/tmp/portage/mod_p erl-1.99.09/work/mod_perl-1.99_09/t/filter /var/tmp/portage/mod_perl-1.99.09/wor k/mod_perl-1.99_09/t /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/t/h tdocs/testdirective/perlmodule-vh /var/tmp/portage/mod_perl-1.99.09/work/mod_per l-1.99_09/t/htdocs/testdirective/main /usr/lib/perl5/5.8.0/i686-linux /usr/lib/p erl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i686-linux /usr/lib/perl5/site_perl/5. 8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i686-linux /usr/li b/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /var/tmp/portage/mod_perl-1 .99.09/work/mod_perl-1.99_09/t/ /var/tmp/portage/mod_perl-1.99.09/work/mod_perl- 1.99_09/t/lib/perl) at (eval 66) line 3. Lots of repeated lines like: [Mon Apr 28 10:02:39 2003] [error] failed to resolve handler `TestHooks::trans' Should I create another bug report for 1.99.09 or are we going to deal with 1.99.09 here?
Maybe should start a new bug for .09 - I tried it (change a couple of lines to: NEWPV=$(echo $PV | perl -pe 's/\.([^.]+)$/_\1/') NEWP="${PN}-${NEWPV}" ...to make it work after renaming the ebuild), but I got sandbox violations, so it can't go in the tree yet.
The ebuild for .09 works fine for me. Still stuck during the make test where a lot of the tests are failing for me under portage and passing 100% when done manually. I created bug 20124 for the .09 ebuild.
Phew... what a relief. All tests successful 100%. The catch is that I had to: chown -R nobody:nobody /var/tmp/portage/mod_perl-1.99.09/work As it was, the test configuration specifies absolute paths which are not readable by the user nobody, hence the tests don't get run properly. Just for your curiousity, here's my emerge --info which might help you decide what to do with this issue (I hope the linebreaks don't extend the lines as they used to in Bugzilla a little while ago): Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.2-r1) ================================================================= System uname: 2.4.20-gentoo-r1 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /var/bind /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/portage.local" USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gtkhtml alsa gdbm berkdb slang readline arts tetex bonobo svga tcltk java guile mysql postgres X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla cdr xfs gtk2 apache2" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe -s -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -ffast-math" CXXFLAGS="-O2 -mcpu=i686 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
I see what you mean about the sandbox violations. I added a chown -R nobody.nobody ${WORKDIR} right before the make test in the .ebuild file. The emerge process was going about its business and passed all of the tests 100%. Then while installing into the image directory, I got: cp xs/modperl_xs_sv_convert.h xs/modperl_xs_typedefs.h xs/modperl_xs_util.h /usr/include/apache2 ACCESS DENIED open_wr: /usr/include/apache2/modperl_xs_sv_convert.h cp: cannot create regular file `/usr/include/apache2/modperl_xs_sv_convert.h': Permission denied ACCESS DENIED open_wr: /usr/include/apache2/modperl_xs_typedefs.h cp: cannot create regular file `/usr/include/apache2/modperl_xs_typedefs.h': Permission denied ACCESS DENIED open_wr: /usr/include/apache2/modperl_xs_util.h cp: cannot create regular file `/usr/include/apache2/modperl_xs_util.h': Permission denied make: *** [modperl_xs_h_install] Error 1 !!! ERROR: dev-perl/mod_perl-1.99.09 failed. !!! Function src_install, Line 40, Exitcode 2 !!! (no error message) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-mod_perl-1.99.09-22963.log" open_wr: /usr/include/apache2/modperl_xs_sv_convert.h open_wr: /usr/include/apache2/modperl_xs_typedefs.h open_wr: /usr/include/apache2/modperl_xs_util.h -------------------------------------------------------------------------------- The Changes file mentions: 'make install' now installs mod_perl*h files under httpd's include tree [Stas] I think the ebuild has to be modified to install the *.h files under images/usr/include/apache2 rather than trying to write directly to /usr/include/apache2. Something to investigate further. This is getting out of my comfort zone as the problems are more and more related to permissions and/or portage. Thanks for helping out.
ebuild mod_perl-1.99.09.ebuild unpack ebuild mod_perl-1.99.09.ebuild compile work fine. ebuild mod_perl-1.99.09.ebuild install gives the sandbox access violation.
Good news. "ebuild mod_perl-1.99.09.ebuild install" and "ebuild mod_perl-1.99.09.ebuild qmerge" is now working fine without sandbox violations. Here's a diff between the old .08 ebuild and the .09 ebuild: --- mod_perl-1.99.08.ebuild 2003-03-11 16:20:59.000000000 -0500 +++ /usr/portage.local/dev-perl/mod_perl/mod_perl-1.99.09.ebuild 2003-04-29 10:34:27.000000000 -0400 @@ -5,7 +5,8 @@ DESCRIPTION="An embedded Perl interpreter for Apache2" HOMEPAGE="http://perl.apache.org/" -NEWP="${PN}-1.99_08" +NEWPV=$(echo $PV | perl -pe 's/\.([^.]+)$/_\1/') +NEWP="${PN}-${NEWPV}" S=${WORKDIR}/${NEWP} SRC_URI="http://perl.apache.org/dist/${NEWP}.tar.gz" DEPEND="dev-lang/perl =net-www/apache-2*" @@ -27,13 +28,15 @@ INSTALLDIRS=vendor </dev/null || die emake || die - #make test + chown -R nobody.nobody ${WORKDIR} + make test } src_install() { dodir /usr/lib/apache2-extramodules make install \ MODPERL_AP_LIBEXECDIR=${D}/usr/lib/apache2-extramodules \ + MODPERL_AP_INCLUDEDIR=${D}/usr/include/apache2 \ MP_INST_APACHE2=1 \ INSTALLDIRS=vendor || die After making sure everything worked properly, I did a regular "emerge mod_perl" and it installed .09 and unmerged .08. Website seems to be holding up fine. It is a DBI driven website so at least the connection to the database is working fine.
I'm still getting sandbox errors and failures on the CGI tests. Something is trying to open a socket in /var/run and make CGI temporary files in /usr/tmp. So it's close, but I still can't enable "make test". We'll keep at it. Thanks again for your effort. Better news in bug 20124.
The following ebuild diff should fix all of the sandbox violations. Dare I say, its ready to go?? (into the tree, at least?) --- /usr/portage/dev-perl/mod_perl/mod_perl-1.99.08.ebuild 2003-03-11 16:20:59.000000000 -0500 +++ mod_perl-1.99.09.ebuild 2003-04-30 14:31:21.000000000 -0400 @@ -5,7 +5,8 @@ DESCRIPTION="An embedded Perl interpreter for Apache2" HOMEPAGE="http://perl.apache.org/" -NEWP="${PN}-1.99_08" +NEWPV=$(echo $PV | perl -pe 's/\.([^.]+)$/_\1/') +NEWP="${PN}-${NEWPV}" S=${WORKDIR}/${NEWP} SRC_URI="http://perl.apache.org/dist/${NEWP}.tar.gz" DEPEND="dev-lang/perl =net-www/apache-2*" @@ -27,13 +28,32 @@ INSTALLDIRS=vendor </dev/null || die emake || die - #make test + if has userpriv $FEATURES; then + # make backups before we take care of some sandbox violations + cp ${S}/t/conf/extra.conf.in \ + ${S}/t/conf/extra.conf.in.orig + cp ${S}/ModPerl-Registry/t/conf/extra.conf.in \ + ${S}/ModPerl-Registry/t/conf/extra.conf.in.orig + # tell mod_cgid to make the socket here instead of + # /var/run/cgisock + echo "ScriptSock logs/cgisock" >> \ + ${S}/t/conf/extra.conf.in + echo "ScriptSock logs/cgisock" >> \ + ${S}/ModPerl-Registry/t/conf/extra.conf.in + # tell CGI.pm to create new tmpfiles in this directory + echo "SetEnv TMPDIR ${T}" >> \ + ${S}/t/conf/extra.conf.in + else + chown -R nobody.nobody ${WORKDIR} + fi + make test } src_install() { dodir /usr/lib/apache2-extramodules make install \ MODPERL_AP_LIBEXECDIR=${D}/usr/lib/apache2-extramodules \ + MODPERL_AP_INCLUDEDIR=${D}/usr/include/apache2 \ MP_INST_APACHE2=1 \ INSTALLDIRS=vendor || die
Created attachment 11333 [details] current state of ebuild Close, but not quite yet here. I've attached the ebuild I'm using now. A couple of questions - why the special case for usersandbox? Until I understand, in the interests of simplicity your usersandbox case is going to be the only code path, as you can see. Also, are the backup files necessary? I nuked those too for now. The problem here is cgi test 2 in the second round of tests - the ModPerl::Registry ones. That test fails for me. Here's what I think is the relevant portion of the error log, although it's a bit confusing with all the "the following error is expected" lines: [Wed Apr 30 13:50:49 2003] [error] 8461: ModPerl::Registry: Can't locate object method "boot" via package "mod_perl" at /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/Constants.pm line 8. Compilation failed in require at /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache.pm line 6. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache.pm line 6 . Compilation failed in require at /usr/lib/perl5/5.8.0/CGI.pm line 161. Compilation failed in require at /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/ModPerl-Registry/t/cgi-bin/cgi.pl line 1. BEGIN failed--compilation aborted at /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/ModPerl-Registry/t/cgi-bin/cgi.pl line 1.
Here's some answers for you from my limited knowledge. 1. Backup files are not necessary so nuking them is okay :-) 2. Regarding the "has userpriv" business its kind of complicated. I'll see if I can explain. I also noticed that the chown -R nobody.nobody is missing as well. More on that later in the comments. I started off with my portage setup such that /etc/make.conf had FEATURES commented out. At first, I got failures related to tests not passing. That was because everything was being built as root but the webserver never runs as root, instead it runs as nobody and user nobody did not have read access to the WORKDIR. Hence the need for chown -R nobody.nobody. Then when I tried to install, I got sandbox errors related to the copying of *.h files into /usr/include/apache2. That's when MODPERL_AP_INCLUDEDIR line was included. At this point, you mentioned that you were still getting sandbox errors (and I was not!), so I figured it had to do something with FEATURES. So, I uncommented my FEATURES line in /etc/make.conf and sure enough I started to get sandbox errors. The first one was related to /var/run/cgisock. It took a while to track that down but that was fixed by the ScriptSock directive. The second set of errors was for /usr/tmp/CGITemp* files. That was fixed by the SetEnv directive. As a result, regardless of whether I have FEATURES commented or uncommented in /etc/make.conf, my ebuild (with the "if has userpriv" and "else" statements) builds, compiles and installs without any problems. I have tried it both ways. I hope you come to the same conclusion as me that the chown -R nobody.nobody is needed in one scenario and the other stuff is needed to prevent the sandbox violations when userpriv is in effect. Its just odd that the ScriptSocket and SetEnv tricks are not needed in the "regular" scenario. Regarding the "Compilation failed in require at" errors that you encountered, I have the following comments. 1. My first thought is that you have some orphan files lying around. Perhaps a co-existing mod_perl version 1? What's the output of? qpkg -v -f /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/Constants.pm I don't have that file at all on my system. If its a case of coexisting mod_perl1 and mod_perl2, then we'll have to figure out how to "keep them apart". 2. Can you replicate these errors when not compiling "under" portage? e.g., Just untar into a directory as yourself (not root, just a regular user), issue a perl Makefile.PL (similar structure as in the ebuild) and then make and make test. What are the results of that exercise?
Created attachment 11372 [details] Next ebuild state Progress continues. The failed test with the CGI was due to my having CGI.pm 2.91. I trust you have 2.93 installed? So I have added a dep to 2.93 in here (and also updated dev-perl/CGI in CVS). Now it compiles OK if I have userpriv enabled (although I need to check with mod_perl 1.27 installed), but the no userpriv case still isn't quite working. I would prefer not to chown the entire work directory nobody:nobody if I can avoid it, so I've been trying to just chown the directories I can see that it needs, but maybe I've missed something. The current state of affairs is attached.
> Progress continues. The failed test with the CGI was due to my having > CGI.pm 2.91. I trust you have 2.93 installed? So I have added a dep to > 2.93 in here (and also updated dev-perl/CGI in CVS). > I disagree regarding the CGI dependency for the following 2 reasons. (note: its good to upgrade to 2.93 but not for this reason): 1. I had CGI 2.91 installed when I did most of my testing and NOT 2.93 (I upgraded this morning to test if 2.93 had any negative and/or positive effects) 2. Your originally reported errors mentioned the file /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/Constants.pm which is not even part of the CGI package!!! It must be from mod_perl1 or something else. What was the result of qpkg -f -v for this file? If that returns nothing then its an orphan file. > Now it compiles OK if I have userpriv enabled (although I need to check > with mod_perl 1.27 installed), but the no userpriv case still isn't > quite working. I would prefer not to chown the entire work directory > nobody:nobody if I can avoid it, so I've been trying to just chown the > directories I can see that it needs, but maybe I've missed something. Your ebuild is pretty close, however, regarding the chown nobody.nobody I can make the following suggestion. Your ebuild tries to chown Apache-Test and t directories. IMO, those directories are NOT the problem. They are already readable/writable during the test phase. The "make test" takes care of fs ownership which are underneath the WORKDIR. When run on nonuserpriv mode, there is a line during "make test" that caught my eye. *** root mode: changing the fs ownership to 'nobody' (65534:65534) The problem is the WORKDIR itself. drwx------ 3 root root 29 May 2 10:04 work These permissions, combined with the fact that the test setup references absolute paths for a lot of its config files, in turn, means that nobody will be denied access to all those files until we modify the ownership of the work directory. So, please modify your ebuild to only have one chown statement as follows: chown nobody:nobody ${WORKDIR} That will take care of the problem. Notice, that there is no need to supply the recursive -R flag. Cheers,
> I disagree regarding the CGI dependency The ModPerl-Registry CGI test 2 failed on me with CGI 2.91 and worked with 2.93. The error was a result of CGI.pm being unable to find the Apache module, and I assumed that 2.93 had updated names to be compatible with mod_perl 1.99, such as Apache2. > Your originally reported errors mentioned the file > /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/Constants.pm which is not > even part of the CGI package!!! It must be from mod_perl1 or something else. > What was the result of qpkg -f -v for this file? If that returns nothing then > its an orphan file. It was indeed part of mod_perl 1.27. I unmerged all other versions of mod_perl prior to 1.99 and the CGI test 2 still continued to fail. I will check the WORKDIR chown.
I added the chown for WORKDIR as you suggested, but am still having trouble with userpriv off. compat/apache_file.............FAILED tests 10-18 modules/cgi....................# Failed test 3 in /var/tmp/portage/mod_perl-1.99.09/work/mod_perl-1.99_09/Apache-Test/lib/Apache/Test.pm at line 48 fail #3 modules/cgiupload..............# Failed test 1 in modules/cgiupload.t at line 32 # Failed test 2 in modules/cgiupload.t at line 32 fail #2 server was shutdown but port 8529 is still in use, please shutdown the service using this port or select another port for the tests !!! port 8529 is in use, cannot determine server pid to shutdown !!! error running tests (please examine t/logs/error_log) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-mod_perl-1.99.09-14517.log" open_wr: /usr/tmp/CGItemp5104 unlink: /usr/tmp/CGItemp5104 etc etc That /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/Constants.pm file no longer exists on the system I am testing this on. Any more information helpful?
OK, the first set of tests now passes with userpriv off. I added a chown nobody:nobody for ${T} also, and that fixed things. However, now I hit another problem. The second battery of tests fails, claiming it cannot bind to the test socket, because the server from the previous round is still running. This is not the case, as both ps and lsof verify. I can only assume that setsockopt(REUSEADDR) is not working as user "nobody". Ick. This could be kernel-, libc-, or even hardware speed specific. I may try increasing some timeouts. We may end up having a USE="test" option or something, because I anticipate the potential for future trouble reports from others as fairly high, given the various pitfalls just the few folks working on this bug have hit.
I wish I could be more helpful here but I can't replicate what you are experiencing. Perhaps you can post your "emerge --info" output. Regarding your second battery of tests failing, have you been able to figure out why the access violations are occuring? The sandbox access violations are still referring to /usr/tmp/CGI* files which means we need to add an additional line for the 2nd battery of tests as follows (which will tell CGI.pm to create directories in the temp area): echo "SetEnv TMPDIR ${T}" >> ${S}/ModPerl-Registry/t/conf/extra.conf.in Perhaps this might even fix the "port 8529 is still in use" error.
Created attachment 11611 [details] Round 3 ebuild Here's another try at the ebuild. The comments in src_unpack describe my current state of thinking around the non-userpriv case. This ebuild builds without error with all tests passing on my first test machine both with userpriv enabled and without. However, lengthening out the timeout is rather kludgy, and I will try to solicit a bit more testing for this before committing it. Thanks for your patience and continued help.
Wow... this timeout thing is really odd. I still can't replicate it. First things first. Here's what I did just now: su - cd /tmp tar xzvf /usr/portage/distfiles/mod_perl-1.99_09.tar.gz cd mod_perl-1.99_09 perl Makefile.PL MP_APXS=/usr/sbin/apxs2 make make test And everything passed. So, I'm building this as root, with portge not involved at all and it passed with flying colors. So, if you can try the above and it still fails with the "port still in use" error, then you NEED to file a bug upstream with mod_perl. Once we get beyond that, then we need to focus on portage itself. I propose that we recruit some extra people to run the following tasks (you can chastise me if I'm being over enthusiastic :-) ): * Run the ebuild (without timeout patch) via portage in userpriv mode * Run the ebuild (without timeout patch) via portage in non-userpriv mode * Compile, make, make test the package as a regular user manually * Compile, make, make test the package as root manually (making sure to use a publicly readable directory, like /tmp instead of /root) And then compare the results from the above exercise. One single posting on the forums could do the trick?
Yes, i still get the timeouts when compiling outside portage, following exactly the instructions you detailed: All tests successful, 1 test skipped. Files=118, Tests=622, 29 wallclock secs (22.69 cusr + 3.26 csys = 25.95 CPU) *** server localhost:8529 shutdown *** port 8529 still in use... ...............!!! server was shutdown but port 8529 is still in use, please shutdown the service using this port or select another port for the tests !!! port 8529 is in use, cannot determine server pid to shutdown cd ModPerl-Registry && make test make[1]: Entering directory `/tmp/mod_perl-1.99_09/ModPerl-Registry' /usr/bin/perl -I../blib/arch -I../blib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean !!! port 8529 is in use, cannot determine server pid to shutdown APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/bin/perl -I../blib/arch -I../blib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 *** root mode: changing the fs ownership to 'nobody' (65534:65534) !!! port 8529 is in use, cannot determine server pid to shutdown make[1]: *** [run_tests] Error 1 make[1]: Leaving directory `/tmp/mod_perl-1.99_09/ModPerl-Registry' make: *** [run_tests] Error 2 I am using kernel 2.4.20-pfeifer-r1_pre7, and glibc 2.3.2-r1.
Now that we've verified that this is not portage's problem, a bug needs to be filed upstream. AFAIK, there is no bug reporting database. If not already subscribed, you will need to subscribe to the mod_perl mailing list (instructions at http://perl.apache.org/maillist/modperl.html). Instructions about reporting 2.0 problems are at: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Thanks for your persistence. Cheers,
I have confirmation for you regarding the CGI.pm version issue. A friend of mine could not pass the 2nd batch of tests with CGI.pm at version 2.81. Upgrading to 2.93 made the 2nd batch of tests pass 100%. Still no resolution for your "port still in use" issue when running as root?
No, and I'm reluctant to report it upstream, because I'm fairly sure they will blow it off as a Gentoo bug. I'm trying to draw more testers to the version in this bug, and if enough people can install it correctly, I will probably release it to the tree next week sometime.
make test enabled in 1.99.09 in CVS.
