php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56526 pear list-all empty
Submitted: 2005-09-05 10:10 UTC Modified: 2005-09-14 07:15 UTC
From: bertrand at toggg dot com Assigned: pajoye (profile)
Status: Closed Package: PECL website (PECL)
PHP Version: 4.3.11 OS: fc3
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: bertrand at toggg dot com
New email:
PHP Version: OS:

 

 [2005-09-05 10:10 UTC] bertrand at toggg dot com
Description:
------------
with b1 or cvs:

pear list-all does not output anything

(default pear channel)

but pear remote-list is ok

Seems never to enter in doListAll(), where you have some unbraced if, btw.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-05 16:51 UTC] bertrand at toggg dot com
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.
 [2005-09-05 18:38 UTC] klaus at capitalfocus dot org
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.
 [2005-09-05 18:40 UTC] cellog@php.net
nice sleuthing, that should be enough to kill it
 [2005-09-05 18:48 UTC] 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.
 [2005-09-05 19:07 UTC] bertrand at toggg dot com
Confirmed, with or without xmlrpc the same
 [2005-09-06 16:28 UTC] 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-06 17:25 UTC] 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-09 01:12 UTC] 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-14 07:15 UTC] pajoye@php.net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Nov 09 13:01:28 2024 UTC