Re: TeX Live transition complete
On 3/2/2012 12:04 AM, Yaakov (Cygwin/X) wrote: If you have any more questions about TeX Live, please let me know. Just one small question for now. I found that asymptote didn't build from source for me: g++ -Wall -ansi -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -I/usr/include/tirpc -g -O2 -pipe --no-var-tracking -I . -I/usr/include/tirpc -o runsystem.o -c runsystem.cc runfile.in: In function ‘void run::gen_runfile47(vm::stack*)’: runfile.in:353:19: error: ‘mkstemp’ was not declared in this scope Makefile:307: recipe for target `runfile.o' failed After reverting your patch to runfile.in (i.e., restoring the declaration of mkstemp), the build succeeded. Could my build environment be different from yours so that I need that declaration but you don't? I'm using Cygwin's gcc4-g++-4.5.3-3. Thanks. Ken
Re: TeX Live transition complete
On Sun, 2012-03-04 at 11:39 -0500, Ken Brown wrote: On 3/2/2012 12:04 AM, Yaakov (Cygwin/X) wrote: If you have any more questions about TeX Live, please let me know. Just one small question for now. I found that asymptote didn't build from source for me: g++ -Wall -ansi -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -I/usr/include/tirpc -g -O2 -pipe --no-var-tracking -I . -I/usr/include/tirpc -o runsystem.o -c runsystem.cc runfile.in: In function ‘void run::gen_runfile47(vm::stack*)’: runfile.in:353:19: error: ‘mkstemp’ was not declared in this scope Makefile:307: recipe for target `runfile.o' failed After reverting your patch to runfile.in (i.e., restoring the declaration of mkstemp), the build succeeded. Could my build environment be different from yours so that I need that declaration but you don't? I'm using Cygwin's gcc4-g++-4.5.3-3. I've been working on improving the feature test macros which control which symbols are exposed by the headers. You can just revert that section of the patch in the meantime. Yaakov
[ANNOUNCEMENT] New package: qscintilla2-2.6.1-1
The following packages have been added to the Cygwin distribution: *** libqscintilla2_8-2.6.1-1 *** libqscintilla2-common-2.6.1-1 *** libqscintilla2-devel-2.6.1-1 QScintilla is a port to Qt of the Scintilla C++ editor control. -- Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
Building ROOT (was Re: Updated: qt4-4.7.4-3)
On Sat, 2012-03-03 at 21:13 +0100, Angelo Graziosi wrote: Trying to build a CERN application, ROOT [*], it fails in this way: [...] g++ -O2 -pipe -Wall -Woverloaded-virtual -Iinclude -I/usr/X11R6/include -DQT3_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I. -I/usr/include/qt4 -I/usr/include/qt4/Qt -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtWebKit -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtXmlPatterns -o gui/qtgsi/src/TQCanvasImp.o -c /tmp/root/gui/qtgsi/src/TQCanvasImp.cxx Generating dictionary gui/qtgsi/src/G__QtGSI.cxx... core/utils/src/rootcint_tmp.exe -cint -f gui/qtgsi/src/G__QtGSI.cxx -c -DQTVERS=4 /tmp/root/gui/qtgsi/inc/TQApplication.h /tmp/root/gui/qtgsi/inc/TQRootDialog.h /tmp/root/gui/qtgsi/inc/TQRootCanvas.h /tmp/root/gui/qtgsi/inc/TQRootGuiFactory.h /tmp/root/gui/qtgsi/inc/TQCanvasMenu.h /tmp/root/gui/qtgsi/inc/TQRootApplication.h /tmp/root/gui/qtgsi/inc/TQCanvasImp.h /tmp/root/gui/qtgsi/inc/LinkDef.h Error: Symbol QCloseEvent is not defined in current scope include/TQRootDialog.h:81: Error: Symbol ce is not defined in current scope include/TQRootDialog.h:81: Error: void type variable can not be declared include/TQRootDialog.h:81: Error: Syntax error include/TQRootCanvas.h:159: Warning: Error occurred during reading source files Warning: Error occurred during dictionary source generation !!!Removing gui/qtgsi/src/G__QtGSI.cxx gui/qtgsi/src/G__QtGSI.h !!! Error: core/utils/src/rootcint_tmp: error loading headers... /tmp/root/gui/qtgsi/Module.mk:69: recipe for target `gui/qtgsi/src/G__QtGSI.cxx' failed make: *** [gui/qtgsi/src/G__QtGSI.cxx] Error 1 I believe this is a problem in the ROOT sources, not qt4, but I can't be sure since... To reproduce: $ wget ftp://root.cern.ch/root/root_v5.32.01.source.tar.gz $ tar -xf root_v5.32.01.source.tar.gz $ cd root $ ./configure win32gcc --enable-qt --with-qt-incdir=/usr/include/qt4 --with-qt-libdir=/usr/lib/qt4/lib 21 | tee /tmp/build-ROOT.log $ make 21 | tee -a /tmp/build-ROOT.log ROOT builds fine with QT4 4.5 on Cygwin and on GNU/Linux Kubuntu with QT4 4.7.4. I have unrelated problems building ROOT: Generating dictionary graf3d/g3d/src/G__G3D.cxx... core/utils/src/rootcint_tmp.exe -cint -f graf3d/g3d/src/G__G3D.cxx -c /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TTUBS.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TPARA.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TNodeDiv.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TGeometry.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TCTUB.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TPolyMarker3D.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TTUBE.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TMaterial.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TNode.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TAxis3D.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TRotMatrix.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TELTU.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TTRD1.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TXTRU.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TShape.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TPCON.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TBRIK.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/THYPE.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TPointSet3D.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TCONE.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TMarker3DBox.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TGTRA.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TPoints3DABC.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TPolyLine3D.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TSPHE.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TPGON.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/THelix.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TView3D.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TTRAP.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TCONS.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TMixture.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/TTRD2.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/inc/LinkDef.h /usr/src/ports/root/root-5.32.01-1/src/root/graf3d/g3d/Module.mk:55: recipe for target `graf3d/g3d/src/G__G3D.cxx' failed make: *** [graf3d/g3d/src/G__G3D.cxx] Floating point exception make: *** Deleting file
RE: Xwin.exe always take about 50% CPU load on Windows 7 with XDCMP connection
Hi, Thanks for your reply. I looked in the mail archives about what was solved, and thus missed indeed this announcement. So I apparently looked at the wrong place, or the wrong month of the archive, sorry. My keyword where I searched for was 'CPU' 'load'. Kees On 02/03/2012 09:24, Kees Dekker wrote: I’m using Xwin.exe (version 5. Feb 2012, X.org servers – 1.11.4-3) on my Windows 7 system. When connecting with XDCMP (using startxdcmp.bat, with %RUN% XWin -query %REMOTE_HOST% -once -lesspointer -clipboard -emulate3buttons), after connect, the CPU load is about 50%. Even when nothing is done (only the CDE desktop is running, nothing else). On another Windows 7 system, also connecting with XDCMP to the same server, same CDE, the CPU load is not that high. The version of XWin is one of 5. Feb 2009. The XCDMP server is a Solaris 10 system, using Solaris classic CDE (not the Java Desktop environment). The high CPU load did not happen when the CDE waits for the logon screen, but happens as soon as login was completed. BTW. Just when I was writing this email I decided to check (again) for a newer version, and there was one… Moving to X.org servers 1.11.4-5 seems to solve this issue ☺. However, I did not find any release note telling that this problem was solved…. I'm not sure where you were looking if you didn't find [1]. 'On Cygwin 1.7.10 this caused XWin to spin, when started from a non-cygwin process, spamming the log with _XSERVTransSocketUNIXAccept: accept() failed messages.' [1] http://cygwin.com/ml/cygwin-xfree-announce/2012-02/msg4.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer
src/winsup/cygwin ChangeLog winver.rc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-03-04 13:19:21 Modified files: winsup/cygwin : ChangeLog winver.rc Log message: * winver.rc: Bump copyright date. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5732r2=1.5733 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/winver.rc.diff?cvsroot=srcr1=1.9r2=1.10
src/winsup/cygwin ChangeLog dll_init.cc dll_init.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-03-04 13:50:12 Modified files: winsup/cygwin : ChangeLog dll_init.cc dll_init.h Log message: * dll_init.cc: Revert pathname changes from 2012-02-08. (dll_list::operator[]): Add long comment to explain the misery. (dll_list::alloc): Skip long pathname prefix potentially returned by GetModuleFileNameW. * dll_init.h (dll_list::find_by_modname): Add back declaration. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5733r2=1.5734 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dll_init.cc.diff?cvsroot=srcr1=1.100r2=1.101 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dll_init.h.diff?cvsroot=srcr1=1.31r2=1.32
src/winsup/cygwin ChangeLog dll_init.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-03-04 16:47:45 Modified files: winsup/cygwin : ChangeLog dll_init.cc Log message: * dll_init.cc (dll_list::alloc): Compare linked DLLs by basename only. Explain why. Add code to check if a DLL with the same basename but different path is the same DLL. Bail out if not. (in_load_after_fork): New static NO_COPY bool to allow to differ between linked and loaded DLL at fork. (dll_list::load_after_fork): Set in_load_after_fork accordingly. (dll_dllcrt0_1): Don't treat DLL as linked if in_load_after_fork is set. Drop test for in_forkee. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5734r2=1.5735 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dll_init.cc.diff?cvsroot=srcr1=1.101r2=1.102
[ANNOUNCEMENT] [TEST] Uploaded base-files-4.1-2
Version 4.1-2 of base-files has been uploaded. Base-files is a set of system configuration and setup files. Testers please report to the cygwin list cases where the ACL enforcement described below is not properly set. 4.1-2 * Enforce a secure ACL in /home /tmp /usr/tmp /var/log /var/run using new files /etc/profile.d/1777fix.* written by Corinna Vinschen. See cygwin.com/ml/cygwin/2012-03/msg00103.html * Setting CYG_SYS_BASHRC in bash.bashrc has no effect because it is run in a subshell environment. Reported by Christian Franke. See cygwin.com/ml/cygwin/2012-02/msg00832.html 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: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: 1.7.10 cygrunsrv.exe fails with fork: 11, Resource temporarily unavailable
On Mar 3 20:16, Ulf-Dietrich Braumann wrote: On Sat, 3 Mar 2012, Larry Hall (Cygwin) wrote: Try this: http://cygwin.com/faq-nochunks.html#faq.using.fixing-fork-failures Thanks. Unfortunately, rebaseall did not help. I also tried peflagsall and a reboot, but no change. Also, I do not run programs mentioned in the BLODA (Big List Of Dodgy Apps). And, when I temporally replace the present cygwin1.dll version 1.7.11 with an old version 1.7.9 copied from another non-updated installation, the sshd again can be started as service, i.e. the fork problem does not occur. Any more ideas? You wrote: $ peflags --cygwin-heap=1024 /usr/sbin/sshd.exe Did you revert this setting? It's a hell of a lot of heap, which just by itself can break fork. sshd doesn't need that much heap anyway. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty scroll to bottom
On Mar 2 20:20, Andy Koppe wrote: On 2 March 2012 08:41, Corinna Vinschen wrote: On Mar 1 20:43, Andy Koppe wrote: On 29 February 2012 12:46, Lemke, Michael SZ/HZA-ZSW wrote: What is the mintty equivalent to rxvt/xterm's -si|+si Turn on/off scroll-to-bottom on TTY output inhibit; resource scrollTtyOutput has opposite effect. There's no such option. Shift+End will get you back to the current output after looking at something in the scrollback, as will any keypress that sends something to the terminal. Any chance to implement this? Automatic scroll-to-bottom is a useful feature, IMHO. I disagree. The point of being able to scroll back to earlier output is to read and perhaps copy something. When doing that, having the scrollback jump back to the bottom without the user asking for it is rather unhelpful. The Windows console does this, and I always found it really frustrating. THat's why this is an option in xterm. Every use has another idea how the terminal should behave in this regard, I guess. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setting TZ may break time() in non-Cygwin programs
On Mar 2 22:35, Christian Franke wrote: Corinna Vinschen wrote: On Mar 1 21:15, Christian Franke wrote: TZ environment variable is set by default since base-files 4.0.7. Unfortunately this breaks the time() calculation for all non-Cygwin programs run from Cygwin if Microsoft C runtime (mscrt*.dll) is used. MS CRT evaluates TZ but supports only a very old syntax subset. IIRC this is the case since VS1.x (DOS/Win16) and did not change since at least VS10. I'm sorry, but I really don't care enough. If that's a problem, then just unset TZ in your environment before calling non-Cygwin tools, no? Of course, after tracking down the problem to the new TZ it is now easy to unset it :-) No problem in scripts, but inconvenient and error prone for interactive use. But, as usual, PTC. OK, ... Simple: Unset TZ for Win32 programs run from Cygwin. More flexible: Set (unset) TZ=CYGWIN_WINENV_TZ if this variable is set (to empty). Otherwise keep TZ as is. would a patch for any of the above have a chance to get accepted? If it's not getting too complicated, yes. However, the second idea I don't understand. Can you explain this differently? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh-add hangs with latest snapshot
On Mar 2 17:38, Karl M wrote: On a system I have, which has not been updated to 1.7.11 (or a snapshot) I get the following when I type $ ssh-add -l Could not open a connection to your authentication agent. $ uname -a CYGWIN_NT-6.1-WOW64 Coyote 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin in the case when there is no ssh-agent running. On a machine that I have updated to the latest, and now today, a snapshot, $ ssh-add -l just hangs. $ uname -a CYGWIN_NT-6.1 Susan 1.7.12s(0.260/5/3) 20120302 13:00:25 i686 Cygwin cygcheck for the second machine attached. Works fine for me. Tested on W7/64, W2K8R2, W7/32. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.11-1 broke perl using dynamic loading
On Mar 3 10:04, Scott wrote:
With the introduction of cygwin 1.7.11-1, perl scripts that use
dynamic loading fail with dll errors when another program is exec'ed.
The host OS is windows 7 professional, 32-bit. The error message
looks like the familiar perl problem fixed by rebaseall, but this
time, that remedy did not fix the problem.
A perl one-liner is enough to demonstrate:
win7% perl -MParams::Util -e 'system q{date}'
3 [main] perl 3428 child_copy: loaded dll data write copy failed,
0x721D6000..0x721D635C, done 0, windows pid 5360, Win32 error 487
Thanks for the report. I fixed that in CVS. I really hope this has
no other side effects this time :-P
I'm just generating a developers snapshot for testing. Please give the
today's snapshot from http://cygwin.com/snapshots/ a try.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.10 cygrunsrv.exe fails with fork: 11, Resource temporarily unavailable
Yes, Corinna, I reverted this setting again to the default 384MB heap size calling: $ peflags --cygwin-heap=0 /usr/sbin/sshd.exe and $ peflags --cygwin-heap=0 /usr/bin/cygrunsrv.exe Later on, someone has recommended me to downgrade cygrunsrv from 1.36-1 to 1.34-1. This helped, so now under cygwin1.dll 1.7.11 the sshd can be started. However, the mechanism behaves strange reporting problems: C:\net start sshd The CYGWIN sshd service is starting. The CYGWIN sshd service could not be started. The service did not report an error. More help is available by typing NET HELPMSG 3534. Having a look into the Event Viewer of my Win2k3 64bit machine, I correspondingly find: ... `sshd' service stopped, exit status: 0. This however is misleading, since I clearly see the sshd running now (I made sure it was not running before), and indeed I can now connect using slogin and sftp: top - 14:41:26 up 21:27, 0 users, load average: 0.00, 0.00, 0.00 Tasks: 3 total, 1 running, 2 sleeping, 0 stopped, 0 zombie top - 14:42:48 up 21:29, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 7 total, 1 running, 6 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0% user, 0.4% system, 0.0% nice, 99.6% idle Mem: 13630564k total, 2475144k used, 11155420k free,0k buffers Swap: 2095104k total,56792k used, 2038312k free,0k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 14960 mylogin RT 0 5128 5272 1144 R2 0.0 0:00.09 top 14616 mylogin RT 0 4668 4596 952 S0 0.0 0:00.06 sftp-server 14132 cyg_serv RT 0 6380 6840 960 S0 0.1 0:00.06 sshd 14460 mylogin RT 0 6596 7440 2064 S0 0.1 0:00.14 tcsh 14104 mylogin RT 0 4336 3844 888 S0 0.0 0:00.07 ash 1 mylogin RT 0 6096 6796 2068 S0 0.0 0:00.04 tcsh 14340 cyg_serv RT 0 9784 10m 1876 S0 0.1 0:00.12 sshd When I try to start sshd from Services menu accessible from the Administrative Tools menu, I also get a message that the sshd has been started and then stopped again (even though it actually runs). And in the Status column no Started entry occurs. Hope this report may help to fix these problems seemingly related to cygwin1.dll 1.7.11 and cygrunsrv 1.36-1. Now I have downgraded to cygrunsrv 1.34-1 and sshd can be used, whereas earlier I found that cygrunsrv 1.36-1 and cygwin1.dll 1.7.9 (I had manually downgraded) also made sshd launchable as service (but have not documented the messages, I think similar misleading start-stop messages were given). Thanks - Ulf-Dietrich On Sun, 4 Mar 2012, it was written: You wrote: $ peflags --cygwin-heap=1024 /usr/sbin/sshd.exe Did you revert this setting? It's a hell of a lot of heap, which just by itself can break fork. sshd doesn't need that much heap anyway. Corinna On Mar 3 20:16, Ulf-Dietrich Braumann wrote: On Sat, 3 Mar 2012, Larry Hall (Cygwin) wrote: Try this: http://cygwin.com/faq-nochunks.html#faq.using.fixing-fork-failures Thanks. Unfortunately, rebaseall did not help. I also tried peflagsall and a reboot, but no change. Also, I do not run programs mentioned in the BLODA (Big List Of Dodgy Apps). And, when I temporally replace the present cygwin1.dll version 1.7.11 with an old version 1.7.9 copied from another non-updated installation, the sshd again can be started as service, i.e. the fork problem does not occur. Any more ideas? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: xetex problem - Couldn't open font map file kanjix.map
Ken Brown writes: On 3/3/2012 12:21 PM, Dr. Volker Zell wrote: Hi I just tried xetex according to o http://www.tug.org/texlive/doc/texlive-en/texlive-en.html (3.5 Testing the installation) but got the following: 01:54 PM [516] xetex opentype-info.tex This is XeTeX, Version 3.1415926-2.3-0.9997.5 (TeX Live 2011) restricted \write18 enabled. entering extended mode (/usr/share/texmf-dist/tex/xetex/xetexfontinfo/opentype-info.tex [1] ** WARNING ** Couldn't open font map file kanjix.map. I get this warning also, but it appears to be harmless. kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+240/600 --dpi 840 ec-lmssbx10 mktexpk: don't know how to create bitmap font for ec-lmssbx10. mktexpk: perhaps ec-lmssbx10 is missing from the map file. kpathsea: Appending font creation commands to missfont.log. ** WARNING ** Could not locate a virtual/physical font for TFM ec-lmssbx10. ** WARNING ** There are no valid font mapping entry for this font. ** WARNING ** Font file name ec-lmssbx10 was assumed but failed to locate that font. ** ERROR ** Cannot proceed without .vf or physical font for PDF output... Have you installed the texlive-collection-fontsrecommended package? This is the one that contains the ec-lmssbx10 font. Yes it's installed and the contents was also listed in the ls-R file. Strange... BTW I just did the following steps manually /usr/bin/updmap-sys --syncwithtrees /usr/bin/updmap-sys /usr/bin/mktexlsr and now everything is fine. I think the call to /usr/bin/updmap-sys is missing from the texlive postinstall scripts. This step at least creates the kanjix.map file below /var/lib/texmf/fonts/map/dvipdfm/updmap Ken Ciao Volker -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[Packaging bug] asymptote-2.15-1: info file in wrong location
Hi asymptote-2.15-1 has it's info file in the wrong location, below /usr/share/info/asymptote Ciao Volker -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh-add hangs with latest snapshot
On Sun, Mar 04, 2012 at 02:45:09PM +0100, Corinna Vinschen wrote: On Mar 2 17:38, Karl M wrote: On a system I have, which has not been updated to 1.7.11 (or a snapshot) I get the following when I type $ ssh-add -l Could not open a connection to your authentication agent. $ uname -a CYGWIN_NT-6.1-WOW64 Coyote 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin in the case when there is no ssh-agent running. On a machine that I have updated to the latest, and now today, a snapshot, $ ssh-add -l just hangs. $ uname -a CYGWIN_NT-6.1 Susan 1.7.12s(0.260/5/3) 20120302 13:00:25 i686 Cygwin cygcheck for the second machine attached. Works fine for me. Tested on W7/64, W2K8R2, W7/32. Also works for me with W7/64. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: xetex problem - Couldn't open font map file kanjix.map
On 3/4/2012 10:03 AM, Dr. Volker Zell wrote: Ken Brown writes: On 3/3/2012 12:21 PM, Dr. Volker Zell wrote: Hi I just tried xetex according to o http://www.tug.org/texlive/doc/texlive-en/texlive-en.html (3.5 Testing the installation) but got the following: 01:54 PM [516] xetex opentype-info.tex This is XeTeX, Version 3.1415926-2.3-0.9997.5 (TeX Live 2011) restricted \write18 enabled. entering extended mode (/usr/share/texmf-dist/tex/xetex/xetexfontinfo/opentype-info.tex [1] ** WARNING ** Couldn't open font map file kanjix.map. I get this warning also, but it appears to be harmless. kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+240/600 --dpi 840 ec-lmssbx10 mktexpk: don't know how to create bitmap font for ec-lmssbx10. mktexpk: perhaps ec-lmssbx10 is missing from the map file. kpathsea: Appending font creation commands to missfont.log. ** WARNING ** Could not locate a virtual/physical font for TFM ec-lmssbx10. ** WARNING ** There are no valid font mapping entry for this font. ** WARNING ** Font file name ec-lmssbx10 was assumed but failed to locate that font. ** ERROR ** Cannot proceed without .vf or physical font for PDF output... Have you installed the texlive-collection-fontsrecommended package? This is the one that contains the ec-lmssbx10 font. Yes it's installed and the contents was also listed in the ls-R file. Strange... BTW I just did the following steps manually /usr/bin/updmap-sys --syncwithtrees /usr/bin/updmap-sys /usr/bin/mktexlsr and now everything is fine. I think the call to /usr/bin/updmap-sys is missing from the texlive postinstall scripts. This step at least creates the kanjix.map file below /var/lib/texmf/fonts/map/dvipdfm/updmap The first call to updmap-sys is in the postinstall scripts. I'm surprised that you need to call it a second time. I'll look into this. Thanks for the report. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird behavior of tcsh.exe?
On Mar 4 06:55, sborer wrote: Hi, I'm not sure if this is a bug or some kind of feature, but it seems like the behavior of tcsh.exe somewhat depends on its file name. running the line: tcsh.exe -c 'echo d:\a\b\c' results in the output: d. As if escaping of the argument occurred. if i copy tcsh.exe to a different name not starting with tcsh.exe, for example ntcsh.exe, then running: ntcsh.exe -c 'echo d:\a\b\c' results in the output: d:\a\b\c Is this intentional? (Are there inside the code of tcsh.exe some lines that actually check its filename and determine its behavior accordingly?) Yes. If the name is tcsh, it behaves as tcsh, as csh otherwise. As for the builtin echo command, the tcsh variant allows SysV and BSD-style, the non-tcsh version only BSD-style. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin-1.7.10-1 fork - address space needed by ... already in use
On Feb 8 11:22, Denis Excoffier wrote: On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote: On Feb 8 10:08, Denis Excoffier wrote: Result is: 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C with type 1=DLL_LINK) is perhaps already occupied 1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C with type 1=DLL_LINK) is perhaps already occupied 2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C with type 2=DLL_LOAD) is perhaps already occupied 2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C with type 2=DLL_LOAD) is perhaps already occupied Denis, can you please give the latest snapshot DLL a try in all circumstances in which you saw the above kind of fork problems in 1.7.10? I applied a patch which should now work out the differences between linked and loaded DLLs better than before. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setting TZ may break time() in non-Cygwin programs
Corinna Vinschen wrote: On Mar 2 22:35, Christian Franke wrote: Corinna Vinschen wrote: But, as usual, PTC. OK, ... Simple: Unset TZ for Win32 programs run from Cygwin. More flexible: Set (unset) TZ=CYGWIN_WINENV_TZ if this variable is set (to empty). Otherwise keep TZ as is. would a patch for any of the above have a chance to get accepted? If it's not getting too complicated, yes. However, the second idea I don't understand. Can you explain this differently? Let another variable change the value passed to Windows environment: $ printenv TZ Europe/Berlin $ cmd /c echo %TZ% Europe/Berlin $ export CYGWIN_WINENV_TZ=CET-1CEST $ printenv TZ Europe/Berlin $ cmd /c echo %TZ% CET-1CEST $ export CYGWIN_WINENV_TZ= $ cmd /c echo %TZ% %TZ% (which means TZ is not set) Christian -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: xetex problem - Couldn't open font map file kanjix.map
On Sun, 2012-03-04 at 16:03 +0100, Dr. Volker Zell wrote: BTW I just did the following steps manually /usr/bin/updmap-sys --syncwithtrees /usr/bin/updmap-sys /usr/bin/mktexlsr and now everything is fine. I think the call to /usr/bin/updmap-sys is missing from the texlive postinstall scripts. This step at least creates the kanjix.map file below /var/lib/texmf/fonts/map/dvipdfm/updmap Doing that would require texlive-collection-langcjk to be installed, otherwise udpmap-sys returns an error. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh-add hangs with latest snapshot
On Mar 4 10:00, Karl M wrote: From: karl To: cygwin Subject: RE: ssh-add hangs with latest snapshot Date: Sun, 4 Mar 2012 09:41:09 -0800 Date: Sun, 4 Mar 2012 14:45:09 +0100 From: corinna To: cygwin Subject: Re: ssh-add hangs with latest snapshot On Mar 2 17:38, Karl M wrote: On a system I have, which has not been updated to 1.7.11 (or a snapshot) I get the following when I type $ ssh-add -l Could not open a connection to your authentication agent. $ uname -a CYGWIN_NT-6.1-WOW64 Coyote 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin in the case when there is no ssh-agent running. On a machine that I have updated to the latest, and now today, a snapshot, $ ssh-add -l just hangs. $ uname -a CYGWIN_NT-6.1 Susan 1.7.12s(0.260/5/3) 20120302 13:00:25 i686 Cygwin cygcheck for the second machine attached. Works fine for me. Tested on W7/64, W2K8R2, W7/32. Corinna Here is an strace in case that helps. I used setup to reinstall everything (selected reinstall for each item) and I still have the problem. Does the agent run? From the strace it looks like the socket file still exists but there's no process listening on the port. Or maybe there is a process listening, but doesn't reply to the credential package sent from the ssh-add client: 195 495706 [main] ssh-add 4636 fhandler_socket::af_local_connect: af_local_connect called 1120 496826 [main] ssh-add 4636 fhandler_socket::af_local_send_secret: Sending af_local secret succeeded And here you're pressing Ctrl-C: --- Process 4636, exception 40010005 at 777AE37D Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setting TZ may break time() in non-Cygwin programs
On Mar 4 19:42, Christian Franke wrote: Corinna Vinschen wrote: On Mar 2 22:35, Christian Franke wrote: Corinna Vinschen wrote: But, as usual, PTC. OK, ... Simple: Unset TZ for Win32 programs run from Cygwin. More flexible: Set (unset) TZ=CYGWIN_WINENV_TZ if this variable is set (to empty). Otherwise keep TZ as is. would a patch for any of the above have a chance to get accepted? If it's not getting too complicated, yes. However, the second idea I don't understand. Can you explain this differently? Let another variable change the value passed to Windows environment: $ printenv TZ Europe/Berlin $ cmd /c echo %TZ% Europe/Berlin $ export CYGWIN_WINENV_TZ=CET-1CEST $ printenv TZ Europe/Berlin $ cmd /c echo %TZ% CET-1CEST $ export CYGWIN_WINENV_TZ= $ cmd /c echo %TZ% %TZ% (which means TZ is not set) Hmm. I think just unsetting TZ should be sufficient. MSVCRT uses the current timezone as default anyway, doesn't it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh-add hangs with latest snapshot
On Mar 4 21:47, Corinna Vinschen wrote: On Mar 4 10:00, Karl M wrote: Here is an strace in case that helps. I used setup to reinstall everything (selected reinstall for each item) and I still have the problem. Does the agent run? From the strace it looks like the socket file still exists but there's no process listening on the port. Or maybe there is a process listening, but doesn't reply to the credential package sent from the ssh-add client: 195 495706 [main] ssh-add 4636 fhandler_socket::af_local_connect: af_local_connect called 1120 496826 [main] ssh-add 4636 fhandler_socket::af_local_send_secret: Sending af_local secret succeeded And here you're pressing Ctrl-C: --- Process 4636, exception 40010005 at 777AE37D And, btw., there is no change at all in the socket code between 1.7.10 and 1.7.11, except for the BLODA detection when creating a socket, and that code is disabled by default. It looks like some local problem on your machine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: ssh-add hangs with latest snapshot
On Mar 4 21:47, Corinna Vinschen wrote: On Mar 4 10:00, Karl M wrote: Here is an strace in case that helps. I used setup to reinstall everything (selected reinstall for each item) and I still have the problem. Does the agent run? From the strace it looks like the socket file still exists but there's no process listening on the port. Or maybe there is a process listening, but doesn't reply to the credential package sent from the ssh-add client: 195 495706 [main] ssh-add 4636 fhandler_socket::af_local_connect: af_local_connect called 1120 496826 [main] ssh-add 4636 fhandler_socket::af_local_send_secret: Sending af_local secret succeeded And here you're pressing Ctrl-C: --- Process 4636, exception 40010005 at 777AE37D And, btw., there is no change at all in the socket code between 1.7.10 and 1.7.11, except for the BLODA detection when creating a socket, and that code is disabled by default. It looks like some local problem on your machine. Odd...I manually deleted the socket file and now it works. And it again works even when the old socket file is left behind. In any event, thanks for your help. ...Karl -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.11-1 broke perl using dynamic loading
On Sun, 4 Mar 2012 15:08:33 +0100, Corinna Vinschen wrote:
On Mar 3 10:04, Scott wrote:
With the introduction of cygwin 1.7.11-1, perl scripts that use
dynamic loading fail with dll errors when another program is exec'ed.
The host OS is windows 7 professional, 32-bit. The error message
looks like the familiar perl problem fixed by rebaseall, but this
time, that remedy did not fix the problem.
A perl one-liner is enough to demonstrate:
win7% perl -MParams::Util -e 'system q{date}'
3 [main] perl 3428 child_copy: loaded dll data write copy failed,
0x721D6000..0x721D635C, done 0, windows pi
d 5360, Win32 error 487
Thanks for the report. I fixed that in CVS. I really hope this has
no other side effects this time :-P
I'm just generating a developers snapshot for testing. Please give the
today's snapshot from http://cygwin.com/snapshots/ a try.
I installed the snapshot cygwin1.dll in place of the 1.7.10-1 version,
crossed my fingers, and ran the perl one-liner. I am delighted to
report you've fixed it!
Corinna, you rock! Thank you!
Scott
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [Packaging bug] asymptote-2.15-1: info file in wrong location
On 3/4/2012 10:05 AM, Dr. Volker Zell wrote: Hi asymptote-2.15-1 has it's info file in the wrong location, below /usr/share/info/asymptote Thanks. I'll fix it for the next release. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin-1.7.10-1 fork - address space needed by ... already in use
On Sun, Mar 04, 2012 at 06:22:10PM +0100, Corinna Vinschen wrote: On Feb 8 11:22, Denis Excoffier wrote: On Wed, Feb 08, 2012 at 10:27:11AM +0100, Corinna Vinschen wrote: On Feb 8 10:08, Denis Excoffier wrote: Result is: 1 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C with type 1=DLL_LINK) is perhaps already occupied 1720 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C with type 1=DLL_LINK) is perhaps already occupied 2085 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygiconv-2.dll' (0x674C with type 2=DLL_LOAD) is perhaps already occupied 2440 [main] gcc-4 4084 dll_list::reserve_space: address space needed by 'cygintl-8.dll' (0x6F5C with type 2=DLL_LOAD) is perhaps already occupied Denis, can you please give the latest snapshot DLL a try in all circumstances in which you saw the above kind of fork problems in 1.7.10? I applied a patch which should now work out the differences between linked and loaded DLLs better than before. % uname -a CYGWIN_NT-5.1 edited 1.7.12s(0.260/5/3) 20120304 17:49:39 i686 Cygwin % I am now unable to report any problem of that sort. I have compiled the cygwin1.dll, the new gcc-4.7.0-rc-20120302, and several other packages with no occurrence of such a message. I've only to report that i observe some time to time the something failed for pid message (see several instances below). Win32 Error 5 is ERROR_ACCESS_DENIED i suppose (in winerrors.h). I don't know what we are expected to do with these. In addition, they do not seem to hurt much. Also i've to say that i've installed the CYGWIN=detect_bloda and nothing has shown up (still). Regards, Denis Excoffier. 947 [main] sh 660! _pinfo::dup_proc_pipe: something failed for pid 0: res 660, hProcess 0x6C8, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 2 [main] sh 3360! _pinfo::dup_proc_pipe: something failed for pid 0: res 3360, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1345 [main] sh 3772! _pinfo::dup_proc_pipe: something failed for pid 0: res 3772, hProcess 0x6CC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 2 [main] sh 792! _pinfo::dup_proc_pipe: something failed for pid 0: res 792, hProcess 0x6D0, wr_proc_pipe 0x75C vs. 0x75C, Win32 error 5 1 [main] sh 3328! _pinfo::dup_proc_pipe: something failed for pid 0: res 3328, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] sh 1980! _pinfo::dup_proc_pipe: something failed for pid 0: res 1980, hProcess 0x6BC, wr_proc_pipe 0x74C vs. 0x74C, Win32 error 5 1 [main] sh 628! _pinfo::dup_proc_pipe: something failed for pid 0: res 628, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] sh 856! _pinfo::dup_proc_pipe: something failed for pid 0: res 856, hProcess 0x6BC, wr_proc_pipe 0x758 vs. 0x758, Win32 error 5 1 [main] tcsh 3300! _pinfo::dup_proc_pipe: something failed for pid 0: res 3300, hProcess 0x6F0, wr_proc_pipe 0x768 vs. 0x768, Win32 error 5 Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[TEST] Uploaded base-files-4.1-2
Version 4.1-2 of base-files has been uploaded. Base-files is a set of system configuration and setup files. Testers please report to the cygwin list cases where the ACL enforcement described below is not properly set. 4.1-2 * Enforce a secure ACL in /home /tmp /usr/tmp /var/log /var/run using new files /etc/profile.d/1777fix.* written by Corinna Vinschen. See cygwin.com/ml/cygwin/2012-03/msg00103.html * Setting CYG_SYS_BASHRC in bash.bashrc has no effect because it is run in a subshell environment. Reported by Christian Franke. See cygwin.com/ml/cygwin/2012-02/msg00832.html 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: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
