Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-2861359 ] Installer fails immediately
|
From: SourceForge.net <no...@so...> - 2009-09-25 11:57:39
|
Bugs item #2861359, was opened at 2009-09-18 11:34 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2861359&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: 5 Private: No Submitted By: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: Installer fails immediately Initial Comment: 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!" ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2009-09-25 11:57 Message: >> 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 might also point out that such addition is beyond the scope of the present issue. That said, if you want to contribute toward that goal, please raise a new patch tracker entry to "Add gcc-4.4.0 support to MinGW-5.1.x", attach your patches as appropriate, and to get the ball rolling, I'll assign it to Aaron for review. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2009-09-25 11:41 Message: To avoid any potential confusion, in my previous comment... export CVSROOT=... was intended to appear on the same command line, (not split over two as it appears, for me, in the tracker display). That's valid in bash, (or ksh IIRC); for traditional Bourne shell it needs to be: export CVSROOT CVSROOT=... as two separate commands. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2009-09-25 11:27 Message: > By the way, the tags got mixed up again... No, they didn't; as of 13 hours ago, when I FIXED them, the tags are exactly as they should be. The only oddity I see, looking specifically at mingw.nsi, is that MinGW-5_1_1 and MinGW-5_1_3 refer to the same revision, (which may be correct), but there is no MinGW-5_1_2, (which is suspicious), but I didn't touch any of these three tags. > Newest tag for installer seems to be MinGW_5_1_1 The newest tag is MinGW-5_1_5, which is now (correctly) at the end of branch MinGW-5_1; this is a faithful reflection of the state, as I established it on 2009-08-21, migrated from the inadvertently created MinGW-5_1_4 branch, (which is now abandoned; I've reassigned the MinGW-5_1_4 tag, as non-branch, back to the correct point on the MinGW-5_1 branch). Your patches should be against the LATEST version on the MinGW-5_1 branch; currently that is MinGW-5_1_5. You should check out the BRANCH; (my previous mistake was to check out MinGW-5_1_4 instead of MinGW-5_1, and in haste, to forget that I could fix it with `cvs -z3 up -A -rMinGW-5_1'): export CVSROOT=:pserver:ano...@mi...:/cvsroot/mingw cvs -z3 login cvs -z3 co -P -rMinGW-5_1 MinGW then cd into the resultant MinGW directory, make your changes as appropriate, to the copies of the files you find there, and create the diff using: cvs -z3 diff -u > patchfile.diff Please DON'T include ChangeLog modifications in your diff, (unless you are only correcting typos in existing content), but DO provide the content for your ChangeLog entry as standalone text. (It is permissible to edit this text directly into the head of the diff file, as preamble to the diff itself -- it just shouldn't be part of the generated diff). ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-25 09:40 Message: By the way, the tags got mixed up again. Newest tag for installer seems to be MinGW_5_1_1. I also noted this in the patch artifact. Please don't fix it and then have someone apply the patch to the wrong rev :) ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-25 09:37 Message: I have sent the patch which now also correctly handles the built-in INI. I will also make it detect already installed packages very soon. Cheers. ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-25 01:52 Message: @earnie: I am a serios developer. One who uses git instead of CVS or SVN - I do know how patching works. Diff patches are not necessarily common in Windows - for instance we have a custom tool for that that has a different internal representation for patches. We're getting OT here though :) If I submit a bigger patch I promise to learn how to do it properly. Cheers ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-09-24 16:32 Message: @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. ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-24 13:45 Message: 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... ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2009-09-24 12:48 Message: > 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. observation). 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. ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-23 20:28 Message: s/idea/intention ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-23 20:28 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2009-09-23 15:25 Message: > 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-09-23 13:21 Message: 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. ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-23 04:30 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-09-22 18:20 Message: 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. ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-22 16:14 Message: 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. ---------------------------------------------------------------------- Comment By: Jeremy Sanders (jeremysanders) Date: 2009-09-22 16:11 Message: 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. ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-22 16:02 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2009-09-22 15:22 Message: > 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). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-09-21 13:44 Message: @love4boobies: Do not hijack issues. ---------------------------------------------------------------------- Comment By: Love4Boobies (love4boobies) Date: 2009-09-19 16:32 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-09-18 15:06 Message: 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. ---------------------------------------------------------------------- Comment By: Jeremy Sanders (jeremysanders) Date: 2009-09-18 13:06 Message: Where is documented how to change the mirror? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-09-18 12:58 Message: Try choosing a different mirror. This error is common when the mirror service fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2861359&group_id=2435 |