Re: [ITA] joe 3.5 - Fast and simple editor which emulates 5 other editors
* Thu 2007-08-16 Corinna Vinschen [EMAIL PROTECTED] On Aug 16 11:08, Jari Aalto wrote: Adopted joe (by Joe Allen) The packaging looks mostely ok, but not quite. The /usr/share/joe directory is now /etc/joe. Is that a good reason to move it? [Currect sources rely on that location and changing it is not easy] I've now addressed this so that the highlighting, language and charmap files go under /user/share/package/ and *rc files go under: /etc/package/ Jari sdesc: Fast and simple editor which emulates 5 other editors ldesc: JSTAR is a close immitation of WordStar with many JOE extensions. JPICO is a close immitation of the Pine mailing system's PICO editor, but with many extensions and improvements. JMACS is a Emacs imitation. RJOE is a restricted version of JOE, which allowes you to edit only the files specified on the command line. category: Editors requires: cygwin libncurses8 a) manual wget\ http://cygwin.cante.net/joe/setup.hint \ http://cygwin.cante.net/joe/joe-3.5-2-src.tar.bz2 \ http://cygwin.cante.net/joe/joe-3.5-2.tar.bz2 \ b) atomatic; for build testing gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8 mkdir joe ; cd joe rm -f get.sh get.sh.sig wgethttp://cygwin.cante.net/joe/get.sh \ http://cygwin.cante.net/joe/get.sh.sig gpg --verify get.sh.sig get.sh sh get.sh -- Welcome to FOSS revolution: we fix and modify until it shines
Re: [ITP] VOTE bmp2png 1.62 -- Convert BMP images to PNG and vice versa
According to Jari Aalto on 12/2/2007 7:27 AM: Needs votes. Reini +1 Volker +1 Eric +1 Ping, any more voters? Jari
RE: [ITP] VOTE bmp2png 1.62 -- Convert BMP images to PNG and vice versa
On 14 December 2007 08:24, Jari Aalto wrote: According to Jari Aalto on 12/2/2007 7:27 AM: Needs votes. Reini +1 Volker +1 Eric +1 Ping, any more voters? Jari +1. Source build ok. Packaging, ok except two things: in your man page, it's trival but may as well mention: DESCRIPTION A image conversion program -- An image conversion program. Secondly: /tmp/bmp2png $ cygcheck usr/bin/* usr/bin/bmp2png.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cygpng12.dll C:\cygwin\bin\cygz.dll usr/bin/png2bmp.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cygpng12.dll C:\cygwin\bin\cygz.dll /tmp/bmp2png $ cat setup.hint sdesc: Convert BMP images to PNG and vice versa ldesc: Command-line utilities that convert between Windows BMP format and PNG (Portable Network Graphics). category: Graphics requires: cygwin libpng12 zlib Not supposed to mention indirect dependencies in setup.hint requires lines. cheers, DaveK -- Can't think of a witty .sigline today
[GTG] Re: [ITA] joe 3.5 - Fast and simple editor which emulates 5 other editors
Jari Aalto writes: * Thu 2007-08-16 Corinna Vinschen [EMAIL PROTECTED] On Aug 16 11:08, Jari Aalto wrote: Adopted joe (by Joe Allen) The packaging looks mostely ok, but not quite. The /usr/share/joe directory is now /etc/joe. Is that a good reason to move it? [Currect sources rely on that location and changing it is not easy] I've now addressed this so that the highlighting, language and charmap files go under /user/share/package/ and *rc files go under: /etc/package/ Builds fine from source, packaging and setup.hint look good. GTG Volker
Re: [ITA] ttcp 20071212 -- Network benchmarking tool
Jari Aalto writes: * Wed 2007-12-12 Dr Dr [EMAIL PROTECTED] * Message-Id: [EMAIL PROTECTED] /usr/include/sys/time.h:73: warning: previous declaration of 'gettimeofday' was here 10:58 PM [819] cygcheck -cd | grep cygwin cygwin 1.5.25-4 I Needed to upgrade to newest Cygwin dll. Fixed now. Builds fine from source and setup.hint looks good. But there used to be a package README file in the original version. Ciao Volker
Re: setup.exe segfaults on upgrade of libopenldap2_3_0
I'm running setup.exe version 2.573.2.2. Every time I run it, it wants to upgrade libopenldap2_3_0 from version 2.3.36-1 to 2.3.39-1. If I accept that, then setup gets past the checksum check stage and then segfaults. This is probably the issue of a corrupt .lst.gz file. Delete /etc/setup/libopenldap2_3_0.lst.gz and everything should work fine. Yup, that was it: $ zcat /etc/setup/libopenldap2_3_0.lst.gz gzip: /etc/setup/libopenldap2_3_0.lst.gz: unexpected end of file I removed the file and libopenldap has now upgraded successfully. Thanks! Andrew.
Re: [ITA] xmon 1.5.6-2 -- An interactive X protocol monitor
Jari Aalto writes: * Wed 2007-12-12 Dr Dr [EMAIL PROTECTED] * Message-Id: [EMAIL PROTECTED] Jari Aalto writes: Adopting package by Harold L Hunt. Packaging and setup.hint looks good. Builds fine from source. But is the postinstall script really needed ? setup will remove the old files when installing the new version. You're right. Now removed. The original package contained an additional symbolic link from xmonui.1x to xmon.1x Ciao Volker
Re: [ITA] nedit 5.5-2 -- A powerful, customizable, Motif based text editor
Jari Aalto writes: Adoption of package by Harold L Hunt. 12:49 PM [859] ./nedit-5.5-2.sh all -- cygbuild 2007.1213.0940 http://freshmeat.net/projects/cygbuild -- [NOTE] Using GBS compat mode for source and binary packages -- [NOTE] command [all] is used for checking build procedure only. See -h for source development options. ** Verifying signatures in /usr/local/src -- Extracting /usr/local/src/nedit_5.5.orig.tar.gz -- [WARN] archive does not contain nedit-5.5/ -- Renaming unpack dir: mv nedit-5.5.orig nedit-5.5 -- [NOTE] applying included patches to sources (if any) -- Making Cygwin directories under /usr/local/src/nedit-5.5 -- Running 'make clean' (or equiv.) in /usr/local/src/nedit-5.5 (cd util; make -f Makefile.common clean) make[1]: Entering directory `/usr/local/src/nedit-5.5/util' rm -f DialogF.o getfiles.o printUtils.o misc.o fileUtils.o prefFile.o fontsel.o managedList.o utils.o clearcase.o libNUtil.a check_lin_tif make[1]: Leaving directory `/usr/local/src/nedit-5.5/util' (cd Xlt;make -f Makefile.common clean) make[1]: Entering directory `/usr/local/src/nedit-5.5/Xlt' rm -f BubbleButton.o SlideC.o libXlt.a make[1]: Leaving directory `/usr/local/src/nedit-5.5/Xlt' (cd Microline/XmL;make -f Makefile.common clean) make[1]: Entering directory `/usr/local/src/nedit-5.5/Microline/XmL' rm -f Folder.o XmL.o libXmL.a make[1]: Leaving directory `/usr/local/src/nedit-5.5/Microline/XmL' (cd source; make -f Makefile.common clean) make[1]: Entering directory `/usr/local/src/nedit-5.5/source' rm -f nedit.o file.o menu.o window.o selection.o search.o undo.o shift.o help.o preferences.o tags.o userCmds.o shell.o regularExp.o macro.o text.o textSel.o textDisp.o textBuf.o textDrag.o server.o highlight.o highlightData.o interpret.o parse.o smartIndent.o regexConvert.o rbTree.o windowTitle.o calltips.o server_common.o rangeset.o nedit nc nc.o parse.c linkdate.o make[1]: Leaving directory `/usr/local/src/nedit-5.5/source' -- Running 'make distclean' (or equiv.) in /usr/local/src/nedit-5.5 ** Shadow command -- Running: make clean distclean (ignore errors; if any) (cd util; make -f Makefile.common clean) make[1]: Entering directory `/usr/local/src/nedit-5.5/util' rm -f DialogF.o getfiles.o printUtils.o misc.o fileUtils.o prefFile.o fontsel.o managedList.o utils.o clearcase.o libNUtil.a check_lin_tif make[1]: Leaving directory `/usr/local/src/nedit-5.5/util' (cd Xlt;make -f Makefile.common clean) make[1]: Entering directory `/usr/local/src/nedit-5.5/Xlt' rm -f BubbleButton.o SlideC.o libXlt.a make[1]: Leaving directory `/usr/local/src/nedit-5.5/Xlt' (cd Microline/XmL;make -f Makefile.common clean) make[1]: Entering directory `/usr/local/src/nedit-5.5/Microline/XmL' rm -f Folder.o XmL.o libXmL.a make[1]: Leaving directory `/usr/local/src/nedit-5.5/Microline/XmL' (cd source; make -f Makefile.common clean) make[1]: Entering directory `/usr/local/src/nedit-5.5/source' rm -f nedit.o file.o menu.o window.o selection.o search.o undo.o shift.o help.o preferences.o tags.o userCmds.o shell.o regularExp.o macro.o text.o textSel.o textDisp.o textBuf.o textDrag.o server.o highlight.o highlightData.o interpret.o parse.o smartIndent.o regexConvert.o rbTree.o windowTitle.o calltips.o server_common.o rangeset.o nedit nc nc.o parse.c linkdate.o make[1]: Leaving directory `/usr/local/src/nedit-5.5/source' (cd util; \ make -f Makefile.distclean verify_config \ make -f Makefile.distclean libNUtil.a) make[1]: Entering directory `/usr/local/src/nedit-5.5/util' make[1]: Makefile.distclean: No such file or directory make[1]: *** No rule to make target `Makefile.distclean'. Stop. make[1]: Leaving directory `/usr/local/src/nedit-5.5/util' make: *** [distclean] Error 2 ** Configure command -- [NOTE] No standard configre script found. ** Build command -- [NOTE] Building with external: CYGWIN-PATCHES/build.sh nedit 5.5 2 (cd util; \ make -f Makefile.linux verify_config \ make -f Makefile.linux libNUtil.a) make[1]: Entering directory `/usr/local/src/nedit-5.5/.build/build/util' cc -O2 -DBUILD_UNTESTED_NEDIT -DUSE_DIRENT -o check_lin_tif check_lin_tif.c check_lin_tif.c:57:19: Xm/Xm.h: No such file or directory check_lin_tif.c: In function `main': check_lin_tif.c:203: error: `XmVERSION_STRING' undeclared (first use in this function) check_lin_tif.c:203: error: (Each undeclared identifier is reported only once check_lin_tif.c:203: error: for each function it appears in.) check_lin_tif.c:252: error: `XmVERSION' undeclared (first use in this function) check_lin_tif.c:252: error: `XmREVISION' undeclared (first use in this function) check_lin_tif.c:253: error: `XmUPDATE_LEVEL' undeclared (first use in this function) make[1]: *** [check_tif_rule] Error 1 make[1]: Leaving directory `/usr/local/src/nedit-5.5/.build/build/util' make: *** [linux] Error 2 There was an error. Run [finish] (y/N) y ** [finish] Removing /usr/local/src/nedit-5.5 -- [NOTE] GBS compat mode:
Re: [ITA] epstool 3.08-2 -- edit preview images and fix bounding boxes in EPS files
Jari Aalto writes: Adoption of package by James R. Phillips Please remove /usr/share/doc/epstool-3.08/epstool.txt as it's one liner content is wrong anyway. Otherwise builds fine from source. Maybe change: sdesc: edit preview images and fix bounding boxes in EPS files to sdesc: Edit preview images and fix bounding boxes in EPS files Ciao Volker
Re: tcp_wrappers-7.6-2 in test category should be moved to current
On Dec 14 05:41, Bryan D. Thomas wrote: I regret that I won't be able to continue as the maintainer of the tcp-wrappers package for Cygwin. Too bad. I added the tcp_wrappers package to the list of orphaned packages again. Sigh. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] nedit 5.5-2 -- A powerful, customizable, Motif based text editor
* Fri 2007-12-14 Dr Dr [EMAIL PROTECTED] * Message-Id: [EMAIL PROTECTED] check_lin_tif.c:57:19: Xm/Xm.h: No such file or directory This was probably due to INCLUDE_PATH, that I didn't notice in my end. Thanks, now fixed. Jari a) manual wget\ http://cygwin.cante.net/nedit/setup.hint \ http://cygwin.cante.net/nedit/nedit-5.5-2-src.tar.bz2 \ http://cygwin.cante.net/nedit/nedit-5.5-2.tar.bz2 \ b) automatic gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8 mkdir nedit ; cd nedit rm -f get.sh get.sh.sig wgethttp://cygwin.cante.net/nedit/get.sh \ http://cygwin.cante.net/nedit/get.sh.sig gpg --verify get.sh.sig get.sh sh get.sh -- Welcome to FOSS revolution: we fix and modify until it shines
Re: [ITA] epstool 3.08-2 -- edit preview images and fix bounding boxes in EPS files
* Fri 2007-12-14 Dr Dr [EMAIL PROTECTED] * Message-Id: [EMAIL PROTECTED] Please remove /usr/share/doc/epstool-3.08/epstool.txt as it's one liner [capitalize] sdesc: edit preview images and fix bounding boxes in EPS files Thanks, fixed. Jari a) manual wget\ http://cygwin.cante.net/epstool/epstool-3.08-2-src.tar.bz2 \ http://cygwin.cante.net/epstool/epstool-3.08-2.tar.bz2 \ http://cygwin.cante.net/epstool/setup.hint b) automatic gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8 mkdir epstool ; cd epstool rm -f get.sh get.sh.sig wgethttp://cygwin.cante.net/epstool/get.sh \ http://cygwin.cante.net/epstool/get.sh.sig gpg --verify get.sh.sig get.sh sh get.sh -- Welcome to FOSS revolution: we fix and modify until it shines
Re: [ITA] xmon 1.5.6-2 -- An interactive X protocol monitor
* Fri 2007-12-14 Dr Dr [EMAIL PROTECTED] * Message-Id: [EMAIL PROTECTED] The original package contained an additional symbolic link from xmonui.1x to xmon.1x Thanks, fixed. Jari a) manual wget\ http://cygwin.cante.net/xmon/xmon-1.5.6-2-src.tar.bz2 \ http://cygwin.cante.net/xmon/xmon-1.5.6-2.tar.bz2 \ http://cygwin.cante.net/xmon/setup.hint b) automatic gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8 mkdir xmon ; cd xmon rm -f get.sh get.sh.sig wgethttp://cygwin.cante.net/xmon/get.sh \ http://cygwin.cante.net/xmon/get.sh.sig gpg --verify get.sh.sig get.sh sh get.sh -- Welcome to FOSS revolution: we fix and modify until it shines
Re: [ITA] ttcp 20071212 -- Network benchmarking tool
* Fri 2007-12-14 Dr Dr [EMAIL PROTECTED] * Message-Id: [EMAIL PROTECTED] Jari Aalto writes: * Wed 2007-12-12 Dr Dr [EMAIL PROTECTED] * Message-Id: [EMAIL PROTECTED] /usr/include/sys/time.h:73: warning: previous declaration of 'gettimeofday' was here 10:58 PM [819] cygcheck -cd | grep cygwin cygwin 1.5.25-4 I Needed to upgrade to newest Cygwin dll. Fixed now. Builds fine from source and setup.hint looks good. But there used to be a package README file in the original version. Do you mean this: ttcp-19980512-1.README It was the 1998 ttcp.READE. I rewote it while packaging. It's now: [binary package] usr/share/doc/Cygwin/ttcp-20071212.README [source package] CYGWIN-PATCHES/ttcp.README Jari -- Welcome to FOSS revolution: we fix and modify until it shines
Re: [ITP] VOTE bmp2png 1.62 -- Convert BMP images to PNG and vice versa
* Fri 2007-12-14 Dave Korn dave.korn-RQamRl9Jd2/[EMAIL PROTECTED] * Message-Id: [EMAIL PROTECTED] On 14 December 2007 08:24, Jari Aalto wrote: According to Jari Aalto on 12/2/2007 7:27 AM: Needs votes. Reini +1 Volker +1 Eric +1 Dave +1 One more. A image conversion program -- An image conversion program. requires: cygwin libpng12 zlib Not supposed to mention indirect dependencies in setup.hint requires lines. Thanks, both fixed. Jari wget\ http://cygwin.cante.net/bmp2png/bmp2png-1.62-1-src.tar.bz2 \ http://cygwin.cante.net/bmp2png/bmp2png-1.62-1.tar.bz2 \ http://cygwin.cante.net/bmp2png/setup.hint -- Welcome to FOSS revolution: we fix and modify until it shines
Re: [ITP] VOTE bmp2png 1.62 -- Convert BMP images to PNG and vice versa
Jari Aalto wrote: * Fri 2007-12-14 Dave Korn dave.korn-RQamRl9Jd2/[EMAIL PROTECTED] * Message-Id: 004201c83e3c$2033ba80$2e08a8c0-D/[EMAIL PROTECTED] On 14 December 2007 08:24, Jari Aalto wrote: According to Jari Aalto on 12/2/2007 7:27 AM: Needs votes. Reini +1 Volker +1 Eric +1 Dave +1 One more. +1 -- Chuck
Re: xmessage color
On Fri, 14 Dec 2007, Tom Bruning wrote: I am a newbie using cygwin/x. I have tried to find an answer in all documentation I can find but to no avail I am trying to send a message through xmessage that includes color escape sequences. I can display color in a normal xterm window but in xmessage I only display the escape sequences. I have tried to find out how to use xmessage-color but have been unable to use it. xmessage doesn't interpret escape sequences. You may be able to get what you want with a shell script, e.g., xterm -hold -e echo $@ -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- 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/
Re: Fwd: ForwardX11 not working
On Dec 13, 2007 6:25 PM, Larry Hall (Cygwin X) [EMAIL PROTECTED] wrote: Mirko Vukovic wrote: Hi, I have cygwin installed as a server on my desktop. I can log into it from my linux box using ssh, but I cannot open displays on the linux box. By that I mean that if I login in using ssh, and invoke a command that should open a window (like gnuplot), it opens the plot on the server, and not on the client. Here is my setup (the cygwin distribution is a few days old). On the desktop (server), - I have ran ssh-host-config and set CYGWIN=ntsec server. I said yes to privilege separation, and I have an sshd user in /etc/passwd - I have set DISPLAY=localhost:0.0 in .bash_profile ^^ Don't do this. On my linux box (client), I have an ~/.ssh/config file with the lines in the section refering to the server: ForwardX11 yes and ForwardX11Trusted yes I can login to the server from both the linux box and my laptop (where I also have cygwin), and can run unison (which requires ssh). I read the various doc's and searched mails (does not mean I understood everything), which resulted in the above setup. I am including the output of cygcheck. Any suggestions as to what I may have missed, or what server/client setting I can look at? See above. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 Thanks Larry, but ... I am confused with the discussion in the this post: http://sourceware.org/ml/cygwin-xfree/2002-10/msg00071.html. Those guys specifically tell to have DISPLAY defined before an ssh login. When I did the ssh login and tried gnuplot on the remote machine I received an error: unable to open display ''. Can you please clarify: I have a remote machine and a local machine. Which of them, if any should have DISPLAY set or not set before I attempt to login and open an X-window? Naively, I am assuming that each machine should have a DISPLAY set, for the simple reason that when I am physically at that machine, I need display in order to open x-windows. Another data point: I have a linux box. If I login from cygwin via ssh to the linux box (having DISPLAY already set on the cygwin side), I can run applications on the linux box that do open new x-windows on my cygwin machine. Thank you, Mirko -- 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/
xmessage color
I am a newbie using cygwin/x. I have tried to find an answer in all documentation I can find but to no avail I am trying to send a message through xmessage that includes color escape sequences. I can display color in a normal xterm window but in xmessage I only display the escape sequences. I have tried to find out how to use xmessage-color but have been unable to use it. Any help would be greatly appreciated, thanks tgb -- 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/
Re: Fwd: ForwardX11 not working
Mirko Vukovic schrieb: - I have ran ssh-host-config and set CYGWIN=ntsec server. I said yes to privilege separation, and I have an sshd user in /etc/passwd - I have set DISPLAY=localhost:0.0 in .bash_profile ^^ Don't do this. Really don't. Just give it a try. I am confused with the discussion in the this post: http://sourceware.org/ml/cygwin-xfree/2002-10/msg00071.html. Those guys specifically tell to have DISPLAY defined before an ssh login. If you read that post more carefully you will see your mistake. You need to set DISPLAY on the computer you're X11 Server is runninng before you use ssh to login to your Windows Computer. That is to let ssh know which connection to forward. 'Inside' the ssh connection the forwarding mechanism will set DISPLAY. If you change it, it will be wrong. Naively, I am assuming that each machine should have a DISPLAY set, for the simple reason that when I am physically at that machine, I need display in order to open x-windows. That will not work. If you change the role of the computers you can not fix DISPLAY in .bash_profile. That is not a good idea anyway, because you could have more than one X Server running. -- 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/
Re: Fwd: ForwardX11 not working
Maybe it will help, if you know what the DISPLAY variable is used for. It is like this: when you start a program (like gnuplot), it will okk at the DISPLAY variable and use its value as the address of the X11 display to use. So in your case, it will read localhost:0.0 and it will connect and display on ... the localhost (localhost means the same PC). Never set DISPLAY manually. That is the golden rule ;-) OK, _almost_ never. Regards, David -- 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 dtable.cc spawn.cc
CVSROOT:/cvs/src Module name:src Branch: cr-0x5f1 Changes by: [EMAIL PROTECTED] 2007-12-14 11:32:50 Modified files: winsup/cygwin : ChangeLog dtable.cc spawn.cc Log message: * dtable.cc (dtable::set_file_pointers_for_exec): Reenable. Fix comment. * spawn.cc (spawn_guts): Call cygheap-fdtab.set_file_pointers_for_exec only for non-Cygwin processes. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.3582.2.44r2=1.3582.2.45 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.169.4.3r2=1.169.4.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/spawn.cc.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.233.2.4r2=1.233.2.5
src/winsup/cygwin ChangeLog include/cygwin/soc ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-12-14 12:12:32 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include/cygwin: socket.h Removed files: winsup/cygwin/include/cygwin: uio.h Log message: * include/cygwin/socket.h: Include sys/uio.h instead of cygwin/uio.h. * include/cygwin/uio.h: Remove. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3976r2=1.3977 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/socket.h.diff?cvsroot=srcr1=1.23r2=1.24 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/uio.h.diff?cvsroot=srcr1=1.1.1.1r2=NONE
src/winsup/cygwin ChangeLog include/cygwin/soc ...
CVSROOT:/cvs/src Module name:src Branch: cr-0x5f1 Changes by: [EMAIL PROTECTED] 2007-12-14 12:12:52 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include/cygwin: socket.h Removed files: winsup/cygwin/include/cygwin: uio.h Log message: * include/cygwin/socket.h: Include sys/uio.h instead of cygwin/uio.h. * include/cygwin/uio.h: Remove. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.3582.2.45r2=1.3582.2.46 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/socket.h.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.19r2=1.19.4.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/uio.h.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.1.1.1r2=NONE
src/winsup/cygwin ChangeLog dtable.cc spawn.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-12-14 11:32:40 Modified files: winsup/cygwin : ChangeLog dtable.cc spawn.cc Log message: * dtable.cc (dtable::set_file_pointers_for_exec): Reenable. Fix comment. * spawn.cc (spawn_guts): Call cygheap-fdtab.set_file_pointers_for_exec only for non-Cygwin processes. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3975r2=1.3976 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srcr1=1.178r2=1.179 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/spawn.cc.diff?cvsroot=srcr1=1.249r2=1.250
RE: Need help with Perl/Tk
On 14 December 2007 03:12, Andrew DeFaria wrote: Dave Korn wrote: DynaLoader is just spitting out the bog-standard canned error message that perror() returns for ENOENT. Oh I totally understand that. I guess what I'm saying is - could it be a wee bit more, ahem, helpful! There's certainly no reason why it couldn't look out for that particular errno and issue a more detailed explanation, instead of relying solely on the default. But it doesn't, and that's essentially the point. Well, PTC I'm sure. But there's a limited use to tweaking the error message text if it still can't tell you /which/ file was missing, and that would mean adding a whole bunch of PE-reading functionality to do it right. 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: 1.5.25-6: Win32 programs don't get correct redirection
On Dec 13 19:36, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jack Brennen on 12/13/2007 6:34 PM: sh-3.2$ echo ABCDEFGHIJKLMNOPQRST foo.txt sh-3.2$ cmd /c echo UVWXYZ foo.txt sh-3.2$ cat foo.txt UVWXYZ IJKLMNOPQRST This issue was discussed on the lists in May: http://thread.gmane.org/gmane.os.cygwin/89327/focus=89411 Cygwin 1.5.24 was incorrectly positioning fd's opened in append mode to the last byte just before exec'ing a child process, rather than leaving the position untouched (note that POSIX requires open(O_RDWR|O_APPEND)/lseek to always be at position 0, but fopen(a+)/ftell can be either 0 [as on Linux] or the end of the file [as on BSD] - cygwin currently uses the Linux approach). But it looks like this means that Windows programs are too stupid to realize that they are being handed a file opened in append mode [...] Even though it sounds nice to blame Windows, the blame is on Cygwin entirely here. The problem with O_APPEND mode is that you can switch a file descriptor to and from append mode at will using fcntl. This functionality doesn't exist in the Win32 API. You either open the file handle in append mode or not, but you can't switch it back and forth. For that reason, the file is always opened in generic write mode in Cygwin. Append mode is emulated in the write() call by seeking to the end of the file before writing (in 1.5.x) or by using a feature of the native NT ZwWriteFile call (in 1.7.x). At this point we have three choices: 1. We revert to the old behaviour and accept a (long-standing) POSIX misbehaviour in terms of the file position in Cygwin child processes. 2. We keep the current behaviour and accept a (new) Win32 misbehaviour in terms of the file position in native Win32 child processes. 3. We (probably I) rework the append mode handling using a native NT feature to re-open a new handle from an existing handle while changing the append mode and keeping everything else as it is, thus risking that I break something else. Solution 3 sounds like something which should only go into 1.7.x. While I usually tend to prefer correct POSIX behaviour over correct native behaviour, it looks like a rather surprising change which might break a lot of existing installations. So it appears as if 1 would be the way to go for now. Oh well... 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: VM and non-blocking writes
On Dec 13 11:19, Wayne Christopher wrote: Okay, here's my test program. Compile and run with no arguments, then connect to it from another machine - on a linux box I just did: python import socket s = socket.socket() s.connect((name-of-windows-box, 12345)) At this point, nbcheck printed: listening to port 12345 on host xp1 (10.1.2.40) got connection from 10.1.2.14 trying to write 1 1 bytes written When I hit return to exit from nbcheck, it does not actually exit until the remote socket is closed. This is due to trying to work around a problem in WinSock. If you want to make sure that your application has shutdown gracefully, call shutdown and close. Otherwise Cygwin has to linger. Not doing so resulted in data loss in some scenarios. The VM usage is 100M, which is all the data array that I allocated, so it doesn't look like the write() call allocated anything in my process space. This behavior makes some sense to me, but it's not how I expect it to work (based on the write(2) man page and how it works on linux). It's more like asynchronous write than non-blocking write. Using O_NONBLOCK instead of O_NDELAY doesn't change the behavior. I can reproduce this behaviour. Stepping through the code shows that the socket has been successfully switched to non-blocking (the WinSock ioctlsocket function returns with success). But the WinSock function WSASendTo hangs for a while and returns with SOCKET_SUCCESS and the number of bytes written is 1. Since the peer doesn't read these bytes, it appears that WSASendTo creates a temporary buffer in kernel space and copies the full user buffer into this temporary buffer. When I raised the memory buffer to 512K, the WSASendTo function failed with WSAENOBUFS, No buffer space available. This is really surprising. The socket write buffer size on Windows is usually 8K, afaik, if you don't change it with setsockopt(SO_SNDBUF). Why it tries to buffer more than this 8K beats me. I searched the net for this problem but I didn't find any other report which would describe such a weird behaviour. However, I have to make some more tests, especially in a pure Win32 application to be sure that it's not a Cygwin problem only. For the time being, I can only suggest to use smaller user buffer sizes in calls to send()/write(). Thanks for the testcase, 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: Stop turning CPAN modules into Cygwin packages
Brian Mathis wrote: Because when you package something using a distro's packaging system, you can start to have other programs that depend on it install them automatically using the package system. Also, installing from CPAN, while very easy to do, does not keep track or even know about a distro's package management system. So if you wanted to remove it later, it is not easy to do, and you could easily run into problems where you have installed one version from CPAN, then another package requires that module, but because you installed via CPAN it doesn't know that, and will then install an older version, overwriting your CPAN-installed version. Just two more cents: No one mentioned that CPAN is a source distribution and cygwin is a binary distribution. For those modules that require compilation, pre-packaging means the module can be easily installed on a system that doesn't have a compiler installed. -- 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: VM and non-blocking writes
On Dec 14 14:41, Corinna Vinschen wrote: On the other hand, as soon as I call send (or WSASendTo) multiple times with smaller sizes (I tried with 10k), select starts to block at one point. But even then strange things happen. After some time (after 5 seconds, then after 14 seconds, then about every 60 seconds) select() just signals the socket ready for write and the next send adds another 10K to the internal buffer. A tcpdump on the interface shows that no package goes over the line... which would be a surprise anyway, given that the peer does not even once call read(). Hmm, a few minutes ago select() mysteriously blocked fully after send has written 19 blocks of 10K each 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: VM and non-blocking writes
On Dec 14 12:15, Corinna Vinschen wrote: On Dec 13 11:19, Wayne Christopher wrote: Okay, here's my test program. [...] I can reproduce this behaviour. Stepping through the code shows that the socket has been successfully switched to non-blocking (the WinSock ioctlsocket function returns with success). But the WinSock function WSASendTo hangs for a while and returns with SOCKET_SUCCESS and the number of bytes written is 1. Since the peer doesn't read these bytes, it appears that WSASendTo creates a temporary buffer in kernel space and copies the full user buffer into this temporary buffer. When I raised the memory buffer to 512K, the WSASendTo function failed with WSAENOBUFS, No buffer space available. This is really surprising. The socket write buffer size on Windows is usually 8K, afaik, if you don't change it with setsockopt(SO_SNDBUF). Why it tries to buffer more than this 8K beats me. I searched the net for this problem but I didn't find any other report which would describe such a weird behaviour. However, I have to make some more tests, especially in a pure Win32 application to be sure that it's not a Cygwin problem only. I can reproduce this behaviour with a native Windows application. It does not depend on using WSASendTo vs. using send, and in case of using WSASendTo it happens independently of using one big WSABUF element or multiple smaller elements. I can reproduce the behaviour on Windows 2000 SP4, XP SP2 and Vista SP1 RC1, so it's not even OS dependent. On the other hand, as soon as I call send (or WSASendTo) multiple times with smaller sizes (I tried with 10k), select starts to block at one point. But even then strange things happen. After some time (after 5 seconds, then after 14 seconds, then about every 60 seconds) select() just signals the socket ready for write and the next send adds another 10K to the internal buffer. A tcpdump on the interface shows that no package goes over the line... which would be a surprise anyway, given that the peer does not even once call read(). Given that, I don't see what we can do about this misbehaviour. I guess I'll report this as a bug and see what the reaction will be. Especially if there's a useful workaround. 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: VM and non-blocking writes
On Dec 14, 2007 8:52 AM, Corinna Vinschen wrote: On Dec 14 14:41, Corinna Vinschen wrote: On the other hand, as soon as I call send (or WSASendTo) multiple times with smaller sizes (I tried with 10k), select starts to block at one point. But even then strange things happen. After some time (after 5 seconds, then after 14 seconds, then about every 60 seconds) select() just signals the socket ready for write and the next send adds another 10K to the internal buffer. A tcpdump on the interface shows that no package goes over the line... which would be a surprise anyway, given that the peer does not even once call read(). Hmm, a few minutes ago select() mysteriously blocked fully after send has written 19 blocks of 10K each Good luck with figuring this stuff out. The way winsock deals with all of this stuff is rather mysterious and quite hackish, basically because it's all implemented in an emulation layer afd.sys and msafd.dll which tries to give bsd socket syntax (or something sorta close anyway) on top of the native overlapped io. The afd layer does some mighty weird things. See, for example, my reverse engineering of one aspect of it's send buffer management here: http://www.cygwin.com/ml/cygwin-patches/2006-q2/msg00031.html There's a whole bunch of tuning parameters that deal with when afd should make a copy of an application-supplied buffer (incurring the copy costs) or just lock the application buffer in ram (incurring VM manipulation costs) and so on. Look at registry configuration parameters: DefaultReceiveWindow, DefaultSendWindow, FastCopyReceiveThreshold, FastSendDatagramThreshold, LargeBufferSize, LargeBufferListDepth, MaxFastTransmit, MaxFastCopyTransmit, MediumBufferSize, MediumBufferListDepth, OverheadChargeGranularity, PriorityBoost, SmallBufferListDepth, SmallBufferSize, TransmitIoLength, FFPControlFlags, FFPFastForwardingCacheSize, GlobalMaxTcpWindowSize and probably others. You can probably do something about this particular issue by tweaking those parameters, or making sure you make the sends fall on the right side of some boundary defined by those parameters. But in general I'm not confident. Lev Lev -- 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: tcp_wrappers-7.6-2 in test category should be moved to current
I regret that I won't be able to continue as the maintainer of the tcp-wrappers package for Cygwin. - Original Message From: Corinna Vinschen [EMAIL PROTECTED] To: cygwin@cygwin.com Cc: [EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 6:14:15 AM Subject: Re: tcp_wrappers-7.6-2 in test category should be moved to current On Dec 12 11:16, Dr. Volker Zell wrote: Hi I think tcp_wrappers-7.6-2 can be moved out of test category. According the README: Done so. I just removed the curr: and test: markers from its setup.hint file. Port Notes: 7.6-2: Simply moved documents to /usr/share per FHS. Although the man pages under /usr/man/ are still not FHS compliant. This should really be fixed, Bryan. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- 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: missing 'which' documentation
As seen from lists.cygwin, on Thu, 13 Dec 2007 15:51:46 -0800, Brian Dessent wrote: glib != glibc. Yeah, I realized my error (faulty memory) just an hour or two ago when I ran setup again and read the short package descriptions: glib is part of GNOME, and Cygwin Ports doesn't have a port of glibc. :( And I don't see why this is specific to Cygwin Ports, because the main Cygwin distro has glib and glib2 as well. It's not specific to CP-- they host the standard Cygwin distro as well, which is convenient when a CP package has dependencies. But again these are *not* in any way related to glibc. Yep, this error brought to you by an arguably POSIX-noncompliant environment running on 52-year-old wetware, which is consequently subject to bit rot from time to time... -- Sorry, my life is still in beta, and nowhere near stable enough for a release. -- 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: FW: Combining winpcap packet wait with poll/select in cygwin
On Thu, 13 Dec 2007, S A wrote: Summary: Has anyone tried to have events (POLL_IN/POLL_OUT) on regular fd descriptors combined with winpcap packet receive handles incorporated into the same sleep event (i.e. poll/select)? No, I haven't tried because it looked too fragile if it even works, and Cygwin's poll/select (or the preamble to read/recv; I'm not sure yet) was causing significant packet reception jitter in my real time application. I know very little of windows but I understand both winpcap cygwin poll (winsup/cygwin/select.cc right?) use a call WaitForMultipleObjects () to sleep and wait for new receive events. I've seen some of the code in select.cc but is there an easy way to translate the fd's into the HANDLE w4 array so I can somehow combine it with the winpcap HANDLE)? You could try get_osfhandle, but I'd suggest going the other way around by using Cygwin's cygwin_attach_handle_to_fd. I don't know if it will work for you, but this might get you an fd that you can use in poll/select for the winpcap handle. My only other options (none of which I like) are: 1. Use threads. I went this route and it worked out well for me, but my application was already threaded, and it didn't have this kind of interaction. 2. Use winpcap to also receive IP packets and thus handle the telnet protocol in my program. However this is unnnecessarily complex. Why did you choose this strange localhost telnet IPC to begin with? Couldn't it just be a library? I guess it might be because of privilege issues? Any recommendations on what to do or more code to look at are greatly welcomed. Thanks! I would appreciate you letting us know how it turns out. -- Brian Ford Lead Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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: building DLLs?
On Dec 14 14:19, [EMAIL PROTECTED] wrote: Hi, When I download winsup from CVS it only builds the executables and 3 dlls. I'd need to build cygintl-8.dll and cygiconv-2.dll. How can I build them? Should I get the intl package from CVS (I tried, but it said that it doesn't exist, also when web-browsing the CVS folder, it is there) The intl subdir in CVS has nothing to do with the libintl provided as a Cygwin package. To get the libintl sources, download the gettext source package by using setup.exe. 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: building DLLs?
Thanks, that works! Oszkar Corinna Vinschen [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/14/2007 03:44 PM Please respond to cygwin@cygwin.com To cygwin@cygwin.com cc Subject Re: building DLLs? On Dec 14 14:19, [EMAIL PROTECTED] wrote: Hi, When I download winsup from CVS it only builds the executables and 3 dlls. I'd need to build cygintl-8.dll and cygiconv-2.dll. How can I build them? Should I get the intl package from CVS (I tried, but it said that it doesn't exist, also when web-browsing the CVS folder, it is there) The intl subdir in CVS has nothing to do with the libintl provided as a Cygwin package. To get the libintl sources, download the gettext source package by using setup.exe. 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/ -- 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: 1.5.25-6: Win32 programs don't get correct redirection
On Dec 14 11:50, Corinna Vinschen wrote: On Dec 13 19:36, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jack Brennen on 12/13/2007 6:34 PM: sh-3.2$ echo ABCDEFGHIJKLMNOPQRST foo.txt sh-3.2$ cmd /c echo UVWXYZ foo.txt sh-3.2$ cat foo.txt UVWXYZ IJKLMNOPQRST This issue was discussed on the lists in May: http://thread.gmane.org/gmane.os.cygwin/89327/focus=89411 Cygwin 1.5.24 was incorrectly positioning fd's opened in append mode to the last byte just before exec'ing a child process, rather than leaving the position untouched (note that POSIX requires open(O_RDWR|O_APPEND)/lseek to always be at position 0, but fopen(a+)/ftell can be either 0 [as on Linux] or the end of the file [as on BSD] - cygwin currently uses the Linux approach). But it looks like this means that Windows programs are too stupid to realize that they are being handed a file opened in append mode [...] Even though it sounds nice to blame Windows, the blame is on Cygwin entirely here. The problem with O_APPEND mode is that you can switch a file descriptor to and from append mode at will using fcntl. This functionality doesn't exist in the Win32 API. You either open the file handle in append mode or not, but you can't switch it back and forth. For that reason, the file is always opened in generic write mode in Cygwin. Append mode is emulated in the write() call by seeking to the end of the file before writing (in 1.5.x) or by using a feature of the native NT ZwWriteFile call (in 1.7.x). At this point we have three choices: [...] Scratch that, I implemented the forth choice. Eric's point Maybe it is worth teaching cygwin's exec code that fd's in append mode must be repositioned to the end if the child about to be spawned is a non-cygwin program? was right. I implemented this now, for 1.5.25 as well as for the main trunk. I will look into implementing this in a more transparent way for 1.7.x, though. 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/
building DLLs?
Hi, When I download winsup from CVS it only builds the executables and 3 dlls. I'd need to build cygintl-8.dll and cygiconv-2.dll. How can I build them? Should I get the intl package from CVS (I tried, but it said that it doesn't exist, also when web-browsing the CVS folder, it is there) Thanks, Oszkar -- 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: xemacs does not work
NE writes: Dear All, I am trying to use xemacs. After installation of cygwin, I used once but later it doesn't work. it gives this error: temacs can only be run in -batch mode what do you suggest? cygcheck -cv xemacs thanks regards Ciao Volker -- 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 Installation Problems on Windows Vista (killing sh.exe helps)
lent wrote: On the semi-broken installation: Actually, the problem was that the whatever vital job that /etc/postinstall/gnuplot.sh was doing never completed. 30 minutes of wait time by multiple Vista users on multiple brands of spanking new laptops indicates some sort of interaction bug of these shell scripts (or the programs they run) with the wonders of Vista. This hang at 99% forever symptom persists even with setting the Properties of setup.exe to run in Windows XP(SP2) compatibility mode. It's a very disappointing installation experience for novice programmers. Our XP and Windows 2000 users do not have these problems as setup.exe completes just fine. Thanks again for your attention to this annoying bug. Chris Lent Actually I'm having this same problem right now with good ol' Windows XP. If it doesn't hang in /etc/postinstall/update-info-dir.sh, it hangs somewhere else. I've walked away and let it run for hours. There's something wrong with the scripts. And this is three months later. -Q -- View this message in context: http://www.nabble.com/Cygwin-Installation-Problems-on-Windows-Vista-tp9889324p14339689.html Sent from the Cygwin list mailing list archive at Nabble.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/
Shop Artisanal... Reloaded
Hi, Please visit the new version of www.shopartisanal.com ...Reloaded in a brand new user-friendly form and with unique, and exclusive items. Check it out yourself... B.Regards Anass Mrabet www.shopartisanal.com [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: VM and non-blocking writes
On Dec 14 09:34, Lev Bishop wrote: http://www.cygwin.com/ml/cygwin-patches/2006-q2/msg00031.html Gosh, I didn't even remember this discussion anymore, sorry. There's a whole bunch of tuning parameters that deal with when afd should make a copy of an application-supplied buffer [...] You can probably do something about this particular issue by tweaking those parameters, or making sure you make the sends fall on the right side of some boundary defined by those parameters. But in general I'm not confident. Same here. Tweaking registry parameters is nothing the Cygwin DLL should resort to. 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: Need help with Perl/Tk
Michael Kairys [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] It's all pretty disappointing, compared to ActiveState's implementation, which looks much better and requires no setup, no extraneous directories on my path, and no otherwise uneeded daemons. A little research reveals this issue has been around for a while and is apparently well-known by everyone but me :) From: Yaakov S (Cygwin Ports) yselkowitz at users dot sourceforge dot net To: cygwin at cygwin dot com Date: Wed, 14 Dec 2005 17:54:19 -0600 Subject: Re: PerlTK under Windows References: [EMAIL PROTECTED] Andrew DeFaria wrote: However I'd like PerlTk to fall back to using Windows widgets much like rxvt will do a Windows window if there is no X server to connect to. Just how rxvt manages to use both X11 and Win32GUI is unique, as has been discussed before at length. Don't expect anything else X11 based to do that on Cygwin. perl-Tk is X11-based because it *does not compile* on Cygwin for Win32. PTC. -- 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/
Timezone manipulation within Perl script
Hi all,
I want to ask you how convert time between different timezones in perl script
running under cygwin. I have an application which store datetime information in
Zulu/GMT. I need to provide date in user timezone. How to do the correct
conversion? I want to be able to offer Timezone info like 'Europe/Prague'.
Following code snippet will provide correct output when running under Active
state Perl (time will differ 1 or 2 hours depending on input date), but when
running under cygwin perl no conversion will be done. Can anyone help me?
$ENV{TZ}= 'Zulu';
POSIX::tzset();
$time = timegm($second, $minute, $hour, $day, $month, $year);
$ENV{TZ}= 'Europe/Prague';
POSIX::tzset();
($second, $minute, $hour, $day, $month, $year) =
POSIX::localtime($time);
Attached program will produce under ActiveState PERL
Winter (delta should be +1 h)
ZULU : 2007-12-13 11:47:02 Zulu
LOCAL: 2007-12-13 12:47:02 Europe/Prague
Summer (delta should be +2 h)
ZULU : 2007-06-13 11:47:02 Zulu
LOCAL: 2007-06-13 13:47:02 Europe/Prague
and under CygWin PERL output will be
Winter (delta should be +1 h)
ZULU : 2007-12-13 11:47:02 Zulu
LOCAL: 2007-12-13 11:47:02 Europe/Prague
Summer (delta should be +2 h)
ZULU : 2007-06-13 11:47:02 Zulu
LOCAL: 2007-06-13 11:47:02 Europe/Prague
Best Regards,
Roman
test-1.pl
Description: Perl program
--
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] cygwin-1.5.25-7
I've uploaded another test version of the Cygwin DLL and its utilities, version 1.5.25-7. It contains all fixes related to what cropped up since the release of 1.5.25-5 on Sunday. Changes since test version 1.5.25-6: - Fix return value of poll(). - Fix file position in append mode for non-Cygwin processes. - Fix missing definition of struct iovec when including sys/socket.h. Changes since version 1.5.25-5: - tzset is now thread safe. - Fix a problem with spurious memory allocation failure. - Fix permission settings for directories on non-NTFS file systems. - Fix NaN and +-inf handling in various math functions. - Fix a problem with potentially wrong results in tgammaf(). Please test. 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. Save it and run setup, answer the questions, then look for 'cygwin' in the 'Base' category (it should already be selected). You will need to use the 'Exp' radio button to get the test version. If you have questions or comments, please send them to the Cygwin mailing list. See http://cygwin.com/lists.html for details. *** 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://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Corinna Vinschen 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/
mmap failing
I have a 268MB file open for writing. I close it and then immediately try to mmap() it, and a get ENOMEM. However I do have the VM space available and can malloc() the size of the file right after the failure. Also, I have mmap()'ed other similar files in the same program before this, but these had not just been closed. My initial guess was that it was timing related, but if I wait for 5 seconds and try again I still get the failure. I wasn't able to duplicate it in a small example since my app has a bunch of threads and is doing other stuff at the same time. Any suggestions for solutions or workarounds? Maybe strategic use of fsync() ? Thanks, Wayne -- 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: Timezone manipulation within Perl script
2007/12/14, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Hi all,
I want to ask you how convert time between different timezones in perl script
running under cygwin. I have an application which store datetime information
in Zulu/GMT. I need to provide date in user timezone. How to do the correct
conversion? I want to be able to offer Timezone info like 'Europe/Prague'.
Following code snippet will provide correct output when running under Active
state Perl (time will differ 1 or 2 hours depending on input date), but when
running under cygwin perl no conversion will be done. Can anyone help me?
$ENV{TZ}= 'Zulu';
POSIX::tzset();
$time = timegm($second, $minute, $hour, $day, $month, $year);
$ENV{TZ}= 'Europe/Prague';
POSIX::tzset();
($second, $minute, $hour, $day, $month, $year) =
POSIX::localtime($time);
Attached program will produce under ActiveState PERL
Winter (delta should be +1 h)
ZULU : 2007-12-13 11:47:02 Zulu
LOCAL: 2007-12-13 12:47:02 Europe/Prague
Summer (delta should be +2 h)
ZULU : 2007-06-13 11:47:02 Zulu
LOCAL: 2007-06-13 13:47:02 Europe/Prague
and under CygWin PERL output will be
Winter (delta should be +1 h)
ZULU : 2007-12-13 11:47:02 Zulu
LOCAL: 2007-12-13 11:47:02 Europe/Prague
Summer (delta should be +2 h)
ZULU : 2007-06-13 11:47:02 Zulu
LOCAL: 2007-06-13 11:47:02 Europe/Prague
Interesting. For me the standard cygwin perl works okay.
$ perl test-1.pl
Winter (delta should be +1 h)
ZULU : 2007-12-13 11:47:02 Zulu
LOCAL: 2007-12-13 12:47:02 Europe/Prague
Summer (delta should be +2 h)
ZULU : 2007-06-13 11:47:02 Zulu
LOCAL: 2007-06-13 13:47:02 Europe/Prague
$ printenv TZ
Windows XP, currently in the GMT-5 timezone
--
Reini Urban
--
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: Timezone manipulation within Perl script
[EMAIL PROTECTED] wrote: I want to ask you how convert time between different timezones in perl script running under cygwin. I have an application which store datetime information in Zulu/GMT. I need to provide date in user timezone. How to do the correct conversion? I want to be able to offer Timezone info like 'Europe/Prague'. Following code snippet will provide correct output when running under Active state Perl (time will differ 1 or 2 hours depending on input date), but when running under cygwin perl no conversion will be done. Can anyone help me? The testcase works fine for me as well. You didn't include cygcheck output, so do you have the tzcode package installed? If not, try installing it. It should be part of Base now so you should get it automatically the next time you run setup. 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/
Ping failure under Vista 64 SP1 rc1
Hi, I'm running Vista 64 with Cygwin and, now that they finally have 64-bit support for it, MinGW msys. I just installed the new Vista SP1 rc1, and now Cygwin ping does not work: [~]: ping 10.0.77.1 ping: socket: Operation not permitted [~]: ping localhost ping: socket: Operation not permitted [~]: ping yahoo.com ping: socket: Operation not permitted It was working fine previously, and MinGW ping still works fine, as does Cygwin ftp. I turned off Windows firewall just in case that was having an effect, but that made no difference. I'm using bash 3.2.25 and ping 1.0-1. And ideas? Ian -- 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/
