Description: ------------ I have almost never been able to use the "pear" command. I always times out before downloading packages. like: [root@tux ~]# pear install --alldeps Mail Could not download from "http://pear.php.net/get/Mail-1.1.10.tgz", cannot download "pear/Mail" Error: cannot download "pear/Mail" Could not download from "http://pear.php.net/get/Net_SMTP-1.2.8.tgz", cannot download "pear/Net_SMTP" Error: cannot download "pear/Net_SMTP" Could not download from "http://pear.php.net/get/Net_Socket-1.0.6.tgz", cannot download "pear/Net_Socket" Error: cannot download "pear/Net_Socket" Could not download from "http://pear.php.net/get/Auth_SASL-1.0.2.tgz", cannot download "pear/Auth_SASL" Error: cannot download "pear/Auth_SASL" When going to you webside and finding the packages and trying to download it can't. (firefox) This is not just a temporary problem with your server, it has been like this for years, I think it about works 1 out off 10 times I have tryied. It is really annoying when you reaaly need a package to get on with your work, that you have to find it on google. Where is the mirror sites for pear.php.net ?

Do you use a proxy? Use the verbose method pear -vvv cmd options. Our server works well.

I had the same issue as described. The problem happened because I initially installed a local pear repository as the root user. The next day, I changed the permissions to another user account, but that user couldn't install any new packages because the /tmp/pear/ directory was still present from the previous day, and it was owned by the root user. After I removed the /tmp/pear/ directory, I was able to install new PEAR packages without any problems.

a permission problem is not a PEAR bug.

this is a problem in PEAR - PEAR does not inform of the failure reason. In many cases, it breaks everything. The same happens if there is a file named "package.xml" or "package2.xml" in the temp directory that is marked read-only. The problem was introduced with PEAR 1.4.10 download_dir/temp_dir fixes

This bug is older than 1.4.10. The problem is not the temp_dir and download_dir additions but the lack of correct error reporting (in many parts of the stack). However yes, I bogus'ed this bug based on the last comment, but the initial report is valid, back to open, unassigned for now.

agreed, error reporting is the culprit. I had a live site completely stop working because of the temp_dir addition in 1.4.10, took me a long time to track it down to the package.xml issue in my last comment. No matter, this will be fixed soon.

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.