As of apache-2.0.52-r3 and -1.3.33-r1 the apache paths are changing. the mod_perl ebuilds need to be updated to use apache-module eclass so that it uses the correct paths. There was some preliminary changes to an older version of a mod_perl ebuild in our overlay at http://svn.northnitch.com/gentoo/apache-overlay/, but that version is out of date and didn't make the changes to the 1.29 line either. Thanks.
Created attachment 51778 [details] mod_perl-2.0.0_rc4.ebuild
Created attachment 51779 [details] 75_mod_perl.conf
Created attachment 51780 [details] apache2-mod_perl-startup.pl
Created attachment 52300 [details, diff] mod_perl.patch
and don't forgot about mod_perl 1.xx
the latest patch has 1.29-r1 included
I had to add this to the files/2.0.0/75_mod_perl.conf file to get this to work. This came from my old commonapache2.conf <IfModule mod_perl.c> #Provide two aliases to the same cgi-bin directory, #to see the effects of the 2 different mod_perl modes #for Apache::Registry Mode ScriptAlias /perl/ /var/www/localhost/perl/ #for Apache::Perlrun Mode ScriptAlias /cgi-perl/ /var/www/localhost/perl/ <Directory /var/www/localhost/perl> AllowOverride All Options -Indexes FollowSymLinks MultiViews ExecCGI <IfModule mod_access.c> Order allow,deny Allow from all </IfModule> </Directory> PerlModule Apache2::ModPerl::Registry <Location "^/perl/*.pl> SetHandler perl-script <IfDefine MODPERL2> PerlResponseHandler Apache2::ModPerl::Registry </IfDefine> <IfDefine !MODPERL2> PerlResponseHandler ModPerl::Registry </IfDefine> Options -Indexes ExecCGI PerlSendHeader On </Location> </IfModule>
I've been using the supplied patches for more than a week now and it's been working fine. How long until we see mod_perl-2.0.0_rc4 in ~arch? Right now it's not even in there at all. Robert Coie has >=dev-perl/mod_perl-1.99.16 masked in packages.mask, but the issue he cites doesn't seem to be related to this stuff. I was just wondering if there were any outstanding issues that still needed to be taken care of.
*** Bug 85469 has been marked as a duplicate of this bug. ***
*** Bug 89360 has been marked as a duplicate of this bug. ***
Apologies for not updating this bug. I've been having trouble with mod_perl and the latest Apache (segfault parties), which is 'fixed' with a non-LFS Apache, APR and APU. I'll be adding hard-masked mod_perl ebuilds to the tree in a couple of hours for when these issues are fixed.
*** Bug 89798 has been marked as a duplicate of this bug. ***
FWIW -- I haven't tried the patch here yet, but mod_perl-1.99.17-r1 has been working fine for me so far with apache-2.0.53 (after moving files to the appropriate places), so I'm not sure why it's masked. I did get segfaults with mod_perl-1.99.11.
*** Bug 38079 has been marked as a duplicate of this bug. ***
*** Bug 90375 has been marked as a duplicate of this bug. ***
Tried Benedikt's ebuild with mod_perl-2.0.0_rc5, but couldn't get it to work. :( >>> emerge (1 of 1) dev-perl/mod_perl-2.0.0_rc5 to / >>> md5 files ;-) mod_perl-2.0.0_rc5.ebuild >>> md5 files ;-) files/digest-mod_perl-2.0.0_rc5 >>> md5 files ;-) files/75_mod_perl.conf >>> md5 files ;-) files/mod_perl.patch >>> md5 files ;-) files/apache2-mod_perl-startup.pl >>> md5 src_uri ;-) mod_perl-2.0.0-RC5.tar.gz >>> Unpacking source... >>> Unpacking mod_perl-2.0.0-RC5.tar.gz to /var/tmp/portage/mod_perl-2.0.0_rc5/work >>> Source unpacked. Reading Makefile.PL args from @ARGV MP_TRACE = 1 MP_DEBUG = 1 MP_USE_DSO = 3 Unknown Option: MP_INST_APACHE2 Usage: MP_APR_CONFIG - Path to apr-config MP_APR_LIB - Lib used to build APR::* on Win32 (default is aprext) MP_APXS - Path to apxs MP_AP_CONFIGURE - Apache ./configure arguments MP_AP_DESTDIR - Destination for Apache specific mod_perl bits MP_AP_PREFIX - Apache installation or source tree prefix MP_CCOPTS - Add to compiler flags MP_COMPAT_1X - Compile-time mod_perl 1.0 backcompat (default is on) MP_DEBUG - Turning on debugging (-g -lperld) and tracing MP_GENERATE_XS - Generate XS code based on httpd version MP_INCLUDE_DIR - Add directories to search for header files MP_LIBNAME - Name of the modperl dso library (default is mod_perl) MP_MAINTAINER - Maintainer mode: DEBUG=1 -DAP_DEBUG -Wall ... MP_OPTIONS_FILE - Read options from given file MP_PROMPT_DEFAULT - Accept default value for all would-be prompts MP_STATIC_EXTS - Build Apache2::*.xs as static extensions MP_TRACE - Turn on tracing MP_USE_DSO - Build mod_perl as a dso MP_USE_GTOP - Link with libgtop and enable libgtop reporting MP_USE_STATIC - Build mod_perl static MP_XS_GLUE_DIR - Directories containing extension glue at lib/ModPerl/BuildOptions.pm line 109, <DATA> line 22. !!! ERROR: dev-perl/mod_perl-2.0.0_rc5 failed.
*** Bug 92214 has been marked as a duplicate of this bug. ***
Hello, what's the status on this? I get a lot of segfaults in apache2 with mod_perl-1.99.11 and 1.99.17 so I tried this mod_perl-2.0.0-rc5 ebuild: http://bugs.gentoo.org/show_bug.cgi?id=89798 and followed this to the letter: http://perl.apache.org/docs/2.0/rename.html but got nothing but 500s and bareword Apache2::Const::OK errors in error_log. I was able to roll back successfully though. Is there a problem with integrating mod_perl > 1.99.17 into the Gentoo layout? Is there a discussion on this somewhere that I could follow? - Grant
Works here with some modifications. 1. mod_perl does not honor CCFLAGS. At all. It will happily white it to src/modules/perl/Makefile. As ccomment. It will never use supplied options at all! Since I'm not sure about "proper fix" I've added CFLAGS to generated Makefiles. 2. This version DOES NOT play nice with previous installations of mod_perl. Apache2.pm is not needed and should be avoided! This is it. With this ebuild I was able to install it on my (LFS-enabled via CFLAGS="$CFLAGS -D_FILE_OFFSET_BITS=64" ) Apache and use it for small stuff. Not sure if it works fully - but at least it does what I need.
Created attachment 58969 [details, diff] This is what I use right now. Ugly, I know. But works.
Nice work in getting to the bottom of this. Hwvr, this is at the edge of my knowlege. could you post exactly how to apply that patch? [maintainers:] can this be fixed properly in portage? If I have understood this correctly , there is no current way to install apache2 perl and mod_perl using gentoo portage, since there are mutual inconsistancies. (ie this is not just some users with an oddball CFLAG) Thx
Just a ping from the apache guys re: the status of updating mod_perl for new-style apache. mod_perl being ready is what's holding us up from going stable with new-style. LFS has been removed from Apache, and won't be supported until Apache 2.1/2.2, so that should clear up many of the issues (if I'm reading it right, LFS is causing all the issues in this bug). Please let us know. Thanks!
I've been using mod_perl 2.x with the repackaged apache on Gentoo since March and have not noticed any problems. How to I reproduce the bug as I haven't seen one yet.
Any news about the ebuild for the 1.29 version ? I'm waiting on it to update apache on 2 servers, and I'm stuck with Apache 1.3 for the moment...
I've actually posted a comment on Bug 95125 http://bugs.gentoo.org/95125 if anyone would like to try it out for me. I haven't updated it to use the new eclass as mod_perl has special fixes in the ebuild. Until I look at those a little more closely, this works for the time being. All the files are attached to that bug.
hi all, i have been doing some looking into this problem and from what i know of apache and mod_perl which has been gathered over the many years i have been using both the apache-module eclass is not really useable by mod_perl. the problem is that mod_perl is an apache module but it is also a perl module but it doesn't really conform with with the standard way apache modules get installed. i have made the latest version of mod_perl comply with the new layout but i can't really use the functions in apache-module.eclass to do this. if there was separate functions for installing the apache config files i could use them but i cant use the src_install or the configure function. so unless i am missing something mod_perl can't be made to work with the current functions in apache-module.eclass. and if i am missing something please let me know.
ok i have a request. it would be good if i had an install_apache_conf_files function that just installs the files in APACHE2_MOD_CONF and friends. the name isnt important it was just want jumped into my head that said everything it does and got my point across. this would be useful for mod_perl and libapreq[2] and other perl modules that use apache and need extra conf added to enable them. that way its all handled correctly and everyone is happy.
just a further note. it also seems that using apache-module and perl-module together doesnt work when you want to inheret as much from the perl-module eclass as possible. the apache-module eclass takes over the function list and this is bad cause libapreq2 can be installed pretty much Out-of-the-box as a perl module. i didn't notice this with mod_perl becuase all the functions have to be rewritten for it. is there any way we can get around this? or can we have a separate apache-perl-module eclass? or should i just add some extra functions to perl-module for dealing with apache-conf files and the like?
Mass re-assign.
apache2-mod_perl-startup.pl still has the wrong path in it: use lib qw(/home/httpd/perl); Should be /var/www... right?
*** Bug 108413 has been marked as a duplicate of this bug. ***
Created attachment 76681 [details, diff] An attempt to change mod_perl-1.29.ebuild Worked for me, but I didn't do any massive testing. Just checked with Apache::Status. Please let me know if it works/doesn't work. Please create this file: files/1.29/75_mod_perl.conf <IfDefine PERL> <IfModule !mod_perl.c> LoadModule perl_module modules/libperl.so </IfModule> </IfDefine>
Sorry, I forgot to mention that I tested with apache-1.3.33-r11.
Ugh, did I completely ignore Benedikt Boehm's mod_perl-1.29*.ebuild? :) Sorry -- the attachment was a total mess, I read comment #24, and I guess I thought there were only patches for 2.0.* :-)
1.29 fixed up; 2.0.1 fixed up and unmasked; 2.0.2 added as ~arch; everything tested and good, closing this bug out. (In reply to comment #30) > apache2-mod_perl-startup.pl still has the wrong path in it: > > use lib qw(/home/httpd/perl); Really irrelevant tbh - that line is from the supplied examples, where mod_perl is assumed to be installed in /home/httpd/perl, but in our case they neither add nor detract from functionality (its just trying to add a lib line we don't need since we install as root to perl's @INC). Closing this out (and updating Changelog with at least a few credits - sorry if i miss anyone, honest) ~mcummings