Bug #5301 [Opn->Csd]: pear list-all empty

Edit report at http://pear.php.net/bugs/bug.php?id=5301&edit=1 ID: 5301 Updated by: pajoye@php.net Reported By: bertrand at toggg dot com -Status: Open +Status: Closed Id: 5301 Type: Bug -Package: PEAR +Package: Web Site Operating System: fc3 PHP Version: 4.3.11 -Assigned To: +Assigned To: pajoye New Comment: This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. It was originally a pearweb problem and is fixed. Every other problems _not_ related must go to a specific bug report. Previous Comments: ------------------------------------------------------------------------ [2005-09-09 01:12:29] bertrand at toggg dot com Congrats ! Using the corrected (with encooding) release rest info .xml files did solve the list-all problem (verfied by Klaus and I). However, the ineffective raiseError() problem remains, certainly the same as #5319. So, we cannot yet close this bug. ------------------------------------------------------------------------ [2005-09-06 17:25:55] klaus at capitalfocus dot org Apparently, error handling is turned off. And it seems that there are several places in the code where references were fixed in the latest 1.3 branch, but not merged into head. Maybe I'm mistaken, but between that and suppressed errors, that's going to bite us. I would be happy if Bertrands patch would be accepted. And if the list-all wouldn't fail instantly on a bad package. Rather, how about looping through, ignorning the bad packages (since they're individual files with REST) and printing errors at the end of the list? (or at the top) Also, I forgot to rewrite a portion of my report yesterday. I tried it both with and without xmlrpc and both times it failed. ------------------------------------------------------------------------ [2005-09-06 16:28:58] bertrand at toggg dot com This bug presents 2 problems: * why Services_Amazon produces it now, this package was released last year ... and b1 seems to accept it. * why the error does not show up but stop the process. It seems that the error mode is set to RETURN at this moment which inhibates its triggering. The numerous push/pop/set error handling from diffferent objects obfuscates the origins... Anyway , a PEAR_Error returns back to pearcmd.php (which test false) so nothing from this script too but stop. Much generally, it's uneasy to debug and track the errors, it should be very advisable when verbose set , say to 3, to have the error_handler() throw *1* line for any error (even E_STRICT if error_reporting() is set that way), the general silencing makes loose of lots of notices/warning. If, needed, I can produce a patch for it. ------------------------------------------------------------------------ [2005-09-05 19:07:12] bertrand at toggg dot com Confirmed, with or without xmlrpc the same ------------------------------------------------------------------------ [2005-09-05 18:48:54] bertrand at toggg dot com I reproduced it with a b2 from cvs, but it was correct with b1 (from go-pear install on 20th august) It seems that the description of Services_Amazon has a single quote in it. This php5 build was with xmlrpc, but I'm not sure it's related, testing without now. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://pear.php.net/bugs/bug.php?id=5301 -- Edit this bug report at http://pear.php.net/bugs/bug.php?id=5301&edit=1