Bug found - Re: Needing a debug version of setup.exe
First, my thanks to Igor Pechtchanski for reminding me that there is a firewall between me and the CVS server. I had no problem getting the source, from outside the firewall. I built a debug version of setup.exe and used that to find the problem in the setup.ini generated for a repository we maintain on our company LAN. What I found was that a 'source:' line without either a preceding 'version:' or 'install:' line in the package entry will cause setup.exe to crash. In my case, it was an old gperf source package that did not have a version number that led to the problem (no 'version:' line was generated by upset). But, the issue can be duplicated in the gcc-testsuite package entry by just commenting-out a 'version:' line in setup.ini; or in any other package entry, by commenting-out the 'version:' and 'install:' lines, leaving the 'source:' entry for a particular version number. My apologies for not being able to offer a patch. It's been a *very* long time since I last constructed a YACC grammar or action routines for one. I don't even know that the developers will even consider this to be a bug. It's certainly not a serious one. Regards, Doug Wyatt
Needing a debug version of setup.exe
I'm trying to obtain a version of setup.exe that I can use with insight/gdb to investigate a problem with a Cygwin repository created within our Company's LAN. Since I recently updated our repository, setup.exe just crashes. This is with setup.ini created with the last original Upset from the infra directory, also with a more recently acquired upset (v1.0.5, slightly modified to fix some category related problems). I've tried to acquire Setup source from cvs, with variations on the following, over the last few weeks: $ export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/src $ cvs login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvs/src CVS password: [anoncvs] cvs [login aborted]: connect to sourceware.org(209.132.176.174):2401 failed: Connection timed out $ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps \ checkout setup cvs [checkout aborted]: connect to sources.redhat.com(209.132.176.174):2401 failed: Connection timed out Has something changed with respect to cvs access to Setup.exe source code, or is this a manifestation of my cvs cluelessness? Can someone please tell me how to get the Setup source code for the current stable version? Thanks, Doug -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Doug Wyatt [EMAIL PROTECTED] Sys Admin - Kohlman Systems Research, Inc. 319 Perry St., Lawrence, KS 66044 USA Phone: 785-843-4099 Fax: 785-843-6459
Setup.hint for base-passwd is incorrect
I've just investigated an anomaly with the base-passwd package, which turns out to be an incorrect setup.hint file in the repository. repository base-passwd directories contain base-passwd-2.0-1.tar.bz2 30-Nov-2003 07:16 1k base-passwd-2.1-1.tar.bz2 21-Aug-2004 11:48 1k md5.sum 21-Aug-2004 13:54 1k setup.hint 16-Jul-2004 02:11 1k but the setup.hint file contains sdesc: A script to set up initial passwords and groups requires: cygwin ash category: base test: 2.0-1 curr: 1.1-1 Is 2.0-1 curr and 2.1-1 test, or is 2.0-1 prev and 2.1-1 curr? Regards, Doug Wyatt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
libXinerama ?
Hi, I'm trying to built the latest ICEwm package for Cygwin (current), but it appears to need/want libXinerama - checking for XineramaQueryScreens in -lXinerama... no configure: error: Xinerama can not be found I've only found 1 hit in a search of the online archive, dated 23Mar2003. Also, it doesn't show up in a Cygwin package search, though Xinerama is in xorg-x11-bin-dlls-6.7.0.0.4-src and in xorg-x11-devel-6.7.0.0.4-src. I've downloaded the two src packages but at least at first glance, I'm out of my depth w/resp to trying to build libXinerama. Can someone tell me how to obtain a libXinerama for Cygwin ? Regards, Doug Wyatt
'info' observations and questions
I'd found that info v4.2 was not working for me, % info info info: dir: No such file or directory Playing around with it for a while, it seems that info works best when INFOPATH is not defined and /usr/info/dir, rather than /usr/share/info/dir, is the primary index. Even when an up-to-date /usr/info/dir is present, if an INFOPATH is defined, I will see something like Unable to find node referenced by `gcc' in `(dir)Top'. for some entries like gcc. Running 'strings /bin/info.exe | grep usr' reveals a reference to /usr/info, but not to /usr/share/info, which may suggest a reason for part of what I've seen. I don't know where the info.exe source is - doing a setup package search for info or info.exe does not seem to be helpful in locating it. Any hints? Can someone explain why INFOPATH seems to muck-up the behavior of info and why /usr/share/info has been chosen for the default location of the dir file, rather than /usr/info? Regards, Doug Wyatt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question about latest build - openssh-3.5p1-2
Hi, Thank you for the quick feedback, Corinna! What follows is what I've done so far to try to figure out what is causing my problem. I doubt, seriously, that anyone is going to read this and solve the problem for me, but perhaps one or more readers can suggest things to look at or tools that might help me in diagnosis. To restate the problem, I use ssh to connect to a Linux box from Cygwin. On the 6th I suddenly found that vim (enhanced) on the linux host was no longer useable. Vim would load a text file, but almost any input produced a series of beeps and streams of trash chars at the bottom of the screen. Ctrl-Z worked most of the time to get me out of vim, but it would be followed by a lot of beeps and a fair time delay before the shell prompt appeared. The first input to the shell would then produce varying amounts of garbage output (e.g. ^[[?6c^[[?6c^[[?6c^[[?6c). Sometimes bash on the linux system would then give another prompt, other times the connection would hang and the Cygwin bash window on Windows NT4 would have to be killed or even sometimes bash would generate a DrWatson and then have to be killed. On the 5th I upgraded the kernel and vim (5.7 - 6.1) on the linux box and installed the latest tidy and python on my Cygwin machine. The linux box is an important server so I can't roll back the kernel but I did try rolling back vim to 5.7 on linux, without benefit. I can't imagine that the two Cygwin pkgs contributed to the problem. For reasons now forgotten, I tried rolling back Cygwin's ssh-3.5p1-3 to 3.5p1-2 and found that I no longer had the vim problem when connected to the linux host. I put dash-3 back and the problem was back, then again the dash-2 and it was gone. This gave me hope, however short-lived. Finally, the vim problem only occurs when the linux env var TERM=linux, but not when it is set to 'vt100'. Of course, there is lost functionality with vt100 - this is a useable workaround but really not an acceptable fix. I've now built openssh-3.5p1-3 and openssh-3.5p1-2 from src on Cygwin and installed each in turn. The new 3.5p1-3 did not fix the problem and the newly-built 3.5p1-2 failed to eliminate the problem, too. What's worse, I reinstalled opessh-3.5p1-2 from setup.exe and now the problem persists under that, too. (Aarrgggh!!) I've now upgraded from openssl-0.9.6g to openssh-0.9.7 and rebuilt and reinstalled openssh-3.5p1 on the linux host and tried connections thru that with both the linux vim's, 5.7 and 6.1... no joy. I've tried rolling Cywin back to 1.18 and 1.19, using various combinations of Cygwin openssh and linux vim's. I've now lost any way of getting proper vim terminal control with TERM=linux on the remote linux host Does anyone want to venture any ideas, suggestions? Is there something glaringly obvious that I've missed looking at in my frustration? Regards, Doug Wyatt On 9 Feb 2003 at 12:24, Corinna Vinschen wrote: On Sun, Feb 09, 2003 at 05:19:37AM -0600, Doug Wyatt wrote: Is it possible that 3.5p1-3 was built somehow differently than 3.5p1-2? No. I'm using 3.5p1-3 with Linux w/o problems btw. What were the exact options used to configure and build each? I don't see any documentation of this in the source. /usr/doc/Cygwin/openssh-3.5p1-3.README at the very end. Add a --with-tcp-wrappers (which I forgot to add in the README). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question about latest build - openssh-3.5p1-2
Thanks for the suggestion. I should have thought of trying this myself, but a long time ago I put a 'cygwin' terminfo entry on the Linux host and after a while trying to get it to work without success I just settled on using TERM=linux. The current 'cygwin' entry is substantially different from the older one, so I thought this was going to work. I've transferred a copy of the 'sygwin' terminfo entry from Cygwin to the Linux host (infocmp == tic) and after 'export TERM=cygwin' tried a few vim samples. This works no better or worse than TERM=vt100, even after setting 'syntax' and 'filetype' manually to appropriate values (they don't currently auto-set, here) I get no syntax highlighting. I'll continue to investigate this further. I've now also tried opening an xterm (tunneling X11 through ssh) and in this case, with TERM=xterm, vim works well and properly as far as I can tell at this point. So, this is a reasonable workaround for now and also suggests that there isn't something drastically wrong with the vim setup. Thanks again for the help. Doug On 10 Feb 2003 at 14:15, Corinna Vinschen wrote: On Mon, Feb 10, 2003 at 04:55:01AM -0600, Doug Wyatt wrote: Finally, the vim problem only occurs when the linux env var TERM=linux, but not when it is set to 'vt100'. Of course, there is lost functionality with vt100 - this is a useable workaround but really not an acceptable fix. Try copying the terminfo file cygwin to the appropriate place on your linux box and set TERM=cygwin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Question about latest build - openssh-3.5p1-2
Hi, I use ssh to connect to a Linux box and on the 6th I suddenly found that vim (enhanced) on the linux host was no longer useable over the usual ssh connection. Vim would load a text file, but almost any input produced a series of beeps and streams of trash chars at the bottom of the screen. Fortunately, ctrl-Z worked most of the time to get me out of vim. On the 5th I had upgraded the vim rpm's on the linux host, so I rolled back from 6.1 to 5.7 on linux, but this didn't help. Vim over ssh from Cygwin was still broken. I reinstalled vim 6.1 on the linux box. However, I've found that rolling back openssh from 3.5p1-3 to 3.5p1-2 fixes the problem. Going back to 3.5p1-3 brings it back. I've compared the source for these two versions of openssh and the difference (in session.c) seems (to me) to be unrelated to anything that might produce a terminal control issue. Is it possible that 3.5p1-3 was built somehow differently than 3.5p1-2? What were the exact options used to configure and build each? I don't see any documentation of this in the source. Regards, Doug Wyatt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Attempting to build Tk800.024 module for Perl5.8.0
Hi, If this is not the appropriate forum for this question, I'm sure someone will let me know. I'm trying to build the latest Tk module (800.024) for perl. My current setup includes tcltk 20030128-3, cygwin 1.3.19-1 and perl 5.8.0-1. The Tk module make terminates with the following: LD_RUN_PATH=/usr/lib gcc -shared -s -L/usr/local/lib Event.o pTkCallback.o tclEvent.o tclNotify.o tclPlatEvent.o tclPlatNotfy.o tclPlatTime.o tclTimer.o tkWin32Dll.o -o ../blib/arch/auto/Tk/Event/Event.dll ../pTk/libpTk.a /usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a -lm Event.o(.text+0x245):Event.c: undefined reference to `_win32_get_osfhandle' collect2: ld returned 1 exit status make[1]: *** [../blib/arch/auto/Tk/Event/Event.dll] Error 1 make: make[1]: Leaving directory `/c/user/daw/test/Tk800.024/Event' Other than one other reference in TkGlue.c, I can't find any other occurrence for `_win32_get_osfhandle' in this source or in the Tcltk 20030128-3, w32api-2.1-1 or cygwin-1.3.19-1 source. I haven't been able to figure out which version of Tcl/Tk the Cygwin source is based on, either. Does anyone have any ideas or pointers? Regards, Doug Wyatt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setup hangs repetedly
FWIW, some time ago I thought that setup was hanging regularly while doing 'Install from a local directory' when the directory was on a network share. Then on one occasion I started one such install and got sidetracked for about 5 hrs. When I returned to check on this install I found that it actually had progressed, though a snail would have outrun it by a fair margin. Other methods of accessing the same network share showed no lag at the same time this slow install was 'progressing'. There's something about the way I/O is done by setup that made installing from a shared directory totally unworkable. This example completed in about 6.5 hrs, installing fewer than 20 pkgs. Doug On 1 Feb 2003 at 19:24, Martin Magnusson wrote: Pavel Tsekov wrote: Now this is a hell of a bugreport... Would you care to be more specific ? What choices do you make on the various pages of the setup wizard. * First, either Install from Internet or Install from Local Directory. * Then I specify the root directory (same as I used to have when it worked), Install For All Users, Default Text File Type: Unix. * At Select You Internet Connection I choose Direct Connection. I usually download from ftp.sunet.se, but I have tried a couple of other servers too. * At Select Packages, I leave everythnig as Default, except the Devel category, the Publishing category and Graphics/OpenGL, where I choose Install. What does it mean hang for you ? Is it that the setup application just sits and waits for a very long time without progressing at all Exactly. It is not unresponsive though. I can still cancel it gracefully, but it doesn't do anything. I have left it on for an hour after it seems to hang, just to confirm that it isn't just progressing slowly. I did scan my hard drives (as suggested by L Anderson) with Norton Disk Doctor a couple of days ago, but I'm doing it again now. I'll post again if that fixes the problem. / Martin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: NTP server?
Ntp looks like it might be a tough build under Cygwin, but you can get ntp v4.1.71 pre-built for NT with a gui installer at: http://www.five-ten-sg.com/. Regards, Doug Wyatt On 29 Nov 2002 at 2:03, jose_gonzalez wrote: Hi NTP (Network Time Protocol) server available in cygwin? Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin official logo ?
Otters are great! O'reilly definitely likes them http://www.oreilly.com/catalog/javanp2/index.html http://www.oreilly.com/catalog/perlsysadm/colophon.html http://www.oreilly.de/catalog/wdnut2/colophon.html http://perl.oreilly.com/usage/ Doug On 29 Nov 2002 at 12:32, Christopher Faylor wrote: On Fri, Nov 29, 2002 at 01:39:39PM +0100, Corinna Vinschen wrote: On Thu, Nov 28, 2002 at 10:26:21AM +, Yann Crausaz wrote: Hello, As an illustration for a paper I'm writing about Cygwin, I'm looking for THE official Cygwin logo. I guess that this official logo isn't the GNU + Cygnus + Windows = Cygwin standing on the homepage (www.cygwin.com), and not even the black C above the Install Cygwin Now link... Where could I find it ? Actually there is no official logo besides what you've already seen. Months ago we discussed an animal logo like other OSS project have and one idea was an otter. A koala would be funny, too. The idea failed so far mainly due to the inability to find a good, copyright-free drawing of such an animal. Please grant me this one conceit. Linus likes penguins. I like otters. If there is going to be an animal mascot for cygwin it should be an otter. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gdb segfaults with dumper core file
Hi, I've been unable to find much in the archives about the dumper.exe tool and I'm almost as unfamiliar with gdb usage so ... I've compiled a program called pcps, which converts text to postscript and sends it to a printer. Under an admin login, it works pretty much correctly. But, under a normal 'Domain Users' account it delivers the job to the print spooler and then segfaults. The output does print. Under gdb it runs without segfaulting... as any cynic would expect. So, I modified cygwin.bat with the dumper.exe entry, reran pcps and got a pcps.exe.core that is about 2MB in size. I tried a few variations on 'gdb --core=pcps.exe.core' and gdb itself segfaults in every case and generates a 'gdb.exe.core' of about 7MB. Is there some trick to using dumper output with gdb? Or do I need to resign myself to the recursive strategy of now debugging gdb, and so on ... Regards, Doug Wyatt Versions used are: binutils20020706-2 cygwin1.3.12-4 gcc 3.1.1-4 gdb 20020718-1 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is Cygwin legal under Windows XP?
You wrote in [EMAIL PROTECTED] in gmane.os.cygwin on Sun, 21 Apr 2002 09:54:01 +0200: Microsoft's XP license agreement says, Except as otherwise permitted by the NetMeeting, Remote Assistance, and Remote Desktop features described below, you may not use the Product to permit any Device to use, access, display, or run other executable software residing on the Workstation Computer, nor may you permit any Device to use, access, display, or run the Product or Product's user interface, unless the Device has a separate license for the Product. That means using any software other than Microsoft's to view an XP desktop from Windows 2000 or any other operating system would violate the company's license agreement, in case you care. That is not correct, you can use whatever software you want to as long as your 'Device' has a XP license. I've not read the full licence for XP but this passage taken alone would suggest that you need an extra licence for a monitor. After all, it's a separate device that displays the software and the UI. ;-) -- Sam Edge Or, Web servers which download Java, Javascript and ASP's. What concerns me is the the apparent stricture on any non-MS remote access to one's own PC via sshd! I guess this would even make PCAnywhere connections from a non-XP host illegal w/o an additional XP license. Doug -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question on the new behavior of setup.exe
Hi, It appears that the problem with downloads on the W2k PC is the result of one or more problems on the PC itself and between W2k PC's in general and the NT Domain Server. The download dir is on a server share and it always worked w/o problems on and before 18Mar02. Naturally, my first assumption when I saw the changes in the operation of setup.exe was that it was at fault. Now, I doubt it! A segment of the log you asked for is: 2002/04/05 02:04:18 Starting cygwin install, version 2.194.2.22 2002/04/05 02:04:18 Current Directory: P:\Cygwin-v1_1_x 2002/04/05 02:04:18 Command line parameters 2002/04/05 02:04:18 0 - 'P:\Cygwin-v1_1_x\setup.exe' 2002/04/05 02:04:18 1 parameters passed 2002/04/05 02:04:26 source: download 2002/04/05 02:04:29 Selected local directory: P:\Cygwin-v1_1_x 2002/04/05 02:04:30 net: Direct 2002/04/05 02:05:05 site: ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus 2002/04/05 02:05:05 site: http://mirrors.rcn.net/pub/sourceware/cygwin 2002/04/05 02:05:16 Downloaded P:\Cygwin-v1_1_x/ftp%3a%2f%2fftp.unierlangen.de %2fpub%2fpc%2fgnuwin32%2fcygwin%2fmirrors%2fcygnus/latest/autoconf/autoconf- 2.53-1.tar.bz2 2002/04/05 02:05:16 mbox fatal: Can't open P:\Cygwin-v1_1_x/ftp%3a%2f%2fftp.uni- erlangen.de%2fpub%2fpc%2fgnuwin32%2fcygwin%2fmirrors%2fcygnus/latest/ automake/automake-devel/automake-devel-1.5b-1.tar.bz2.tmp for writing: No such file or directory 2002/04/05 02:09:11 Ending cygwin install Regards, Doug Wyat -Original Message- From: Doug Wyatt [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 04, 2002 8:50 PM To: [EMAIL PROTECTED] Subject: Question on the new behavior of setup.exe Hi, Back on 25Mar2002, Robert Collins replied to a posting which mentioned an oddly named subdir in a local hosts download dir. Earlier today, I tried to dowload the latest updates to a local dir with the newest setup.exe, running from a W2k PC and got errors about not being able to find a subdir with a long name containing what looked like printf format sequences. Hmm, if you could send the logs from that failing machine, I can try to see whats happening. When I got home, I again downloaded the current setup.exe and updated my local repository, this time without problem, but when I updated my Cygwin installation I got a warning that my setup.ini was out of date. Nonetheless, it appears that the newer packages were installed. That's probably due to the setup.ini the the old cache dirs (contrib and latest immediately under the directory you specify as local package dir). Looking in the download directory, I now see a new subdir, called 'ftp%3a%2f%2fmirrors.rcn.net%2fmirrors%2fsources.redhat.com%2fcygwin' which contains the newly downloaded contrib and latest dirs and the new setup.ini. For that specific site. You can choose multiple mirrors on the mirror selection screen - personally I choose 4 mirrors - and then you simply leave those selected, and setup will intelligently use the most up to date mirror automatically. The setup.log and the setup.log.full files under the download dir (the parent of the above named dir) contain the history of the downloads, but not of the installs. Only if you do a two run install. If you simply 'install from the internet', then all the log data goes to one place. The setup.log and setup.log.full in the Cygwin root dir contain no information on today's install, either - only the info from my last installation upgrade on 2002/03/17. Look in /var/logs I really like the improved look and organization of the new setup.exe, but can someone clarify what it is doing behind the scenes? Thanks (on behalf of all the contributors). I hope the above info helps. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Question on the new behavior of setup.exe
Hi, Back on 25Mar2002, Robert Collins replied to a posting which mentioned an oddly named subdir in a local hosts download dir. Earlier today, I tried to dowload the latest updates to a local dir with the newest setup.exe, running from a W2k PC and got errors about not being able to find a subdir with a long name containing what looked like printf format sequences. I tried several http and ftp sources for the download, but failed every time. When I got home, I again downloaded the current setup.exe and updated my local repository, this time without problem, but when I updated my Cygwin installation I got a warning that my setup.ini was out of date. Nonetheless, it appears that the newer packages were installed. Looking in the download directory, I now see a new subdir, called 'ftp%3a%2f%2fmirrors.rcn.net%2fmirrors%2fsources.redhat.com%2fcygwin' which contains the newly downloaded contrib and latest dirs and the new setup.ini. The setup.log and the setup.log.full files under the download dir (the parent of the above named dir) contain the history of the downloads, but not of the installs. The setup.log and setup.log.full in the Cygwin root dir contain no information on today's install, either - only the info from my last installation upgrade on 2002/03/17. I really like the improved look and organization of the new setup.exe, but can someone clarify what it is doing behind the scenes? Thanks, Doug Wyatt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
