Bugzilla Bug 56295

For all non-x86 arches.
The PHP development herd is trying to move ahead to get our tree into a good state for PHP5, including a large scale cleanup of both our ebuilds and old eclasses.

high priority - allow for eclass cleanup, and compatibility with parts of PHP5, important PHP bugfixes:
dev-php/php-4.3.7-r1
dev-php/php-cgi-4.3.7-r1
dev-php/mod_php-4.3.7-r1

medium priority - if you have one of the above ebuilds supported by your arch, you MUST have these ebuilds in ~arch at the very minimum, stable is recommended for ppc/sparc - needed for our PHP5 work - these are all pure PHP code:
dev-php/PEAR-Date-1.4
dev-php/PEAR-HTML_Common-1.2.1
dev-php/PEAR-HTML_Javascript-1.1.0
dev-php/PEAR-HTML_QuickForm-3.2.1
dev-php/PEAR-HTML_Select_Common-1.1-r1
dev-php/PEAR-HTML_Template_Flexy-0.6.3
dev-php/PEAR-HTML_Template_Sigma-1.0.2
dev-php/PEAR-I18N-0.8.6
dev-php/PEAR-Image_IPTC-1.0.2
dev-php/PEAR-Log-1.8.3
dev-php/PEAR-MDB-1.2
dev-php/PEAR-Mail_Mime-1.2.1-r1
dev-php/PEAR-Net_Sieve-0.9.0
dev-php/PEAR-Net_SmartIRC-0.5.5_p1
dev-php/PEAR-Net_Socket-1.0.1-r1
dev-php/PEAR-OLE-0.5
dev-php/PEAR-PEAR_Info-1.5.2
dev-php/PEAR-Spreadsheet_Excel_Writer-0.7
dev-php/PEAR-System_Command-1.0-r1
dev-php/PEAR-Text_Wiki-0.8.2
dev-php/PEAR-XML_Beautifier-1.1
dev-php/PEAR-XML_CSSML-1.1-r1
dev-php/PEAR-XML_RSS-0.9.2
dev-php/PEAR-XML_Tree-2.0_beta2
dev-php/PEAR-XML_XPath-1.2-r1

low priority - well-used packages, just check for compiling then mark as ~arch:
dev-php/adodb-4.0.5
dev-php/phpxmlrpc-1.0.99.2
dev-php/memcached-client-php-0.1.2
dev-php/sqlite-php-0.0.5
dev-php/PECL-sqlite-1.0.2
dev-php/turck-mmcache-2.4.6
dev-php/PEAR-PhpDocumentor-1.3.0_rc3

lowest priority - these get very little use, mark as ~arch on successful compile if you have time:
dev-php/PECL-apc-2.0
dev-php/PECL-imagick-0.9.8-r1
dev-php/asp2php-0.76.19
dev-php/ioncube_loaders-2.4
dev-php/php-accelerator-1.3.3-r1
dev-php/xdebug-1.3.0

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.