wget postinstall
wget postinstall tries to copy the configuration file from
/usr/doc/wget-${VERSION}/sample.wgetrc although it's now
under /usr/share/doc
Pierre
Re: wget postinstall
Pierre A. Humblet wrote:
wget postinstall tries to copy the configuration file from
/usr/doc/wget-${VERSION}/sample.wgetrc although it's now
under /usr/share/doc
Ops, I'll try to fix that this weekend. And that will bring it up to cygwin
1.5+ as the current package is from november 2003.
Pierre
--
Med venlig hilsen / Kind regards
Hack Kampbjørn
Re: how to install new font in cygwin
Duong Dang wrote: I am working a project in cygwin. I must install some VietNam font but I don't know how. could you help me? Is it a ttf font? copy it to /usr/X11R6/lib/X11/fonts/TTF and run font-update. That should be all. bye ago NP: In Macula - Future times -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
changing monitors dynamically confuses Xwin
Dear Cygwin/Xwin maintainers: First let me say that I am running Cygwin/XFree 6.8.1.0-9 on a Windows XP box. I start X with the default parameters (plus -clipboard). Here's what I want to do, and what happens: -- Want to: Use the XP Display Properties Settings menu to add. on the fly, a second display, namely a video projector. I Extend the Windows Desktop to this projector for displaying PowerPoint slides. I want X to stay the way it was, in an XP window that covers the whole laptop LCD screen, but not displaying on the video projector. -- What happens: When I do this, after the display configuration change, the X window contents no longer display, though the cursors show and input appears to be active. XP things work as expected, and I can move the cursor from one screen to another, etc. PowerPoint does the right thin, showing presenter view on LCD screen anbd slide show on video projector. Once I am done and change the configuration back to one display, X works again like normal. Any suggestions? Or is this going to need some heavy duty programming to fix? Regards -- Eliot Moss == J. Eliot B. Moss, Associate Professor http://www.cs.umass.edu/~mosswww Director, Arch. and Lang. Impl. Lab. +1-413-545-4206voice Department of Computer Science+1-413-695-4226 cell 140 Governor's Drive, Room 372+1-413-545-1249 fax University of Massachusetts at Amherst[EMAIL PROTECTED] email Amherst, MA 01003-9264 USA +1-413-545-3733 Priscilla Coe sec'y ==
winsup/cygwin ChangeLog pinfo.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-01-22 18:07:11 Modified files: cygwin : ChangeLog pinfo.cc Log message: * pinfo.cc (pinfo::maybe_set_exit_code_from_windows): Make sure that process has exited before getting an error code. (pinfo::exit): cd to innocuous location before exiting to make sure that process does not keep the current working directory busy while it is in the process of really exiting. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.2672r2=1.2673 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/pinfo.cc.diff?cvsroot=uberbaumr1=1.148r2=1.149
src/winsup/doc how-programming.texinfo install ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-01-22 23:39:37 Modified files: winsup/doc : how-programming.texinfo install.texinfo Log message: * install.texinfo: Add live CD, registry information. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/how-programming.texinfo.diff?cvsroot=srcr1=1.35r2=1.36 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/install.texinfo.diff?cvsroot=srcr1=1.50r2=1.51
Re: [Fwd: RE: ssh problem on Windows XP]
On Jan 21, 6:34pm, Corinna Vinschen wrote:
-- Subject: [Fwd: RE: ssh problem on Windows XP]
is there any chance that we get a fix in the next couple of weeks?
I remain absolutely committed to fixing the problems that have been
reported, but I can't say that I'll have a fix in that timeframe,
because I have some urgent deadlines for other projects. Maybe
early to mid-February?
If we don't get a patch, I'm inclined to revert the pipe patch before
we release 1.5.13.
Instead of reverting the entire patch, if you want to restore the old
behavior (select always returning true for writes on pipes), you could
add a small piece of code to short-circuit the NtQueryInformationFile
logic that I added.
That would make it much easier for me to apply my fix when it's available,
because I could just remove the short-circuit when I add a test to
detect the problem, which I think I understand completely, and have
described in an earlier posting: NtQueryInformationFile acts strangely
when there is a pending, blocking read on the other end of the pipe.
I need time to finish prototyping the new test, however.
Btw., didn't you announce more pipe patches yet to come? Is it possible
that you already have a patch which will get that working again? I'm
still hoping for something more satisfying than reverting...
-- End of excerpt from Corinna Vinschen
Yes, I have more patches, but they don't fix the outstanding problem
with the first patch (I would have certainly sent the fix if I had one).
All of my fixes are related to detecting and avoiding deadlocks, and I
have some that are not pipe related.
In case anyone is curious, let me relate the story of what started all
of this ...
At Curl (where I work), we have a pool of about a dozen Windows servers
that we use for automated builds of our products. Each build starts by
rsync-ing the sources from a Linux server to a Windows build server (over
ssh), then we launch make via ssh and collect std{out,err} over an ssh
channel, and finally the build finishes by rsync-ing the build tree back
from the Windows build server to the Linux build server, again over ssh.
Our Windows build servers are in almost continuous use. As you
can imagine, this setup acts as a severe stress test for Cygwin.
Unfortunately, last year Cygwin deadlocks were killing our productivity:
at least 25% of our builds were wedging, which was completely
unacceptable.
So, I rolled up my sleeves, installed a Cygwin DLL with all of the
debugging symbols, and went to work investigating and fixing each deadlock
that I encountered.
It soon became apparent that pipes were a major problem. We observed
deadlocks because select for writes on pipes always returned true,
so I implemented a fix (that's the first patch). Similar deadlocks
occurred because nonblocking writes on pipes could block, so I added
an implementation for nonblocking writes too (a second patch, which I
submitted, but was never applied, because we wanted to investigate the
reported problems with the first patch).
Later, I found that Cygwin is burned by unfortunate winsock behavior
that we had already encountered in other contexts: it sometimes assigns a
local port that can't actually be used immediately, because it is still
in TIME_WAIT, so connect fails with EADDRINUSE. I fixed one nasty case
where this phenomenon can cause a missed notification in the code for
select on sockets (a third patch), and another that caused socketpair
to fail sporadically (a fourth patch).
The improvement in Cygwin's behavior with these four patches has been
dramatic at Curl. Our builds almost never experience deadlocks now. I am
eager to contribute them to the rest of the world, but I recognize that
I need to fix the first patch before we apply the rest, and I will do it.
Our patches have been extensively tested, but we missed the problem
that occurs for pending, nonblocking reads, because our automated builds
don't use commands like sftp, unison, etc. Most of the other commands
seem to use nonblocking I/O on pipes (often with select), and that works
with my patches.
--
Bob
1.5.12-1: documentation bug in lib[cm].texinfo
From the info dir file in /usr/share/info, you can't get to the info files for libc or libm, because their entries are wrong. The file cygwin-1.5.12-1/newlib/libc/libc.texinfo in the source distribution for cygwin-1.5.12-1 contains the following lines near the top of the file: START-INFO-DIR-ENTRY * libc::The ANSI C library. END-INFO-DIR-ENTRY This incorrectly instructs info to look for a node named libc, which doesn't exist. The correct entry would be: * libc: (libc). The ANSI C library. This tells info to look for the *file* libc.info. There is a similar problem in cygwin-1.5.12-1/newlib/libm/libm.texinfo: START-INFO-DIR-ENTRY * libm::An ANSI-C conforming mathematical library. END-INFO-DIR-ENTRY This entry, of course, should read: * libm: (libm). An ANSI-C conforming mathematical library. Steve -- 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: Multiple installations and 3PPs (FAQ alert)
On Sat, 22 Jan 2005 01:51:38 -0500 (EST), Igor Pechtchanski [EMAIL PROTECTED] wrote: [] | Should we, perhaps, provide a small 'uninstall' script, maybe in | /usr/sbin, that would perform a umount and then use regtool to remove the | registry key? It could even be a .bat, which will enable it to delete all | of Cygwin once the last Cygwin process exits... A postinstall script | could generate it, too, so that it contains explicit paths of the Cygwin | root directory. Something like | | -- BEGIN gen-uninst.sh -- | #!/bin/sh | CYGDIR=`/bin/cygpath -aw /` | cat /usr/sbin/uninstall.bat EOF | $CYGDIR\\umount -s -A | $CYGDIR\\umount -A | copy $CYGDIR\\cygwin1.dll $CYGDIR\\regtool.exe %TEMP% | $CYGDIR\\rm -rf / | del /s $CYGDIR | %TEMP%\\regtool remove /HKLM/Software/Cygnus Solutions | %TEMP%\\regtool remove /HKCU/Software/Cygnus Solutions | del %TEMP%\\cygwin1.dll %TEMP%\\regtool.exe | EOF | --- END gen-uninst.sh --- Looks good to me. But perhaps an option to save the current mount points somewhere would be useful in case the purpose of the uininstall is not removal for it's own sake but removal in order to perform a clean install, with subsequent restoration of the mount points. In other words insert a mount -m command before the first umount. -- davidp / DavidPostill -- 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: Couple of scripts to remove duplicate packages
On Thu, 20 Jan 2005 13:56:10 -0500, Christopher Faylor wrote: On Thu, Jan 20, 2005 at 08:48:11AM -0500, Jonathan Arnold wrote: Igor Pechtchanski wrote: That's a nice attempt. However, I can see that you're not aware of Michael Chase's clean_setup.pl (which does that and much, much more). Google for it. It is here if you are interested: http://home.ix.netcom.com/~mchase/zip/ Should this be a cygwin (or maybe a cygutuils) package? I originally wrote it as a stop-gap until setup.exe provided a way to remove obsolete packages. The other options came from user suggestions. You should have a release on file for me. Anyone who wants to add the script to a package is welcome to. The only dependency would be the main Perl package. -- Mac :}) ** I usually forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age. -- 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: Multiple installations and 3PPs (FAQ alert)
On Sat, 22 Jan 2005 01:51:38 -0500 (EST), Igor Pechtchanski wrote: | Should we, perhaps, provide a small 'uninstall' script, maybe in | /usr/sbin, that would perform a umount and then use regtool to remove the | registry key? It could even be a .bat, which will enable it to delete all | of Cygwin once the last Cygwin process exits... A postinstall script | could generate it, too, so that it contains explicit paths of the Cygwin | root directory. I like the idea of it at least saving mounts. And the paths should work (note the bin). :) -- BEGIN gen-uninst.sh -- #!/bin/sh CYGDIR=`/bin/cygpath -aw /` mount -m /saved-mounts.sh cat /uninstall.bat EOF $CYGDIR\\bin\\umount -s -A $CYGDIR\\bin\\umount -A copy $CYGDIR\\bin\\cygwin1.dll $CYGDIR\\bin\\regtool.exe %TEMP% copy $CYGDIR\\saved-mounts.sh %TEMP% $CYGDIR\\bin\\rm -rf / del /s $CYGDIR %TEMP%\\regtool remove /HKLM/Software/Cygnus Solutions %TEMP%\\regtool remove /HKCU/Software/Cygnus Solutions del %TEMP%\\cygwin1.dll %TEMP%\\regtool.exe EOF -- 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: cygwin bughunt (FAQ alert?)
OK the three FAQs beginning at http://cygwin.com/faq/faq0.html#SEC102 now read: How do I build Cygwin on my own? First, you need to get the Cygwin source. Ideally, you should check out what you need from CVS (http://cygwin.com/cvs.html). This is the preferred method for acquiring the sources. Otherwise, you can install the cygwin source package from the distribution. If you are trying to duplicate a cygwin release then you should just download the corresponding source package and use tar xjf to unpack it. This will unpack the sources into a directory named cygwin-x.y.z-n, where x.y.z-n correspond to the version numbering of the tar.bz2 package. tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 You must build cygwin in a separate directory from the source, so create something like a `build/' directory. You will also want to install to a temporary location: mkdir build mkdir /install cd build (../configure --prefix=/install -v; make) make.out make install install.log 21 Normally, this procedure ignore errors in building the documentation. which requires the `docbook-xml', `docbook-xsl', and `xmlto' packages. For more information on building the documentation, see the README included in the cygwin-doc package. To check a cygwin1.dll, run make check in the winsup/testsuite directory. If that works, install everything except the dll (if you can). Then, close down all cygwin programs (including bash windows, inetd, etc.), save your old dll, and copy the new dll to the correct place. Then start up a bash window, or run a cygwin program from the Windows command prompt, and see what happens. If you get the error shared region is corrupted it means that two different versions of cygwin1.dll are running on your machine at the same time. Remove all but one. I may have found a bug in Cygwin, how can I debug it (the symbols in gdb look funny)? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so we recommend trying the latest snapshot from http://cygwin.com/snapshots/ or build the DLL from CVS. To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the `--enable-debugging' option to `../configure'. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). How can I compile Cygwin for an unsupported platform (PowerPC, Alpha, ARM, Itanium)? Unfortunately, this will be difficult. Exception handling and signals support semantics and args have been designed for x86 so you would need to write specific support for your platform. We don't know of any other incompatibilities. Please send us patches if you do this work! -- 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: Very strange rxvt problem - game hangs when it is running
Igor Pechtchanski wrote: On Fri, 21 Jan 2005, Jonathan Arnold wrote: Igor Pechtchanski wrote: On Fri, 21 Jan 2005, Jonathan Arnold wrote: Igor Pechtchanski wrote: On Fri, 21 Jan 2005, Jonathan Arnold wrote: 1] Run Day of Defeat - connects and runs just fine. 2] Start rxvt. Try DoD again. It gets about halfway through its startup process, then hangs. 3] Quit rxvt and try again. DoD works fine. I tried the same procedure with the regular Cygwin bash shell, and it behaves the same way. [snip] Any ideas on what it could be? A WAG, and I may be really off on this: Cygwin uses TCP/IP sockets (which essentially require a TCP/IP port) to emulate Unix domain sockets. If rxvt reserves a Unix domain socket (even if it's not using X), and DoD tries to access the same port, because it's somehow predefined and it expects it to be free, there could be a conflict. I can't think of anything else in Cygwin that would interfere with a (presumably) non-Cygwin application. Well, unless the regular bash shell does it too, that probably isn't correct. Like I said, it is very weird and it took me some time to figure it out. The regular bash that you tried is really a login shell. That *can* run X-related stuff, e.g., from /etc/profile.d scripts. A real test would be to try a non-login bash (just run c:\cygwin\bin\bash.exe -i from a CMD prompt). If that doesn't interfere with DoD, it would make my WAG more probable. Otherwise we'll have to look for other possible reasons. Okay, I tried it this way too, and it still hangs DoD. FWIW, running MSYS (MinGW's bash), does not hang DoD. Very Odd. Yep. Curiouser and curiouser... Does *any* Cygwin process have that effect? Try running c:\cygwin\bin\sleep.exe 60 from a CMD prompt -- does *that* make DoD hang? Strangely enough, yes that too does make DoD hang. How very very strange. -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Amazing Developments http://www.buddydog.org I feel like a fugitive from the law of averages. - William H. Mauldin -- 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/
wordexp cygwin dll 1.5.12-1
Can someone explain the existence of wordexp.h in /usr/include in the latest version of Cygwin? I understand that the header file exists and as far as I can tell bash has the --wordexp feature (as required in the header). Is wordexp() compiled into the latest version of cygwin or not? John M. Lauck -- 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: cygwin bughunt (FAQ alert?)
On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the `--enable-debugging' option to `../configure'. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). You must have missed my post where I said not to use the --enable-debugging option. Please remove the mention of the --enable-debugging option. This should only be done when you've been prompted to do so. It's for developers, not for normal users. cgf -- 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: Sharing zsh history in cygwin.
Andrew Markebo [EMAIL PROTECTED] writes: Anyone managed to share command line history between running zsh's in latest cygwin's? I don't use SHARE_HISTORY (just inc_append_history, hist_ignore_all_dups, hist_no_store and my history sizes are 100 times larger than yours), but... setopt HISTIGNOREDUPS HISTIGNORESPACE EXTENDED_HISTORY setopt INC_APPEND_HISTORY SHARE_HISTORY HISTSIZE=300 SAVEHIST=300 HISTFILE=~/.history The last line, HISTFILE, freezes the cygwin-distributed zsh (4.2.0) just after reading the config-files. Removing just that line ...after some cygwin update (a few months ago) my zshs also started freezing during startup. I tracked the problem down to HISTFILE being assigned a file that resides on a network drive (a Linux samba share in this case, I didn't try anything else). If I changed my history file to reside on a local hard drive, zsh no longer froze. Is your home directory on a local drive? -- Hannu -- 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/
Help! Need B.20.1 src
Hi, I'm looking for the source for the cygwin1.dll b.20.1.19 version, put out in 1999. The CVS tree on the RedHat site only goes back 4 years, and I guess they just threw everything before that in the bit bucket. Anybody got a copy, or know where I can get it? -- 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: cygwin bughunt (FAQ alert?)
On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the `--enable-debugging' option to `../configure'. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). On Sat, 22 Jan 2005 16:06:43 -0500, Christopher Faylor wrote: You must have missed my post where I said not to use the --enable-debugging option. Please remove the mention of the --enable-debugging option. This should only be done when you've been prompted to do so. It's for developers, not for normal users. Yep, I missed that. It's gone, but with the other FAQ additions it moved: http://cygwin.com/faq/faq0.html#SEC104 -- 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: Multiple installations and 3PPs
How about a FAQ entry along the following lines: How do I save, restore, delete, or modify the Cygwin information stored in the registry? Currently Cygwin stores its mount table information in the registry. It is recommended that you use the 'mount' and 'umount' commands to manipulate the mount information instead of directly modifying the registry. To save the mount information to a file for later restoration, use mount -m mounts.txt. To remove all mount information use umount -A. To reincorporate saved mount information use eval mounts.txt. The mount -m command is actually intended to be a .bat, so it can be something like: c:\mount -m mounts.bat # to record it OK, I've added that one and one about building a live CD since that's been coming up, too: http://cygwin.com/faq/faq0.html#SEC24 -- 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: Help! Need B.20.1 src
On Sat, Jan 22, 2005 at 05:23:41PM -0500, John Mellor wrote: I'm looking for the source for the cygwin1.dll b.20.1.19 version, put out in 1999. The CVS tree on the RedHat site only goes back 4 years, and I guess they just threw everything before that in the bit bucket. Anybody got a copy, or know where I can get it? How about humoring us and telling us why you think you need this. cgf -- 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: cygwin bughunt (FAQ alert?)
On Sat, Jan 22, 2005 at 03:42:15PM -0800, Joshua Daniel Franklin wrote: On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the `--enable-debugging' option to `../configure'. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). On Sat, 22 Jan 2005 16:06:43 -0500, Christopher Faylor wrote: You must have missed my post where I said not to use the --enable-debugging option. Please remove the mention of the --enable-debugging option. This should only be done when you've been prompted to do so. It's for developers, not for normal users. Yep, I missed that. It's gone, but with the other FAQ additions it moved: http://cygwin.com/faq/faq0.html#SEC104 This feels vaguely like I'm programming in Fortran again. It would be nice (tm, (C), etc.) if there was some way to put permanent anchors in the FAQ so that we wouldn't have to rely on renumbered sections. Isn't there any way to accomplish that? cgf -- 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: Help! Need B.20.1 src
Christopher Faylor wrote: On Sat, Jan 22, 2005 at 05:23:41PM -0500, John Mellor wrote: I'm looking for the source for the cygwin1.dll b.20.1.19 version, put out in 1999. The CVS tree on the RedHat site only goes back 4 years, and I guess they just threw everything before that in the bit bucket. Anybody got a copy, or know where I can get it? How about humoring us and telling us why you think you need this. Isn't it obvious, Chris? Everybody knows that cygwin B20.1 was practically perfect in every way. Later releases were only made to salve the developers' egos, since they had obviously outlasted their usefulness once the perfect cygwin was released, in B20.1. Some people are too smart to be taken in by the bogus claptrap of the higher version numbers like 1.3.18 or 1.5.12. B20.1 is da bomb, baby! -- Chuck -- 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: Help! Need B.20.1 src
On Sat, 2005-22-01 at 18:44 -0500, Christopher Faylor wrote: On Sat, Jan 22, 2005 at 05:23:41PM -0500, John Mellor wrote: I'm looking for the source for the cygwin1.dll b.20.1.19 version, put out in 1999. The CVS tree on the RedHat site only goes back 4 years, and I guess they just threw everything before that in the bit bucket. Anybody got a copy, or know where I can get it? How about humoring us and telling us why you think you need this. Some time ago, I built a package that links in this DLL that somebody found useful, and now actually wants to pay me for. Having to put food on the table, I'd like to oblige them. Rather than upgrading to the latest-and-greatest, and all the work involved in changing APIs, etc., I just want to ship the one that I've got, seeing as it works perfectly well. Correct me if I'm mistaken, but if I'm going to make a few dollars off of a non-free something that links in an open source library, I need to provide the source for the open-source parts with the product, or fall afoul of the LGPL. So, to make everybody happy, I believe that all I need to add, is to provide the source for cygwin1.dll to the Customer. Quite some time ago, I lost my most of my older cygwin stuff when I had a disk crash and a bad backup, and I guess I'm going to need to replace some of it. However, the source tree for this old stuff is no longer available in the RedHat CVS repository or the many mirrors that I've checked. Any idea where I can get it now? -- 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: Help! Need B.20.1 src
On Sat, Jan 22, 2005 at 08:00:00PM -0500, John Mellor wrote: On Sat, 2005-22-01 at 18:44 -0500, Christopher Faylor wrote: On Sat, Jan 22, 2005 at 05:23:41PM -0500, John Mellor wrote: I'm looking for the source for the cygwin1.dll b.20.1.19 version, put out in 1999. The CVS tree on the RedHat site only goes back 4 years, and I guess they just threw everything before that in the bit bucket. Anybody got a copy, or know where I can get it? How about humoring us and telling us why you think you need this. Some time ago, I built a package that links in this DLL that somebody found useful, and now actually wants to pay me for. Having to put food on the table, I'd like to oblige them. Rather than upgrading to the latest-and-greatest, and all the work involved in changing APIs, etc., I just want to ship the one that I've got, seeing as it works perfectly well. Thanks for satisfying my curiousity. We go to quite some effort to make sure that nothing changed from B20 until now, so you should just be able to send your customer the latest cygwin DLL + sources without resorting to finding an almost six year old version of cygwin1.dll. There is no need to change APIs. Any idea where I can get it now? Nope. I wrote all of the warnings on the home page at http://cygwin.com/ : The last Bxx release was in December 1998. The Bxx releases are no longer available. In fact, older versions of the DLL or utilities are not usually available on this web site. Any cygwin program built from December 1998 onward should work correctly with newer DLLs. cgf -- 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: Multiple installations and 3PPs (FAQ alert)
On Sat, 22 Jan 2005, Joshua Daniel Franklin wrote: On Sat, 22 Jan 2005 01:51:38 -0500 (EST), Igor Pechtchanski wrote: | Should we, perhaps, provide a small 'uninstall' script, maybe in | /usr/sbin, that would perform a umount and then use regtool to remove the | registry key? It could even be a .bat, which will enable it to delete all | of Cygwin once the last Cygwin process exits... A postinstall script | could generate it, too, so that it contains explicit paths of the Cygwin | root directory. I like the idea of it at least saving mounts. And the paths should work (note the bin). :) Whoops! Missed that. However, the mounts should be saved *inside* uninstall.bat, using a Windows path. :-) Also, since you're *uninstalling* Cygwin, the mounts should go into a .bat, not a .sh, with a more suggestive name... -- BEGIN gen-uninst.sh -- #!/bin/sh CYGDIR=`/bin/cygpath -aw /` cat /uninstall.bat EOF $CYGDIR\\bin\\mount -m %TEMP%\\restore-mounts.bat $CYGDIR\\bin\\umount -s -A $CYGDIR\\bin\\umount -A copy $CYGDIR\\bin\\cygwin1.dll $CYGDIR\\bin\\regtool.exe %TEMP% copy $CYGDIR\\saved-mounts.sh %TEMP% $CYGDIR\\bin\\rm -rf / del /s $CYGDIR %TEMP%\\regtool remove /HKLM/Software/Cygnus Solutions %TEMP%\\regtool remove /HKCU/Software/Cygnus Solutions del %TEMP%\\cygwin1.dll %TEMP%\\regtool.exe echo Cygwin is now un-installed. echo To restore the mounts later, run %TEMP%\\restore-mounts.bat EOF --- END gen-uninst.sh --- HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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: Help! Need B.20.1 src
John Mellor wrote: Correct me if I'm mistaken, but if I'm going to make a few dollars off of a non-free something that links in an open source library, I need to provide the source for the open-source parts with the product, or fall afoul of the LGPL. So, to make everybody happy, I believe that all I need to add, is to provide the source for cygwin1.dll to the Customer. I don't know if the ancient Bxx series was LGPL, but the current Cygwin source is GPL which means you must provide not only the Cygwin DLL source but also all the source of your app that links to it. There is a mailing list to discuss this: cygwin-licensing at cygwin dot com. Brian -- 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: Help! Need B.20.1 src
On Sat, Jan 22, 2005 at 05:17:44PM -0800, Brian Dessent wrote: John Mellor wrote: Correct me if I'm mistaken, but if I'm going to make a few dollars off of a non-free something that links in an open source library, I need to provide the source for the open-source parts with the product, or fall afoul of the LGPL. So, to make everybody happy, I believe that all I need to add, is to provide the source for cygwin1.dll to the Customer. I don't know if the ancient Bxx series was LGPL, but the current Cygwin source is GPL which means you must provide not only the Cygwin DLL source but also all the source of your app that links to it. There is a mailing list to discuss this: cygwin-licensing at cygwin dot com. I think that cygwin has been GPL since early 1997. So, you're right. I can't believe I missed this. Anything that uses the Cygwin DLL is GPLed. cgf -- 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: Very strange rxvt problem - game hangs when it is running
On Sat, 22 Jan 2005, Jonathan Arnold wrote: Igor Pechtchanski wrote: On Fri, 21 Jan 2005, Jonathan Arnold wrote: 1] Run Day of Defeat - connects and runs just fine. 2] Start rxvt. Try DoD again. It gets about halfway through its startup process, then hangs. 3] Quit rxvt and try again. DoD works fine. I tried the same procedure with the regular Cygwin bash shell, and it behaves the same way. [snip] Any ideas on what it could be? A WAG, and I may be really off on this: Cygwin uses TCP/IP sockets (which essentially require a TCP/IP port) to emulate Unix domain sockets. If rxvt reserves a Unix domain socket (even if it's not using X), and DoD tries to access the same port, because it's somehow predefined and it expects it to be free, there could be a conflict. I can't think of anything else in Cygwin that would interfere with a (presumably) non-Cygwin application. Well, unless the regular bash shell does it too, that probably isn't correct. Like I said, it is very weird and it took me some time to figure it out. The regular bash that you tried is really a login shell. That *can* run X-related stuff, e.g., from /etc/profile.d scripts. A real test would be to try a non-login bash (just run c:\cygwin\bin\bash.exe -i from a CMD prompt). If that doesn't interfere with DoD, it would make my WAG more probable. Otherwise we'll have to look for other possible reasons. Okay, I tried it this way too, and it still hangs DoD. FWIW, running MSYS (MinGW's bash), does not hang DoD. Very Odd. Yep. Curiouser and curiouser... Does *any* Cygwin process have that effect? Try running c:\cygwin\bin\sleep.exe 60 from a CMD prompt -- does *that* make DoD hang? Strangely enough, yes that too does make DoD hang. How very very strange. Well, I guess you found a reliable way to delay the startup of DoD on your friends' computers for 20 seconds if you ever need to -- just install Cygwin and run sleep 20. :-) Seriously, though -- must be something in the Cygwin DLL inner workings that's doing this, and it can't be the networking subsystem (as 'sleep' doesn't use it, AFAIK). One guess is that Cygwin interferes with one of the DLLs that DoD needs to load, but that would result in a failure, not a hang... Other possibilities may be that Cygwin uses some Windows API call that does something with the network on your system, and that freezes DoD (in which case other applications may do this as well), or that the name of some shared memory region coincides (I'm really grasping at straws here, you know)... See if the Windows Event Log contains any messages that could be connected with this... You might also want to try some of the system monitoring tools at http://sysinternals.com/, to perhaps trace the DoD startup in both cases and compare the traces... In short, you'll probably have to debug this yourself, sorry. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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/
SIGTRAP in /netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038
This was with 1.5.12 also happens w/ latest snapshot.
How to reproduce.
compile any C program w/ -g (the latest snapshot
Aborts
even simple compiles.)
#include stdio.h
int main(void)
{
printf(Hello World.\n);
return 0;
}
gcc -o hello -g hello.c
gdb ./hello.exe
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show
warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) b main
Breakpoint 1 at 0x40107e: file hello.c, line 5.
(gdb) r
Starting program: /home/bpriest/hello.exe
Breakpoint 1, main () at hello.c:5
5 printf(Hello World.\n);
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/bpriest/hello.exe
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
error return
/netrel/src/gdb-20041228-1/gdb/win32-nat.c:2038 was 6
Program received signal SIGTRAP, Trace/breakpoint
trap.
0x7c810867 in KERNEL32!CreateThread ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
(gdb)
__
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
--
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: gnome-vfs problems with XP SP2
Gerrit P. Haase [EMAIL PROTECTED] wrote: Walter Landry wrote: Gerrit P. Haase [EMAIL PROTECTED] wrote: Walter Landry wrote: About the gconftool-2 postinstall script hangs: Is there an easy way to figure out why gconftool is hanging? I guess the problem is starting up gconfd-2. It fails if there is a stale /tmp/gconfd-USER directory with files in it, look into /tmp if there is a directory gconfd-USERNAME and if so remove it and try to run the postinstall script again. You may need to shutdown any running gconfd-2 instances to do so. That's not it. /tmp is empty. Also, if I try to see if gconfd is running with gconftool-2 --ping, that also hangs. And during gconftool-2 is running (hanging), gconfd-2 is active or doesn't it run at all? Evtl. you're using another directory as TMP? What says: set | grep TMP set | grep TEMP As I mentioned in another message, I managed to get gnome-vfs working by removing all traces of gconfd. However, I have to do this periodically, because gconfd hangs around too long. If I run my program, then gconfd doesn't exit when the program exits. So when I exit cygwin and log out, gconfd leaves around stale locks. Am I doing something wrong? Thanks, Walter Landry [EMAIL PROTECTED] -- 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/
cygpng12.dll not found
How can I get the cygpng12.dll? I got the libpng12 installed via setup.exe. But there is no cygpng12.dll -- 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: update on hyperthreading system for cgf
I wrote: http://secure.newegg.com/app/WishR.asp?ID=1251752 Christopher Faylor wrote: Well, yeah. I sort of need a hard disk, though and is that system *guaranteed* to exhibit this problem? This motherboard, case, and power supply are the core of my desktop machine and the machines I build for clients. The 2.4C processor and 256 MB of RAM represent skimping to get the price down to near $400.00. Honestly, if you're going to build a new hyperthreading box for yourself, spend the money to do it right. You're a developer and power user; time is money. $600 vs. $400 now will save you countless hours over the next several years. I have a Pentium 4 2.8E GHz processor; current is 3.0E. I recommend it for power users and SOHO servers (+$32.00): http://www.newegg.com/app/viewProductDesc.asp?description=19-116-171DEPA=0 I have and recommend 1 GB of matched pair DDR 400 for 800 MHz FSB Pentium 4 systems (+$94.00): http://www.newegg.com/app/ViewProductDesc.asp?description=20-141-423depa=0 Here's the hard drive I use in all systems ($59.79): http://www.newegg.com/app/ViewProductDesc.asp?description=22-144-122depa=0 Here's the script running on my machine: [EMAIL PROTECTED]:~/mydocuments/cygwin-issues/hyperthreading$ cat test #! /bin/ksh mypath=$(pwd) while [[ ! -z $mypath ]] do mypath=$(pwd) if [[ -z $mypath ]] then echo Test Failed..Path is empty fi done When I fire it up in two Cygwin Bash windows, one or the other fails within 3 to 10 seconds: Trial #1: [EMAIL PROTECTED]:~/mydocuments/cygwin-issues/hyperthreading$ ./test Test Failed..Path is empty Trial #2: CVSENV[EMAIL PROTECTED]:~/mydocuments/cygwin-issues/hyperthreading$ time ./test 4 [exiting thread] pdksh 3684 cygthread::stub: erroneous thread activation (shell locked) Trial #3: [EMAIL PROTECTED]:~/mydocuments/cygwin-issues/hyperthreading$ time ./test 4 [exiting thread] pdksh 2532 cygthread::stub: erroneous thread activation (shell locked) Trial #4: [EMAIL PROTECTED]:~/mydocuments/cygwin-issues/hyperthreading$ time ./test Test Failed..Path is empty real0m41.530s user0m55.135s sys 0m21.650s David -- 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/
Cygwin Time Machine
I'm probably going to regret this :) For some time, I've been keeping a private mirror of Cygwin for my own personal use. Unlike other mirrors, I've been keeping all of the versions of all packages, along with a revision of setup.ini to go with it. Now, call me crazy (and I know you already do :), but since Cygwin Setup uses nothing more than setup.ini and the release/ directory, I thought: why not provide a historical representation of Cygwin's package from which you can actually install from? Think of it as a time machine for going back to a previous version of Cygwin. And so, that's what I did. See http://www.fruitbat.org/Cygwin/index.html#cygwincirca This provides the details of how it works. Basically, it's a bunch of timestamp based URLs which allow you to install a specific snapshot of Cygwin. So, why am I doing this? Well, I actually have need of this for work. It saved me much time and effort, because I could install additional packages at the same level of what we already had installed, thus introducing less instability into our environments, and it gives us a chance to gradually upgrade. It's a cop-out, I know, and I can already see people tut-tut'ing at this, but on the plus side, it's kind of neat to see a form of historical review of Cygwin packages. My mirroring is done automatically each day, and the time machine is also automatically regenerated along with it to keep it up to date. I really only did this for my work, but thought perhaps someone else might find it useful or interesting. Unfortinately, it only goes back to April of 2002, though I actually have package versions going back further, but not the setup.ini to go with them. Once our work has migrated to a more current Cygwin, I might remove this, but for now it's useful to me. -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood -- 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/
