| Summary: | PHP packages to mark stable - for non-x86 arches | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Robin Johnson <robbat2> |
| Component: | [OLD] Server | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | hppa |
| Priority: | Highest | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Robin Johnson
2004-07-06 18:27:34 UTC
Done it last night on PowerPC for all packages except the following: - ioncube_loaders - PEAR-PhpDocumentor - php-accelerator All done on alpha. php, mod_php, and php-cgi and stable on sparc, rest still need to be done. I've looked so far at everything up to and including PEAR-System_Command for the medium priority packages. Found a few things in testing that may want to be fixed. Note that I don't use PHP much so I could be botching things here. If so let me know. PEAR-Date needs PHPUtils.php for tests (not currently installed on my system, what package?) PEAR-HTML_QuickForm needs PEAR-HTML_Template_Flexy to have docs work (and HTML/Template/ITX.php, what package?) PEAR-I18N needs Tree/OptionsDB.php and HTML/IT.php for docs to work (what package?) PEAR-HTML_Template_Flexy Test.php needs Gtk/VarDump.php (what package?) PEAR-HTML_Template_Sigma needs PHPUnit.php for tests (what package?) PEAR-Log - /usr/lib/php/doc/Log/docs/examples/pear_error_handler.php can't find class pear PEAR-MDB needs PHPUnit for tests PEAR-Net_Sieve needs a ./passwords.php for test to work The PEAR packages in dev-php/PEAR* exist primarily as they are needed as dependancies for various webapps. For PEAR packages not in portage, there is the 'pear' utility, modeled somewhat after Perl's CPAN. Coredumb was working on a g-pear (like g-cpan.pl), but he's never released it for general use. > PEAR-Date needs PHPUtils.php for tests (not currently installed on my system, > what package?) PHPUtils is this: http://www.zippydesign.com/ying/phputils/ Entirely useless as anything except examples. > PEAR-HTML_QuickForm needs PEAR-HTML_Template_Flexy to have docs work (and > HTML/Template/ITX.php, what package?) ITX is in PEAR-HTML_Template_IT, which I've just added for you. 99.999% of people looking for the docs see them via http://pear.php.net/ anyway. I've made a new revision with these in the deps. > PEAR-I18N needs Tree/OptionsDB.php and HTML/IT.php for docs to work > (what package?) PEAR-HTML_Template_IT is in now, see about. I'm not adding PEAR-Tree at this time, it's upstream doesn't consider it stable. > PEAR-HTML_Template_Flexy Test.php needs Gtk/VarDump.php (what package?) I'm not doing to add PEAR-Gtk_VarDump, if you want it yourself for tests, you'll need php-gtk and then you can use Pear to get it. > PEAR-HTML_Template_Sigma needs PHPUnit.php for tests (what package?) PEAR-PHPUnit, added now. > PEAR-Log - /usr/lib/php/doc/Log/docs/examples/pear_error_handler.php > can't find class pear Upstream example out of date, not our problem. > PEAR-MDB needs PHPUnit for tests PEAR-PHPUnit, added now. sparc: I'm still waiting for you on the medium priority stuff ... Sorry for the slow going. Very few of the packages seem to have anything that depends on them which makes testing more difficult. XML_Beatifier doesn't seem to be working, though not sure what the problem is. No errors are reported but it doesn't seem to be functioning as the example they give should, and no output xml file is generated. unfortunely a lot of upstream PEAR suffers from their examples being badly out of date relative to their code. Some more notes from testing PEAR-XML_CSSML - looking for libxslt.php in /usr/lib/php/XML_CSSML/CSSML when it gets installed to /usr/lib/php/extensions/no-debug-non-zts-20020429/XML_CSSML/CSSML PEAR-XML_RSS - doesn't seem to work, example script to show RSS feeds just returns an empty list If possible, can you provide or point to valid examples with which to test? Otherwise it may be a while before we can get these all knocked out. I've put out a new revision of PEAR-XML_CSSML, to force the files to /usr/lib/php/XML_CSSML/CSSML (I assume you meant it was looking for libxslt.xsl). The upstream package.xml specified to install the content in the extensions directory, so we followed it as it said until now. The PEAR-XML_RSS testcase with a single fix (correcting require for the include path, the correct value is 'XML/RSS.php') works 100% perfectly both manually and with pear's automated testing. So what webapps are most or all of these packages dependencies for? I've been using gentoo-portage.com to check reverse dependencies on them, and other than a few packages that have reverse dependencies on other PEAR packages, none of them seem to have any packages that depend on them. Since a good number of these packages have broken testing scripts, having a test plan or script for each one would be very valuable and save time for all of us. Weeve: it's not so much the present webapps, as many of the future ones.
also, some of the webapps bundle their own copies of the PEAR classes, just to complicate matters. furthermore, unless upstream specifically mentions the word 'PEAR' in their (often non-existant) documentation, it's very hard to grep and find what is being used.
off the top of my head, for some webapps (Should be most of dev-php, net-www):
phpgroupware: PEAR-DB PEAR-PHPUnit
tikiwiki: PEAR-PHPUnit PEAR-DB PEAR-Date PEAR-PHPUnit PEAR-Net_Socket
phpwebsite: a massive set of them. see ${S}/lib/pear
horde-*: a massive set of them. see horde-pear for upstream's collection of them. I'd like to replace horde-pear with a large set of dependancies on the PEAR packages directly, for easier upgrading.
drupal: PEAR-DB
dotproject: PEAR-Date
webapps _is_ working on trying to put together a list of all PEAR packages in use, as the conversion to the new webapp-config is being done.
whoops, closed by accident. In emerging PEAR-Date-1.4 I get a whole load of errors like the following as it does the src_install portion of the package PHP Warning: Function registration failed - duplicate name - mssql_connect in U nknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_pconnect in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_close in Unk nown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_select_db in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_query in Unk nown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_free_result in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_get_last_mes sage in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_num_rows in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_num_fields i n Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_fetch_field in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_fetch_row in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_fetch_array in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_fetch_object in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_data_seek in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_field_seek in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_result in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_min_error_severity in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - mssql_min_message_severity in Unknown on line 0 PHP Warning: mssql: Unable to register functions, unable to load in Unknown on line 0 Should I care about that or not? weeve: you compiled with both USE="freetds mssql" didn't you? while we do support it (and it does work if you write your PHP carefully), it's strongly recommended that you pick one OR the other. Yeah, on a couple of my boxes I try to compile php with as many useflags as possible to help ensure that php will build with them enabled. I tried looking at the packages you mentioned, but none of them actually dependencies on any of the PEAR-* packages. Do you have a rough eta on when the webapp list of PEAR using packages will be done? weeve: heavily in need of more dedicated webapp+php manpower to complete it. i've got one possible candidate as php dev, but many more are needed to bring it up to speed. updated versions of the primary set have been out for a while now. dev-php/php-4.3.8 dev-php/php-cgi-4.3.8 dev-php/mod_php-4.3.8 ia64/s390: I've seen absolutely no response from you on this bug, nor any of the PHP security advisory bugs, where you should have bumped versions up to the above packages. s390 is headless currently. i.e. there is no gentoo developer that is willing to maintain any s390 related stuff. you'd better just ignore the presence of s390 for now all set on ia64, sorry for the lag :-| I'll take care of this first thing tomorrow all done on ppc All of the high priority bugs are stable on sparc. As for the rest, they now have ~sparc keywords other than the 3 problematic packages below; PEAR-PhpDocumentor-1.2.3 failes with the error; Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 169 bytes) in /usr/lib/php/PEAR/Installer.php on line 374 Allowed memory size of 8388608 bytes exhausted (tried to allocate 0 bytes) ioncube-loaders have a bad digest php-accelerator seems to be fetching from a bad URL now, so the content downloaded is unusable. Many (most?) of these are missing KEYWORDS=[~]amd64. What needs to be done to add support? $ cd /tmp $ for i in /usr/portage/dev-php/*; do ls $i/*.ebuild | tail -n1 | xargs egrep ^KEYWORDS; done > keywords $ grep -c x86 keywords 56 $ grep -c ppc keywords 51 $ grep -c sparc keywords 47 $ grep -c amd64 keywords 6 PHP duders, Do the problems encountered in comment #24 cause an issue for you folks, or is SPARC now all set? weeve: sparc should be all set now, i'm removing you from the CC. Thanks. all done except: - php-cgi-4.3.7-r1 (fails on configure, needs sablotron) - PECL-imagick-0.9.8-r1 - ioncube_loaders - PEAR-PhpDocumentor - php-accelerator argh, forgot to remove us :) i'm closing this now, as hppa and s390 are slow moving unstable anyway it seems. |