This bug deals with the fallout from bug #340807. The problem is, that php-5.3.4 and php-5.2.16 are slotted to their minor versions. This creates problems for PHP extensions, which must cope with changed paths, blockers, etc. The Gentoo php team has uploaded a new version for all affected packages (taking the latest available version and making it minor version slotting aware). This bug deals with marking those packages stable along with php. Here's a list of stuff you need to keyword: dev-php5/eaccelerator-0.9.6.1-r1: amd64 x86 ~sparc dev-php5/pecl-apc-3.1.6-r1: amd64 ~ia64 ~ppc ~ppc64 ~sparc x86 dev-php5/pecl-crack-0.4-r1: amd64 ppc ppc64 ~sparc x86 dev-php5/pecl-dbx-1.1.0-r1: ~ppc ~ppc64 ~sparc dev-php5/pecl-htscanner-0.9.0-r1: amd64 x86 dev-php5/pecl-http-1.7.0-r1: amd64 x86 dev-php5/pecl-imagick-3.0.0-r1: amd64 ~ppc ~ppc64 ~sparc x86 (or use -3.0.1-r1 if you want) dev-php5/pecl-mailparse-2.1.5-r1: amd64 ~ppc ~ppc64 ~sparc x86 dev-php5/pecl-mcve-7.0.3-r1: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 dev-php5/pecl-memcache-3.0.5-r1: amd64 hppa ppc ppc64 sparc x86 dev-php5/pecl-pdflib-2.1.8-r1: ~ppc ~ppc64 ~sparc dev-php5/pecl-ps-1.3.6-r1: ~ppc ~ppc64 ~sparc dev-php5/pecl-ssh2-0.11.2-r1: amd64 x86 dev-php5/pecl-syck-0.9.3-r1: amd64 ~ppc ~ppc64 x86 dev-php5/pecl-timezonedb-2010.15-r1: ~alpha ~ia64 ~ppc ~ppc64 ~s390 ~sh ~sparc dev-php5/pecl-yaz-1.0.14-r1: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 dev-php5/phpdbg-2.15.5-r1: ~ppc ~ppc64 ~sparc dev-php5/suhosin-0.9.32.1-r2: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 dev-php5/xcache-1.3.0-r2: amd64 x86 dev-php5/xdebug-2.1.0-r1: ~alpha amd64 hppa ~ia64 ~ppc ~sparc x86 The list has been created by: grep inherit */*/*ebuild | egrep 'php-.*-r2' | cut -d '/' -f 1-2 | uniq > ~/gentoo/mvs_pkgs_to_update and eshowkw'ing my way through the list. The minor version slotting guide can be found here: http://www.gentoo.org/proj/en/php/php-guide.xml If your arch supports php-5.2 and php-5.3 you can test more thoroughly (at the cost of doubled compile time) by compiling the extension against each php version by setting: PHP_TARGETS="php5-3 php5-2" in your make.conf (remember eselect php set cli <version> && php -i | grep <extension> is an easy way to see if your extension was successfully loaded with that version of php) If you encounter errors while testing, but have an already stable and working version, please say so (either on the bug or irc), and we'll put up an ebuild that has minor version slotting and is based off the working version. That's the best we can do to resolve this situation asap. I've also collapsed a lot of testing keywords in this bug. There are seperate bug reports, but from jer's feedback, i think one big bug with a list is preferable to many small ones. I'll close the others next day. Thanks for your effort and patience. Happy holidays!
*** Bug 349602 has been marked as a duplicate of this bug. ***
*** Bug 349350 has been marked as a duplicate of this bug. ***
*** Bug 337218 has been marked as a duplicate of this bug. ***
*** Bug 312785 has been marked as a duplicate of this bug. ***
Stable for HPPA.
~ppc64 done
Testing on SPARC has turned up this error. eselect-php was installed before =dev-lang/php-5.2.16 was built and installed. Also, php-toolkit was a blocker so I removed that and =dev-lang/php-5.2.14. >>> Installing (1 of 1) dev-lang/php-5.2.16 eselect php !!! Error: Bad target exiting * Switched cli to use php:5.2 # php bash: /usr/bin/php: No such file or directory # eselect php list cli (none found) # eselect php list apache2 (none found) eselect php list fpm (none found) eselect php list cgi (none found)
On further investigation, it appears that eselect-php isn't working properly for php:5.2 and php:5.3, it just doesn't set up the symbolic links.
(In reply to comment #8) > On further investigation, it appears that eselect-php isn't working properly > for php:5.2 and php:5.3, it just doesn't set up the symbolic links. This is on SPARC.
Alex, I'm assuming a "user" error here. Anyway, please file new bugs for issues and don't clutter up stablereq bugs.
Filed as bug #350092, sorry for messing up your stabilisation request!
Stable on alpha (took xdebug-client along for the ride).
x86 stable
amd64 done
Now that eselect-php has been fixed in the tree for SPARC, I have tested both slotted 5.2.16 and 5.3.4 on SPARC, both appear to work just fine, by testing with a browser on index.php. Please stabilise for SPARC.
arm stable
ppc done
ia64/s390/sh/sparc done
(In reply to comment #17) > ppc done > Closing bug then, no more arches.