Closed (fixed)
Project:
Drush
Component:
PM (dl, en, up ...)
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Anonymous (not verified)
Created:
12 Jan 2012 at 01:06 UTC
Updated:
19 May 2023 at 18:29 UTC
Jump to comment: Most recent file
Comments
Comment #1
fr34ck commentedI have the same issue.
I'm on site5
Comment #2
vuzzbox commentedSame issue.
Command: drush pm-update date
Messages:
Could not download project status information from d/d/d [error]
Invalid argument supplied for foreach() drush.inc:199 [warning]
Security updates will be made to the following projects: Date [date-6.x-2.8]
Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): y
Project date was updated successfully. Installed version is now 6.x-2.8.
Backups were saved into the directory [ok]
/usr/svm/drush-backups/empa01-011_staging/20120113023359/modules/date.
Backups were restored successfully. [ok]
Comment #3
mojzis commentedwhen i run it with -d i get several screens of this :
then the list of modules and :
runinng on CentOS with php 5.3
Comment #4
capellicI am having the same issue.
Comment #5
edulterado commentedSame issue here, I´m experimenting it with Godaddy as well, btw (Drupal 6.x, All-versions-5.x-dev).
Before showing the list of available updates, I got this error message with one warning:
Then, it seems that the update process begins as it normally does, but no module is updated at the end.
drush dl <module>works as expected.Comment #6
grossmann commentedSame here. If I try drush self-update I get this:
Could not download project status information from d/d/dOn a drush up -projectname- this:
Onward it says that the module is updated but it isn't.
Back to 4.5 (I began to like the autocomplete feature :-( ).
grossmann-mcs
Comment #7
mojzis commentedthe same happens with self-update. imho this deserves some attention, so i have raised the priority. newest version from git doesnt do it (on a different machine though).
i suppose that $request['status url'] comes prefiled with some nonsense to the function release_info_fetch() function
this is drush installed with pear and then self-updated to dev-5 (because of problems with php 5.3)
Comment #8
Larry Jones commentedBased on my godaddy shared host experience, this is a php version issue. I fixed it by creating this .bashrc file in root (same directory that contains html directory):
Edit this to match your environment. For example, I installed drush in ~/.drush, which may not match your choice.
This cleaned up all the odd problems using drush version 4.5 on godaddy for me.
Comment #9
greg.1.anderson commentedDrush self-update should have been completely removed from Drush-5, but I see that "drush help self-update" is still producing output. Hmmm.
In any event, please try using pm-update with other Drupal modules. If you are having trouble with godaddy, check to see if you are using php-cgi instead of php-cli. pm-updatecode is working well in master for most people, and the unit tests are passing. It is entirely possible that there are configuration-specific bugs in pm-updatecode, but we will need more information to reproduce if they are going to be found and fixed.
Comment #10
brianbeam commentedI am having the same problem with Drush 5x. Unable to update modules. Appears that the modules are backed up, new ones downloaded, but the old ones are then restored from backup.
The PHP version is on the affected server is:
PHP 5.3.2-1ubuntu4.11 with Suhosin-Patch (cli) (built: Dec 13 2011 18:45:32)
As a test, Drush 5 updates work properly on a similarly configured server. But the PHP version is slightly older:
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) (built: May 3 2011 00:43:34)
Comment #11
greg.1.anderson commentedI am using
PHP 5.3.6-13ubuntu3.2 with Suhosin-Patch (cli) (built: Oct 13 2011 23:19:13), so the PHP version is probably not a contributing factor. Anything that you could do to isolate the difference between the working and non-working installations would be very helpful.One question that comes to mind is whether it is the modules that need to be updated that make the difference. Perhaps you could post the working and non-working module + version list, if that is in fact the factor that causes the failure. Also, if the old modules are being restored from backup, that indicates that drush_set_error is being called. If you run with --debug, you should get more information about what is causing the rollback.
Comment #12
mojzis commentedin my case (#3 above) the modules to update were date and google_analytics
drupal 6 - could that be the difference ? and the debug option yielded several interesting things :
in my case it is not Go Daddy, but MT with CentOS, setup (screwed) with Plesk (i.e. - php.ini is shared for cli and apache - is this usual on CentOS ? or is it a Plesk specialty ?). APC was setup to work with cli, otherwise drush was extremely slow.
Comment #13
brianbeam commentedIn my case (#10) the modules affected are date and webform.
Date (date) 6.x-2.7 6.x-2.8 SECURITY UPDATE available
Webform (webform) 6.x-2.10 6.x-3.15 SECURITY UPDATE available
I've attached the contents of the debug session.
Comment #14
brianbeam commentedAlso getting an error simply doing a "drush version"
$ drush version
drush version 5.0-dev
Could not download project status information from d/d/d [error]
Invalid argument supplied for foreach() drush.inc:199 [warning]
Comment #15
njcheng commentedUnfortunately I'm having the same issue on multiple servers (ubuntu 10.04.3 LTS and Debian 5) after upgrading from a previous dev version. No matter what command I run, I get the following output:
Could not download project status information from d/d/d [error]
Invalid argument supplied for foreach() drush.inc:199
What information can I provide that would be helpful in getting this fixed? Thanks!
Comment #16
mry4n commentedI'm having the same issue as #14.
Comment #17
jonhattand/d/d error fixed at #1419576: self-update broken in 5.x dev.
@greg.1.anderson: self-update remains, but only informs of new version. See #1324948-2: Vestiges of selfupdate still present