This is on Windows XP, SP3, 32 bit. I run the installer WinGW-5.1.5. With any of the install options selected when I start to install it prints "URL Parts Error\nCould not download mingwrt-3.15.2-mingw32-dev.tar.gz!"
Try choosing a different mirror. This error is common when the mirror service fails.
Where is documented how to change the mirror?
The mirror selection is part of the SourceForge software service. Somewhere there is or used to be a default mirror preference for the user account. You could change that default to what ever you wished it to be. I've spent a few minutes trying to find it again but cannot seem to spot it in the new redesigned page views.
Hmm, I guess no one noticed me reporting this bug before? Could you guys also add the MinGW autoconfig and automake in there? It's a pain having to download each individual archive and then extracting them.
@love4boobies: Do not hijack issues.
> Hmm, I guess no one noticed me reporting this bug before?
Hmm, yourself. I DID notice, and as a consequence withdrew the defective version of the installer from general release; perhaps YOU didn't notice that?.
FTR, the installer, in its present form, is unmaintained; (those who have worked on it in the past have abandoned it). I did the patch to get to MinGW-5.1.5, and generated it using makensis on my GNU/Linux box. It appeared to work fine, when I tested it under Wine. I asked other developers to test natively; only one responded, and he said it looked okay, so I uploaded it. Now it doesn't seem to work, either for me or anyone else. I don't know why, and I'm not going to waste any more time on it; (in common with all typical MS-Windows installers, NSIS ensures that it will always be the epitome of mediocrity, no doubt inspired by the mediocre standard of the entire OS, which sadly, users seem to have come to accept, and even expect).
> Could you guys also add the MinGW autoconfig and automake in there?
> It's a pain having to download each individual archive
> and then extracting them.
This is completely unrelated to the scope of this ticket, which is why Earnie enjoins you to refrain from hijacking. In any case, given the unmaintained state of this installer, the answer is an unequivocal "ABSOLUTELY NOT"! (You will just have to wait for mingw-get, which is where I prefer to focus my effort).
I would appreciate it if the developers/maintainers would lose the attitude.
At any rate, I have no problem updating the existing installer or even creating a new one as long as it'll help MinGW users. How would I go about submiting it? Should I just attach it here or use a mailing list? I'm unfamiliar with MinGW policies.
It would also be nice if the developers would remove the text saying this is the recommended way to install mingw from the website if the installer is broken.
Adding to my last comment:
@keithmarshall: If you're okay with my proposal would you mind uploading your version of MinGW-5.1.5-src.gz somewhere again? It would probably spare me some time to debug that.
I don't see a tag for 5.1.5 but it appears to have been updated in http://mingw.cvs.sourceforge.net/viewvc/mingw/MinGW/?pathrev=MinGW-5_1_4 but no tar.gz will be created.
Thank you for pointing me, earnie.
I was able to fix the glitch in the installer script. However, mingw.ini still needs to be updated - the one from keithmarshall only adds runtimeDLL in there but doesn't point to the new MinGW release (GCC 4.4.0, etc.) - once I do that it will also need to be uploaded to http://www.mingw.org/mingw.ini (that one is outdated).
May I also add the MinGW releases for automake and autoconfig to the package?
Before I do any of this I have a question. I wasn't able to figure out what the numbers in mingw.ini on the right of the "|" characters are - sorry if it's obvious.
Automake and autoconf are dependent on MSYS to execute. In the current form I do not believe they should be added to the MinGW installation. In the mingw-get version Keith referred to I would hope that MSYS and MSYS packages would be included in the list.
Can you attach the patch for us to look at please? Please use ``cvs diff -up'' to create the patch file.
> I don't see a tag for 5.1.5...
I think I may have stuffed up the branch tagging :-( It was late, and I wasn't in any mood for arguing with CVS, when it didn't want to allow a commit after I checked out 5.1.4; I forced it in, as a new branch.
> mingw.ini still needs to be updated - the one from
> keithmarshall only adds runtimeDLL in there but doesn't
> point to the new MinGW release (GCC 4.4.0, etc.)
And deliberately so; responsibility for that change rests with the maintainer of the GCC-4 package set, (i.e. Aaron). I have no intention of pre-empting his decision as to when it may be appropriate to support automated installation of gcc-4.4.0, and neither should you, without his agreement.
> I wasn't able to figure out what the numbers in mingw.ini
> on the right of the "|" characters are...
AFAIK, they represent the disk space needed to accommodate the installed package, expressed in units of 1kB blocks.
> Automake and autoconf are dependent on MSYS to execute.
> In the current form I do not believe they should be added to
> the MinGW installation.
I agree; in absolutely no way do they belong there.
> In the mingw-get version Keith referred to I would hope that
> MSYS and MSYS packages would be included in the list.
Off topic here, but...
The infrastructure will support this. From a user perspective, mingw-get will be loosely modelled on apt-get. Invoked with arguments, it will run as a CLI application, e.g.:
mingw-get install gcc
will download and install all packages needed for a working MinGW GCC (C only), with all package dependencies resolved.
Invoked without arguments, it will run as a GUI application, loosely modelled on synaptic, in which users can select individual packages, and have them installed with their dependencies resolved.
I'm fairly close to a working prototype, for the CLI aspect; the GUI may be some way off.
The available packages, and their dependencies, are described in an XML catalogue. This is flexible enough to evolve with demand, *without* having to rebuild mingw-get itself every time a new package needs to be added; (this is where I consider NSIS to be seriously deficient). However, what does get included in that catalogue will be at the discretion of the individual package maintainers.
> Can you attach the patch for us to look at please?
> Please use ``cvs diff -up'' to create the patch file.
Likely not, since [s]he isn't the owner of this issue. If it isn't possible, please submit as a new entry, on the patch tracker.
I have no idea on learning how to use either CVS or diffutils. The "patch" is fairly simple:
On line 599 of mingw.nsi, instead of /POPUP write /POPUP ""
There needs to be a string after /POPUP - the plug-in used for downloading files is apparently tricky in that sometimes it will compile scripts correctly even with such bugs, as I've seen in their thread discussions.
mingw.ini on the website still needs an entry for runtimeDLL otherwise it will fail.
> I have no intention [of] learning how to use either CVS or diffutils...
So, perhaps it is YOU who needs to "lose the attitude". You expect me to give freely of my spare time to address your issues, and to pander to your every whim, when you are unwilling to acquire even the basic skills to help yourself? Get real.
> On line 599 of mingw.nsi, instead of /POPUP write /POPUP ""
Not even remotely like a patch, (and curiously, this omission was already apparent in the previous version, which seemed to work), but even if I make this change it's STILL comprehensively broken:
1) Once I've chosen an install type, it's locked; all the initial screens are skipped, so I have no chance to select an alternative class, nor to choose an alternative installation path, to trial such alternative class, nor even simply to test the installer function.
2) Already installed components are no longer visible in the components list.
3) Even if I have a NEWER mingw.ini, (as indicated by a greater build number), it still trashes it in favour of an out-of-date version from the web. (This bug leads to your...
> mingw.ini on the website still needs an entry for runtimeDLL
> otherwise it will fail.
I've never liked NSIS installers, (nor indeed ANY MS-Windows style installer). I will not waste any more time on this, so unless another volunteer maintainer (who is prepared to work within the established project infrastructure) steps forward, this will become a "won't fix" issue.
FIY, if the change was any bigger than that I would've looked diffutils commands up. When is something as simplie as that I don't really see how it'd spare anyone the time (does it take longer to run diff or add them manually?). I know the old version had the same omission - I even tried building it and it FAILED in the same manner. I tried explaining why it sometimes works in my comment.
And I do not expect anyone to give up their spare time. This is what a bug tracker is for - reporting bugs. I will perhaps find the time to find that bug too - note that I've never used NSIS before and I have never heard of the plug-ins the installer uses. Is that "unwilling to acquire even the basic skills to help"? Give me some time - I have a job, you know...
@love4boobies stated "I have no idea on learning how to use either CVS or diffutils."
Too bad, the open source community could use worthy developers. This comment tells me you're not a serious developer. Every project worth its salt has some form of version control system. CVS is the oldest open source VCS and is used in many shops.
Thanks for pointing out the flaw. Providing a patch would have been a great thing for MinGW. The command I provided you is simple to run. Then the maintainer just does a ``patch -p0 < diff.patch''. It is easier for you to provide a patch file than it is for you to point to the file and line and say change this or that and then the maintainer has to open the file, go to the line and then make the change. So I hope I demonstrate that providing the patch file would have been easier for everyone. Less time is spent in total.