mod_mono needs to be updated to work with apache-2.0.52-r3 and -1.3.33-r1. Instructions for modification are at http://dev.gentoo.org/~vericgar/doc/apache-package-refresh.html There is a preliminary updated package in our overlay at http://svn.northnitch.com/gentoo/apache-overlay/, but that is against an old version of mod_mono.
I'll get mod_mono updated tonight, unless someone beats me to it ;-)
I'd appreciate that. I took a shot at this a few nights ago, and got bogged down in the mess that is the configure script/defines for this package. I'll continue looking at it when I find time, but please feel free. (:
I (or rather, urilith) already did it for 1.0.2, it just needs a bump and a test (the bit I was spose'd to do two days ago ;-) I'll attach it here in the morning.
Created attachment 50129 [details] Updated ebuild
Created attachment 50130 [details] Updated config file
*tada* ;-)
Ok, that works, but I thought one of the points of the new eclass was to make life easier for building for either apache2 *or* apache1. mod_mono supposedly works for either, the ebuild currently in portage is the way it is because supporting both was painful. Can we get apache1/2 support worked out before bothering to commit this change?
Things are supposed to be like that, but I messed up and totally forgot about supporting both. I forgot to install docs, too. Updated ebuild correcting this will follow shortly.
While you're at it, you might incorporate the changes discussed in bug #77169 that I see you also tracking, regarding the worker mpm stuff. Thanks again for working on this.
*Ahem*, and sorry for messing you around Peter :-)
Blast my quick fingers.. I'll add the warnings, too.
Created attachment 50171 [details] Updated ebuild (Try #2)
Created attachment 50172 [details] Updated ebuild (take #2) Okay, here's an updated ebuild (apologies for the snafu just a while ago - I uploaded the wrong file). This ebuild uses several APACHE{1,2}_* variables that are used by the functions in apache-modules.eclass to build and install modules: APACHE{1,2}_MOD_FILE is the module DSO to be installed ("src/.libs/mod_mono.so"); APACHE{1,2}_MOD_CONF is the name of the config file to be installed (minus the extension part, "70_mod_mono"), that is expected to be in files/; APACHE{1,2}_MOD_DEFINE is the name of the conditional IfDefine that's in the config file ("MONO"). There's also a new variable, DOCFILES, which is used by the exported src_install() in apache-module.eclass to install documentation - see the eclass for more info). As this is a dual ebuild, I had to select the right apxs in src_compile() to pass off to configure, as there isn't a unified way to get that for dual-ebuilds yet (hoping we can sort something out for this in the future). I've done the mv-foo in src_install() so it's all consistant with other module ebuilds (i.e., no symlinkage), but I'm in no way attached to that, so I'll put that back if wanted/required. :-) I haven't added the warnings re b0rked'ness on non-prefork Apache installs as it appears to not be just threaded MPM's that are affected, and I don't want to misinform people. There is some warnings in pkg_setup() however, so that should cover it. Does the ebuild look alright? Apache herd: Any way we can support installing man pages from DOCFILES? ;-)
I may be incorrect, but I believe that apxs1 puts the module in a different place then apxs2 (i.e. not in the hidden .libs directory). I've run into this with other modules. I would test this to see if this is the case, but the dependencies are rather large. Test it with apache2 unset please.
Indeed apxs1 does do that, however mod_mono doesn't use apxs to compile at all - it uses it's own libtool - so mod_mono.so wil always be in "src/.libs" (upon successful compile, of course ;-).
As bug 77169 will be resolved once I've attached patches (*crosses fingers* ;), the ewarn's can be removed now. What I'm wondering though, is if the the ebuild should fix permissions on /tmp/.wapi if it exists and it's not owned by apache/has bad permissions, or just ewarn if they are bad. Any preference/do neither/go away, stop bugging me? ;-)
added to CVS. or we'll just wait 2 years longer ;-) However, I reviewed the ebuild, and couldn't find any flaws so far. So far, what's missing in the ebuild? (it's testing-masked, of course)
Resolving FIXED as this has been in the tree for a while. :)