There seems to be a problem with the make file and some versions of drush and drush make.
This is a report from paskainos over at #1435352: Update INSTALL.txt for make file:
Yes, please update INSTALL.txt to avoid user confusion. Also, the drupal-org.make file passes verification, but git cloning for most (actually, it looks like 'all') of the non-stable modules is failing. Here's what I'm seeing:
Unable to clone ns_core from [error]
git://git.drupal.org/project/ns_core.git.
Unable to clone defaultconfig from [error]
git://git.drupal.org/project/defaultconfig.git.
Unable to clone ctools from git://git.drupal.org/project/ctools.git. [error]
Unable to clone uuid from git://git.drupal.org/project/uuid.git. [error]
Unable to clone views_rss from [error]
git://git.drupal.org/project/views_rss.git.
Unable to clone draggableviews from [error]
git://git.drupal.org/project/draggableviews.git.
Unable to clone wysiwyg from [error]
git://git.drupal.org/project/wysiwyg.git.
Unable to clone media_youtube from [error]
git://git.drupal.org/project/media_youtube.git.
Unable to clone pathfilter from [error]
git://git.drupal.org/project/pathfilter.git.
Unable to clone admin_menu from [error]
git://git.drupal.org/project/admin_menu.git.
Unable to clone entityreference from [error]
git://git.drupal.org/project/entityreference.git.
Unable to clone crossclone from [error]
git://git.drupal.org/project/crossclone.git.
Unable to clone panels_ref_formatter from [error]
git://git.drupal.org/project/panels_ref_formatter.git.
He also posted a patched that resolved the issue that resolved the issue for his version of drush make.
We previously had the links in our make file, but we webchick and dww pointed out that this would throw off the drupal build system, so we removed it, see #1432210: Changes to nodestream required to work with new packaging system . When building with drush 4.5 together with the latest drush make, you get no errors.
Comment | File | Size | Author |
---|---|---|---|
#10 | 1440668-10.drush-make-git-default-url-http.patch | 809 bytes | dww |
added_git_project_links-1435352-5593248.patch | 4.22 KB | fabsor |
Comments
Comment #3
paskainos CreditAttribution: paskainos commentedUsing
PHP 5.2.17
, I was runningDrush 4.5
/Drush Make 2.3
at the outset of this issue. Then Idrush selfupdate
'ed to7.x-5.0-rc2
which led to this issue. So then I switched toDrush 5.0-dev
, and I'm still experiencing problems.Here are the steps I'm using:
drush dl
mv drupal-7.12 site
cd site/profiles
git clone --branch 7.x-2.x http://git.drupal.org/project/nodestream.git
cd nodestream
** All's well up to this point. Then I run: **
drush make --no-core drupal-org.make
** After which I get: **
So my first question at this point is; based on the afoermentioned issue, could this be a PHP 5.2 conflict?
Comment #4
paskainos CreditAttribution: paskainos commentedAnd once again, reverting the
drupal-org.make
file (formerlynodestream.make
) to exclude[version]
and include[url]
works fine (now usingDrush 5.0-dev
).Comment #5
fabsor CreditAttribution: fabsor commentedThis definitely has to do with drush 5. I'm changing the name to reflect that.
Comment #6
fabsor CreditAttribution: fabsor commentedSo I switched to drush 5 and tried to do a build and that worked fine. I installed my version through pear. There must be some twist on this, like the PHP version that you mentioned. I'm running PHP 5.3.
Comment #7
gumdrop CreditAttribution: gumdrop commentedWell I am using Drush 5.0-dev before rc2 and had no issues. I am not upgrading to rc2 because it's still "yellow" and has obvious issues.
Comment #8
fabsor CreditAttribution: fabsor commentedI finally tracked this down. The issue is not with Drush make or the format we are currently using - it's simply because we are using git:// and not http:// when fetching our repos.This works well for most people, but if you are behind a firewall that does not allow traffic on the port that git is using, you can't download anything from drush make, or clone anything using git:// for that matter. I'm moving this over to the drush issue queue, where we can discuss how we should fix this.
Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedIt looks to me like drupal.org recommends using http when one is not a maintainer (the common case) so we should probably default to that. I think ssh:// might be needed when one needs to authenticate. For example, see project instructions like http://drupal.org/node/97249/git-instructions/7.x-4.x
Comment #10
dwwTrivial patch. Verified it works. It's hard to have unit tests for this since md5 checks on --working-copy will change whenever there's a commit to the repo in question. I guess we could have a test that doesn't rely on md5 comparison, but that seems like more of a can of worms than I want to get into for fixing this. ;)
Comment #11
joestewart CreditAttribution: joestewart commentedjhedstrom pointed me to how testInfoFileWritingGit() in makeTest.php reads the hash in the .info file since the md5 will be changing. So I read the hash in .git/HEAD for a test in #1206340: introduce an options array in the root level of the makefile.
Comment #12
joestewart CreditAttribution: joestewart commentedOn second thought don't our other git tests cover this? Just without using working-copy or changing the .info file.
Comment #13
dwwYeah, the existing tests continue to pass and keep working. What I'm saying is that it's hard to write a test to verify that the default URL is actually using http not git. To do so, you need to use --working-copy and inspect the resulting .git/config file. However, once you turn on --working-copy, you can no longer get reliable md5 hashes of the build directories, since the hash will change every time there's a commit to any repo we're cloning.
So, our choices are:
A) Write a test that *just* inspects .git/config and doesn't try to compare md5 hashes (although I'm not sure how to do this).
B) Ignore a test specifically for this feature, and just acknowledge that it works. ;)
Comment #14
jhedstromYou could also capture the output of
git remote -v
to verify the proper remote url is used. No need to actually perform an md5 test, this could be done by building one of the test .make files with--working-copy
.Comment #15
moshe weitzman CreditAttribution: moshe weitzman commentedCommitted. I mulled this a bit and decided for Option B from #13. We'll be OK without a test for this small change.
Comment #16.0
(not verified) CreditAttribution: commentedFix issue links