Sorry, I have to put it bogus.
The problem was due to a double pear installation I missed from the go-pear tests. So the wrong executable was a PHP5.1 build.
After discarding it, problem was solved.

Reopening this bug. I'm running on 5.1 snap of this evening. Suse 9.1. Pear installed using the wonderful Makefile.frag patch :)

I'm still getting this error. Bertrand pointed out on the list that the difference between his install and mine is that I have xmlrpc enabled, while he doesn't.

Putting a var_dump($available); after line 292 gives me the following output:

object(PEAR_Error)#18 (8) {
  ["error_message_prefix"]=>
  string(0) ""
  ["mode"]=>
  int(1)
  ["level"]=>
  int(1024)
  ["code"]=>
  NULL
  ["message"]=>
  string(126) "Invalid xml downloaded from "http://pear.php.net/rest/p/services_amazon/info.xml": XML Error: 'Invalid character' on line '10'"
  ["userinfo"]=>
  NULL
  ["backtrace"]=>
  NULL
  ["callback"]=>
  NULL
}

What happens then is that the error handler should kick in (as the error is recognized and a PEAR_Error is returned), but instead, nothing happens. I'm not sure exactly where to go from here. I don't know the installer source well enough to fix it.

nice sleuthing, that should be enough to kill it

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.

Confirmed, with or without xmlrpc the same

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.

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.

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.

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.