As of apache-2.0.52-r3 and -1.3.33-r1 we are using new configuration and installation paths. mod_php needs to be updated to work with these paths. The prefered way would be to use apache-modules (which also handles apache DEPEND in the preferred way for modules that can use both apache-1 and apache-2). If you decide not to use our eclass, your paths will at least need to be updated so that mod_php puts it's module in the correct place. There is preliminary work done in our overlay at http://svn.northnitch.com/gentoo/apache-overlay/dev-php/mod_php/ Thanks!
I already took this over since noone from the PHP herd didn't take this and it should have been taken really seriousely; the *php*.eclass and mod_php ebuilds still needs lots of design improvements, however, the adoption to the new apache eclass is done and functional.
trapni: You complain nobody from the PHP herd took it, but I wasn't even aware of this until just you added us to the CC. Is there a guide/howto/basic-docs for your apache-modules eclass, so that the mod_php ebuilds can be converted?
I originally filed the bug to php-bugs@gentoo.org, so you should have seen it before. The eclass itself is decently documented. Also, there are skeleton ebuilds in our overlay at http://svn.northnitch.com/gentoo/apache-overlay/ that are well documented on how to use the new eclass. More documentation is on it's way - though it will be mostly user-oriented on how to upgrade and deal with the changes between versions, but there will also be a section for ebuild maintainers.
Christian, It is Gentoo policy that no developer makes a commit to an ebuild maintained by another developer or herd without their consent. Please do not do this again. Saying that something hasn't been taken "really seriously" is uncalled for. All Gentoo developers are *volunteers*. If a bug has been overlooked, most of the time it is because the developers in question just haven't had the time to get to your bug. Next time you need action on a bug that you've filed, please find one of the maintainers on IRC, or send them a private email, and ask them to take a look at it. I'm not happy with the changes that you have made to the eclass either. They are not 100% compatible with the current stable Apache release. glibc-2.2 is still in the Portage tree, and in the eclass you should have stripped the flags the same way that the current stable Apache ebuild does, to ensure consistency. Best regards, Stu
The reason for committing was the Jan 8. 2005, the merge day; The second reason for committing was, that no one, and I mean *NO* one gave me any response to the changes I made. I remember you (stu), writing something like you noticed that I converted mod_php to the new eclass and that you'll gonna take a look at it. This either didn't happen, or you didn't give me the feedback I'd love to. And, AFAIR, you're part of php herd, too. I do not wanne skip any guys over, just to commit on my own. It's just: I got NO feedback. So I concluded silently, that noone was interested in - until now - obviousely. So, sorry for committing, even if no one gave me any feedback on what I have done. Secondly, I'm actually only semi-online, in fact, I have no internet at home, and I've to pay to go online, using internet cafe and windows software like putty to get a gentoo environment. That's not the problem, but this is a problem wrt to contacting ppl on irc. This bug here seems a better place instead (thx vericgar :-) mod_php is not the only case I got *NO* input from at least one maintainer (just hollow tested once for me). I contacted pauldv wrt subversion. He must have been ignored my mail. And, since he's quite rare on irc, I do not know how to contact him instead. Recently, he bumped to 1.1.3, which completely reverts the changes chipig and I made from 1.1.2 to 1.1.2-r1. How shall I handle this case? However. stuart: I know, I made the LFS-related code in the apache/apr ebuilds you're talking about. Why I didn't do it with mod_php? Well, I guess, because I made a fault. sorry. I could do this, but will you accept by now or will you do this yourself?
please cvs up php-sapi.eclass && cvs diff it; It now disabled LFS for glibc-2.2 explicitely only, though, apache can still be emerged with LFS enabled [default]. I did really only LFS related changes to the eclass; and apache-module eclass related adoptions to the ebuild itself. I took this job because no one else was doing it, and I *NEEDED* mod_php on my test system. (anything missing?) Regards, Christian Parpart.
I got no feedback, and it still WORKSFORME. Though, closing this report.
Trapni: I would rather the php herd take a look at this and give it thier blessing so to say, they understand all the complexities that is mod_php and the php eclass. PHP herd: please test trapni's changes, adjust as necessary, and resolve this bug when you are done. Thanks!
*** Bug 83842 has been marked as a duplicate of this bug. ***
This is currently being worked out by the PHP team. However, I should mention that our doc (http://dev.gentoo.org/~vericgar/doc/apache-package-refresh.html) recommends that users not upgrade if they require PHP support.
*arghs* What's left to get this ebuild unmasked? I already adapted it to the apache related changes. I'm willing todo the rest as well (when noone wants do).
From a users' point of view I can only say the following: I don't understand why the php-ebuild people don't fix the ebuild as quick as possible or let other people do it for them (at least that's the impression I get) - It's such an important package!
Andreas Bulling: just unmask it, test it, use it, and report any oddies you get. I'm using it as well. Yeah, I'm using it even on my (3) production servers. I didn't notice any negativiness yet. Although, I just adapted the php-herd's mod_php ebuild just to the changes we made in our apache herd's apache-module eclass. However, they might - each of them - of course have there reasons not for unmasking it and/or doing things they have to do right before they think unmasking would be a good reason afterthen. This but now already blocks three other bugs. Though, I'd prefer to see this bug's severity as major+
Well, I didn't know that an (masked) ebuild already existed. I unmasked and emerged it, works fine - thanks! ;)
Works for me too.
*** Bug 84116 has been marked as a duplicate of this bug. ***
PHP team, please update us as to the status of this bug.
yo. please. ASAP! :-D
1. then don't unmask before you're done. At least mod_php is *very* important. 2. you have to upgrade if you need the bugs fixed in 2.0.53 I have no problem at all with changes for the better. But you have to do it completely before you kick users into trouble. You "emerge sync" and see "oh, a new version, great". Then you upgrade and see that anything is broken. THAT IS NOT NICE. Now you have the option to downgrade again or do the step forward and look that all packaged are ported quickly. I prefer the latter!
this was an answer to Comment 10. The unmasked ebuild works for me also.
Re: comment #19 You are running ~/testing. Stuff Breaks. Deal with it.
"Me too" - mod_php-5.0.3-r1 and apache-2.0.53 are working fine for me now. Thank you to everyone who has been working on this.
wrt comment 19. we have been waiting for the other herds to update their apache ebuilds for a very long time - if not even too long. But too many seem to be just "not interested" in taking their maintaincechip seriosely. I am really tired of waiting - as others in our herd for sure are too. We delayed the unmasking and even importing (in masked state) several times, because there has been ebuilds by other herds still lagging in support for the new apache-module / depend.apache eclass. At least I ... do not feel responsible for those lazy effords. I just do not understand why there's mostly even neither a "Hey, then please do it for us"-comment, so, that we could take the job (including unmasking). I'm not really complaining, but this really sucks up. Though, if herd FOO, for apache module mod_FOO doesn't feel responsible, they should at least take the time in asking for the next related herd (in this case: apache) to take over maintainceship. I did the changes to the mod_php ebuild because no one else feld responsible for it, but I wanted to have our apache and alike ebuilds running on my prod. servers (as I do really stand behind our all work). Why it's still masked, well, because someone told me, that the php herd somewhere wanna still add some more/other/misc changes/features/alike to this (yet masked) release. If you still feel uncomfortable with the current state, please address the maintainers _directly_, so they'll see, that there's a need for it. - sure, this bug is assigned to the php herd, but I just can't find any comment of them in the recent - major - comments being made. Regards, Christian Parpart.
The "sharedmem" use-flag has the effect of compiling php-5.0.3/ext/session/mod_mm.c which will #error out if ZTS is defined. ZTS (Zend Thread Safety) is defined in a number of circumstances, one of which is if apxs2 -q MPM_NAME returns something other than prefork. (For me it returns leader, altough I have activated all MPM use-flags [but without the threads use-flag].) This is with dev-php/mod_php-5.0.3 and apache 2.0.53.
~arch is for testing but not for breaking things! if you want to experiment, then use the "mask" feature like everybody else. deal with it. It was NOT NICE!
following a wish of Elfyn McBratney in bug 83842, I copy my comment to this bug. ----8<--------8<--------8<--------8<--------8<---- I run ~x86 to find and fix bugs. But ~arch doesn't mean, that the maintainer has no responsibility and that there's no need to be careful. Breaking your installation isn't an option for ~arch. For experiments you can mask your ebuilds. If you unmask, then you have to take care not to break anything you know about. And unmasking apache while mod_php isn't ported yet IS NOT NICE, because you know that you break anything that depends on PHP. ----8<--------8<--------8<--------8<--------8<----
@ Comment 23: that's odd. I agree. But at least mod_php should have been ported before unmasking. :-/
Re; the comments that we should have held back the entire unmasking of apache changes... Take a look at when this bug was filed. Jan 11. Nearly 2 months ago, while apache was still masked. And not to mention that members of the PHP herd knew we would need an updated module before this bug was ever filed. How long do you hold back the improvement and updating of everything else apache related when a single herd is dragging thier feet updating thier module? We decided that we couldn't wait for them any longer. Our masked tree was already starting to fall behind upstreams' versions. Sometimes you have to push on and make it known that certain previously working features no longer work because of certain teams dragging thier feet. Also, we had a working ebuild for mod_php (IIRC it's actually in the tree and hard-masked) that the PHP herd just needs to put thier stamp of approval on and unmask, and we wouldn't be having this issue. But they are supposedly doing massive changes in PHP land, and we (the apache team) doesn't know how long that will take. We just couldn't sit on these changes waiting any longer.
Dear PHP Team. Why just don't you bump a mod_php version that does *NOT* contain the new changes you are about to apply. As you see, there IS a need for a working mod_php with current apache ebuilds. And we already adapted YOUR mod_php to work with ours. So, please, verify our adaptions, make your advancing ideas in a SEPERATED(!) revision bump, so that the endusers just don't have to wait for further 2 months (or even longer). Regards, Christian Parpart.
All of the large scale changes are happening to PHP5. I've been exceedingly busy with university as this is my last semester (6 weeks of class left). I've just gotten to this as of yesterday, and I've been working thru making my apache work with after the apache unmasking (I'll file a bug on the problems encountered in a moment). There is a problem with your PHP changes. They cause this change in php.ini: -extension_dir = /usr/lib/php/extensions/no-debug-non-zts-20020429 +extension_dir = /usr/lib/extensions/no-debug-zts-20020429 Which means that mod_php won't find any of it's extensions anymore. I can't see why your changes are causing this however.
My apologies. The extension_dir breakage is NOT your fault. It's a breakage in portage, due to the multilib changes in January. Eradicator, ferringb and myself are currently discussing how to fix it without totally breaking everybodies systems.
Ok, the new mod_php builds are now unmasked. I suggest that all PHP users to re-merge php, mod_php, php-cgi, and then all PHP extensions that they use, due to the multilib bug.
Still not working for me, here's what I've done today as of 2005-03-11 : 1) Be sure that ACCEPT_KEYWORDS="~x86" is in /etc/make.conf 2) emerge -C apache php mod_php 3) Just to be sure to wipe out everything and start with a fresh install : rm -fr /var/tmp/* rm -fr /usr/portage/distfiles/* rm -fr /usr/portage/packages/* rm -fr /etc/apache rm /etc/conf.d/apache2 rc-update del apache2 rm /etc/init.d/apache2 4) emerge sync and emerge -a world : shows nothing 5) Make sure I have php in my USE flags in make.conf 6) emerge apache php mod_php 7) Configure /etc/apache2/httpd.conf 8) Put -D PHP5 in /etc/conf.d/apache2 9) /etc/init.d/apache2 start 10) Trying a test.php with my dyndns.org account (not loading /web/test.php) : Firefox tries to download a .php file, not displaying the php file. test.php contains : <?php phpinfo(); ?> Have I miss something ?
First off take a look in /var/log/apache2/errors.log When you start apache2 you should see a line like this: Apache/2.0.52 (Gentoo/Linux) mod_ssl/2.0.52 OpenSSL/0.9.7e PHP/5.0.3 configured -- resuming normal operations If the PHP/5.0.3 isn't there then mod_php isn't loading. Next check if mod_php5.conf is in /etc/apache2/modules.d. One thing I found was that index.php was not auto-displaying until I manually added index.php to httpd.conf as follows: DirectoryIndex index.html index.php index.html.var
add the following line into your config: AddDirectoryIndex index.php This will (hopefully) be added to next mod_php update.
I already had in httpd.conf : Include conf/modules.d/*.conf DirectoryIndex index.php index.html index.html.var And I added AddDirectoryIndex index.php Restarted apache and now php is working. Thanks all!
