Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
As requested ;-) This is a tracker bug for the keywording of the new PHP packages for Gentoo. At the moment, the packages are only available via an overlay. It'd be a great help to me if each arch could indicate what keywords they would like for the new PHP packages before they go into the tree. I'll handle x86 and ppc, but help for other arches would be muc appreciated. Best regards, Stu
If the "pear" useflag is enabled when testing with the overlay ebuilds, it pulls in a dependency for a non-existant package; emerge: there are no ebuilds to satisfy ">=dev-php/PEAR-PEAR-1.3.5-r2". SPARC testing is still going on, will report back about keywording when done.
The "pear" USE flag depends on dev-php/PEAR-PEAR-1.3.5-r2 like the message says, and that package exists in the overlay on http://svn.gnqs.org/projects/gentoo-php-overlay/. It's in the dev-php/ category, not dev-php4/ or dev-php5/, we still maintain some packages in dev-php/. Thanks for helping us with keywording. :) Have a nice day, CHTEKK.
testing appears to be going well so far. php-4.4.0 and php-5.1.0_rc1 are working on SPARC. Two things to note about having "test in FEATURES; 1). dev-lang/php-4* will run the included php test suite, whild dev-lang/php-5* will not. 2) All of the sub-packages (stuff in dev-php4 and dev-php5) show this error message; "ERROR: Cannot run tests without CLI sapi". I have confirmed when testing dev-php4 that eselect shows php4 as the selected version and /usr/bin/php -v confirms this. I've also built both php4 and php5 with CLI, CGI, APACHE and APACHE2 SAPIs.
Hi, Here's a list of the packages from the overlay that are now in the Portage tree. app-admin/eselect-php-0.96 app-doc/php-docs-20050822 dev-db/freetds-0.63 dev-lang/php-4.4.0 dev-lang/php-5.0.4 dev-php/PEAR-PEAR-1.3.6 dev-php/phpdbg-client-2.11.32 dev-php4/eaccelerator dev-php4/pecl-apc dev-php4/pecl-crack dev-php4/pecl-fileinfo dev-php4/pecl-imagick dev-php4/pecl-mailparse dev-php4/pecl-memcache dev-php4/pecl-pdflib dev-php4/pecl-ps dev-php4/pecl-sqlite dev-php4/pecl-tidy dev-php4/pecl-yaz dev-php4/pecl-zip dev-php4/php-java-bridge dev-php4/phpdbg dev-php4/xdebug dev-php5/pecl-apc dev-php5/pecl-crack dev-php5/pecl-dbx dev-php5/pecl-fileinfo dev-php5/pecl-imagick dev-php5/pecl-mailparse dev-php5/pecl-memcache dev-php5/pecl-pdflib dev-php5/pecl-pdo dev-php5/pecl-pdo-dblib dev-php5/pecl-pdo-firebird dev-php5/pecl-pdo-mysql dev-php5/pecl-pdo-oci dev-php5/pecl-pdo-odbc dev-php5/pecl-pdo-pgsql dev-php5/pecl-pdo-sqlite dev-php5/pecl-ps dev-php5/pecl-yaz dev-php5/pecl-zip dev-php5/php-java-bridge dev-php5/phpdbg Of these, only the following need stabilising as a group. The rest can be stabilised on their own afterwards. dev-lang/php-4.4.0 dev-lang/php-5.0.4 dev-php/PEAR-PEAR-1.3.6 dev-php4/php-java-bridge dev-php4/pecl-yaz dev-php4/pecl-zip dev-php5/php-java-bridge dev-php5/pecl-pdo dev-php5/pecl-pdo-dblib dev-php5/pecl-pdo-firebird dev-php5/pecl-pdo-mysql dev-php5/pecl-pdo-oci dev-php5/pecl-pdo-odbc dev-php5/pecl-pdo-pgsql dev-php5/pecl-pdo-sqlite dev-php5/pecl-yaz dev-php5/pecl-zip Best regards, Stu
Hi, We're not in a position to support the "test" FEATURE of Portage. Like many other packages in the tree, upstream don't provide/maintain a comprehensive set of tests that work with all possible options. Best regards, Stu
If you folks aren't going to support the test feature, then as a suggestion, you might disable the test functionality that gets called when test is in FEATURES. Cheers.
Guys, while you're at it, could you remove the .filemap and .lock files that get installed with every PEAR-* package? They cause lots of headache with collision-protect. I have INSTALL_MASK-ed them for now, but why not do it in the eclass -- they are useless currently.
I have a little question here, I only need php5 on my system, and also, I want to use pear, but if I specify the pear flag, then emerge dev-lang/php -pv, it says I need to install a php4.40, why I must install a php4 for pear support?
Haven't post this, after I emerged dev-lang/php-5.0.4, because I want pear, so I do a emerge -uDp world, emerge give me 3 blocks: [blocks B ] media-libs/libswf (is blocking dev-lang/php-5.0.4) [blocks B ] dev-php/php (is blocking dev-lang/php-5.0.4) [blocks B ] dev-php/php (is blocking dev-php/PEAR-PEAR-1.3.6) all are caused by pear and php4 problem. php5 don't need libswf.
Trying to install pear, will install php4 _and_ php5. This isn't tested, but php4 isn't listed as dep any more. Just change this line (line 21) from DEPEND="$DEPEND virtual/php dev-php/php" to DEPEND="$DEPEND virtual/php dev-lang/php" in /usr/portage/eclass/php-pear.eclass. I will report, if it's working, or not. HAND, Steffen
(In reply to comment #10) > Just change this line (line 21) from DEPEND="$DEPEND virtual/php dev-php/php" > to DEPEND="$DEPEND virtual/php dev-lang/php" > in /usr/portage/eclass/php-pear.eclass. Which is about the only difference between php-pear.eclass and php-pear-r1.eclass. I guess that while we're waiting for this to happen, putting dev-php/php in /etc/profile/package.provided is enough of a workaround.
problem with wordpress: RDEPEND=">=dev-php/mod_php-4.1 >=dev-db/mysql-3.23.23" force mod_php 4.4 install. please fix.
i can confirm a problem with pear ebuilds: [nomerge ] dev-php/PEAR-Archive_Tar-1.3.1 [ebuild N ] dev-php/php-4.4.0 [ebuild N ] media-libs/libswf-0.99 inherit php-pear must be changed a bit :)
I have successfully installed dev-lang/php on amd64 and it appears to work correctly. Please add ~amd64 keywords to dev-lang/php-5.0.4 and app-admin/ eselect-php-0.96. Changing line 21 in php-pear.eclass as described in #10 fixes the dependency on php4 for me. There seems to be dependencies on dev-php/php in many other ebuilds. I ran across one in dev-lang/swig.
all pecl-extensions compile correctly on my system... they are installed in /-dir (root-dir). I have to move them by hand to /usr/lib/php[4|5]/lib/php/extensions/no-debug-non-zts-20020429 if i don't want php-cli complaining that there is something missing... that should be fixed :) [ Searching for packages matching dev-php4/pecl-zip... ] dev-php4/pecl-zip-1.0 * Contents of dev-php4/pecl-zip-1.0: /etc /etc/php /etc/php/apache2-php4 /etc/php/apache2-php4/ext /etc/php/apache2-php4/ext/zip.ini /etc/php/cli-php4 /etc/php/cli-php4/ext /etc/php/cli-php4/ext/zip.ini /usr /usr/share /usr/share/doc /usr/share/doc/pecl-zip-1.0 /usr/share/doc/pecl-zip-1.0/CREDITS.gz /usr/share/doc/pecl-zip-1.0/package.xml.gz /zip.so the last row is bad :) you can replace pecl-zip with pecl-pdo and so on... its some kind of the same..
i forgot to say that i had to create that extension-dir by hand... it was non existant and should probably be createt by the first script, that will install some extensions...
(In reply to comment #15) > all pecl-extensions compile correctly on my system... they are installed in > /-dir (root-dir). I have to move them by hand to > /usr/lib/php[4|5]/lib/php/extensions/no-debug-non-zts-20020429 if i don't want Hm, it's quite alright here: chutz@tiger chutz $ equery f pecl-zip [ Searching for packages matching pecl-zip... ] dev-php5/pecl-zip-1.0 * Contents of dev-php5/pecl-zip-1.0: /etc /etc/php /etc/php/apache2-php5 /etc/php/apache2-php5/ext /etc/php/apache2-php5/ext/zip.ini /etc/php/cgi-php5 /etc/php/cgi-php5/ext /etc/php/cgi-php5/ext/zip.ini /etc/php/cli-php5 /etc/php/cli-php5/ext /etc/php/cli-php5/ext/zip.ini /usr /usr/lib /usr/lib/php5 /usr/lib/php5/lib /usr/lib/php5/lib/php /usr/lib/php5/lib/php/extensions /usr/lib/php5/lib/php/extensions/no-debug-non-zts-20041030 /usr/lib/php5/lib/php/extensions/no-debug-non-zts-20041030/zip.so /usr/share /usr/share/doc /usr/share/doc/pecl-zip-1.0 /usr/share/doc/pecl-zip-1.0/CREDITS.gz /usr/share/doc/pecl-zip-1.0/package.xml.gz I only have dev-lang/php-5.0.4 from the virtual/php family installed.
gatekeeper ~ # equery files dev-php5/pecl-zip [ Searching for packages matching dev-php5/pecl-zip... ] dev-php5/pecl-zip-1.0 * Contents of dev-php5/pecl-zip-1.0: /etc /etc/php /etc/php/apache2-php5 /etc/php/apache2-php5/ext /etc/php/apache2-php5/ext/zip.ini /etc/php/cli-php5 /etc/php/cli-php5/ext /etc/php/cli-php5/ext/zip.ini /usr /usr/share /usr/share/doc /usr/share/doc/pecl-zip-1.0 /usr/share/doc/pecl-zip-1.0/CREDITS.gz /usr/share/doc/pecl-zip-1.0/package.xml.gz /zip.so gatekeeper ~ # php --version PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/lib/php/extensions/no-debug-non-zts-20050617/zip.so' - /usr/lib/php5/lib/php/extensions/no-debug-non-zts-20050617/zip.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP 5.1.0RC1 (cli) (built: Sep 5 2005 10:25:24) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies maybe i do something wrong...
Created an attachment (id=67797) [edit] portage-logfile about dev-php5/pecl-zip
thats strange on another gentoo-box it works with that extensions.. first on php-4.4.0
Curious. What does "php-config --extension-dir" say?
both times /usr/lib/php4/lib/php/extensions/no-debug-non-zts-20020429 which sounds correct
And what about /usr/lib/php4/bin/php-config --extension-dir. You could also check the temp/environment file from building and look at PHPCONFIG and EXT_DIR.
ehm... php-config is not wrapped by eselect-php, is it? i get both times the same result... either on php4 or on php5 ... and the php-config-version is always 4.4.0... php-config belongs to php5 and php4, but won't be wrapped, too ... maybe that could influence the merging-process
EXT_DIR is empty in temp/environment, when i do "ebuild /usr/portage/dev-php4/pecl-zip-1.0.ebuild compile" at least on the one machine that doesn't install correctly..
(In reply to comment #25) > EXT_DIR is empty in temp/environment, when i do "ebuild > /usr/portage/dev-php4/pecl-zip-1.0.ebuild compile" at least on the one machine > that doesn't install correctly.. Well that explains why the .so's get inserted into /, with no ${EXT_DIR} the path remains "/extname.so" and get installed to /. Now the question is, why doesn't EXT_DIR get correctly filled with /usr/lib/... ? The fact that /usr/bin/php-config isn't for both PHPs is normal, /usr/bin/php-config is a symlink you can edit using eselect or manually and links to either PHP4's or PHP5's php-config. But the ebuilds find out the complete and correct path themselves, the eclass calls the correct /usr/lib/phpX/bin/php-config, and not the /usr/bin/php-config symlink. Now, ${EXT_DIR} gets defined in php-ext-base-r1.eclass, calling /usr/lib/phpX/bin/php-config --extension-dir, so if that one, executed on the shell, returns a result, your problem really is strange... Please open a different bug for this (this one here is only the tracker bug for the KEYWORDS, we don't want to put too much stuff in it that doesn't have to do with KEYWORDS) and post your emerge info etc., so we can help you better. Best regards, CHTEKK.
since portage doesn't recognize categories in PORT_TMPDIR, can't compare the two ebuilds at the same moment, but PHPCONFIG is in both cases correct (php4/php5) and EXT_DIR is in both cases empty... not only on the machine which installs it not correctly, but also on the machine that does install it correctly... one difference is the portage-version on both machines... on that which installs not correctly, emerge info follows: Portage 1.589-cvs (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.13-gentoo i686) ================================================================= System uname: 2.6.13-gentoo i686 AMD Athlon(tm) MP Processor 1900+ Gentoo Base System version 1.12.0_pre8 Python: dev-lang/python-2.3.5,dev-lang/python-2.4.1-r1 [2.4.1 (#1, Jun 18 2005, 01:42:22)] distcc: No such file or directory [disabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.8.5-r3, 1.7.9-r1, 1.9.6, 1.5, 1.6.3, 1.4_p6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-mp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/env /etc /share/config /shutdown /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/kde/devel/env /usr/kde/devel/share/config /usr/kde/devel/shutdown /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-mp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/mnt/backup/gatekeeper-temp/" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/kde-live /usr/local/overlays/php/experimental" SYNC="rsync://gentoo-distfiles.local.nil.nul/gentoo-portage" USE="x86 X aac aalib alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts bzlib cdparanoia cdr chroot crypt cups curl dba divx4linux dvd dvdr dvdread eds emacs emboss encode esd fam foomaticdb fortran ftp gd gdbm gif gimpprint gpm gstreamer gtk gtk2 gtkhtml icq imagemagick imap imlib ipv6 java jpeg junit ldap libg++ libwww lzo mad mikmod motif mozilla mp3 mpeg mysql ncurses nls nvidia offensive ogg oggvorbis opengl oss pam pdflib perl php png python qt quicktime readline samba sdl session soap spell sql ssl stroke subversion svg svga tcpd tiff truetype truetype-fonts type1-fonts unicode vhosts vorbis win32codecs xine xinerama xml xml2 xmlrpc xmms xpm xprint xsl xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS Config files: /etc/make.conf, /etc/portage/modules, /etc/portage/mirrors, /etc/portage/package.mask, /etc/portage/package.unmask, /etc/portage/package.keywords on the other machine emerge follows: nqintra pecl-zip-1.0 # emerge info Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.11-gentoo-r9 i686) ================================================================= System uname: 2.6.11-gentoo-r9 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.4.19-r1, 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon -O2 -pipe -mmmx -m3dnow" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon -O2 -pipe -mmmx -m3dnow" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://gentoo-distfiles.local.nil.nul/gentoo-portage" USE="x86 acl acpi acpi4linux activefilter alsa apache2 apm berkdb bitmap-fonts crypt cscope eds emboss encode fortran gd gd-external gdbm gif gstreamer gtk2 imlib ipv6 jpeg ldap libg++ libwww maildir mp3 mpeg mysql ncurses oav ogg oggvorbis pam pdflib perl png python samba sdl ssl tcpd tiff truetype truetype-fonts type1-fonts vhosts vorbis xml xml2 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Hmmm: 1) Use stable Portage. 2) -O3 never is the best idea, but this shouldn't be the cause of the problem here. 3) I'm not sure PORTAGE_TMPDIR can be done on external partitions, it's never such a good idea imho, why can't you set it to /tmp for example like on your 2nd machine? Most likely the cause of the problem is number 1, though 2 and 3 can play small parts around as well. ;) Best regards, CHTEKK.
(In reply to comment #28) > Hmmm: > 1) Use stable Portage. i think, that would resolve this "feature"... i get different results from different portage-versions... i can live with that feature on assorted boxes with new alpha-portage.... -O3 never did me any harm.. and PORT_TMPDIR on another partition... its still local, so that should work, too but i try... --> doesnt change a thing...
Guys, the current php-pear-r1.eclass (the one in portage) does not have a php-pear-r1_src_install() function. It has one without the -r1. This screws things up pretty badly. The following does the trick: - php-pear_src_install() { + php-pear-r1_src_install() {
wordpress is still not fixed. [nomerge ] www-apps/wordpress-1.5.2 [ebuild N ] dev-php/mod_php-4.4.0-r1 move it to dev-lang and virtual. it's confimed to work with php5, check the bugzilla bugs too.
(In reply to comment #30) > Guys, the current php-pear-r1.eclass (the one in portage) does not have a > php-pear-r1_src_install() function. It has one without the -r1. This screws > things up pretty badly. We know, thanks for spotting this too. It was committed some time ago to CVS and should appear in an hour or so if you do a new emerge sync. Best regards, CHTEKK.
I would like to ask to also provide dev-lang/php-4.3.11 because we maintain backward compatibility support down to this version and updated packages require dev-lang/php and not dev-php/php. There is also problem with php-4.4.0 - Zend Optimizer cannot work with this version (at least it was true some weeks ago). We also use mapserver ebuild (still not in portage tree) that requires to have both mod_php and php of the same version in the system. mod_php-4.3.11 is still in the system but php-4.3.11 is not in the dev-lang.
I would like to ask that all of the current broken keywords (with relation to this) in the live portage tree be fixed ASAP and that no new ones (like dev-php/PEAR-Date-1.4.3-r1) be introduced. Thanks.
I've got an issue with some ebuilds depending on mod_php and forcing it's install. terra ~ # equery depends mod_php [ Searching for packages depending on mod_php... ] net-analyzer/cacti-0.8.6f-r1 www-apps/mythweb-0.18.1 www-apps/websvn-1.61
(In reply to comment #33) > I would like to ask to also provide dev-lang/php-4.3.11 because we maintain > backward compatibility support down to this version and updated packages require > dev-lang/php and not dev-php/php. dev-lang/php-4.3.11 momentarly exists only on the PHP Overlay [1], I'll try to get it added to Portage this evening, it was already planned but slipped through the last update. :) > There is also problem with php-4.4.0 - Zend Optimizer cannot work with this > version (at least it was true some weeks ago). a) We don't provide ZendOptimizer or support it, yet. b) Afaik it does, the last time I downloaded it it had a 4_4_0 directory in it. > We also use mapserver ebuild (still not in portage tree) that requires to have > both mod_php and php of the same version in the system. mod_php-4.3.11 is still > in the system but php-4.3.11 is not in the dev-lang. dev-lang/php provides both CLI, CGI and mod_php in the same Ebuild, controlled by USE flags. So when we'll add dev-lang/php-4.3.11 you can compile both CLI and mod_php with it. (In reply to comment #35) > I've got an issue with some ebuilds depending on mod_php and forcing it's install. > > terra ~ # equery depends mod_php > [ Searching for packages depending on mod_php... ] > net-analyzer/cacti-0.8.6f-r1 > www-apps/mythweb-0.18.1 > www-apps/websvn-1.61 We know, there already are bugs filed for them or they are listed in our TODO list [2]. I'll see to get hold of someone to fix all the web-apps/, but that will need some time. Best regards, CHTEKK. [1] http://svn.gnqs.org/projects/gentoo-php-overlay/ [2] http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/TodoList
(In reply to comment #14) > I have successfully installed dev-lang/php on amd64 and it appears to work > correctly. Please add ~amd64 keywords to dev-lang/php-5.0.4 and app-admin/ > eselect-php-0.96. Same here. All is working well on amd64.
(In reply to comment #37) > Same here. All is working well on amd64. they're already ~amd64 keyworded. as for php-5.0.5 at amd64 - take a look at bug #105374
(In replay to comment #36) >(In reply to comment #33) >> There is also problem with php-4.4.0 - Zend Optimizer cannot work with this >> version (at least it was true some weeks ago). >a) We don't provide ZendOptimizer or support it, yet. >b) Afaik it does, the last time I downloaded it it had a 4_4_0 directory in it. It will work with ZendOptimizer 2.5.10a (not 2.5.10) ... i have to use it for a webapp, and i had to search and google for that answer... just download 2.5.10a (the latest one) from Zend Website, and you get settled.. Greetings
(In reply to comment #14) > There seems to be dependencies on dev-php/php in many other ebuilds. I ran > across one in dev-lang/swig. dev-lang/swig-1.3.21 should be converted somehow... i need that for many ebuilds :) (netscape-flash e.g.)
(In reply to comment #0) on Thursday the keyword for PHP 5.0.4 was ~ppc - so I installed it (I did not intend to test the keyword). Later it got again removed, why? I unmerged PHP 4 and php_mod and still all my php application work nicely (squirrelmail and phpmyadmin on apache2). Therefore I would recommend to re-add ~ppc to the keywords (or are there other examples for problems?) After the removal of ~ppc from PHP 5.0.4 I had to accept keyword ~x86 to keep emerge from complaining. I had also to mask squirrelmail since this package wants to pull in PHP4.4.0 My recommendation: accept ~ppc and fix squirrelmail Best Dirk
Just to add that the missing deps are now keyworded for ~amd64, and I have added dev-lang/php-4.4.0 and dev-lang/php-5.0.4 back to ~amd64. They are both working very well on my server.
dev-php/mod_php doesn't honor the "pdflib" keyword, although php has support for it (configure --with-pdflib). Will submit modified ebuild as attachment for mod_php-4.4.0-r3
Created an attachment (id=69484) [edit] Modified mod_php ebuild for pdflib support
Thanks, but: a) USE flags and features directly used in PHP go into it's corresponding Eclass (in this case php-sapi.eclass for mod_php). b) mod_php will be deleted from the tree on 8th January 2006, please migrate to dev-lang/php. mod_php will only be updated in case of _critical_ bugs and/or security fixes. c) pdflib will not be enabled in PHP directly, not in mod_php and neither in dev-lang/php. Please use the pecl-pdflib package wich provides this functionality, thanks. Best regards, CHTEKK.
we're currently testing a new alias system, sorry for the bugspam
Sorry for bugspam, checking up on all php-bugs. Best regards, CHTEKK.
I don't know if this is one for the list, but installing php4 only and you have sasl USE set ebuild halts complaining this flag require USE ldap also to be set. Doesn't look aright to me?
(In reply to comment #48) > I don't know if this is one for the list, but installing php4 only and you have > sasl USE set ebuild halts complaining this flag require USE ldap also to be set. > Doesn't look aright to me? But it is. The "sasl" USE in PHP enables SASL support for the LDAP extension, so it's required you also enable the "ldap" USE flag. Best regards, CHTEKK.
Ok although it seem to me being much easier then to ignore it if ldap isn't set as in this case I had sasl set globaly, and I'm running unstable, so normally doesn't bother with package.use but no problem, I just found it easer to ignore in a general sense but there might be other things behind it I'm not aware of. Btw, an other thing and I'm not sure if this matter either, but better one report too much then... When only installing php4 it's easy to conclude you don't need to bother about the eselect, but I was currious and found that syms are initially set starting with // until you have done a eselect set, as below. But it not be of any importance? merc ~ # eselect php set php4 merc ~ # stat /usr/bin/php /usr/bin/php-cgi /usr/bin/phpize /usr/bin/php-config | grep File File: `/usr/bin/php' -> `/usr/lib/php4/bin/php' File: `/usr/bin/php-cgi' -> `//usr/lib/php4/bin/php-cgi' File: `/usr/bin/phpize' -> `//usr/lib/php4/bin/phpize' File: `/usr/bin/php-config' -> `//usr/lib/php4/bin/php-config'
(In reply to comment #45) > Thanks, but: > b) mod_php will be deleted from the tree on 8th January 2006, please migrate to > dev-lang/php. mod_php will only be updated in case of _critical_ bugs and/or > security fixes. Is there a "new" mod_php-ebuild? How should i install apache2+mod_php+pdflib see bug #111449 > c) pdflib will not be enabled in PHP directly, not in mod_php and neither in > dev-lang/php. Please use the pecl-pdflib package wich provides this
(In reply to comment #51) > Is there a "new" mod_php-ebuild? How should i install apache2+mod_php+pdflib > see bug #111449 Please, stop bugspamming us. I've already answered repeatedly on the other bug, that pdflib has been moved to PECL and there's dev-php/PECL-pdflib for old dev-php/mod_php ebuilds and dev-php{4,5}/pecl-pdflib for new dev-lang/php-{4,5} ebuilds. Support question belong to forums.gentoo.org or #gentoo-apache on IRC. TIA.
SPARC has all of the packages asked for marked as ~sparc. Is this ticket also going to be used for stablization or can we remove ourselves from the list?
Please don't include the ppc-macos keyword in any of the ebuilds. We will mark them once they are in the tree and sufficient infrastructure is available.
Weeve: I have no preference. Happy to use this bug to stabilise too, or (if you prefer) happy to handle that under another bug. Let us know what you prefer. Best regards, Stu
added finaly ~ppc64 to packages in comment #4. please readd ppc64 if you want to use this bug for stable marking.
A seperate bug would be preferred. Thanks
alpha/arm/ia64/s390 should be done
ppc has been done for a bit, please re-add us if you need any other keywording done
Looks like everything has x86 in those categories. Please CC us on the stablization bug.
When I try: shapeshifter ~ # emerge online-bookmarks Calculating dependencies ...done! >>> emerge (1 of 4) dev-php/PEAR-PEAR-1.3.6-r4 to / >>> checksums files ;-) PEAR-PEAR-1.3.5.ebuild >>> checksums files ;-) PEAR-PEAR-1.3.6-r4.ebuild >>> checksums files ;-) files/pear.conf >>> checksums files ;-) files/digest-PEAR-PEAR-1.3.6-r4 >>> checksums files ;-) files/digest-PEAR-PEAR-1.3.5 >>> checksums src_uri ;-) Archive_Tar-1.3.1.tgz >>> checksums src_uri ;-) Console_Getopt-1.2.tgz >>> checksums src_uri ;-) XML_RPC-1.4.5.tgz >>> checksums src_uri ;-) PEAR-1.3.6.tgz !!! ERROR: dev-php/PEAR-PEAR-1.3.6-r4 failed. !!! Function require_php_cli, Line 360, Exitcode 0 !!! No PHP CLI installed !!! If you need support, post the topmost build error, NOT this status message. Is that part of this bug? Do I need to write a new one?
(In reply to comment #61) > !!! No PHP CLI installed > !!! If you need support, post the topmost build error, NOT this status message. > Is that part of this bug? Do I need to write a new one? This bug is about keywording *only*, please don't clutter it. And there's no bug in what you have posted either, you simply missed USE=cli when emerging dev-lang/php (as the error message says). You can't use pear without CLI SAPI.
Superseded by bug 119461 and bug 119722 (et al.).
