From: SourceForge.net <no...@so...> - 2008-11-06 15:59:48
|
Bugs item #2218384, was opened at 2008-11-03 08:02 Message generated for change (Comment added) made by fatman_uk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2218384&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known bugs Status: Open Resolution: None Priority: 7 Private: No Submitted By: John Smith (godfall) Assigned to: Earnie Boyd (earnie) Summary: Installer Fails to Download "MinGW base tools" Initial Comment: Hi: I tried to install MinGW with MinGW-5.1.4.exe yesterday (November 1, 2008), and it fails at the download stage. I am running Windows XP with SP2. The steps to reproduce this problem are: 1) Run installer 2) Choose "Download and install" or "Download only" (the problem appears either way) 3) Choose "Current" package 4) Select any type of install that includes "MinGW base tools". The simplest would be, of course, a "Minimum" install. 5) Select a download location. It doesn't matter whether it has a space or not (for this bug). 6) The download process will almost immediately fail with something like "Connection appears to have dropped. Please check your dial-up settings or IE proxy settings." It will fail no matter how many times you click "Retry". I downloaded the source code for the installer, and looking at the file mingw.nsi (I'm not sure what language this is written in, so bear with me), it appears the problem is in the file parsing code. Specifically, in the function ChoosePackage, there is the following code, presumably to extract the names and sizes of the various tarballs: ReadINIStr $R0 "$EXEDIR\mingw.ini" $Package "runtime" ${If} $R0 == "" ReadINIStr $R0 "$EXEDIR\mingw.ini" current "runtime" ${EndIf} ${StrTok} $runtime $R0 "|" 0 0 ${StrTok} $R1 $R0 "|" 1 0 SectionSetSize ${SecRuntime} $R1 ReadINIStr $R0 "$EXEDIR\mingw.ini" $Package "w32api" ${If} $R0 == "" ReadINIStr $R0 "$EXEDIR\mingw.ini" current "w32api" ${EndIf} ${StrTok} $W32API $R0 "|" 0 0 ${StrTok} $R1 $R0 "|" 1 0 SectionSetSize ${SecW32API} $R1 If you then take a look at the init file mingw.ini, you will see that for the "Current" package (make sure you look at the file after running the installer so that you have an updated version), there are 2 problems: 1) There is more than one "runtime" entry, and moreover, they are called "runtime-dev" and "runtime-dll" 2) The "w32api" entry is actually called "w32api-dev". If you attempt to download the "Previous" package, everything will work, because, looking at mingw.ini again, the "runtime" and "w32api" entries are in the format that the parsing code expects. The "Current" package also works if you change the appropriate mingw.ini entries as the installer is running. In terms of solving it, I'm guessing you could either make the parsing code more robust by only matching the beginning of the entry name instead of the whole name, and looping over all entries instead of assuming a singly entry (e.g., look for all entries which begin with "runtime"). Of course, you could instead make server-side changes as to how the entries are named (e.g., make sure there is only one "runtime" entry and that its actually called "runtime"). Well anyways, I'm sure you guys will have no problems solving this :D Thanks for your wonderful work, GodFall ---------------------------------------------------------------------- Comment By: Fatman (fatman_uk) Date: 2008-11-06 15:59 Message: ernie, cynebeald: Try changing the IP of downloads.sf.net to a known good mirror in your HOSTS file. That will affect all programs which try to connect, not just your browser. Of course if SF are moving things around, that might not be such a great idea. ---------------------------------------------------------------------- Comment By: John Smith (godfall) Date: 2008-11-04 04:38 Message: Thanks to ernie for the fix and cynebeald for testing the fix. I just got home, and can confirm that the fix works (the mingw.ini file for the "Current" release looks good now). Keep up the good work, GodFall ---------------------------------------------------------------------- Comment By: Cynebeald (cynebeald) Date: 2008-11-03 18:57 Message: Is setting a mirror going to help when downloading via the installer? I always thought this affects only how things go when I'm using a browser. But thanks for the suggestion - I thought I had a default mirror picked, but with SF moving things around, it's probably gone stale. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-11-03 18:31 Message: Thanks for the report about the typo. For the mirror issue, you might try setting your SF account with a default mirror. ---------------------------------------------------------------------- Comment By: Cynebeald (cynebeald) Date: 2008-11-03 16:25 Message: Correction: after fixing the line, I was able to download the runtime but only on the second or third attempt. Repeatedly hitting "retry" fixes this, apparently Sourceforge has some problems with it's mirrors (this happens in my browser too). (disabling my firewall didn't help with this). ---------------------------------------------------------------------- Comment By: Cynebeald (cynebeald) Date: 2008-11-03 16:14 Message: There seems to be a typo in the updated ini file, I have runtime=mingw-3.15.1-mingw32.tar.gz|560294 but the file is called mingwrt-3.15.1-mingw32.tar.gz But even after fixing the ini file (after the installer has downloaded it, as suggested in the original bug report), the download doesn't proceed - even though the URL seems correct (when I tried typing http://downloads.sourceforge.net/mingw/mingwrt-3.15.1-mingw32.tar.gz into a browser, I got a download). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-11-03 14:10 Message: I have a simple workaround in place. I uploaded a file mingwrt-3.15.1-mingw32.tar.gz that combines the -dev and -dll files. I then modified and uploaded a new mingw.ini file. Can you test this workaround, please? My proxy settings are in the way for me to test right at the moment. Improving the installer is already under way by John E. (tdragon) with a new package in CVS called mingw-get. You might want to offer assistance to him. As for the current installer, I'll probably release a fix just to handle our new file name formatting and to hopefully fix the proxy issue. Therefore, I'm leaving this issue open. ---------------------------------------------------------------------- Comment By: John Smith (godfall) Date: 2008-11-03 13:53 Message: Hmm, interesting. If I'm not mistaken, Nullsoft is involved with WinAmp right? What further testing do you require? Or do you mean testing once you have a solution? In either case, I have time (its pretty easy to reproduce :D). I was even thinking of fixing it myself - I guess the only thing stopping me was an uncertainty about the best approach. In other words, fixing it so that it works for now is pretty simple, but fixing it with an eye towards the future (i.e., future changes to the name/quantity of the tarballs) is not so simple. Cheers, GodFall ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-11-03 13:27 Message: BTW the language is NSIS (see nsis.sf.net). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-11-03 13:17 Message: This issue has come about because of the split up of mingwrt*-dev and mingwrt*-dll, we require both. Thanks for the bug report; I hope you have time to test for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2218384&group_id=2435 |