I have been working on this all day, to no avail. I continue to get messages like the one shown below, resulting in a partial install of the MinGW and MSYS system. Doesn't seem to matter which components I choose to install. Starting with the GUI installer, but trying it on the command-line with an mingw-get update also gives similar failures.
Very frustrating. Doesn't matter if I do this at work, from behind a firewall or at home. Both network connections are veyr fast and reliable, There doesn't seem to be a way to force a different site for the download, if there is a way to do that, sure would appreciate understanding how, maybe it would solve the problem.
example error message: and full log attached
- - - - -
mingw-get.exe: *** WARNING *** http://prdownloads.sourceforge.net/mingw/inetutils-1.7-1-msys-1.0.13-bin.tar.lzma?download: opened with unexpected status: code = 404
mingw-get.exe: *** WARNING *** please report this to the mingw-get maintainer
mingw-get.exe: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/inetutils-1.7-1-msys-1.0.13-bin.tar.lzma?download: download failed
mingw-get log file -- with errors
I know this probably isn't what you want to hear, but I see no evidence of any mingw-get bug here -- I see only HTTP 404 error codes, (for URIs, every one of which should be resolvable), indicating probable network faults. FWIW, I cannot reproduce your problem, (and I can't fix what I can't reproduce).
If the problem persists, and you are certain that it isn't caused by network faults, or configuration issues at your end, then you might consider raising the issue with SF directly.
This has been happening to me also. It happens, when I do a fresh install, update or upgrade. That said when I install the individual packages that failed, everything works just fine.
It has probably been happening to quite a number of people, but it still isn't a mingw-get bug. SF have been experiencing network problems over the past few days, and these are certainly responsible. Until SF resolve their issues, it will remain a problem; there is nothing we can do about it.
Have you considered moving the catalogue files to another site, for instance the one where the homepage is hosted? SF:s reliability for hosting these files does not seem optimal and unless my memory tell me wrong it is a recurring issue
Thanks for the replies. I posted the problem report here because I wasn't sure where else to turn, and the messages all say to "report this to the mingw-get maintainer" --
I'm confident the problem is not on my end, given I tried two completely separate networks (work and home -- with no VPN from home to work) and I have not been experiencing similar problems with other activities.
I did locate an old (~2-3 years old) MinGW bug report for the same issue, that seemed to be related to how files were being posted on SF by the MinGW team, the bug was closed but unresolved, so I thought maybe this was still a lingering issue.
Regardless, I'll go through and manually download and install that way -- long and painful. :-(
Thank you for the repliles.
p.s. Is there a way to force mingw-get to use a different location for the files it is downloading?
Please see message posted with SourceForge.
https://sourceforge.net/apps/trac/sourceforge/ticket/25576
Let the finger pointing begin! :-)
I've downloaded files and installed manually, now having a different set of problems which I will describe with a different ticket. The new problem is definitely MinGW and not SourceForge, and is the reason I went to download and reinstall in the first place. Looks like the reinstall has not resolved the issue...
I've commented in the SF support ticket.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Issues"
I've got a slightly different symptom. mingw-get simply reports "download failed". Enabling --trace=0x100 I see:
Connecting ... failed(status=2); retrying...
I can take the URL and download with curl and wget OK. I have noticed that the download URL throws a 301 redirect. Is it possible that mingw-get is considering this an error instead of following the Location:?
Cheers, Al
Re: 301 redirect.
> Is it possible that mingw-get is considering this an error
> instead of following the Location:?
I guess it's possible, but seems unlikely.
http://tinyurl.com/cp7o5hg suggests that InternetOpenUrl() transparently follows redirects, (unless they cross an HTTP/HTTPS protocol boundary), and majority experience tends to confirm that this is so.
> Enabling --trace=0x100 I see:
> Connecting ... failed(status=2); retrying...
This message indicates that InternetOpenUrl failed to acquire a resource handle for the URL -- none whatsoever; not even one which could possibly have been queried to identify a redirect request. The (status=2) is the GetLastError() return for file not found, which hardly seems relevant in this context, unless the preceding InternetOpen() call specifies INTERNET_FLAG_OFFLINE, (or the synonymous INTERNET_FLAG_FROM_CACHE), which isn't the case here.
Hmm. Reviewing the mingw-get code, I see that InternetOpen() may fail without complaint, which surely isn't ideal. Perhaps this is the problem, in your case; however, when I force InternetOpen() to fail, (by running on an offline host), I see (status=12007) in the "Connecting ... failed" message, (and I would expect some status code in the 12000..12174 range, in any similar context).
Ticket moved from /p/mingw/support-requests/151/
Can't be converted:
Keith, what to do with this one?
I'm going to close it. I can't reproduce the issue, so all I can do is beef up the diagnostics, and I plan to do that more generally, in any case.