You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 27, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 27, 2019. It is now read-only.
fatal : no remote found for dependency '....' #634
{
"name": "democracyos",
"version": "0.14.0",
"description": "An online space for deliberation and voting on political proposals. The software aims to stimulate better arguments and come to better rulings.",
"paths": [
"lib"
],
"locals": [
"boot"
]
}
Okay its just being non determinate. GitHub was being DDoS'ed apparently and I think its possibly to do with this maybe as some things are now working that were not working before but for no reason. And it seems only to be with new repos, not existing ones.
I think the componentjs component architecture does not do enough retries or wait long enough at times in places like when resolving dependencies.
I am still having problems with 'component install' particularly redirects like tj/debug -> visionmedia/debug are still not getting resolved when the internet is busy even with a --timeout 480000
I seemed to have clear periods of working behaviour when the internet is quiet in the early hours in the UK, i.e. 6:00AM GMT.
It seems to be redirects that are hit worst, then newer created repositories, then when it very busy other modules at random. It looks like the '--timeout' flag does not work on all operations within 'component'.
I am in the UK so probably have longer latencies that the US.
I think its the component-resolve module is where the problem is occurring.
So search for this file within your node_modules. Be careful, if you using node without generators you need to use the index file in the build directory instead of in the lib.
you should not read the build, it's a generated code, switch to node 0.12 with --harmony or just use iojs, then you can read and execute the raw code (in the lib directory)
Okay seemed to have fixed it by using long timeouts of 240000ms I will close this issue as soon as the it has been tested at peak US and UK internet access time, later today.
Activity
AaronNGray commentedon Apr 4, 2015
On Windows the files are the same except the visionmedia/debug dependency is obviously missing in the lib/debug
is giving :-
AaronNGray commentedon Apr 4, 2015
I am getting the same error message on doing a 'make' on Linux :-
I don't know if I am missing doing something with componentjs at this stage ?
AaronNGray commentedon Apr 5, 2015
Okay its just being non determinate. GitHub was being DDoS'ed apparently and I think its possibly to do with this maybe as some things are now working that were not working before but for no reason. And it seems only to be with new repos, not existing ones.
I think the componentjs component architecture does not do enough retries or wait long enough at times in places like when resolving dependencies.
timaschew commentedon Apr 5, 2015
DEBUG=*can help to find where the error comes from, see https://github.com/componentjs/guide/blob/master/component/troubleshooting.mdcomponent uses cogent for http requests, there is a deafult timeout of 5 seconds, but you change the timeout:
component/bin/component-install
Line 13 in 1faa776
so we can close this issue?
AaronNGray commentedon Apr 5, 2015
Thanks !
AaronNGray commentedon Apr 8, 2015
I am still having problems with 'component install' particularly redirects like tj/debug -> visionmedia/debug are still not getting resolved when the internet is busy even with a --timeout 480000
I seemed to have clear periods of working behaviour when the internet is quiet in the early hours in the UK, i.e. 6:00AM GMT.
It seems to be redirects that are hit worst, then newer created repositories, then when it very busy other modules at random. It looks like the '--timeout' flag does not work on all operations within 'component'.
I am in the UK so probably have longer latencies that the US.
I think its the component-resolve module is where the problem is occurring.
timaschew commentedon Apr 8, 2015
Yep, I think this is the problem, here is the code:
https://github.com/componentjs/remotes.js/blob/0c32e97cc07dd2bbb7076fdf52102e514d4b7431/lib/remotes/github.js#L43
The options are not passed at this place.
Good catch, thanks!
AaronNGray commentedon Apr 8, 2015
Is it possible to solve this ?
I don't have good enough knowledge of the component codebase.
Aaron
On 8 April 2015 at 11:00, Anton Wilhelm notifications@github.com wrote:
timaschew commentedon Apr 8, 2015
I was wrong, it's not the problem, I add a
console.loginto every request and the timeout option works fine:timaschew commentedon Apr 8, 2015
Cannot go further without any debug lines
AaronNGray commentedon Apr 8, 2015
Anton,
As I am experiencing the problem at this end I suppose I need to do the
debugging here.
Is it possible you can push what you have done onto a github repo or branch
and give me instructions on how to set it up for debugging ?
On 8 April 2015 at 17:58, Anton Wilhelm notifications@github.com wrote:
timaschew commentedon Apr 8, 2015
I just added a console.log after this line with the ´timeout` value: https://github.com/timaschew/cogent/blob/patch-1/lib/index.js#L39
So search for this file within your node_modules. Be careful, if you using node without generators you need to use the index file in the build directory instead of in the lib.
AaronNGray commentedon Apr 8, 2015
Yeah I have tried DEBUG=* but there seem to be no debug lines at the
relevant points so I suppose I need to further instrument the code.
I have found the line that throws up the actual fatal throw line :-
Not sure how the build directory gets there from looking at componentjs/resolver.js
I find this code very hard to follow !
timaschew commentedon Apr 8, 2015
line 565 form in build comes from line 130 in the source: https://github.com/componentjs/resolver.js/blob/master/lib/semver.js#L130
you should not read the build, it's a generated code, switch to node 0.12 with --harmony or just use iojs, then you can read and execute the raw code (in the lib directory)
AaronNGray commentedon Apr 8, 2015
AaronNGray commentedon Apr 9, 2015
Okay seemed to have fixed it by using long timeouts of 240000ms I will close this issue as soon as the it has been tested at peak US and UK internet access time, later today.
AaronNGray commentedon Apr 9, 2015
Ah its still not working on a Windows VMWare with Fedora installed, even with a timeout of 480000 !
So there is some form of timing latency or retry problem, probably not enough reties at some points in the code.
See issue https://github.com/UKDemocracyOS/app/issues/1
AaronNGray commentedon Apr 10, 2015
Okay its not working on deployment on my Fedora F20 i686 HP DL140 G3 Dual Core Servers
I think either there is a race condition in the code or there are no retries or not enough retries.
rickdog commentedon Apr 26, 2015
win64 with npm v2.1.18
npm install component fails for certain shells: msys32 msys64, cygwin64 bash - POSIX filenaming incompatibiliity.
use regular cmd or git bash
AaronNGray commentedon Apr 26, 2015
I use CMD on Windows. But was getting the problem there at times of high
level internet usage, when UK and US were quiet the problemS ceased.
It still looks like a timing and retry issue to me. As it also happens on
Linux VM's under VMWare on Windows. And on my Fedora 21 Linux machine too.
Its intermittent basically.
On 26 April 2015 at 07:10, rickdog notifications@github.com wrote: