Re: ITP: algol68g
On May 21 15:34, Yaakov (Cygwin/X) wrote: On 2012-05-16 02:19, Thomas Wolff wrote: wget http://towo.net/algol68g/setup.hint wget http://towo.net/algol68g/algol68g-2.3.7.4-0.tar.bz2 wget http://towo.net/algol68g/algol68g-2.3.7.4-0-src.tar.bz2 Release numbers start with 1, not 0, but otherwise this okay now. Uploaded. Thanks to both of you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] subversion-1.7.5-1 and subversion-1.7.5-2
On 21 May 2012 18:30, David Rothenberger wrote: On 5/20/2012 9:10 PM, Andy Koppe wrote: On 20 May 2012 02:22, David Rothenberger wrote: Please upload subversion-1.7.5-1 as the new current release and -2 as the new test release (built against the test Perl). Please delete 1.7.4-1 and leave 1.6.17-1 as prev. I'm getting error 403 (not authorized) for these. This should be fixed now. Uploaded. Thanks, Andy
Re: glib doesn't build from source
On 2012-05-19 15:48, Ken Brown wrote:
I tried to build glib using glib2.0-2.32.2-1.cygport from the source for
Cygwin's libglib2.0_0-2.32.2-1 package, and the build failed as follows:
So I added the lines
export LIBFFI_LIBS=-lffi
export LIBFFI_CFLAGS=-I${includedir}
to the .cygport file, and the build then succeeded.
Yaakov, why did the build work for you with the existing .cygport?
Good question. :-) It turns out I had a hand-written libffi.pc file on
my system, probably from my short-lived gcc packaging work. I fixed
this in glib2.0-2.32.3-1.cygport.
Yaakov
Re: no display specified
Ben Voigt-2 wrote: Maybe check to see if different extensions are negotiated on the Linux X server vs CygwinX ?[...] Yes, looks like there are. The .log - file is that from the linux machine. I should have uploaded the windows component in an earlier post. Can there be found a reason for the slowdown from this information? -- View this message in context: http://old.nabble.com/cygwin-octave-x11-tp33864360p33887259.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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: [SOLVED] Why does nedit complain about these missing fonts?
On Mon, May 21, 2012, at 17:30, Kiehl, Horst wrote: Ronald Fischer wrote [text rewrapped]: xset fp+ /usr/share/fonts I got the error message xset: bad font path element (#90), possible causes are: Directory does not exist or has wrong permissions Directory missing fonts.dir Incorrect font server address or syntax My guess is that you get this message because the directories in the font path are from the viewpoint of the server. If your Xming installation is on the same computer as your Cygwin installation and the latter is under C:\cygwin, your command xset fp+ /usr/share/fonts would translate to something like xset fp+ c:/cygwin/usr/share/fonts You are right - now it's so obvious I could bang my head against the wall! Additionally, if I remember correctly, each directory containing a fonts.dir file must be specified in the font path explicitly (i.e. the directories in the font path are not searched recursively). Indeed, this is the case! Thank you for pointing it out. Now by doing xset fp+ $(cygpath -w /usr/share/fonts/100dpi) the nedit messages about missing fonts are gone! Thanks for helping! Ronald -- Ronald Fischer austria_ru...@yepmail.net There are 10 types of people in the world: those who understand binary and those who don't. -- 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/
Trying to find a solution for segmentation fault crashes in the most recent x server provided by setup.exe
So, after several hours more of investigation, I discovered that while gdb was installed on my machine, it was not installed on the machine where we were testing. I installed it there, but the crash still occurs. The backtrace produced is quite huge - and less useful because X didn't have any of the debugging symbols in it. here is a bit of what we are seeing. We start up the X server. It is configured to use xauth. We start up a mintty session and an xterm session. We ssh from these windows to our SPARC Solaris 9 work machines. We start up, in each window, an in-house written binary application which makes use of the Tk C libraries. If we run just 1 mintty, or just 1 xterm, that works. If we run one of each (which the developers do due to various features, etc. they wish to leverage), we often - not always - get an error of the following nature. GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special) This GDB was configured as i686-cygwin. Backtrace Thread 25 (Thread 5368.0x1704): #0 0x775e000d in ntdll!LdrFindResource_U () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x7766f896 in ntdll!RtlQueryTimeZoneInformation () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x70d9aec6 in ?? () No symbol table info available. : and so on : Thread 24 (Thread 5368.0x1b24): #0 0x775ef8b1 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x775ef8b1 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x762f0a91 in WaitForSingleObjectEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll No symbol table info available. #3 0x07a4 in ?? () No symbol table info available. : and so on : Thread 23 (Thread 5368.0x1590): #0 0x775efd71 in ntdll!RtlFindSetBits () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x762f31bb in SleepEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll No symbol table info available. #2 0x in ?? () No symbol table info available. Thread 22 (Thread 5368.0x1a20): #0 0x775f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x775f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x762f0bdd in WaitForMultipleObjectsEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll : and so on : Thread 21 (Thread 5368.0x18f4): #0 0x775ef8e5 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x775ef8e5 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x762ed348 in ReadFile () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll No symbol table info available. #3 0x0794 in ?? () : and so on : many more threads and finally : Thread 1 (Thread 5368.0x1bec): #0 0x775f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #1 0x775f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #2 0x762f0bdd in WaitForMultipleObjectsEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll No symbol table info available. #3 0x0003 in ?? () No symbol table info available. : and so on : Backtrace stopped: previous frame inner to this frame (corrupt stack?) Backtrace End [ 3569.256] Segmentation fault at address 0x65682e91 [ 3569.256] Fatal server error: [ 3569.256] Caught signal 11 (Segmentation fault). Server aborting [ 3569.256] [ 3569.256] Server terminated with error (1). Closing log file. Note that in several of the skipped portions above there were lines such as Backtrace stopped: Not enough registers or memory available to unwind further The log file is 45K, so I didn't include it completely until I hear back that someone would find it useful -- Tcl - The glue of a new generation. http://wiki.tcl.tk/ Larry W. Virden http://www.facebook.com/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -- 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/
[ANNOUNCEMENT] Updated: GNOME 3.4.2 libraries
The following GNOME components in the distro have been updated to the latest 3.4.2 stable releases: * glib2.0 * glib2.0-networking * gnome-themes-standard * gsettings-desktop-schemas * gtk3 * gvfs * python-gi * yelp-xsl -- 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/
[ANNOUNCEMENT] Updated: xterm-279-1
The following package has been updated for the Cygwin distribution: *** xterm-279-1 The xterm program is a terminal emulator for the X Window System. It provides DEC VT102 and Tektronix 4014 compatible terminals for programs that can't use the window system directly. This is an update to the latest upstream release. -- 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/
src/winsup/cygwin ChangeLog thread.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-05-22 10:28:06 Modified files: winsup/cygwin : ChangeLog thread.cc Log message: * thread.cc (pthread::cancel): Set thread's cancel_event in PTHREAD_CANCEL_ASYNCHRONOUS case, too. Explain why. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5836r2=1.5837 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srcr1=1.258r2=1.259
src/winsup/cygwin ChangeLog dtable.cc devices. ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-05-22 17:37:41 Modified files: winsup/cygwin : ChangeLog dtable.cc devices.in fhandler_mem.cc devices.cc Log message: * devices.in: Fix native name of /dev/kmem. * devices.cc: Regenerate. * dtable.cc (fh_alloc): Don't forget FH_KMEM. * fhandler_mem.cc (fhandler_dev_mem::open): Set errno to EACCES rather than ENOENT on systems not granting access to physical memory from user space. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5837r2=1.5838 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srcr1=1.260r2=1.261 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/devices.in.diff?cvsroot=srcr1=1.38r2=1.39 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_mem.cc.diff?cvsroot=srcr1=1.59r2=1.60 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/devices.cc.diff?cvsroot=srcr1=1.47r2=1.48
1.7.15-1: mintty bash failing to run .NET executables ?
Not a newbie exactly, but haven't posted a question to this list before. I've been running Cygwin on both Windows 7 Pro 64-bit SP1 for about eight months and a (virtualised) server running Win Server 2008 R2 Standard SP1 for about two months, mainly as a convenience shell as corporate policy prevents me running native Linux machines. I'm using MonoDevelop to compile command-line C# programs into .NET executables (generally 4.0 by default, but have also tested the following with a Hello, World! compiled to 2.0). I believe MonoDevelop on Windows uses the standard Windows SDK and compiler. Today I happened to reboot the server for another reason, and then found that the standard output of the .NET executables was not appearing in the mintty bash terminal (although standard error was, and the programs were executing: visibly doing things in Task Manager, files being created, etc.). During investigation I wanted to get a utility from the Cygwin site, but hit Enter at the wrong time and ended up refreshing the installation to the latest (1.7.15-1). After that, .NET programs failed to launch at all. The mintty bash terminal just sits there, no CPU or anything else being used, the .NET .exe failing to launch according to Task Manager. (Have left it 10 or 15 minutes to make sure.) Ctrl-C / Ctrl-Break, Ctrl-Z fail to have any effect. Clicking the close 'X' on the window housing the mintty terminal just kills it (mintty.exe and bash.exe) immediately (as seen in Task Manager) without comment or question from Windows. I've tried reinstalling Cygwin on the server, then deleting c:\cygwin and reinstalling from scratch (rebooting each time in between for good measure), and have been unable to get .NET executables to run. Unfortunately, during my investigations, I also updated my laptop Cygwin to 1.7.15-1 as well (although I didn't uninstall or delete it). I've just discovered that it, too, is hanging if I try to launch any .NET exe. Running a normal .exe (e.g. things like explorer.exe from the Windows directory, or just typing 'explorer') works fine, and launches the applicable Windows program. I'm guessing that normal executables (e.g. created directly by gcc) are fine, and it's only those pulling in the .NET CLR that are failing. Both machines have all available Windows updates on them. I've never hit this sort of problem before with Cygwin, and am absolutely perplexed as to what is causing it. The fact that it's happened on two different machines (with different Windows versions), one with only a Cygwin update from setup.exe and the other with a scorched earth clean install, makes me tend to think that I might not be doing something absolutely stupid (which was my default assumption). Fortunately I can run the .NET executables directly from a Windows command prompt (cmd.exe) on either machine, but the loss of the Cygwin convenience shell (and the many shell scripts I use in it) is somewhat painful. I'm attaching the output from cygcheck for both machines, but have had to sanitise a fair bit of corporate information (usernames, servers, domains, etc.) and have replaced in each case with the string !sanitised!. Also, if it's at all possible to rollback to previous version of Cygwin, that would be a great help. (I see 1.5 on the site but that might be a bit too far back unless I get desperate.) Thanks in advance. cygcheck-laptop.out Description: Binary data cygcheck-server.out Description: Binary data -- 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.15-1: mintty bash failing to run .NET executables ?
hi, roll back your cygwin.dll to 1.7.14-2 --pawel On Tue, May 22, 2012 at 8:13 AM, John Costella john.coste...@gmail.com wrote: Not a newbie exactly, but haven't posted a question to this list before. I've been running Cygwin on both Windows 7 Pro 64-bit SP1 for about eight months and a (virtualised) server running Win Server 2008 R2 Standard SP1 for about two months, mainly as a convenience shell as corporate policy prevents me running native Linux machines. I'm using MonoDevelop to compile command-line C# programs into .NET executables (generally 4.0 by default, but have also tested the following with a Hello, World! compiled to 2.0). I believe MonoDevelop on Windows uses the standard Windows SDK and compiler. Today I happened to reboot the server for another reason, and then found that the standard output of the .NET executables was not appearing in the mintty bash terminal (although standard error was, and the programs were executing: visibly doing things in Task Manager, files being created, etc.). During investigation I wanted to get a utility from the Cygwin site, but hit Enter at the wrong time and ended up refreshing the installation to the latest (1.7.15-1). After that, .NET programs failed to launch at all. The mintty bash terminal just sits there, no CPU or anything else being used, the .NET .exe failing to launch according to Task Manager. (Have left it 10 or 15 minutes to make sure.) Ctrl-C / Ctrl-Break, Ctrl-Z fail to have any effect. Clicking the close 'X' on the window housing the mintty terminal just kills it (mintty.exe and bash.exe) immediately (as seen in Task Manager) without comment or question from Windows. I've tried reinstalling Cygwin on the server, then deleting c:\cygwin and reinstalling from scratch (rebooting each time in between for good measure), and have been unable to get .NET executables to run. Unfortunately, during my investigations, I also updated my laptop Cygwin to 1.7.15-1 as well (although I didn't uninstall or delete it). I've just discovered that it, too, is hanging if I try to launch any .NET exe. Running a normal .exe (e.g. things like explorer.exe from the Windows directory, or just typing 'explorer') works fine, and launches the applicable Windows program. I'm guessing that normal executables (e.g. created directly by gcc) are fine, and it's only those pulling in the .NET CLR that are failing. Both machines have all available Windows updates on them. I've never hit this sort of problem before with Cygwin, and am absolutely perplexed as to what is causing it. The fact that it's happened on two different machines (with different Windows versions), one with only a Cygwin update from setup.exe and the other with a scorched earth clean install, makes me tend to think that I might not be doing something absolutely stupid (which was my default assumption). Fortunately I can run the .NET executables directly from a Windows command prompt (cmd.exe) on either machine, but the loss of the Cygwin convenience shell (and the many shell scripts I use in it) is somewhat painful. I'm attaching the output from cygcheck for both machines, but have had to sanitise a fair bit of corporate information (usernames, servers, domains, etc.) and have replaced in each case with the string !sanitised!. Also, if it's at all possible to rollback to previous version of Cygwin, that would be a great help. (I see 1.5 on the site but that might be a bit too far back unless I get desperate.) Thanks in advance. -- 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
Re: bash.exe.stackdump generated using cygwin 1.7.15
On May 21 14:50, Eric Blake wrote: On 05/21/2012 10:42 AM, Corinna Vinschen wrote: The crash occurs after echo exited, so bash wakes up from the wait4 call. However, the problem is that the crash does not occur in Cygwin, but in bash itself. 147 350775 [main] bash 3548 wait4: 2320 = wait4(-1, 0x0, 0, 0x0) --- Process 3548, exception C005 at 00422B0A Eric, can you reproduce this and see where it happens? I'm pretty sure it's a bug in Cygwin, not in bash, but it would be interesting to learn what bash did at the time the crash happened. Incidentally I built bash without -O2 option for better debugging and the problem vanished. Then I built bash again with default optimization and the crash still didn't occur. I built from the latest bash src package.4.1.10-4 using cygport. Uggh. This sounds familiar to another bash bug that I investigated some time ago, where bash was abusing longjmp() and miscompiled under -O2 but compiled correctly at -O0 due to the undefined behavior from that abuse, but I just verified that my patch from back then is still present in my latest build of bash for cygwin. I'll have to find more time to look into this. https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00060.html In my testing it doesn't matter if I build execute_cmd.c or, FWIW, any of bash's source files with -O0, -O1, or -O2. My self-built bash never crashes in this scenario. 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.15-1: mintty bash failing to run .NET executables ?
On May 22 08:22, Pawel Jasinski wrote: Please, don't http://cygwin.com/acronyms/#TOFU hi, roll back your cygwin.dll to 1.7.14-2 Or better, please try the latest developer snapshot from http://cygwin.com/snapshots/ 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: Problem accessing Win98 network drive when logged in via ssh (or cron)
On May 15 13:29, Gareth Howell wrote: Hi I have cygwin (latest) running on an XP machine. It needs to access two workstations running Win95 and one running Win98. At the windows level, there are drive maps to the 'C' drives on the three workstations as X:, Y: and Z: and the filesystem can be seen. Cygwin's fstab has lines to mount the same network shares (using UNC paths) under the /mnt directory. The two Win95 shares and the single Win98 share show up just fine as type vfat when I do a mount when running cygwin terminal on the XP machine. If I log in remotely using ssh (as Administrator), the two Win95 shares show up as before, but the Win98 share shows up as type unknown and I can't access the filesystem. The same occurs if a job is run using the Administrator's crontab. I can see it's probably a permissions issue, but I can't get to the bottom of it or understand why the behaviour is different between Win95 and Win98. Any guidance would be welcome. First, please read the User's Guide chapter about switching the user context. It explains the problems with mapping shares when changing the user account via ssh or whatever: http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview In your scenario it might have something to do with the way the shares are shared. The old SMB knew user level shares and, well, share level shares. The latter doesn't require a logon to be accessible. Maybe the 95 shares are shared this way? 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 Thanks for that Corinna. It's weird; the Win95 shares appear OK, it's only the Win98 share. As I indicated in another thread, I have avoided the problem by using a different workstation as the proxy. I have a different problem with that one though. All three shares appear OK when I log in using SSH. When I try to run rsync over ssh though, I get errors saying the mount points vanished during the transfer. Gareth -- 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.15-1: pthread_cancel and pthread_kill not working as expected
Hi Otto, On May 21 14:44, Otto Meta wrote: Would you mind to provide *simple* testcases to allow easy debugging of your observations? I reduced the various tests to three rather simple individual testcases because those show possibly different bugs. Thanks! Testcase cancel deferred: Works with 1.7.9 and 20120517 snapshot, fails (hangs) with 1.7.12-1 and 1.7.15-1. If that works in the snapshot anyway, I'm not going to look into that one. Testcase cancel asynchronous: Async cancel seems to have no effect with any tested version. I think I found a solution for this problem. See the comment in the patch at http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srcr1=1.258r2=1.259 Please test the today's developer snapshot. Testcase signal/kill: Signals may or may not reach the correct thread with 1.7.12-1 and newer. Confirmed. I think the reason is that we only have a single event to signal that a POSIX signal arrived instead of a per-thread event, but I'm not sure. This is cgf's domain so I leave it at that for now. 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: emacs -nw hangs in a terminal
On May 21 14:51, Ken Brown wrote: On 5/21/2012 12:29 PM, Corinna Vinschen wrote: On May 21 11:31, Ken Brown wrote: On 5/21/2012 6:02 AM, Ken Brown wrote: On 5/21/2012 4:50 AM, Filipp Gunbin wrote: emacs-24.0.96-2 crashes when I am doing the following: 1) emacs -Q -nw 2) M-x shell 3) C-x C-f C-g I can reproduce this. I'll try again to fix it. I've discovered something strange by running emacs under gdb. If I start emacs-24 in a terminal (but not under X) and start a shell as you did, then every press of C-g creates a new thread, and these are never destroyed. I'm pretty sure the threads are created by Cygwin, not by emacs. What does C-g mean in Emacs? What's it supposed to do? Does it call select or poll? It's supposed to quit whatever operation is in progress. It doesn't call select or poll. In the situation of Filipp's instructions above, C-x C-f has caused emacs to prompt for a file name, and C-g should interrupt that. It also rings the the terminal bell and prints Quit in the echo area at the bottom of the screen. The situation in my instructions is slightly different. Prior to the user pressing C-g, emacs is running its idle loop, in which it repeatedly calls select to see if there's any event it needs to respond to. When C-g is pressed, select returns and emacs reacts to the keypress. In this case there's nothing to do but ring the terminal bell and print Quit. Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I try it under Cygwin 1.7.15 or current CVS. 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: emacs -nw hangs in a terminal
On 5/22/2012 7:28 AM, Corinna Vinschen wrote: On May 21 14:51, Ken Brown wrote: On 5/21/2012 12:29 PM, Corinna Vinschen wrote: On May 21 11:31, Ken Brown wrote: On 5/21/2012 6:02 AM, Ken Brown wrote: On 5/21/2012 4:50 AM, Filipp Gunbin wrote: emacs-24.0.96-2 crashes when I am doing the following: 1) emacs -Q -nw 2) M-x shell 3) C-x C-f C-g I can reproduce this. I'll try again to fix it. I've discovered something strange by running emacs under gdb. If I start emacs-24 in a terminal (but not under X) and start a shell as you did, then every press of C-g creates a new thread, and these are never destroyed. I'm pretty sure the threads are created by Cygwin, not by emacs. What does C-g mean in Emacs? What's it supposed to do? Does it call select or poll? It's supposed to quit whatever operation is in progress. It doesn't call select or poll. In the situation of Filipp's instructions above, C-x C-f has caused emacs to prompt for a file name, and C-g should interrupt that. It also rings the the terminal bell and prints Quit in the echo area at the bottom of the screen. The situation in my instructions is slightly different. Prior to the user pressing C-g, emacs is running its idle loop, in which it repeatedly calls select to see if there's any event it needs to respond to. When C-g is pressed, select returns and emacs reacts to the keypress. In this case there's nothing to do but ring the terminal bell and print Quit. Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I try it under Cygwin 1.7.15 or current CVS. That's strange. All my tests were done in mintty. Would it help if I sent some strace output and/or a gdb backtrace? I assumed you could get those (or at least the strace output) yourself, and I didn't want to spam the list. Ken P.S. BTW, I tested today's snapshot, and the problem is still there. -- 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.15-1: pthread_cancel and pthread_kill not working as expected
Testcase cancel deferred:
Works with 1.7.9 and 20120517 snapshot, fails (hangs) with 1.7.12-1
and 1.7.15-1.
If that works in the snapshot anyway, I'm not going to look into that
one.
It worked in the reduced testcase with sem_wait(). With read() it’s
still half-broken. See below.
Testcase cancel asynchronous:
Async cancel seems to have no effect with any tested version.
I think I found a solution for this problem. See the comment in the
patch at
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srcr1=1.258r2=1.259
Please test the today's developer snapshot.
Asynchronous cancel seems to work as well as deferred cancel now. Thanks.
Both cancel types work with sem_wait() and pause() now, but for threads
blocked in read() they’re still unreliable. Only one of three blocked
threads is killed in the attached updated testcases.
Testcase signal/kill:
Signals may or may not reach the correct thread with 1.7.12-1 and newer.
Confirmed. [...] This is cgf's domain so I leave it at that for now.
Okay, I’ll hope for him to respond then.
Otto
#include errno.h
#include pthread.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
pthread_t tids[3];
static void cleanup_handler(void *arg) {
int *intptr = (int*)arg;
pthread_t self = pthread_self();
fprintf(stderr, Thread %i exiting (%p)\n, *intptr, self);
}
static void* simplethread(void *arg) {
int *intptr = (int*)arg;
pthread_t self = pthread_self();
fprintf(stderr, Thread %i starting (%p)\n, *intptr, self);
char buffer[1] __attribute((unused));
pthread_cleanup_push(cleanup_handler, intptr);
int oldtype;
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, oldtype);
fprintf(stderr, Changing canceltype from %i to %i\n, oldtype, PTHREAD_CANCEL_ASYNCHRONOUS);
while (1) {
if (read(STDIN_FILENO, buffer, 1) = 0) {
fprintf(stderr, Thread %i encountered an error: %s (%p)\n,
*intptr, strerror(errno), self);
} else {
fprintf(stderr, Thread %i woke up just fine\n, *intptr);
}
}
pthread_cleanup_pop(1);
return NULL;
}
int main() {
fprintf(stderr, Testing asynchronous pthread_cancel()\n\n);
int i;
int result;
for (i=0; i3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, simplethread, intptr);
if (result != 0) {
fprintf(stderr, Can't create thread: %s\n, strerror(result));
return 1;
}
}
sleep(1);
fprintf(stderr, \n);
int mainint = 42;
pthread_cleanup_push(cleanup_handler, mainint);
for (i=2; i=0; i--) {
fprintf(stderr, Cancelling thread %i (%p)\n, i, tids[i]);
result = pthread_cancel(tids[i]);
if (result != 0) {
fprintf(stderr, Error during pthread_cancel: %s\n, strerror(result));
}
sleep(1);
}
fprintf(stderr, \n);
for (i=0; i3; i++) {
result = pthread_kill(tids[i], 0);
if (result == 0) {
fprintf(stderr, Thread %i is still there (%p)\n, i, tids[i]);
} else {
fprintf(stderr, Thread %i is gone (%p)\n, i, tids[i]);
}
}
pthread_cleanup_pop(0);
return 0;
}
#include errno.h
#include pthread.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
pthread_t tids[3];
static void cleanup_handler(void *arg) {
int *intptr = (int*)arg;
pthread_t self = pthread_self();
fprintf(stderr, Thread %i exiting (%p)\n, *intptr, self);
}
static void* simplethread(void *arg) {
int *intptr = (int*)arg;
pthread_t self = pthread_self();
fprintf(stderr, Thread %i starting (%p)\n, *intptr, self);
char buffer[1] __attribute((unused));
pthread_cleanup_push(cleanup_handler, intptr);
while (1) {
if (read(STDIN_FILENO, buffer, 1) = 0) {
fprintf(stderr, Thread %i encountered an error: %s (%p)\n,
*intptr, strerror(errno), self);
} else {
fprintf(stderr, Thread %i woke up just fine\n, *intptr);
}
}
pthread_cleanup_pop(1);
return NULL;
}
int main() {
fprintf(stderr, Testing deferred pthread_cancel()\n\n);
int i;
int result;
for (i=0; i3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, simplethread, intptr);
if (result != 0) {
fprintf(stderr, Can't create thread: %s\n, strerror(result));
return 1;
}
}
sleep(1);
fprintf(stderr, \n);
int mainint = 42;
pthread_cleanup_push(cleanup_handler, mainint);
for (i=2; i=0; i--) {
fprintf(stderr, Cancelling thread %i (%p)\n, i, tids[i]);
result = pthread_cancel(tids[i]);
if (result != 0) {
fprintf(stderr, Error during pthread_cancel: %s\n, strerror(result));
}
sleep(1);
}
fprintf(stderr, \n);
for (i=0; i3; i++) {
result = pthread_kill(tids[i], 0);
if (result == 0) {
fprintf(stderr, Thread %i is still there (%p)\n, i, tids[i]);
} else {
fprintf(stderr, Thread %i is gone (%p)\n, i, tids[i]);
}
}
pthread_cleanup_pop(0);
return
[ANNOUNCEMENT] New package: nmh-1.5-1
Version 1.5-1 of nmh has been uploaded. nmh is a capable mail handling system with a command line interface. It consists of simple, single-purpose programs for sending, receiving, saving, retrieving, and otherwise manipulating email messages. You can freely intersperse nmh commands with other shell commands or write custom scripts which utilize nmh commands. If you want to use nmh as a true email user agent, you'll want to also install xmh to provide a user interface for it--nmh only has a command line interface. nmh is configured on Cygwin to use less and vim by default but options allow use of more and emacs, respectively. nmh includes a comprehensive set of man pages. man nmh is a good starting point. Please submit bug reports to nmh-work...@nongnu.org. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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: cygwin-announce-unsubscribe-you=yourdomain.com at 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. -- 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: emacs -nw hangs in a terminal
On May 22 07:42, Ken Brown wrote: On 5/22/2012 7:28 AM, Corinna Vinschen wrote: On May 21 14:51, Ken Brown wrote: On 5/21/2012 12:29 PM, Corinna Vinschen wrote: On May 21 11:31, Ken Brown wrote: On 5/21/2012 6:02 AM, Ken Brown wrote: I've discovered something strange by running emacs under gdb. If I start emacs-24 in a terminal (but not under X) and start a shell as you did, then every press of C-g creates a new thread, and these are never destroyed. I'm pretty sure the threads are created by Cygwin, not by emacs. [...] Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I try it under Cygwin 1.7.15 or current CVS. That's strange. All my tests were done in mintty. Would it help if I sent some strace output and/or a gdb backtrace? I assumed you could get those (or at least the strace output) yourself, and I didn't want to spam the list. Ken P.S. BTW, I tested today's snapshot, and the problem is still there. I doubt that an strace is sufficient, but you could send me one created with the latest snapshot off-list, to the address I'm using in the Changelogs. Please point out the places which seem suspicious to you. 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: emacs -nw hangs in a terminal
On May 22 15:41, Corinna Vinschen wrote: On May 22 07:42, Ken Brown wrote: On 5/22/2012 7:28 AM, Corinna Vinschen wrote: On May 21 14:51, Ken Brown wrote: On 5/21/2012 12:29 PM, Corinna Vinschen wrote: On May 21 11:31, Ken Brown wrote: On 5/21/2012 6:02 AM, Ken Brown wrote: I've discovered something strange by running emacs under gdb. If I start emacs-24 in a terminal (but not under X) and start a shell as you did, then every press of C-g creates a new thread, and these are never destroyed. I'm pretty sure the threads are created by Cygwin, not by emacs. [...] Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I try it under Cygwin 1.7.15 or current CVS. That's strange. All my tests were done in mintty. Would it help if I sent some strace output and/or a gdb backtrace? I assumed you could get those (or at least the strace output) yourself, and I didn't want to spam the list. Ken P.S. BTW, I tested today's snapshot, and the problem is still there. I doubt that an strace is sufficient, but you could send me one created with the latest snapshot off-list, to the address I'm using in the Changelogs. Please point out the places which seem suspicious to you. Ouch! Hang on. I didn't test with the 24.x version, but with the old one. Sorry about that. Now I can reproduce the SEGV. 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: Bug in package: nc6-1.0-1
On 5/21/2012 9:38 AM, Corinna Vinschen wrote: I'll check in a fix to Cygwin shortly. Please give the next developer snapshot a try. It works fine with 1.7.16s(0.261/5/3) 20120522 12:32:26. It shows an extra message (on both sides), but maybe that is normal for nc6: $ nc6 -4lup 7000 nc6: using datagram socket ... -- René Berber -- 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.15-1: mintty bash failing to run .NET executables ?
-Original Message- Sent: Tuesday, May 22, 2012 06:14 Subject: 1.7.15-1: mintty bash failing to run .NET executables ? After that, .NET programs failed to launch at all. The mintty bash terminal just sits there, no CPU or anything else being used, the .NET .exe failing to launch according to Task Manager. (Have left it 10 or 15 minutes to make sure.) Ctrl-C / Ctrl-Break, Ctrl-Z fail to have any effect. Clicking the close 'X' on the window housing the mintty terminal just kills it (mintty.exe and bash.exe) immediately (as seen in Task Manager) without comment or question from Windows. I had the same problem with 1.7.15, and so did one or two other people. The latest developer snapshot fixed the problem for me (so far!). roll back your cygwin.dll to 1.7.14-2 I would not suggest doing this. The last several Cygwin versions had a series of problems with handling of standard input/output for non-Cygwin programs; in some situations, the problems were timing-sensitive and did not occur 100% of the time. I would also strongly recommend that you look at setting the new pipe_byte option in the CYGWIN environment variable ( http://cygwin.com/cygwin-ug-net/using-cygwinenv.html ). Unfortunately the documentation has zero indication of why you would need to set this, but to summarize, you will probably want/need to set this if you are redirecting standard input to a non-Cygwin program (either .NET or otherwise). You may find it useful to read some of the archived discussion in the Cygwin mailing list over the past few months; there are several discussions regarding these issues that should give you a deeper understanding of the problems. -- 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.15: Cygwin DLL issue with procps and java
Using the snapshot from 2012-05-22 still did not fix the problem. -- 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: SIGINT not passed to java process
Since apparently nobody wants to take ownership of this regression I'll point out the workaround, for the benefit of those googling and landing on this thread: start Java with -Xrs and use Ctrl-Break instead of Ctrl-C. This will disable thread dump and break any application that relies on normal signal handling, though. -- O.L. -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
What is a better way I can give context (and credit) when I am responding to a message, without implying that I expect a reply from the original author? I've been a Usenet user since 1988, and I've never heard of the convention of quoting implies request for reply. Replies from the original author are always welcome, but I don't necessarily expect them. Maybe I just missed the memo On the receiving side, if I didn't want to respond to a Usenet message, I just didn't. If I wasn't interested in a thread anymore, I just stopped reading it, or put it in my kill file. I read the Cygwin mailing list using the gmane.org newsfeed, too. But I was told that replying via my newsreader (Outlook Newsreader) messes up the e'mail threading. So now I subscribe to the digest as well, so that I can reply to the SMTP e'mail instead of replying to the gmane NNTP post. -- 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
64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
From: Cygwin-L On Behalf Of Warren Young I would say that the vast majority of the packages in the Cygwin distribution could not reasonably make use of 64-bit data spaces. However, one of your arguments in this thread cuts both ways: the fact that there are a few packages that reasonably can do so means you cannot say we don't need it. If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits.
Re: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
On 22/05/2012 20:06, Matt Seitz (matseitz) wrote: From: Cygwin-L On Behalf Of Warren Young I would say that the vast majority of the packages in the Cygwin distribution could not reasonably make use of 64-bit data spaces. However, one of your arguments in this thread cuts both ways: the fact that there are a few packages that reasonably can do so means you cannot say we don't need it. If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits. Hear hear. Well said. Perhaps we can drop this tedious thread now, or else TITTTL. IMHO it has shown rather lamentable knowledge of both compiler technology and RISC/CISC architecture from at least one responder. -- Cliff -- 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: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
On 5/22/2012 9:06 PM, Matt Seitz (matseitz) wrote: From: Cygwin-L On Behalf Of Warren Young I would say that the vast majority of the packages in the Cygwin distribution could not reasonably make use of 64-bit data spaces. However, one of your arguments in this thread cuts both ways: the fact that there are a few packages that reasonably can do so means you cannot say we don't need it. If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits. Could you please stop this discussion ? Until we work and deploy a 64bit cygwin1.dll the idea to build any 64 bit cygwin program is pure academic and not very useful. If you want to propose patches for 64 bit cygwin cygwin-developers is the right mailing list. Regards Marco -- 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: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
From: Cygwin-L: On Behalf Of marco atzeri Until we work and deploy a 64bit cygwin1.dll the idea to build any 64 bit cygwin program is pure academic and not very useful. If you want to propose patches for 64 bit cygwin cygwin-developers is the right mailing list. Sorry if I wasn't clear. That's exactly what I was trying to suggest: if someone wants a 64-bit Cygwin package, they should start by building such a package themselves, including any necessary changes to cygwin1.dll. Once you've got a working example, bring your results and patches to the maintainers.
[ANNOUNCEMENT] Updated: pcre-8.30-1
The following packages have been updated for the Cygwin distribution: *** pcre-8.30-1 *** libpcre1-8.30-1 *** libpcre16_0-8.30-1 *** libpcrecpp0-8.30-1 *** libpcreposix0-8.30-1 *** libpcre-devel-8.30-1 The PCRE library implements regular expression pattern matching using the same syntax and semantics as Perl. This release includes the following notable changes: * Some deprecated functions have been removed from libpcre, whose ABI version was changed accordingly. * A UTF-16 version of the PCRE API is now provided by libpcre16. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-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-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. -- 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
[ANNOUNCEMENT] Updated: audiofile-0.3.4-1
The following packages have been updated for the Cygwin distribution: *** audiofile-0.3.4-1 *** libaudiofile1-0.3.4-1 *** libaudiofile-devel-0.3.4-1 The Audio File Library provides a uniform programming interface for processing of audio data to and from audio files of many common formats (currently AIFF, AIFF-C, WAVE, NeXT/Sun .snd/.au, IRCAM, AVR, Amiga IFF/8SVX, and NIST SPHERE). This is an update to the latest upstream release. The ABI version was bumped, and all current packages which depend on libaudiofile have been rebuilt accordingly. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-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-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. -- 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
[ANNOUNCEMENT] Updated: python-numpy-1.6.2-1
The following package has been updated for the Cygwin distribution: *** python-numpy-1.6.2-1 The NumPy module contains a powerful N-dimensional array object, sophisticated (broadcasting) functions, tools for integrating C/C++ and Fortran code, and useful linear algebra, Fourier transform, and random number capabilities. It derives from the old Numeric code base and can be used as a replacement for Numeric. It also adds the features introduced by numarray and can be used to replace numarray. This is an update to the latest upstream release. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-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-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. -- 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
[ANNOUNCEMENT] Updated: apache2-2.2.22-3
The following packages have been updated for the Cygwin distribution: *** apache2-2.2.22-3 *** apache2-devel-2.2.22-3 *** apache2-manual-2.2.22-3 The Apache HTTP Server is a robust, commercial-grade, featureful, extensible, and freely-available source code implementation of an HTTP (Web) server. This release has been rebuilt for pcre-8.30. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-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-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. -- 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: Updated: python-numpy-1.6.2-1
thanks -Original Message- From: cygwin-announce-ow...@cygwin.com [mailto:cygwin-announce-ow...@cygwin.com] On Behalf Of Yaakov (Cygwin/X) Sent: Tuesday, May 22, 2012 3:25 PM To: cygwin-annou...@cygwin.com Subject: Updated: python-numpy-1.6.2-1 The following package has been updated for the Cygwin distribution: *** python-numpy-1.6.2-1 The NumPy module contains a powerful N-dimensional array object, sophisticated (broadcasting) functions, tools for integrating C/C++ and Fortran code, and useful linear algebra, Fourier transform, and random number capabilities. It derives from the old Numeric code base and can be used as a replacement for Numeric. It also adds the features introduced by numarray and can be used to replace numarray. This is an update to the latest upstream release. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-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-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. -- 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
New package: nmh-1.5-1
Version 1.5-1 of nmh has been uploaded. nmh is a capable mail handling system with a command line interface. It consists of simple, single-purpose programs for sending, receiving, saving, retrieving, and otherwise manipulating email messages. You can freely intersperse nmh commands with other shell commands or write custom scripts which utilize nmh commands. If you want to use nmh as a true email user agent, you'll want to also install xmh to provide a user interface for it--nmh only has a command line interface. nmh is configured on Cygwin to use less and vim by default but options allow use of more and emacs, respectively. nmh includes a comprehensive set of man pages. man nmh is a good starting point. Please submit bug reports to nmh-work...@nongnu.org. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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: cygwin-announce-unsubscribe-you=yourdomain.com at 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.
Updated: audiofile-0.3.4-1
The following packages have been updated for the Cygwin distribution: *** audiofile-0.3.4-1 *** libaudiofile1-0.3.4-1 *** libaudiofile-devel-0.3.4-1 The Audio File Library provides a uniform programming interface for processing of audio data to and from audio files of many common formats (currently AIFF, AIFF-C, WAVE, NeXT/Sun .snd/.au, IRCAM, AVR, Amiga IFF/8SVX, and NIST SPHERE). This is an update to the latest upstream release. The ABI version was bumped, and all current packages which depend on libaudiofile have been rebuilt accordingly. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-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-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.
Updated: python-numpy-1.6.2-1
The following package has been updated for the Cygwin distribution: *** python-numpy-1.6.2-1 The NumPy module contains a powerful N-dimensional array object, sophisticated (broadcasting) functions, tools for integrating C/C++ and Fortran code, and useful linear algebra, Fourier transform, and random number capabilities. It derives from the old Numeric code base and can be used as a replacement for Numeric. It also adds the features introduced by numarray and can be used to replace numarray. This is an update to the latest upstream release. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-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-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.
Updated: apache2-2.2.22-3
The following packages have been updated for the Cygwin distribution: *** apache2-2.2.22-3 *** apache2-devel-2.2.22-3 *** apache2-manual-2.2.22-3 The Apache HTTP Server is a robust, commercial-grade, featureful, extensible, and freely-available source code implementation of an HTTP (Web) server. This release has been rebuilt for pcre-8.30. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-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-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.
