SETUP: new setup.ini with md5 sums crashes setup 2.192.2.24 on W98SE
This started happening today. When I try to 'Install from Internet' from my normal mirror (http://ftp-stud.fth-esslingen.de) Setup starts downloading setup.ini and then crashes with the following error: SETUP caused a general protection fault in module USER.EXE at: 0004:5ff0. Tried with some other mirrors: same crash. One mirror succeeded (ftp://ftp.easynet.be). Investigating the differences it turned out that the setup.ini from ftp.easynet.be does not have the md5sums yet, the other crashing mirrors have setup.ini with md5sums included. Is this W9x specific or is it also happening on NT/2K/XP ? Regards, Ton van Overbeek
Re: SETUP: new setup.ini with md5 sums crashes setup 2.192.2.24 on W98SE
Just to follow up on my own posting: Downloading Setup.exe 2.194.2.25 from cygwin.com solves the problem. Note I made an error in the subject line: 2.192.2.24 instead of 2.194.2.24. So it seems Setup 2.194.2.24 will not be able to tell you to upgrade to 2.194.2.25. Kind of a catch 22 situation. Hope this pre-empts lots of questions on 'Setup does not work any more'. Regards, Ton van Overbeek
SETUP 2.194.2.25 Major(?) Problem in chooser with new setup.ini with md5sums
After getting rid of the crash by downloading setup 2.194.2.25 I noticed that new/uninstalled packages did not show up in the chooser (with Skip status) when downloading from a site which uses the md5sums in setup.ini. Using a site with a setup.ini without md5sums is OK with 2.194.2.25. Looking a bit further to what changed between 2.194.2.24 and 2.194.2.25 I believe iniparse.y (2.25.2.1) is the culprit. Chris has added a rule in simple_line for both 'INSTALL STRING STRING STRING' and 'SOURCE STRING STRING STRING'. However there is no action defined for these new rules. Hence any line in setup which has a md5sum is completely ignored, instead of only the last token (the md5sum). Solution (if my knowledge about bison is correct): Copy the action from 'INSTALL STRING STRING' to 'INSTALL STRING STRING STRING' The same for the equivalent SOURCE case. If I am correct, could Chris or Robert please update setup.exe on cygwin.com asap. Thanks in advance. Ton van Overbeek
Re: rebasing new packages?!
On Fri, May 03, 2002 at 12:58:04PM +1000, Danny Smith wrote: If your just talking about STL in the strict sense, you shouldn't need libstdc++.a. The templated STL lives in the headers. That's the virtue of templated classes. Char specializations for [Non-]Standard iostreams and string classes live in libstdc++.a but they are not templated pre-3.0 Does the above imply that it would easy to add STL to gcc -mno-cygwin? Thanks, Jason
Re: rebasing new packages?!
Rob, On Fri, May 03, 2002 at 11:35:46PM +1000, Robert Collins wrote: -Original Message- From: Jason Tishler [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 11:34 PM Having STL would really speed things up. When I saw you adding libstdc++, I thought implied STL but I was mistaken. Can we enable STL for setup.exe? As long as the required dependencies are easily satisfied: a) STL headers + any libs for gcc on cygwin (i.e. OOTB build for developers). Isn't a) already satisfied? b) STL headers + any libs for gcc -mno-cygwin (i.e. how I build, and the documented release build on Is b) satisfied by the following? http://www.colomsat.net.co/freehost/ngiraldo/cppcygwin.html http://sources.redhat.com/cygwin-apps/setup.html). c) STL headers + any libs for a linux hosted cross-chain targeting mingw. I.e. how I expected Chris builds. I don't know how to satisfy c). Jason
RE: rebasing new packages?!
-Original Message- From: Jason Tishler [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 11:52 PM As long as the required dependencies are easily satisfied: a) STL headers + any libs for gcc on cygwin (i.e. OOTB build for developers). Isn't a) already satisfied? Possibly. I'm simply setting expectations. b) STL headers + any libs for gcc -mno-cygwin (i.e. how I build, and the documented release build on Is b) satisfied by the following? http://www.colomsat.net.co/freehost/ngiraldo/cppcygwin.html b) is an alternative approach to what I've already documented here. So it covers libstc++ aka libg++-3. I don't know how much of the STL that includes (see my earlier email). http://sources.redhat.com/cygwin-apps/setup.html). c) STL headers + any libs for a linux hosted cross-chain targeting mingw. I.e. how I expected Chris builds. I don't know how to satisfy c). If a b are satisfied with the libg++-3 library and headers, then c) is trivial.If not then someone needs to check it is doable. Rob
Re: rebasing new packages?!
Robert Collins wrote: -Original Message- From: Jason Tishler [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 11:52 PM As long as the required dependencies are easily satisfied: a) STL headers + any libs for gcc on cygwin (i.e. OOTB build for developers). Isn't a) already satisfied? Possibly. I'm simply setting expectations. b) STL headers + any libs for gcc -mno-cygwin (i.e. how I build, and the documented release build on Is b) satisfied by the following? http://www.colomsat.net.co/freehost/ngiraldo/cppcygwin.html b) is an alternative approach to what I've already documented here. So it covers libstc++ aka libg++-3. I don't know how much of the STL that includes (see my earlier email). http://sources.redhat.com/cygwin-apps/setup.html). c) STL headers + any libs for a linux hosted cross-chain targeting mingw. I.e. how I expected Chris builds. I don't know how to satisfy c). If a b are satisfied with the libg++-3 library and headers, then c) is trivial.If not then someone needs to check it is doable. As long as rules a b are followed in rule c then c is doable. Earnie.
Re: SETUP: new setup.ini with md5 sums crashes setup 2.192.2.24 on W98SE
On Fri, May 03, 2002 at 10:38:42AM +0200, Ton van Overbeek wrote: This started happening today. When I try to 'Install from Internet' from my normal mirror (http://ftp-stud.fth-esslingen.de) Setup starts downloading setup.ini and then crashes with the following error: SETUP caused a general protection fault in module USER.EXE at: 0004:5ff0. Tried with some other mirrors: same crash. One mirror succeeded (ftp://ftp.easynet.be). Investigating the differences it turned out that the setup.ini from ftp.easynet.be does not have the md5sums yet, the other crashing mirrors have setup.ini with md5sums included. Is this W9x specific or is it also happening on NT/2K/XP ? Use the newest version of setup.exe. cgf
Re: new cygwin package: cgoban
On Fri, May 03, 2002 at 11:46:33AM +0200, Corinna Vinschen wrote: On Tue, Apr 30, 2002 at 07:49:49PM +0200, Teun Burgers wrote: Hello, I've uploaded binary and source packages of cgoban, homepage kgs.kiseido.com/~wms/comp/cgoban/ These are the URL's of binary and source tarballs: http://home.quicknet.nl/qn/prive/ar.burgers/cgoban-1.9.12-1.tar.bz2 http://home.quicknet.nl/qn/prive/ar.burgers/cgoban-1.9.12-1-src.tar.bz2 The tarballs were prepared with generic-build-script.sh. Here is the setup.hint: category: Games Xfree86 requires: Xfree86-base gnugo sdesc:X11 Client to IGS and NNGS go servers, SGF editor, GUI for Gnu Go ldesc:X11 Client to IGS and NNGS go servers, SGF editor, GUI for Gnu Go cgoban is an X11 program related to the game of go. With cgoban you can connect to the IGS and NNGS go servers to play online. You can create and edit SGF (Smart Game Format) files. You can play on your computer against Gnu Go or any other program that communicates throught the Go Modem Protocol (GMP). I hope I got it right! Packaging looks good. I've uploaded the package to cygwin.com. Please prepare to announce according to http://cygwin.com/setup.html#submitting Section 9 in a few hours. This wasn't entirely correct. The package name for XFree86-base was Xfree86-base. Also, I would prefer if packages that relied on X were put in the XFree86 hierarchy. cgf
Re: rebasing new packages?!
Rob, On Fri, May 03, 2002 at 11:55:31PM +1000, Robert Collins wrote: b) is an alternative approach to what I've already documented here. So it covers libstc++ aka libg++-3. I don't know how much of the STL that includes (see my earlier email). http://sources.redhat.com/cygwin-apps/setup.html). I followed the instructions in the above URL and successfully built setup.exe. Then I added some STL test code to main.cc as indicated by the attached patch. Due to warnings generated by the STL headers, I had to remove the -Werror option in order to build. Except for that change, setup.exe built without any problems and the STL test code ran as expected: 2002/05/03 13:10:46 Starting cygwin install, version 2.219 2002/05/03 13:10:46 s = bye 2002/05/03 13:10:46 s = hello ... Can we remove the -Werror option and start using STL in setup.exe? Thanks, Jason Index: main.cc === RCS file: /cvs/cygwin-apps/setup/main.cc,v retrieving revision 2.17 diff -u -p -r2.17 main.cc --- main.cc 29 Apr 2002 11:07:40 - 2.17 +++ main.cc 3 May 2002 17:20:32 - -142,6 +142,9 out: // Other threads talk to this page, so we need to have it externable. ThreeBarProgressPage Progress; +#include set +#include string + #ifndef __CYGWIN__ int WINAPI WinMain (HINSTANCE h, -159,6 +162,13 main (int argc, char **argv) next_dialog = IDD_SPLASH; log (LOG_PLAIN, String (Starting cygwin install, version ) + version); + + setstring s; + s.insert(hello); + s.insert(bye); + + for (setstring::iterator i = s.begin(); i != s.end(); i++) + log (LOG_PLAIN, String (s = ) + (*i).c_str()); SplashPage Splash; SourcePage Source;
Thanks for the quick fix to SETUP
The problem I reported earlier today on Setup 2.192.4.25 (http://cygwin.com/ml/cygwin-apps/2002-05/msg00070.html) has been fixed by Chris in setup 2.192.4.26. Many thanks for the quick fix. Ton van Overbeek
Re: new cygwin package: cgoban
Christopher Faylor wrote: This wasn't entirely correct. The package name for XFree86-base was Xfree86-base. Also, I would prefer if packages that relied on X were put in the XFree86 hierarchy. Also, Trevor Forbes suggested that X-dependent programs should be compiled using --prefix=/usr/X11R6/ (and --sysconfdir=/etc/X11/ ?), as is common on unix systems... Volker Zell agreed. Nobody else responded. I kinda like it, but FHS has moved away from that; now on Red Hat systems it appears that ONLY those programs specifically part of XFree86 are included there -- or programs whose purpose is to manipulate XFree86 itself (like third-party Xconfigurators and such). Similarly, I don't like the restriction that all 'X'-based packages go under XFree86/ on sourceware. We don't put inetutils underneath ncurses/. We don't put openssh under openssl/. If you really want to segregate X apps, create another tree: Xopt/ or something (and give Harold official control of that tree, too). I think XFree86/ should be reserved for the XFree86 distribution itself. I'd like to see a definitive answer to both of these questions, tho, before we get too many X programs in the distribution... 1) --prefix=/usr/X11R6/ 2) packages uploaded under XFree86/ --Chuck
RE: new cygwin package: cgoban
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 1:33 AM This wasn't entirely correct. The package name for XFree86-base was Xfree86-base. Setup is case-insensitive, so while there is a visual discrepancy, setup will be happy. Rob
RE: rebasing new packages?!
-Original Message- From: Jason Tishler [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 3:34 AM To: [EMAIL PROTECTED] Subject: Re: rebasing new packages?! Rob, On Fri, May 03, 2002 at 11:55:31PM +1000, Robert Collins wrote: b) is an alternative approach to what I've already documented here. So it covers libstc++ aka libg++-3. I don't know how much of the STL that includes (see my earlier email). Can we remove the -Werror option and start using STL in setup.exe? IF there are warnings, they should be cleaned up. The Werror option stays unless there is a compelling reason not to use it. At -O2 inlines are only done on code within the class declaration and code marked as inlinable, so this particular warning should be resolvable. Looking at it, they are trying to inline a recursive function call I don't know if that is or isn't an issue for newer gcc's, but it sure sounds like our one doesn't like it. There are 3 instances of that function call in the g++-3 directory, one from within it, and two from the template right below it's definition. Perhaps removing the explicit inline from the definition is appropriate? (-O3 will automatically inline it, and probably get that warning again, but casual users would be safe. Or perhaps it's resolved in newer g++-3 versions, and we can update? Rob
RE: new cygwin package: cgoban
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 5:04 AM Volker Zell agreed. Nobody else responded. I kinda like it, but FHS has moved away from that; now on Red Hat systems it appears that ONLY those programs specifically part of XFree86 are included there -- or programs whose purpose is to manipulate XFree86 itself (like third-party Xconfigurators and such). I'm agnostic on this one, I don't use X enough to really care. However, Earnie has pointed out that extra path elements have a lamentable performance impact, so perhaps we should be avoiding that? Similarly, I don't like the restriction that all 'X'-based packages go under XFree86/ on sourceware. We don't put inetutils underneath ncurses/. We don't put openssh under openssl/. I'm 100% with you here. If it's a package, then it goes under release. If we want a completely separate tree, create a new location and a new setup.ini, and then that becomes the cygwin-xfree lists domain, and they can have whatever policy they want. Whilst it's in the main setup.ini, they need to follow the policies that this list has hammered out - with much pain. If you really want to segregate X apps, create another tree: Xopt/ or something (and give Harold official control of that tree, too). I think XFree86/ should be reserved for the XFree86 distribution itself. Agreed. I'd like to see a definitive answer to both of these questions, tho, before we get too many X programs in the distribution... 1) --prefix=/usr/X11R6/ In short: I don't really care, but am not in favour of. 2) packages uploaded under XFree86/ Really don't like this. Rob
Re: Thanks for the quick fix to SETUP
On Fri, May 03, 2002 at 08:24:16PM +0200, Ton van Overbeek wrote: The problem I reported earlier today on Setup 2.192.4.25 (http://cygwin.com/ml/cygwin-apps/2002-05/msg00070.html) has been fixed by Chris in setup 2.192.4.26. Many thanks for the quick fix. You're welcome. Thanks for the heads up. I would have responded to your email earlier but I saw it as I was on the way out of the door with my wife standing in the other room tapping her foot. So, I just generated a new executable, tested it, installed it, and ran down the street after my car... It was a very stupid bug. It's sad to see how much my knowledge of yacc has eroded... cgf
setup - parsing code
If you want to edit the parsing code, I've just restructured it. The parser is in inilex.l and iniparse.y as previously. Rather than iniparse.y also knowing what objects and classes to use to build the in memory use of the ini file, it uses an IniDBBuilder to create that representation. Currently there are two IniDBBuilders - the base class, and one with the same behaviour the old code has - that is it merges the data into the packagedb. The reason for this is to allow other uses of the parser - such as the inilinter I'm working on, or a mirroring tool that really doesn't care what packages are on the system. Rob
Re: new cygwin package: cgoban
Be sure to read the p.s. ... Christopher Faylor wrote: On Fri, May 03, 2002 at 03:04:04PM -0400, Charles Wilson wrote: Similarly, I don't like the restriction that all 'X'-based packages go under XFree86/ on sourceware. We don't put inetutils underneath ncurses/. We don't put openssh under openssl/. I wasn't really asking for debate. You can feel free not to like it but that is the way I would like to see things organized. Sorry, Chris, but it's my turn to get pissy. Why? You have never stated, not one time that I've seen, WHY you want to put all X-related stuff under a single tree. As long as they are under release/, they're still going to show up in setup no matter where they are located, so setup's behavior can't have anything to do with it. If it's a cleanliness issue (don't clutter the main release/ dir with all that X junk) -- fine, SAY that. At least it's a reason -- and a slightly better one than because I said so. And I've already heard the one about because we're mean. Further, if one accepts that there should be one tree for all X **clients**, you've never stated WHY that single tree must be the same one used by the XFree86 packages. They aren't PART of XFree86. They just USE XFree86. It's not that I merely 'don't like it' -- I think this second part is irredeemably dumb. WHAT am I missing? Please tell me; you normally don't make executive assertions without a reason, you don't normally do dumb things; yet you seem to be doing so now...which makes me think I am somehow missing the obvious reasoning behind your assertion. This just makes zero sense to me: release/package/ release/package/ release/XFree86/ release/XFree86/xfree86-base/ release/XFree86/xfree86-fonts/ release/XFree86/xfree86-.../ release/XFree86/i-happen-to-use-x-package1/ release/XFree86/i-happen-to-use-x-package2/ release/XFree86/i-happen-to-use-x-package3/ release/XFree86/i-happen-to-use-x-package4/ release/XFree86/i-happen-to-use-x-package5/ release/XFree86/i-happen-to-use-x-package6/ release/XFree86/i-happen-to-use-x-package7/ release/XFree86/i-happen-to-use-x-package8/ This makes (some) sense, from a 'keep-release/-clutter-to-a-minimum' perspective ... release/package/ release/package/ release/XFree86/ release/XFree86/xfree86-base/ release/XFree86/xfree86-fonts/ release/XFree86/xfree86-.../ release/Xclients/i-happen-to-use-x-package1/ release/Xclients/i-happen-to-use-x-package2/ release/Xclients/i-happen-to-use-x-package3/ release/Xclients/i-happen-to-use-x-package4/ release/Xclients/i-happen-to-use-x-package5/ release/Xclients/i-happen-to-use-x-package6/ release/Xclients/i-happen-to-use-x-package7/ release/Xclients/i-happen-to-use-x-package8/ --Chuck P.S. wait a minute; I thought of something. Is this a prelude to Any questions about packages that appear under /XFree86/ should be directed to the cygwin-xfree list? And you're afraid that splitting out the Xclients -- either into /release/ or into /release/Xclients/ -- would cloud that issue?
