[Maybe-ITP] PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't have much of a liking for PHP myself, but seeing the large quantity of people who _do_ want it, and being the apache2 maintainer, I feel like I ought to at least make a bit of an effort to make it available. So: I have prospective PHP packages building right now, but: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. (2) I'm making no attempt to support Apache 1.x - it's pretty much in the terminal phase of its life-cycle, and I'm unwilling to spend much time working on it. Given the above caveats, do you think I should proceed with the ITP process, or not? Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFEUPgFfFNSmcDyxYARAmaXAKCiOjxUbXjME9FSr9RVP4ewzUts9QCfV2AK Ubi5xn4bEqA2F/DDcQMjdJ8= =8z3U -END PGP SIGNATURE-
Re: [Maybe-ITP] PHP
Max Bowsher maxb1-B2Gdhv0Jo/[EMAIL PROTECTED] writes: I don't have much of a liking for PHP myself, but seeing the large quantity of people who _do_ want it, and being the apache2 maintainer, I feel like I ought to at least make a bit of an effort to make it available. So: I have prospective PHP packages building right now, but: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. (2) I'm making no attempt to support Apache 1.x - it's pretty much in the terminal phase of its life-cycle, and I'm unwilling to spend much time working on it. Given the above caveats, do you think I should proceed with the ITP process, or not? Please do. PHP 4.x is not a very well designed, but PHP 5.x has decent class support for writing reusable code. Jari
Re: [Maybe-ITP] PHP
On Thu, April 27, 2006 5:57 pm, Max Bowsher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't have much of a liking for PHP myself, but seeing the large quantity of people who _do_ want it, and being the apache2 maintainer, I feel like I ought to at least make a bit of an effort to make it available. So: I have prospective PHP packages building right now, but: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. (2) I'm making no attempt to support Apache 1.x - it's pretty much in the terminal phase of its life-cycle, and I'm unwilling to spend much time working on it. Given the above caveats, do you think I should proceed with the ITP process, or not? Please, that would be most appreciated. The 'limitations' arn't really very bad :) J.
Re: [Maybe-ITP] PHP
Max Bowsher wrote: Given the above caveats, do you think I should proceed with the ITP process, or not? I had tought to do this ITP too, but as I'm already enough behind schedule with existing packages I always delayed this to later... I would obviously appreciate it. I suggest to add FastCGI support (very useful with lighttpd package) and --enable-zend-multibyte: it enables auto-recognition of PHP files in unicode formats, if they have a leading BOM (as used by many editors). In many years of use of that option on both Windows and FreeBSD I found no bad side-effects, and will be active by default in PHP 6. Lapo
Re: [Maybe-ITP] PHP
Max Bowsher wrote: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. A non-modular PHP is very sub-optimal, since it doesn't allow you to add/remove support libraries. It's either all or nothing. But I tried in the past to get a modular one working and it was a great deal of work, so I suppose a static PHP is better than nothing, but still disappointing. Brian
Re: Default directory is C:\PROGRA~1\RATIONAL\RATION~1\NUTCROOT\mksnt\?
Not entirely true, Larry. If he *were* to remove that installation of MKS, he would then discover that his Rational Rose/Clearcase/Clearquest installation was broken. IBM's Rational toolkit relies on having those MKS tools available (and no, they cannot be coerced into using cygwin's tools instead). I don't use Clearquest, but I use both Rose and ClearCase and I didn't installed at all MKS. Anyway I had the problem described by the original poster when I installed Rational Rose the first time because I choose to install Quality Architect (if I remember well), removing that component I haven't had no more problems with Cygwin. Ciao, Danilo -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog pipe.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-04-27 16:38:21 Modified files: winsup/cygwin : ChangeLog pipe.cc Log message: * pipe.cc (DEFAULT_PIPEBUFSIZE): Raise to 64K. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3497r2=1.3498 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/pipe.cc.diff?cvsroot=srcr1=1.85r2=1.86
Ownership/permissions of files on an external disk drive used with several PCs
Hi, My question is how to best manage ownership/permission on an external disk drive. I'm using an external drive with different PCs, and/or different accounts and groups. I would like that all files created or modified on any PC/account is readable AND modifiable from any other PC/account (files created from Windows apps or cygwin (e.g. emacs, latex,...)). For the moment, the default ownership is typically 644 (-rw-r--r--) and therefore not modifiable from an other PC/account (from an other PC the ownership and group are displayed as ). Up to now, I manually modify permission or ownership, but I would very much appreciate an automatic procedure. for example such that all files created (from Windows AND cygwin) are 666. Note that I can not change the name of the different accounts I'm using on different PCs. Olivier -- [EMAIL PROTECTED]http://www.unige.ch/~renaud/ Methodology and Data Analysis - Section of Psychology - FPSE University of Geneva - 40, Bd du Pont d'Arve - CH-1211 Geneva 4 -- 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: rsync over ssh hang issue understood
On Apr 26 15:22, Ren? Berber wrote: Steven Hartland wrote: [snip] tcsh is the default shell on FreeBSD which is the recieving end in this test yes but I'm a little confused how the shell could effect the results of rsync? FreeBSD to FreeBSD for FreeBSD to Windows SFU doesnt have this issue so something specific to tcsh on cygwin? Yes, the problem with cvs (actually cvs over ssh) was caused by the shell that starts the remote ssh process. An example of this failure is: [log] rsync -av --progress cygwin1:/testdir/ /testdir/ receiving file list ... 1705 files to consider created directory testdir / bf2_w32ded.exe 0 0%0.00kB/s0:00:00 ***Hung here*** ^CKilled by signal 2.0.00kB/s0:00:00 rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(242) [receiver] rsync error: unexplained error (code 255) at rsync.c(242) [generator] [/log] Even though the destination has now been terminated the rsync process on the cygwin source box is still sitting there. Checking on the cygwin box no shell is actually running. Then it must be something different. I guess so, too. tcsh on Cygwin reads its input in textmode, that's right, but in the problem of the OP tcsh isn't involved. rant The rsync hangs problem is not actually a new one. We had these reports already ages ago. However, *nobody* so far having that problem seem to be willing to actually debug this problem and track it down. Grrr. /rant Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 1.5.19 Windows 2003 / croned shells stay hung
On Apr 26 21:26, [EMAIL PROTECTED] wrote: Since we installed on Windows 2003 (SP1 or not) few weeks ago, the same problem came back. So I got my own croned job garbage collector that avoid having 50 bash.exe/sh.exe and cron.exe in the air after one month of execution. I browse for a long time the mailing lists and google and so on. If you have some advices or questions, ... You could try a recent developer snapshot from http://cygwin.com/snapshots/ and see if it helps. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Fixing the state of C++ in Cygwin
Doyle Rhynard wrote: Did you have much trouble building gcc-3.4.4-1? I have been trying off and on for several weeks to get it to build with no errors. Interestingly, the --enable-fully-dynamic-string is set by default in the build script. I have followed these steps: ___ cd /tmp mkdir src cd src/ cd /tmp/src/ wget -N ftp://mirrors.kernel.org/sources.redhat.com/cygwin/release/gcc/gcc-g++/gcc-g++-3.4.4-1-src.tar.bz2 wget -N ftp://mirrors.kernel.org/sources.redhat.com/cygwin/release/gcc/gcc-g77/gcc-g77-3.4.4-1-src.tar.bz2 wget -N ftp://mirrors.kernel.org/sources.redhat.com/cygwin/release/gcc/gcc-core/gcc-core-3.4.4-1-src.tar.bz2 wget -N ftp://mirrors.kernel.org/sources.redhat.com/cygwin/release/gcc/gcc-ada/gcc-ada-3.4.4-1-src.tar.bz2 wget -N ftp://mirrors.kernel.org/sources.redhat.com/cygwin/release/gcc/gcc-gdc/gcc-gdc-3.4.4-1-src.tar.bz2 wget -N ftp://mirrors.kernel.org/sources.redhat.com/cygwin/release/gcc/gcc-objc/gcc-objc-3.4.4-1-src.tar.bz2 wget -N ftp://mirrors.kernel.org/sources.redhat.com/cygwin/release/gcc/gcc-java/gcc-java-3.4.4-1-src.tar.bz2 wget -N ftp://mirrors.kernel.org/sources.redhat.com/cygwin/release/gcc/gcc-testsuite/gcc-testsuite-3.4.4-1-src.tar.bz2 tar -xjvf gcc-core-3.4.4-1-src.tar.bz2 tar -xjvf gcc-g++-3.4.4-1-src.tar.bz2 tar -xjvf gcc-g77-3.4.4-1-src.tar.bz2 tar -xjvf gcc-objc-3.4.4-1-src.tar.bz2 tar -xjvf gcc-java-3.4.4-1-src.tar.bz2 tar -xjvf gcc-gdc-3.4.4-1-src.tar.bz2 tar -xjvf gcc-ada-3.4.4-1-src.tar.bz2 tar -xjvf gcc-testsuite-3.4.4-1-src.tar.bz2 Removing: in gcc-3.4.4-1.sh Commented out mountpwd \ Added --enable-fully-dynamic-string \ in conf section ./gcc-3.4.4-1.sh prep ./gcc-3.4.4-1.sh conf ./gcc-3.4.4-1.sh build ./gcc-3.4.4-1.sh build_gnatlib_and_tools ./gcc-3.4.4-1.sh build_info ./gcc-3.4.4-1.sh build_proto ./gcc-3.4.4-1.sh install ./gcc-3.4.4-1.sh strip_exe ./gcc-3.4.4-1.sh install2 ./gcc-3.4.4-2.sh pre_pkg ./gcc-3.4.4-2.sh pkg ___ this gives 7 packages core,g++,...objc I note that the structure is a little different from that of the official packages actually present in Cygwin: - no libphobos* build - part of D compiler is in gcc-core instead of gcc-gdc - some *.a file in i686-pc-cygwin instead in i686-pc-cygwin/3.4.4 - some includes for D not installed ... I also question the wisdom of requiring building of all of the gcc languages: c, c++, d, objc, ada, and java requires a considerable amount of time. I confirm: it takes almost 12 hours on 1.3 GHz processor for the build step (./gcc-3.4.4-1.sh build). I do not have a clue whether a particular patch should be reversed or not before being applied, in ada, for example. I just accepted the default and hoped for the best. I Confirm. I have accepted the default hoping it works, too. In any case I am mainly interessed to gcc, g++, g77. From the mailing list it seems to be urgent some fix to GCC in Cygwin. In the Cygwin distribution there are packages like Octave that are incompatible with gcc-3.4.4-1, yet. Cheers, Angelo. -- 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: Ownership/permissions of files on an external disk drive used with several PCs
On Apr 27 09:51, Olivier Renaud wrote: Hi, My question is how to best manage ownership/permission on an external disk drive. I'm using an external drive with different PCs, and/or different accounts and groups. I would like that all files created or modified on any PC/account is readable AND modifiable from any other PC/account (files created from Windows apps or cygwin (e.g. emacs, latex,...)). For the moment, the default ownership is typically 644 (-rw-r--r--) and therefore not modifiable from an other PC/account (from an other PC the ownership and group are displayed as ). Up to now, I manually modify permission or ownership, but I would very much appreciate an automatic procedure. for example such that all files created (from Windows AND cygwin) are 666. Note that I can not change the name of the different accounts I'm using on different PCs. umask 0 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Call for testing Cygwin snapshot
On Apr 26 17:19, Christopher Faylor wrote: You've mentioned that the first failing snapshot was 2006-03-13 so I'm working under the impression that your report was accurate. Neither Corinna nor I have been able to duplicate this hang. I'm running the cron job every 5 minutes overnight and it still didn't hang on my machine, using the latest Cygwin from CVS. I checked the packages I'm using and found that I'm using the same packages except for bash: $ cygcheck -c bash coreutils wget Cygwin Package Information Package VersionStatus bash 3.0-14 OK coreutils5.94-1 OK wget 1.10.2-1 OK I have switched to bash 3.1-4 a couple of minutes ago and I'm running the cron job every 3 minutes now. No hang so far. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Call for testing Cygwin snapshot
Eric Blake wrote: [...] Another set of tests is to use the experimental coreutils-5.94-5. Doing/bin/pwd inside a directory on the strange filesystem stress tests d_ino (I already know that on ClearCase (MVFS), /bin/pwd fails inside of versioned directories, such as ccase/foo@@/main/, since ClearCase refuses to list foo@@ in a readdir of ccase, but that is not cygwin's bug). And [...] I tried /bin/pwd and pwd in a versioned directory (.../business@@/main/...) and it works. Do you mean that it doesn't work with the current snapshot or with the current stable version? Which test exactly fails? Ciao, Danilo -- 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: rsync over ssh hang issue understood
rant The rsync hangs problem is not actually a new one. We had these reports already ages ago. However, *nobody* so far having that problem seem to be willing to actually debug this problem and track it down. Grrr. /rant Corinna, maybe, the amount of files has to be increased in order to provoke the error. I have run my script with only 100 instead of 300 files and it works. Maybe, you can give it a try. If there is something I can do in order to narrow down the problem, please let me know. This issue has already been discussed on the rsync list (https://bugzilla.samba.org/show_bug.cgi?id=2957) and Wayne from the rsync project was quite sure about what he called the Cygwin's pipe-data bug. Cheers, Peter -- 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: rsync over ssh hang issue understood
Corinna, snip rant The rsync hangs problem is not actually a new one. We had these reports already ages ago. However, *nobody* so far having that problem seem to be willing to actually debug this problem and track it down. Grrr. /rant This is exactly fair, several individuals did their best to debug the issue. I recall several detailed investigations, including my own, looking in detail at the rsync protocol. As I recall, this problem was tracked as far as the local pipe between ssh and rsync on the Cygwin end. When rsync is run on Cygwin, it runs ssh (presumably via popen) in a 'subshell' to start its cooperative rsync on the target and then they both read and write on their standard in and out in a strict protocol. On a UNIX/Linux system the local pipe is handled by the Kernel, on Windows, Cygwin has to handle this magic. It is this magic that eventually fails, the hang occurs when both rsync process are waiting on a read from each other, perhaps a flushing or missed signal This problem was at this point, waiting for someone more experienced to diagnose the local pipe. Brett -- 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: rsync over ssh hang issue understood
snip Doesn't even run once for me. Creating all the files over ssh works fine but the rsync invocation fails with (Client) Protocol versions: remote=1919251285, negotiated=29 protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation) When you log into the target, if there is any output on standard out, it can cause this message, which is what is meant by 'is your shell clean'. rsync runs rsync on the target via ssh and then both copies of rsync communicate with each other over their standard descriptors. The first communication is their version and protocol, if something else prints on the standard out of the target, it will cause the client to become confused. ssh into your target and see what prints during login. If you simply type rsync on each system, you should see a line such as: rsync version 2.6.6 protocol version 29 which can help in the case in which it isn't a printing issue, it is an actual mismatched protocol version. Brett -- 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/
cygrunsrv and windows update problem on W2K SP4
Hello, A few months ago someone reported (subj=Windows update vs. cygrunsrv) that windows update and cygrunsrv fails when trying to update multimedia programs on windows (MP, iTunes, etc). cygrunsrv uses nearly all cpu. With cygrunsrv 1.15-1 and cygwin 1.5.19-4, I still have the problem. A workaround seems to stop the ssh server but I cannot do this since we use it for remote admin of windows boxes. Below you'll find the state of 'cygrunsrv' when it hangs using gdb. What can I do to get more traces ? Compile cygrunsrv with debugging symbols ? (I really need to fix this problem, so please tell me how to help...) Cheers, Ludovic. = gdb session on cygrunsrv (gdb) thread 1 [Switching to thread 1 (thread 648.0x284)]#0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL (gdb) bt #0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e86335 in ReadFile () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x78edd578 in StartServiceW () from /cygdrive/c/WINNT/system32/ADVAPI32.DLL #3 0x00e4 in ?? () #4 0x0022eb0c in ?? () #5 0x0216 in ?? () #6 0x0022ea6c in ?? () #7 0x in ?? () from (gdb) thread 2 [Switching to thread 2 (thread 648.0x28c)]#0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL (gdb) bt #0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e86335 in ReadFile () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x61094182 in wait_sig () from /usr/bin/cygwin1.dll #3 0x61002f12 in cygthread::callfunc () from /usr/bin/cygwin1.dll #4 0x61003749 in cygthread::stub () from /usr/bin/cygwin1.dll #5 0x0f9c in ?? () #6 0x in ?? () from (gdb) thread 3 [Switching to thread 3 (thread 648.0x290)]#0 0x78468f03 in ntdll!ZwWaitForMulti pleObjects () from /cygdrive/c/WINNT/system32/NTDLL.DLL (gdb) bt #0 0x78468f03 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e9a1fb in WaitForMultipleObjectsEx () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x77e9a10e in WaitForMultipleObjects () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #3 0x18bdec48 in ?? () #4 0x0001 in ?? () #5 0x in ?? () from (gdb) thread 4 [Switching to thread 4 (thread 648.0x2a4)]#0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL (gdb) bt #0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e86335 in ReadFile () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x6106f2e9 in proc_waiter () from /usr/bin/cygwin1.dll #3 0x61002f12 in cygthread::callfunc () from /usr/bin/cygwin1.dll #4 0x61003749 in cygthread::stub () from /usr/bin/cygwin1.dll #5 0x in ?? () from (gdb) thread 5 [Switching to thread 5 (thread 648.0x6b8)]#0 0x7847193d in ntdll!DbgUiConnectTo Dbg () from /cygdrive/c/WINNT/system32/NTDLL.DLL (gdb) bt #0 0x7847193d in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e7fe8d in KERNEL32!DebugActiveProcess () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x61004409 in _cygtls::call2 () from /usr/bin/cygwin1.dll #3 0x in ?? () from === -- Ludovic DROLEZ Linbox / FreeALter Soft www.linbox.com www.linbox.org -- 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/
liboil package inclusion
I was wondering if the liboil package could be considered for inclusion in cygwin. I have verified that version 0.3.8 compiles and installs correctly on cygwin 1.5.19 http://liboil.freedesktop.org/ Thanks, __ Eric -- 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: rsync over ssh hang issue understood
On 27 April 2006 10:45, Brett Serkez wrote: snip Doesn't even run once for me. Creating all the files over ssh works fine but the rsync invocation fails with (Client) Protocol versions: remote=1919251285, negotiated=29 protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation) When you log into the target, if there is any output on standard out, it can cause this message, which is what is meant by 'is your shell clean'. rsync runs rsync on the target via ssh and then both copies of rsync communicate with each other over their standard descriptors. The first communication is their version and protocol, if something else prints on the standard out of the target, it will cause the client to become confused. ssh into your target and see what prints during login. Thanks for the explanation. It turns out that 1919251285 is User in ascii-hex! I was getting some output from my startup scripts because lots of the environment was missing and I was getting unbound variable warnings. cheers, DaveK -- Can't think of a witty .sigline today -- 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: rsync over ssh hang issue understood
If there is something I can do in order to narrow down the problem, please let me know. This issue has already been discussed on the rsync list (https://bugzilla.samba.org/show_bug.cgi?id=2957) and Wayne from the rsync project was quite sure about what he called the Cygwin's pipe-data bug. Yes, this is it. Reading the above reference, the 2 processes refered to on the Cygwin end are ssh and rsync, connected via a local pipe. On a Linux/UNIX system the local rsync process would have inherited the socket connected to the rsync process on the target and thus the two rsync processes would be directly connected over the socket. The Windows environment (i.e., lack of a native fork/exec/inheritance) requires the ssh process to remain involved as a middle man, passing socket data to the local pipe and visa versa. It appears to fail in this capacity at some point, leaving both ends waiting for the other. Just as a note, due to this issue, the issue with sshd/.cygrunsrv utilizing 100% of the CPU on occasion, the ssh -X/-Y hang issue, and slow bash startup with real-time virus/spyware detection active, I was forced to find an alternative, I found OpenVPN. Once two systems are securely and privately connected, any protocol can be used, for instance VNC (vs. X forwarding), rsyncd (vs. rsync over ssh), direct file system mounting and so on. OpenVPN has reasonable, UNIX like control so that the connection can be established on demand or continuous as needed and can be routed over a single socket connection like ssh, both OpenVPN and ssh ride over OpenSSL. I've noticed that once Cygwin is removed from a given system, virus scans, spyware scans and disk defragmention speed dramatically improve. I've not investigated, but I believe this is due to the large number of small files in the Cygwin directory hierachy, which is natural in a Linux/UNIX like environment. I would have prefered to have used Cygwin, at this point it is all but eliminted from production systems that I maintain as it has proven too problematic, perhaps (I hope) this will change in the future. I continue to use Cygwin in my personal environment and follow this list. Brett -- 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: Fixing the state of C++ in Cygwin
On 27 April 2006 06:46, Doyle Rhynard wrote: Did you have much trouble building gcc-3.4.4-1? I have been trying off and on for several weeks to get it to build with no errors. Interestingly, the --enable-fully-dynamic-string is set by default in the build script. Building gcc on cygwin is usually simple. What configure and build commands are you using? The bash script that does the build will not even run due an error with an extra ) into the install2 option. There is also a problem with a libstdc++ Makefile that might be caused by an error in bash, itself. This sounds like an error in your configure arguments getting transcribed into the generated makefiles to me. It's not an extra ' )', it's something missing between the '' and the ')' that's the real problem, and that probably happened because a shell variable used to generate the output from that stage of configure ended up being empty because of a failure of a pattern-match earlier on because of a mis-spelt option. (Well, for example.) Configure scripts aren't terribly robust against syntax issues and metacharacters, let's just hope nobody ever invents a target triplet with backtick-rm-dash-rf-star-backtick in it![*] I also question the wisdom of requiring building of all of the gcc languages: c, c++, d, objc, ada, and java requires a considerable amount of time. I also question the wisdom of not having read configure --help and noticed the --enable-languages= option! The reason why the source files have not been patched already is bothersome in itself. I do not have a clue whether a particular patch should be reversed or not before being applied, in ada, for example. I just accepted the default and hoped for the best. You probably shouldn't be patching anything at all. Gcc should build for cygwin OOTB; there are cygwin-specific patches that add things like -mno-cygwin, but the basic compiler should be fine as it stands. I am getting closer, in any case. On the positive side, I have learned how to use the base debugger, bashdb, as well the make debugger, remake. H! There's a *make* debugger!?!?! Hallelujah! cheers, DaveK [*] Actually the - in -rf would probably act end up acting as a triplet separator and meaning that you only ever had two partial and unclosed back-tick expressions. But *I'm* not going to try it out just in case! -- Can't think of a witty .sigline today -- 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: Call for testing Cygwin snapshot
On 26 April 2006 20:21, Jerry D. Hedden wrote: In this case, I used the full 20060426 snapshot and generated some stuck processes. The output from 'ps' showed the following: PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 2944 11332 29292? 78809 13:54:03 /usr/bin/diff 32184 1 436 2860? 78809 14:00:03 /usr/bin/mv 1560 1 28372 29084? 78809 14:06:05 /usr/bin/diff 9768 1 23420 24436? 78809 14:12:04 /usr/bin/diff Looking at the Windows Task Manager, those processes were not listed, but what I suppose to be their shell processes were: Image Name PID bash.exe2736 bash.exe9500 bash.exe 29048 bash.exe 30324 Note that no bash processes were listed by Cygwin under 'ps'. (Is this a clue?) Um. I wonder if those processes are or aren't actually there. Isn't there something about bash keeping a pid table of recently-dead kind-of-zombie processes hanging around for a while? Do they show up in ps? I have a vague memory but haven't tracked down the thread yet. EB or CV might be able to weigh in on this. cheers, DaveK -- Can't think of a witty .sigline today -- 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: rsync over ssh hang issue understood
On 26 April 2006 20:34, Steven Hartland wrote: Interestingly if I try to get a thread dump using sysinternals process explorer the rsync process goes mad using all available cpu. That's a known issue, and one which I'd like to try and work on, but it's really complex. It's a side-effect of procexp doing an RtlQueryProcessDebugInformation call on the cygwin process, which works internally by injecting a remote thread into the cygwin process; this new thread interacts badly with dll csrss in some way because it isn't lpc-registered. Unfortunately it doesn't seem possible to set a breakpoint on that function in either windbg or gdb, so it looks very much like I'm gonna hafta break out the full host'n'target kernel mode debugger to get anywhere with it. cheers, DaveK -- Can't think of a witty .sigline today -- 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: rsync over ssh hang issue understood
- Original Message - From: Dave Korn [EMAIL PROTECTED] That's a known issue, and one which I'd like to try and work on ... Unfortunately it doesn't seem possible to set a breakpoint on that function in either windbg or gdb, so it looks very much like I'm gonna hafta break out the full host'n'target kernel mode debugger to get anywhere with it. Thanks for the info there Dave appreciated. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [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/
Re: Fixing the state of C++ in Cygwin
Dave Korn wrote: The bash script that does the build will not even run due an error with an extra ) into the install2 option. There is also a problem with a libstdc++ Makefile that might be caused by an error in bash, itself. This sounds like an error in your configure arguments getting transcribed into the generated makefiles to me. It's not an extra ' )', it's something missing between the '' and the ')' that's the real problem, and that probably happened because a shell variable used to generate the output from that stage of configure ended up being empty because of a failure of a pattern-match earlier on because of a mis-spelt option. (Well, for example.) Configure scripts aren't terribly robust against syntax issues and metacharacters, let's just hope nobody ever invents a target triplet with backtick-rm-dash-rf-star-backtick in it![*] No, Dave, he's talking about a problem in the cygwin build script for gcc, which is derived from the generic-build-script. It has a syntax error that became exposed when /bin/sh was switched from ash to bash. It should just be fixed by editing the script. End of problem. The reason why the source files have not been patched already is bothersome in itself. Bothersome? No way. I WANT to know what all the official cygwin maintainer had to do to get the code to compile and work properly on cygwin -- rather than having to download the cygwin patched source and the pristine original source and then doing a diff. This is especially true when the cygwin maintainer had to do a autotools update, and the blindly-generated diff contains a lot of autogenerated stuff rather than just the important bits. I do not have a clue whether a particular patch should be reversed or not before being applied, in ada, for example. I just accepted the default and hoped for the best. You probably shouldn't be patching anything at all. Gcc should build for cygwin OOTB; there are cygwin-specific patches that add things like -mno-cygwin, but the basic compiler should be fine as it stands. Oh, sure, that'll work. Except, you know, some of those patches are kind of important: like allowing your C++ code to throw exceptions in DLLs which can then be caught by your application. etc.etc. The whole point of the cygwin packaging system is that SUPPOSEDLY, if you use the packaged script, you can rebuild the package exactly as the official distributed one was built. -- 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: Call for testing Cygwin snapshot
Another set of tests is to use the experimental coreutils-5.94-5. Doing/bin/pwd inside a directory on the strange filesystem stress tests d_ino (I already know that on ClearCase (MVFS), /bin/pwd fails inside of versioned directories, such as ccase/foo@@/main/, since ClearCase refuses to list foo@@ in a readdir of ccase, but that is not cygwin's bug). And [...] I tried /bin/pwd and pwd in a versioned directory (.../business@@/main/...) and it works. Do you mean that it doesn't work with the current snapshot or with the current stable version? Which test exactly fails? If you are using 5.94-5, then you are necessarily using a snapshot, and /bin/pwd would fail inside the versioned directory because I compiled it to use readdir() instead of getcwd(), and clearcase readdir() intentionally fails to list buisiness@@ when listing its parent directory. But coreutils 5.94-1 (and the eventual 5.94-6) stick with getcwd(), so that you should have no problems from inside a Clearcase versioned directory. And just to be sure, I will repeat my tests when I am at work today and have access to a clearcase drive, in case my claims about /bin/pwd were not quite accurate after all. -- Eric Blake volunteer cygwin coreutils maintainer -- 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: Fixing the state of C++ in Cygwin
On 27-Apr-2006, Angelo Graziosi wrote: | In the Cygwin distribution there are packages like Octave that are | incompatible with gcc-3.4.4-1, yet. Octave on Cygwin would also be helped if libstdc++ were built as a DLL. Has there been any progress on that? Is there anyone else who is interested in having a DLL for libstdc++? If there are problems that prevent this from happning, what are they? Thanks, jwe -- 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: Call for testing Cygwin snapshot
Eric Blake wrote: Another set of tests is to use the experimental coreutils-5.94-5. Doing/bin/pwd inside a directory on the strange filesystem stress tests d_ino (I already know that on ClearCase (MVFS), /bin/pwd fails inside of versioned directories, such as ccase/foo@@/main/, since ClearCase refuses to list foo@@ in a readdir of ccase, but that is not cygwin's bug). And [...] I tried /bin/pwd and pwd in a versioned directory (.../business@@/main/...) and it works. Do you mean that it doesn't work with the current snapshot or with the current stable version? Which test exactly fails? If you are using 5.94-5, then you are necessarily using a snapshot, and /bin/pwd would fail inside the versioned directory because I compiled it to use readdir() instead of getcwd(), and clearcase readdir() intentionally fails to list buisiness@@ when listing its parent directory. But coreutils 5.94-1 (and the eventual 5.94-6) stick with getcwd(), so that you should have no problems from inside a Clearcase versioned directory. And just to be sure, I will repeat my tests when I am at work today and have access to a clearcase drive, in case my claims about /bin/pwd were not quite accurate after all. No, sorry: I'm not using a snapshot. I thought you intended to say that /bin/pwd would have failed also with the current version. Ciao, Danilo -- 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: Call for testing Cygwin snapshot
Corinna Vinschen wrote: On Apr 25 00:42, Charles Wilson wrote: I'll take a look at this w.r.t clearcase. How exactly should I test -- what am I looking for? Just a little app that compares dirent.d_ino and stat.st_ino for a specified file on the strange filesystem? Thanks for the offer. Can you please send the output of the tiny tool I mailed in http://sourceware.org/ml/cygwin/2006-01/msg00818.html? Sent separately. Other than that, yes, a bit of comparison between d_ino and st_ino of would be helpful. You could use the tool I posted in http://sourceware.org/ml/cygwin/2006-04/msg00314.html. Just keep in mind that it has to be build using the sys/dirent.h header from the snapshots. Sent separately. Another important factor is, if the underlying filesystem tends to change the inode number between subsequent calls. You can either compare the inode numbers using the above tool, or you can see if you encounter the dreaded cp: skipping file 'foo', as it was replaced while being copied problem. Nope, it was very consistent and did not change over time. One oddity is that if you access a file (in a particular view (MVFS-speak for branch, more or less)) via the 'multi-view' mount /cygdrive/m/my_view/my_VOB/some-path-to/some-file you get (consistently) one number for st_ino and d_ino (call it 'A') But, if you mount my_view to a drive and access the same file in that same view via the mount /cygdrive/r/my_VOB/some-path-to/some-file you get (consistently) a different number for st_ino and d_ino (call it 'B'). Not sure if that's important (maybe it's expected behavior?) -- 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: Call for testing Cygwin snapshot
Danilo Turina danilo.turina at alcatel.it writes: No, sorry: I'm not using a snapshot. I thought you intended to say that /bin/pwd would have failed also with the current version. Here's the behavior I see in a dynamic view, under 5.94-5: $ /bin/pwd /cygdrive/l/Implementation $ cd script@@/main/ $ pwd /cygcrive/l/Implementation/script@@/main $ /bin/pwd /bin/pwd: couldn't find directory entry in `../..' with matching i-node $ Bash has always used getcwd(), and it is only the experimental 5.94-[2-5] versions that use readdir(). If you stick with the stable 5.94-1, which still uses getcwd(), or wait for cygwin-1.5.20 and coreutils-5.94-6, then you will not have the above problem when using clearcase. -- Eric Blake -- 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: Call for testing Cygwin snapshot
Charles Wilson cygwin at cwilson.fastmail.fm writes: Nope, it was very consistent and did not change over time. One oddity is that if you access a file (in a particular view (MVFS-speak for branch, more or less)) via the 'multi-view' mount /cygdrive/m/my_view/my_VOB/some-path-to/some-file you get (consistently) one number for st_ino and d_ino (call it 'A') But, if you mount my_view to a drive and access the same file in that same view via the mount /cygdrive/r/my_VOB/some-path-to/some-file you get (consistently) a different number for st_ino and d_ino (call it 'B'). Not sure if that's important (maybe it's expected behavior?) Expected behavior. According to Corinna's tool: rootdir: l:\ Volume Name: CCase Serial Number : 36984713 Max Filenamelength : 255 Filesystemname : MVFS Flags: FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE it seems MVFS does not present useful inode information, so you are getting the cygwin hash inodes. But the hash is dependent on the drive letter that the view is mounted under. -- Eric Blake -- 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: Call for testing Cygwin snapshot
Dave Korn wrote: On 26 April 2006 20:21, Jerry D. Hedden wrote: In this case, I used the full 20060426 snapshot and generated some stuck processes. The output from 'ps' showed the following: PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 2944 11332 29292? 78809 13:54:03 /usr/bin/diff 32184 1 436 2860? 78809 14:00:03 /usr/bin/mv 1560 1 28372 29084? 78809 14:06:05 /usr/bin/diff 9768 1 23420 24436? 78809 14:12:04 /usr/bin/diff Looking at the Windows Task Manager, those processes were not listed, but what I suppose to be their shell processes were: Image Name PID bash.exe2736 bash.exe9500 bash.exe 29048 bash.exe 30324 Note that no bash processes were listed by Cygwin under 'ps'. (Is this a clue?) Um. I wonder if those processes are or aren't actually there. Isn't there something about bash keeping a pid table of recently-dead kind-of-zombie processes hanging around for a while? Do they show up in ps? I have a vague memory but haven't tracked down the thread yet. EB or CV might be able to weigh in on this. Hmm, that sounds almost exactly like my problem. I'm seeing a large 'make' process occasionally get stuck[1], except the process that *seems* to be stuck shows up in 'ps', but not task manager. Sound familiar? One additional nugget is that I left it stuck over night; when I came back this morning, I found a 'bash' that had been spawned by 'make' where there shouldn't have been any (it should have exec()'d itself out of existence). This sounds like the same problem. I'm running what should be the latest release (minus any updates in the last few days), however, not a snapshot; see [1] for my cygcheck output. [1] http://cygwin.com/ml/cygwin/2006-04/msg00801.html -- Matthew Ok, so the quotes aren't entirely original. -- 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/
Can not run telnet?
Hi, I have cygwin installed on my Dell laptop with Windows XP, it works great. But today I find a strange thing, I can not start telnet. In cygwin, after I run command, telnet myMachine, it quietly returns, nothing happens. Then I go to DOS window and run the same command, it works fine. I come back to cygwin, and type which telnet and type telnet, it is using windows telnet, here is the log, which telnet /cygdrive/c/WINDOWS/system32/telnet type telnet telnet is hashed (/cygdrive/c/WINDOWS/system32/telnet) Any clue why this happens? _ DonÂ’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- 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/
GNUS and cygwin
I am using GNUS to read my news but also wanted to use it to send mail and messages to news groups. The problem is that I want to use gmail for sending and recieving. For this reason I installed cygwin with the ssl and gnutls (gmail requires tls) packages (+defaults) but it still doesn't work. GNUS finds the utilities but halts or gives me an error. I just want to know if anyone have succeeded in doing this? I know it works under Linux but the gnutls-cli utility is a later version in Linux. sincerely System: WinXP, Emacs 22.0.50.1 (cvs) on XP and GNUS 5.11. -- .gnus.el: (eval-after-load mail-source '(require 'pop3)) ;; pop3 with ssl support (setq smtpmail-debug-info t) (setq pop3-debug t) (setq gnus-refer-article-method '(current (nntp news.readfreenews.net) (nntp newshost.uni-koblenz.de) (nntp news.gmane.org) (nnweb gmane (nnweb-type gmane)) (nnweb google (nnweb-type google (setq gnus-select-method '(nntp news.readfreenews.net)) (setq gnus-secondary-select-methods '((nnml ))) (setq gnus-spam-autodetect '((nntp.* . t))) (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number gnus-thread-sort-by-subject gnus-thread-sort-by-score)) (setq user-full-name Name) (setq user-mail-address [EMAIL PROTECTED]) ;;POP mail (setq mail-sources '(; (pop :server pop.gmail.com :port 995 :user [EMAIL PROTECTED] :connection ssl :leave t))) ;; Sending mail (setq message-send-mail-function 'smtpmail-send-it) (setq smtpmail-starttls-credentials '((smtp.gmail.com 587 nil nil))) (setq smtpmail-auth-credentials '((smtp.gmail.com 587 [EMAIL PROTECTED] nil))) (setq smtpmail-default-smtp-server smtp.gmail.com) (setq smtpmail-smtp-server smtp.gmail.com) (setq smtpmail-smtp-service 587) -- 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: Call for testing Cygwin snapshot
On Thu, Apr 27, 2006 at 03:38:27PM +0200, Danilo Turina wrote: No, sorry: I'm not using a snapshot. I thought you intended to say that /bin/pwd would have failed also with the current version. Then please choose another thread to discuss any issues not involved with the Cygwin snapshot. 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: Ghost processes on Cygwin
Christopher Faylor wrote: On Wed, Apr 26, 2006 at 05:12:31PM -0500, mwoehlke wrote: I'm seeing something funny. While trying to build a large program on Cygwin using cl.exe (i.e. I am building a non-Cygwin app; just using Cygwin to drive 'make'), every now and then, cl.exe hangs. Before you tell me I'm on the wrong list :-), here's the funny part. If I do 'ps' in Cygwin, I can see the 'cl' process, along with its WINPID. However, it doesn't show up in task manager! Also, there are about five processes that are clearly Cygwin processes (bash.exe or sh.exe) that do NOT show up in Cygwin's 'ps'. Is there any logic to this that I'm missing? Yes. Windows doesn't implement the exec* family of linux system calls so cygwin has to kludge it. Ok, thanks for the information. It looks like it is actually bash that is hanging (I wonder, is the exec() failing to clean up properly), but I'm not sure what to do about it. If I try to attach with gdb, gdb hangs (but I can 'kill' it with a fatal - i.e. not-SIGINT - signal). Any suggestions on where to go from here to try to debug this? Is there a 'gdb-on-cygwin' howto somewhere that I'm missing? (See also http://cygwin.com/ml/cygwin/2006-04/msg00844.html) -- Matthew Ok, so the quotes aren't entirely original. -- 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: Can not run telnet?
On 27 April 2006 16:13, lin q wrote: Hi, I have cygwin installed on my Dell laptop with Windows XP, it works great. But today I find a strange thing, I can not start telnet. In cygwin, after I run command, telnet myMachine, it quietly returns, nothing happens. Then I go to DOS window and run the same command, it works fine. I come back to cygwin, and type which telnet and type telnet, it is using windows telnet, here is the log, which telnet /cygdrive/c/WINDOWS/system32/telnet type telnet telnet is hashed (/cygdrive/c/WINDOWS/system32/telnet) Any clue why this happens? WAG: no $SYSTEMROOT in your cygwin environment vars leading to winsock initialisation failure? cheers, DaveK -- Can't think of a witty .sigline today -- 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: GNUS and cygwin
Anders Jakobsson writes: I am using GNUS to read my news but also wanted to use it to send mail and messages to news groups. The problem is that I want to use gmail for sending and recieving. For this reason I installed cygwin with the ssl and gnutls (gmail requires tls) packages (+defaults) but it still doesn't work. GNUS finds the utilities but halts or gives me an error. I just want to know if anyone have succeeded in doing this? I know it works under Linux but the gnutls-cli utility is a later version in Linux. BTW, what I am really asking is if this SHOULD work, interaction between a cygwin utility and a non-cygwin utility. -- 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/
Xnest Cygwin package?
Is Xnest available in Cygwin? I see some reference to it in mailing lists but, cannot see a package. -- Neil Watson | Gentoo Linux System Administrator| Uptime 3 days http://watson-wilson.ca | 2.6.11.4 AMD Athlon(tm) MP 2000+ x 2 -- 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: GNUS and cygwin
On 27 Apr 2006, [EMAIL PROTECTED] wrote: Anders Jakobsson writes: I am using GNUS to read my news but also wanted to use it to send mail and messages to news groups. The problem is that I want to use gmail for sending and recieving. For this reason I installed cygwin with the ssl and gnutls (gmail requires tls) packages (+defaults) but it still doesn't work. GNUS finds the utilities but halts or gives me an error. I just want to know if anyone have succeeded in doing this? I know it works under Linux but the gnutls-cli utility is a later version in Linux. BTW, what I am really asking is if this SHOULD work, interaction between a cygwin utility and a non-cygwin utility. It works for me. The solution was: - disable McAfee's on-access scan - as this is no solution on a permanent basis, do: - open VirusScan console - open access protection properties - edit prevent mass mailing worms from sending mails - add emacs.exe to the list of excluded processes That's it! Adrian. -- 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: rsync over ssh hang issue understood
On Apr 27 11:21, Peter Keitler wrote: rant The rsync hangs problem is not actually a new one. We had these reports already ages ago. However, *nobody* so far having that problem seem to be willing to actually debug this problem and track it down. Grrr. /rant Corinna, maybe, the amount of files has to be increased in order to provoke the error. I have run my script with only 100 instead of 300 files and it works. Maybe, you can give it a try. I did and I could reproduce it. Thanks for the testcase. The fix I applied looks certainly wierd, but it works for me. Would you mind to give the next snapshot a try which should be available in a couple of minutes? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: rsync over ssh hang issue understood
On Apr 27 07:50, Brett Serkez wrote: If there is something I can do in order to narrow down the problem, please let me know. This issue has already been discussed on the rsync list (https://bugzilla.samba.org/show_bug.cgi?id=2957) and Wayne from the rsync project was quite sure about what he called the Cygwin's pipe-data bug. Yes, this is it. Reading the above reference, the 2 processes refered to on the Cygwin end are ssh and rsync, connected via a local pipe. On a Linux/UNIX system the local rsync process would have inherited the socket connected to the rsync process on the target and thus the two rsync processes would be directly connected over the socket. Err... that's not right. When rsync connects over ssh, and then ssh (or sshd) disappears, who is going to care for the encryption? You're not actually supposing the underlying OS socket knows anything about the ssh protocol, do you? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: rsync over ssh hang issue understood
On Apr 27 05:35, Brett Serkez wrote: Corinna, snip rant The rsync hangs problem is not actually a new one. We had these reports already ages ago. However, *nobody* so far having that problem seem to be willing to actually debug this problem and track it down. Grrr. /rant This is exactly fair, several individuals did their best to debug the issue. I recall several detailed investigations, including my own, looking in detail at the rsync protocol. Maybe that's not quite fair, but it *is* frustrating that 99% of the debugging stops as soon as it would involve looking into Cygwin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: cygrunsrv and windows update problem on W2K SP4 (gdb bt with cygwin1-20060426.dll)
Hi ! I've attached some backtraces with cygwin1-20060426.dll and cygwin1-20060426.gdb: when cygrunsrv is locked, I attach gdb to it. Hope this helps... BTW, does anyone know how to see which thread is looping ? Any windows system monitor with threads support ? -- Ludovic DROLEZ Linbox / FreeALter Soft www.linbox.com www.linbox.org 5 thread 984.0x668 0x7847193d in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINNT/system32/NTDLL.DLL 4 thread 984.0x500 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL * 3 thread 984.0x51c 0x78468f03 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINNT/system32/NTDLL.DLL 2 thread 984.0x600 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL 1 thread 984.0x2ec 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL [Switching to thread 1 (thread 984.0x2ec)]#0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e86335 in ReadFile () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x78edd578 in StartServiceW () from /cygdrive/c/WINNT/system32/ADVAPI32.DLL #3 0x002c in ?? () #4 0x0022ea7c in ?? () #5 0x0216 in ?? () #6 0x0022e9dc in ?? () #7 0x in ?? () from [Switching to thread 2 (thread 984.0x600)]#0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e86335 in ReadFile () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x610973ea in wait_sig () at /netrel/src/cygwin-snapshot-20060426-1/winsup/cygwin/sigproc.cc:1152 #3 0x61002f52 in cygthread::callfunc (this=0x0, issimplestub=false) at /netrel/src/cygwin-snapshot-20060426-1/winsup/cygwin/cygthread.cc:54 #4 0x61003789 in cygthread::stub (arg=0x7bef10) at /netrel/src/cygwin-snapshot-20060426-1/winsup/cygwin/cygthread.cc:102 #5 0x1074 in ?? () #6 0x in ?? () from [Switching to thread 3 (thread 984.0x51c)]#0 0x78468f03 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINNT/system32/NTDLL.DLL #0 0x78468f03 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e9a1fb in WaitForMultipleObjectsEx () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x77e9a10e in WaitForMultipleObjects () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #3 0x18b8eb68 in ?? () #4 0x0001 in ?? () #5 0x in ?? () from [Switching to thread 4 (thread 984.0x500)]#0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #0 0x78468a87 in ntdll!ZwReadFile () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e86335 in ReadFile () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x61072109 in proc_waiter (arg=0x6110367c) at /netrel/src/cygwin-snapshot-20060426-1/winsup/cygwin/pinfo.cc:855 #3 0x61002f52 in cygthread::callfunc (this=0x0, issimplestub=false) at /netrel/src/cygwin-snapshot-20060426-1/winsup/cygwin/cygthread.cc:54 #4 0x61003789 in cygthread::stub (arg=0x18d9ef10) at /netrel/src/cygwin-snapshot-20060426-1/winsup/cygwin/cygthread.cc:102 #5 0x in ?? () from [Switching to thread 5 (thread 984.0x668)]#0 0x7847193d in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINNT/system32/NTDLL.DLL #0 0x7847193d in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINNT/system32/NTDLL.DLL #1 0x77e7fe8d in KERNEL32!DebugActiveProcess () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x61004489 in _cygtls::call2 (func=0, arg=0x0, buf=0x0) at /netrel/src/cygwin-snapshot-20060426-1/winsup/cygwin/cygtls.cc:74 #3 0x in ?? () from -- 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/
Error on /bin/sh -login: cannot remove /bin/sh.exe: Permission denied
I just updated my cygwin install. on running /bin/sh -login, I got the following message: /bin/cp: cannot remove `/bin/sh.exe': Permission denied Looks like the error is coming out of /etc/profile.d/00bash.sh: the part where it's trying to update /bin/sh.exe via a copy in the midst of running profiles: /bin/cp -fpuv /bin/bash.exe /bin/sh.exe 21 /var/log/setup.log.full 1. Isn't it a little strange to have this done on user time every time users run profiles? 2. If the redirect and the file append were reversed, I'd never see the error; it would go straight to the logs. As it is, nothing goes to the logs. 3. Once I killed all my /bin/sh processes, and ran /bin/bash -login, the copyover happened OK. I'm just a freak trying to stick to sh. 4. Should this code be running when I'm under /bin/sh? Looks like it's bash-specific; I'd expect the default profile code for sh to be sh-specific. Thanks! Webb -- Webb Roberts ([EMAIL PROTECTED]) Research Scientist, Georgia Tech Research Institute Atlanta, GA (404)407-6181 -- 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: liboil package inclusion
Eric Moret wrote: I was wondering if the liboil package could be considered for inclusion in cygwin. I have verified that version 0.3.8 compiles and installs correctly on cygwin 1.5.19 http://liboil.freedesktop.org/ Packages are included when someone volunteers to maintain it. See http://cygwin.com/setup.html for more info. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: GNUS and cygwin
Adrian Lanz writes: It works for me. The solution was: - disable McAfee's on-access scan - as this is no solution on a permanent basis, do: - open VirusScan console - open access protection properties - edit prevent mass mailing worms from sending mails - add emacs.exe to the list of excluded processes That's it! Adrian. Thanks for the quick reply!! I still have problems, I get an error error (Spawning child process) when it is trying to read my account. I added the file cygwin-mount.el and some code in .emacs which I found on the net but it didn't help. Does your .gnus.el look like mine? Do you have any other software installed? Anders -- 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/
[ANNOUNCEMENT] Updated: cygrunsrv-1.16-1
I have updated cygrunsrv to version 1.16-1. This is a bugfix release. cygrunsrv 1.14 introduced the following problem: If a service has been installed with the cygrunsrv -i/--interactive option, the service process couldn't be stopped anymore using net stop or cygrunsrv -E. Instead it had to be killed manually. This should be fixed now with cygrunsrv 1.16. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Error on /bin/sh -login: cannot remove /bin/sh.exe: Permission denied
Webb Roberts webb.roberts at gtri.gatech.edu writes: I just updated my cygwin install. on running /bin/sh -login, I got the following message: /bin/cp: cannot remove `/bin/sh.exe': Permission denied Not the nicest thing to have a random error message appear on stdout during a login, especially if it would interfere with ssh or other remote protocols. But you at least still have a working /bin/sh (albeit out-of-date, or the error wouldn't have printed). Looks like the error is coming out of /etc/profile.d/00bash.sh: the part where it's trying to update /bin/sh.exe via a copy in the midst of running profiles: /bin/cp -fpuv /bin/bash.exe /bin/sh.exe 21 /var/log/setup.log.full Bah - and I'm the bash maintainer, so I should know better when writing a shell script! Not only that, but I've corrected other people on this very list for doing redirections in the wrong order! [/me goes and crawls in a hole] 1. Isn't it a little strange to have this done on user time every time users run profiles? No - because once the update has been done successfully, /bin/sh is no longer out of date, so the profile script short circuits without any further attempt to update /bin/sh. Once up-to-date, the time spent by /bin/test to check timestamps on every user's login is minimal compared to the time wasted on this list for bug reports that /bin/sh was altogether missing when people had upgrade problems that prevented the bash postinstall script from running. 2. If the redirect and the file append were reversed, I'd never see the error; it would go straight to the logs. As it is, nothing goes to the logs. Yep. And the next release of bash (expect it in the next day or two) will fix this heinous bug. 3. Once I killed all my /bin/sh processes, and ran /bin/bash -login, the copyover happened OK. Yep - Windows won't let you replace an in-use file, which is why you were getting permission denied errors on subsequent shells. When you upgrade a cygwin installation, it is MUCH better if you don't have any cygwin processes, including /bin/sh, running at the time. I'm just a freak trying to stick to sh. But in cygwin, /bin/sh IS bash (by default). The only difference is that bash turns on POSIX behavior by default when invoked as sh instead of bash. 4. Should this code be running when I'm under /bin/sh? Looks like it's bash-specific; I'd expect the default profile code for sh to be sh-specific. The code should be run for EVERY bourne-style login shell (sh, ash, bash, ksh, pdksh, zsh), because experience has shown that cygwin without /bin/sh installed is pretty much broken (think system(2), for example). In fact, I might even try to make a counterpart 00bash.csh profile script that runs for a tcsh login shell, now that I think about it. When cygwin swapped from /bin/sh being ash to being bash, I wanted to make sure that everyone has a working /bin/sh. But I also wanted to make sure that advanced users who don't want bash as their /bin/sh (for whatever reason) can have their wish too, by touching /bin/sh to have a timestamp further out into the future so that the upgrade script will not attempt to install bash in place of whatever shell you prefer as your own /bin/sh. I will also try to clean up the profile script to short-circuit when you are running /bin/sh instead of /bin/bash (obviously, if you are in sh, it is not missing, which is the worst problem the profile script tries to prevent; and since attempts to upgrade it must fail, all I can do is let you be aware that your /bin/sh may be out-of-date). Thanks! Webb Thank you for catching the bug in my postinstall script. -- Eric Blake volunteer cygwin bash maintainer -- 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: rsync over ssh hang issue understood
On Apr 27 11:21, Peter Keitler wrote: rant The rsync hangs problem is not actually a new one. We had these reports already ages ago. However, *nobody* so far having that problem seem to be willing to actually debug this problem and track it down. Grrr. /rant Corinna, maybe, the amount of files has to be increased in order to provoke the error. I have run my script with only 100 instead of 300 files and it works. Maybe, you can give it a try. I did and I could reproduce it. Thanks for the testcase. The fix I applied looks certainly wierd, but it works for me. Would you mind to give the next snapshot a try which should be available in a couple of minutes? Looks good, the new snapshot works for me. Thanks for the patch :-) What was the reason? Race-condition or something like that? Have a nice day, I will leave the office now... Peter -- 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: rsync over ssh hang issue understood
On Thu, Apr 27, 2006 at 08:04:50PM +0200, Peter Keitler wrote: corinna wrote: On Apr 27 11:21, Peter Keitler wrote: I did and I could reproduce it. Thanks for the testcase. The fix I applied looks certainly wierd, but it works for me. Would you mind to give the next snapshot a try which should be available in a couple of minutes? Looks good, the new snapshot works for me. Thanks for the patch :-) What was the reason? Race-condition or something like that? Have a nice day, I will leave the office now... Best guess is that it is still this problem: http://www.cygwin.com/ml/cygwin-patches/2004-q3/msg00079.html (see subsequent discussion for why this wasn't a real solution) which, AFAIK, remains as a problem today. The latest snapshot just increases the size of a pipe buffer. So, it isn't a real fix, just a workaround. There is still a problem lurking there but fixing it isn't trivial. 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: rsync over ssh hang issue understood
- Original Message - From: Corinna Vinschen [EMAIL PROTECTED] maybe, the amount of files has to be increased in order to provoke the error. I have run my script with only 100 instead of 300 files and it works. Maybe, you can give it a try. I did and I could reproduce it. Thanks for the testcase. The fix I applied looks certainly wierd, but it works for me. Would you mind to give the next snapshot a try which should be available in a couple of minutes? Would it help the base rsync case do you think Corinna? Should I try the snapshot here to check, if so what's the snapshot indent and where's the best place to obtain it from, not used snapshots before but if it would help you guys test worth a go? Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [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/
Re: rsync over ssh hang issue understood
On Thu, Apr 27, 2006 at 07:41:17PM +0100, Steven Hartland wrote: - Original Message - From: Corinna Vinschen maybe, the amount of files has to be increased in order to provoke the error. I have run my script with only 100 instead of 300 files and it works. Maybe, you can give it a try. I did and I could reproduce it. Thanks for the testcase. The fix I applied looks certainly wierd, but it works for me. Would you mind to give the next snapshot a try which should be available in a couple of minutes? Would it help the base rsync case do you think Corinna? Should I try the snapshot here to check, if so what's the snapshot indent and where's the best place to obtain it from, not used snapshots before but if it would help you guys test worth a go? http://cygwin.com/snapshots/ -- 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: rsync over ssh hang issue understood
- Original Message - From: Christopher Faylor Would it help the base rsync case do you think Corinna? Should I try the snapshot here to check, if so what's the snapshot indent and where's the best place to obtain it from, not used snapshots before but if it would help you guys test worth a go? http://cygwin.com/snapshots/ That's for that replacing the cygwin1.dll prevents anything from running what other steps are required? As far as I know I was running the latest release version of the cygwin1.dll The error seems fairly explanatory but apart from recompiling everything from source I wouldn't know how to progress [log] 27 [main] ? (23648) C:\cygwin\bin\bash.exe: *** fatal error - C:\cygwin\bin \bash.exe: *** system shared memory version mismatch detected - 0x75BE0096/0x75B E009B. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. [/log] Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [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/
Re: rsync over ssh hang issue understood
On Thu, Apr 27, 2006 at 07:59:05PM +0100, Steven Hartland wrote: - Original Message - From: Christopher Faylor Would it help the base rsync case do you think Corinna? Should I try the snapshot here to check, if so what's the snapshot indent and where's the best place to obtain it from, not used snapshots before but if it would help you guys test worth a go? http://cygwin.com/snapshots/ That's for that replacing the cygwin1.dll prevents anything from running what other steps are required? As far as I know I was running the latest release version of the cygwin1.dll The error seems fairly explanatory but apart from recompiling everything from source I wouldn't know how to progress [log] 27 [main] ? (23648) C:\cygwin\bin\bash.exe: *** fatal error - C:\cygwin\bin \bash.exe: *** system shared memory version mismatch detected - 0x75BE0096/0x75BE009B. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. [/log] Here's what you need to do: Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. 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/
Cygwin build error
I ran into the following problem building the latest cygwin snapshot: configure: loading cache .././config.cache configure: error: `CFLAGS' has changed since the previous run: configure: former value: -O2 -g -O2 configure: current value: -O2 -g -O2 configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm .././config.cache' and start over configure: error: /bin/sh '../../../../src/newlib/libc/configure' failed for libc By piping the output to a file, I saw that the former value of CFLAGS is -O2 -g -O2 (two spaces), while the current value is -O2 -g -O2 (one space). This causes the comparison in libc/configure to fail. The way I've resolved this is to replace the following line: if test x$ac_old_val != x$ac_new_val; then with if test `echo $ac_old_val` != `echo $ac_new_val`; then wherever it appears in any configure script (there are 75 configure scripts that contain this test, BTW). There may be a more elegant way around this, but I haven't found it. Running make distclean or removing config.cache doesn't resolve the problem. - Ernie Coskrey SteelEye Technology, Inc.803-461-3875 -- 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: rsync over ssh hang issue understood
- Original Message - From: Christopher Faylor [EMAIL PROTECTED] Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. Stupid me, perl.exe still running in the background using the old .dll. Things now run by unfortunately rsync is still hangs virtually instantly :( [log] rsync -av --progress cygwin1:/testdir/ testdir/ receiving file list ... 1705 files to consider created directory testdir ./ bf2_w32ded.exe ***HUNG HERE*** ^CKilled by signal 2.0.00kB/s0:00:00 rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(242) [receiver] rsync error: unexplained error (code 255) at rsync.c(242) [generator] [/log] Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [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/
Re: Fixing the state of C++ in Cygwin
Charles Wilson wrote: The whole point of the cygwin packaging system is that SUPPOSEDLY, if you use the packaged script, you can rebuild the package exactly as the official distributed one was built As I have written (http://cygwin.com/ml/cygwin/2006-04/msg00822.html), I used the packaged script (gcc-3.4.4-1.sh) but the packaging is a little different. For example, as it results from the script (and after executing gcc-3.4.4-1.sh pkg), libfrtbegin.a is moved in the directory i686-pc-cygwin instead that in i686-pc-cygwin/3.4.4, and g77 -print-file-name=libfrtbegin.a gives /usr/lib/gcc/i686-pc-cygwin/3.4.4/libfrtbegin.a (in which g77 is that just built) It looks that official distributed GCC-3.4.4-1 has been built with a little different script. Cheers, Angelo. -- 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: Error on /bin/sh -login: cannot remove /bin/sh.exe: Permission denied
I will also try to clean up the profile script to short-circuit when you are running /bin/sh instead of /bin/bash One thing you might do is to have the /etc/profile.d sh-update-script delete itself once it's run satisfactorily. I guess what got me on this was that there was a zombie /bin/sh process running during the cygwin update. It might have been a little less nerve-wracking if there had been a visible message during the postinstall, instead of picking it up during the login. Thanks, Webb -- Webb Roberts ([EMAIL PROTECTED]) Research Scientist, Georgia Tech Research Institute Atlanta, GA (404)407-6181 -- 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/
[ANNOUNCEMENT] Updated: (experimental) tcsh-6.14.00-6
I've uploaded an experimental version of tcsh, version 6.14.00-6. This version is supposed to fix problems which are a result of the textmode handling in the Cygwin version of tcsh. Right now, up to version 6.14.00-5, Cygwin's tcsh reads all input in textmode, thus converting \r\n for all input from stdin, not only for commands and script input. This version 6.14.00-6 has been changed so that stdin is always read in the mode with which the stdin file descriptor has been opened originally, usually binmode, except for instance when redirected from a file in a textmode mounted directory. This should solve a couple of problems reported on the Cygwin list, for example the problem with cvs and tcsh reported in http://cygwin.com/ml/cygwin/2006-04/msg00099.html, or stuff like the protocol version mismatch type of error, sometimes reported by rsync if the remote shell is tcsh, as in http://cygwin.com/ml/cygwin/2006-04/msg00780.html This version hopefully also fixes Cygwin's tcsh script misbehaviour. Long scripts with DOS lineendings in a binmode mounted directory might suffer from not being able to run longer for or while loops. The problem here is that long scripts are not kept fully in memory by tcsh. So sometimes it has to seek within the script file. For DOS files written in textmode, tcsh then seeks to the wrong spot in the file. However, I couldn't test this so far, so take this with a grain of salt. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. Look for tcsh in the 'Shells' category. Because this is an experimental version, you will have to use the 'Exp' radio button to access this release of tcsh. If you have general questions or comments, please send them to the Cygwin mailing list at: cygwin at cygwin dot com. I would appreciate it if you would use this mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cygwin@cygwin.com Red Hat, Inc. -- 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: Fixing the state of C++ in Cygwin
Doyle Rhynard wrote: Did you have much trouble building gcc-3.4.4-1? I have been trying off and on for several weeks to get it to build with no errors. Interestingly, the --enable-fully-dynamic-string is set by default in the build script. I just want to remind everyone that using --enable-fully-dynamic-string will incur a somewhat significant performance hit, and it's the reason this hasn't been set as the default for Cygwin. In the PR there is a patch that is reported to fix the problem without the full performance hit, so that would be preferable to use rather than the 20-ton hammer. 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: Fixing the state of C++ in Cygwin
Dave Korn wrote: This sounds like an error in your configure arguments getting transcribed into the generated makefiles to me. It's not an extra ' )', it's something missing between the '' and the ')' that's the real problem, and that probably happened because a shell variable used to generate the output from that stage of configure ended up being empty because of a failure of a pattern-match earlier on because of a mis-spelt option. (Well, for example.) Configure scripts aren't terribly robust against syntax issues and metacharacters, let's just hope nobody ever invents a target triplet with backtick-rm-dash-rf-star-backtick in it![*] I think this is one of those generic build script used to be written for ash but now sh is bash problems that have been reported on other GBS script packages recently. You probably shouldn't be patching anything at all. Gcc should build for cygwin OOTB; there are cygwin-specific patches that add things like -mno-cygwin, but the basic compiler should be fine as it stands. -mno-cygwin ought to work fine from the stock FSF sources I'm told (provided of course that you build it twice, once as i686-pc-cygwin and then again as i686-pc-mingw and install them to the same prefix.) 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: Fixing the state of C++ in Cygwin
On Thu, Apr 27, 2006 at 03:00:05PM -0700, Brian Dessent wrote: -mno-cygwin ought to work fine from the stock FSF sources I'm told (provided of course that you build it twice, once as i686-pc-cygwin and then again as i686-pc-mingw and install them to the same prefix.) I would hope that it does by now. I certainly hacked on it enough over the years and, unless Gerrit has been holding out on me, all of the appropriate changes are in the gcc mainline. 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/
Variable read error? Multiple spaces
Hi. After I try to read the contents of a file containing multiple spaces into a bash variable, only one space is seen in the variable. Output similar to the following 2 space example is seen for 3 spaces as well. Is this an error? If so, does anyone know a work-around? Thanks, -Siddhartha. -- Output from bash follows --- $ cati.txt Hello world $ export b=`cat i.txt` $ echo $b Hello world $ export b=`i.txt` $ echo $b Hello world $ export b=$(cat i.txt) $ echo $b Hello world $ export b=$(i.txt) $ echo $b Hello world $ cat i.txt Hello world __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.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: Variable read error? Multiple spaces
On Thu, Apr 27, 2006 at 04:08:38PM -0700, Siddhartha Shivshankar wrote: Hi. After I try to read the contents of a file containing multiple spaces into a bash variable, only one space is seen in the variable. Output similar to the following 2 space example is seen for 3 spaces as well. Is this an error? If so, does anyone know a work-around? Thanks, -Siddhartha. -- Output from bash follows --- $ cati.txt Hello world $ export b=`cat i.txt` $ echo $b Hello world Try using quotes, i.e., echo $b . 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: Variable read error? Multiple spaces
Siddhartha Shivshankar s_siddhartha at yahoo.com writes: Hi. After I try to read the contents of a file containing multiple spaces into a bash variable, only one space is seen in the variable. Output similar to the following 2 space example is seen for 3 spaces as well. Is this an error? If so, does anyone know a work-around? It is an error on your part for not quoting properly. But this is not cygwin-specific, so I would advise getting a good tutorial on shell programming and reading it (the web has plenty of resources, google is your friend). $ export b=`cat i.txt` $ echo $b Hello world Try echo $b instead. $ export b=$(i.txt) POSIX states that $() command substitutions that consist solely of redirections produce unspecified results, and are thus non-portable. -- Eric Blake volunteer cygwin bash maintainer -- 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: Fixing the state of C++ in Cygwin
Brian Dessent wrote: In the PR there is a patch that is reported to fix the problem without the full performance hit, so that would be preferable to use rather than the 20-ton hammer May you give some more details? Where is the patch? How to build applying that? Thanks, Angelo. -- 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: Fixing the state of C++ in Cygwin
From: Angelo Graziosi Brian Dessent wrote: In the PR there is a patch that is reported to fix the problem without the full performance hit, so that would be preferable to use rather than the 20-ton hammer May you give some more details? Where is the patch? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 NOTICE This e-mail and any attachments are private and confidential and may contain privileged information. If you are not an authorised recipient, the copying or distribution of this e-mail and any attachments is prohibited and you must not read, print or act in reliance on this e-mail or attachments. This notice should not be removed. -- 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: Fixing the state of C++ in Cygwin
Angelo Graziosi wrote: May you give some more details? http://gcc.gnu.org/PR24196 Where is the patch? It is attached to the PR, see comment #11 or http://gcc.gnu.org/bugzilla/attachment.cgi?id=9911action=view. How to build applying that? Like any other patch, apply to the source and then rebuild. Since the patch only touches two libstdc++ include files you *might* be able to apply it directly to the installed c++ headers without having to rebuild the compiler from source, but I don't guarantee that that's possible. 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/
Suggestions for caching only DNS server to run on CygWin
Suggestions for caching only DNS server to run on CygWin -- Herb Martin -- 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: Suggestions for caching only DNS server to run on CygWin
Herb Martin wrote: Suggestions for caching only DNS server to run on CygWin I'm not exactly sure what you're getting at here. I use the win32 native version of BIND9 for this and it works great. It's not really running on Cygwin, but I don't see what that has to do with anything. 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: Suggestions for caching only DNS server to run on CygWin
Herb Martin wrote: Suggestions for caching only DNS server to run on CygWin Like Brian said, bind works fine, either compiled under Cygwin or the binary distributed by ISC. -- René Berber -- 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: Fixing the state of C++ in Cygwin
Brian Dessent wrote: I just want to remind everyone that using --enable-fully-dynamic-string will incur a somewhat significant performance hit, and it's the reason this hasn't been set as the default for Cygwin. In the PR there is a patch that is reported to fix the problem without the full performance hit, so that would be preferable to use rather than the 20-ton hammer. The fuzzy semi-conclusion of the bug report scared me off - figured it'd be a safer choice to go with 'known to work but slower' that wouldn't add a draft patch to the diffs while they finish sorting it out in gcc land. Either way, I'd just like to see this bug fixed. :) 'slow' or 'draft', anything is better than the current: 'crash'. I'm not sure who the current gcc maintainer of Cygwin is - I think Gerrit? If it's a time issue for him, I could build the packages and fix the sh/diff this weekend given a call on which path to take - draft patch or --enable-fully-dynamic-string. I just don't want it to fall through the cracks again. -- 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: Suggestions for caching only DNS server to run on CygWin
On Thu, Apr 27, 2006 at 09:22:26PM -0500, Ren? Berber wrote: Herb Martin wrote: Suggestions for caching only DNS server to run on CygWin Like Brian said, bind works fine, either compiled under Cygwin or the binary distributed by ISC. And, moreover complete sentences which frame well-formed thoughts are also -- 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: Variable read error? Multiple spaces
Thanks Chris, Eric, quoting the variable worked. Eric Blake ebb9 at byu dot net writes: It is an error on your part for not quoting properly. But this is not cygwin-specific, so I would advise getting a good tutorial on shell programming and reading it (the web has plenty of resources, google is your friend). I use Mendel Cooper's Advanced Bash-Scripting Guide. In the following link, there is a discussion of the $IFS internal field separator variable specific to echo and linefeeds. In general, I suppose that any command could replace echo and any $IFS characters (multiple spaces in my example) could replace linefeeds. http://www.tldp.org/LDP/abs/html/internal.html#ECHOREF POSIX states that $() command substitutions that consist solely of redirections produce unspecified results, and are thus non-portable. Thank you. The following page from the scripting guide has a link to a Bash FAQ. The FAQ apparently has a complete listing of bash features that the traditional Bourne shell lacks. http://www.tldp.org/LDP/abs/html/portabilityissues.html The following page from the same guide lists command interpreters and provides a Note that links to the POSIX specifications. http://www.tldp.org/LDP/abs/html/sha-bang.html -Siddhartha. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.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: Good day
Hello, Your mail to [EMAIL PROTECTED] was caught by the SpamAssassin filter running on the bcs.org.uk mail system. To confirm that your mail is genuine, please click this link, or paste it into your browser: https://bcsnet.bcs.org.uk/approve.php?c=6924a01d2958fde615f0b36e You will not have to do this again for any mail sent to this recipient ([EMAIL PROTECTED]). Thank you. -- British Computer Society - www.bcs.org.uk Email Services from gradwell dot com - www.gradwell.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/
