RFU dos2unix 6.0.1-1
New upstream release. wget -x -nH \ http://waterlan.home.xs4all.nl/cygwin/dos2unix-6.0.1-1.tar.bz2 \ http://waterlan.home.xs4all.nl/cygwin/dos2unix-6.0.1-1-src.tar.bz2 \ http://waterlan.home.xs4all.nl/cygwin/setup.hint Changes: * Update Spanish translations. * Update manual. For Cygwin the commands 'd2u' and 'u2d' have been added. best regards, -- Erwin Waterlander Eindhoven
[SECURITY] exif
Jari, A security vulnerability (CVE-2012-2845) has been announced for the outdated version of the exif package currently in the distribution. Please update exif to 0.6.21 ASAP. And while I'm at it, ping: http://cygwin.com/ml/cygwin-apps/2008-11/msg00078.html http://cygwin.com/ml/cygwin/2012-04/msg4.html http://cygwin.com/ml/cygwin/2012-04/msg5.html Yaakov
possible to run XWin as windows service?
Hi, I would like to start XWin automatically on Windows startup (Windows user login). I couldn't find any hint in the manual. Is it possible to run (and automatically start) XWin as windows service? I tried these attempts, but they don't work: sc create testabc1 binpath= D:\Programme\cygwin\bin\startxwin.exe -- /bin/XWin -clipboard -emulate3buttons 100 -nounixkill -nowinkill -xkboptions nbsp:level3 displayname= testabc1 start= demand sc create testabc2 binpath= D:\Programme\cygwin\bin\XWin.exe -clipboard -emulate3buttons 100 -nounixkill -nowinkill -xkboptions nbsp:level3 displayname= testabc2 start= demand ... they all come with the same error message on startup: sc start testabc2 [SC] StartService FEHLER 1053: Der Dienst antwortete nicht rechtzeitig auf die Start- oder Steuerungsanforderung. Thank you very much for ideas! Regards, Paul -- 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: possible to run XWin as windows service?
From: Paul Maier I would like to start XWin automatically on Windows startup (Windows user login). I couldn't find any hint in the manual. How about just adding the XWin Server shortcut to the Startup program group? -- 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/
Maxima can't write to /dev/stdout
The following maxima session encounters an EACCESS error that I can't make sense of: (%i1) m: genmatrix (lambda([i,j], i+j-1), 3, 3)$ (%i2) write_data(m, /dev/stdout)$ Maxima encountered a Lisp error: UNIX error 13 (EACCES): Permission denied Automatically continuing. To enable the Lisp debugger set *debugger-hook* to nil. (%i3) The strace corresponding to opening /dev/stdout looks normal to me up until the write fails: 72 28729956 [main] lisp 196 normalize_posix_path: src /dev/. 25 28729981 [main] lisp 196 normalize_posix_path: /dev/ = normalize_posix_path (/dev/.) 24 28730005 [main] lisp 196 mount_info::conv_to_win32_path: conv_to_win32_path (/dev) 25 28730030 [main] lisp 196 set_flags: flags: binary (0x2) 22 28730052 [main] lisp 196 mount_info::conv_to_win32_path: src_path /dev, dst C:\Programs\Cygwin\dev, flags 0x3000A, rc 0 112 28730164 [main] lisp 196 symlink_info::check: 0x0 = NtCreateFile (\??\C:\Programs\Cygwin\dev) 45 28730209 [main] lisp 196 symlink_info::check: not a symlink 47 28730256 [main] lisp 196 symlink_info::check: 0 = symlink.check(C:\Programs\Cygwin\dev, 0xDC15C0) (0x3000A) 37 28730293 [main] lisp 196 lstat64: entering 25 28730318 [main] lisp 196 normalize_posix_path: src /dev/stdout 21 28730339 [main] lisp 196 normalize_posix_path: /dev/stdout = normalize_posix_path (/dev/stdout) 22 28730361 [main] lisp 196 mount_info::conv_to_win32_path: conv_to_win32_path (/dev/stdout) 38 28730399 [main] lisp 196 set_flags: flags: binary (0x2) 23 28730422 [main] lisp 196 mount_info::conv_to_win32_path: src_path /dev/stdout, dst C:\Programs\Cygwin\dev\stdout, flags 0x3000A, rc 0 67 28730489 [main] lisp 196 symlink_info::check: 0x0 = NtCreateFile (\??\C:\Programs\Cygwin\dev\stdout) 149 28730638 [main] lisp 196 symlink_info::check: 15 = symlink.check(C:\Programs\Cygwin\dev\stdout, 0xDC1700) (0x43000B) 32 28730670 [main] lisp 196 path_conv::check: this-path(C:\Programs\Cygwin\dev\stdout), has_acls(1) 31 28730701 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xC3 25 28730726 [main] lisp 196 stat_worker: (\??\C:\Programs\Cygwin\dev\stdout, 0xDC3B30, 0x612883D0), file_attributes 4 73 28730799 [main] lisp 196 cygpsid::debug_print: get_sids_info: owner SID = S-1-5-21-2052111302-842925246-682003330-75441 26 28730825 [main] lisp 196 cygpsid::debug_print: get_sids_info: group SID = S-1-5-21-2052111302-842925246-682003330-513 24 28730849 [main] lisp 196 get_info_from_sd: uid 85441, gid 10513 40 28730889 [main] lisp 196 fhandler_base::fstat_helper: 0 = fstat (\??\C:\Programs\Cygwin\dev\stdout, 0xDC3B30) st_size=15, st_mode=0xA1FF, st_ino=281474978421744st_atim=4FBF6387.DB7D74 st_ctim=4FBF6387.DB7D74 st_mtim=4FBF6387.DB7D74 st_birthtim=4FBF6387.DB7D74 29 28730918 [main] lisp 196 stat_worker: 0 = (\??\C:\Programs\Cygwin\dev\stdout,0xDC3B30) 51 28730969 [main] lisp 196 normalize_posix_path: src /dev/stdout 23 28730992 [main] lisp 196 normalize_posix_path: /dev/stdout = normalize_posix_path (/dev/stdout) 22 28731014 [main] lisp 196 mount_info::conv_to_win32_path: conv_to_win32_path (/dev/stdout) 22 28731036 [main] lisp 196 set_flags: flags: binary (0x2) 22 28731058 [main] lisp 196 mount_info::conv_to_win32_path: src_path /dev/stdout, dst C:\Programs\Cygwin\dev\stdout, flags 0x3000A, rc 0 63 28731121 [main] lisp 196 symlink_info::check: 0x0 = NtCreateFile (\??\C:\Programs\Cygwin\dev\stdout) 133 28731254 [main] lisp 196 symlink_info::check: 15 = symlink.check(C:\Programs\Cygwin\dev\stdout, 0xDC16B0) (0x3000B) 28 28731282 [main] lisp 196 path_conv::check: this-path(/proc/self/fd/1), has_acls(1) 35 28731317 [main] lisp 196 normalize_posix_path: src /proc/self/fd/. 23 28731340 [main] lisp 196 normalize_posix_path: /proc/self/fd/ = normalize_posix_path (/proc/self/fd/.) 22 28731362 [main] lisp 196 mount_info::conv_to_win32_path: conv_to_win32_path (/proc/self/fd) 24 28731386 [main] lisp 196 fhandler_proc::get_proc_fhandler: get_proc_fhandler(/proc/self/fd) 23 28731409 [main] lisp 196 set_flags: flags: binary (0x2) 21 28731430 [main] lisp 196 mount_info::conv_to_win32_path: src_path /proc/self/fd, dst /proc/self/fd, flags 0x2, rc 0 28 28731458 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFF 24 28731482 [main] lisp 196 fhandler_proc::exists: exists (/proc/self/fd) 24 28731506 [main] lisp 196 mount_info::conv_to_win32_path: conv_to_win32_path (/proc/self) 22 28731528 [main] lisp 196 fhandler_proc::get_proc_fhandler: get_proc_fhandler(/proc/self) 21 28731549 [main] lisp 196 set_flags: flags: binary (0x2) 21 28731570 [main] lisp 196 mount_info::conv_to_win32_path: src_path /proc/self, dst /proc/self, flags 0x2, rc 0 25 28731595 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFF 22 28731617 [main] lisp 196 fhandler_proc::exists: exists (/proc/self) 21 28731638 [main] lisp 196 getpid: 196 = getpid() 25 28731663 [main] lisp 196 normalize_posix_path: src /proc/196/fd 21
Re: Maxima can't write to /dev/stdout
On Jul 26 07:04, Achim Gratz wrote: The following maxima session encounters an EACCESS error that I can't make sense of: (%i1) m: genmatrix (lambda([i,j], i+j-1), 3, 3)$ (%i2) write_data(m, /dev/stdout)$ Maxima encountered a Lisp error: UNIX error 13 (EACCES): Permission denied Automatically continuing. To enable the Lisp debugger set *debugger-hook* to nil. (%i3) The strace corresponding to opening /dev/stdout looks normal to me up until the write fails: [...] 133 28731254 [main] lisp 196 symlink_info::check: 15 = symlink.check(C:\Programs\Cygwin\dev\stdout, 0xDC16B0) (0x3000B) 28 28731282 [main] lisp 196 path_conv::check: this-path(/proc/self/fd/1), has_acls(1) /dev/stdout is a symlink to /proc/self/fd/. 25 28731595 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFF 22 28731617 [main] lisp 196 fhandler_proc::exists: exists (/proc/self) 21 28731638 [main] lisp 196 getpid: 196 = getpid() /proc/self is a symlink to /proc/196. 25 28731663 [main] lisp 196 normalize_posix_path: src /proc/196/fd 21 28731684 [main] lisp 196 normalize_posix_path: /proc/196/fd = normalize_posix_path (/proc/196/fd) And here something goes wrong. If I call `echo foo /dev/stdout' in bash, the above normalize_posix_path calls already handle the path /proc/196/fd/1, not just /proc/196/fd as lisp does. 22 28731706 [main] lisp 196 mount_info::conv_to_win32_path: conv_to_win32_path (/proc/196/fd) 21 28731727 [main] lisp 196 fhandler_proc::get_proc_fhandler: get_proc_fhandler(/proc/196/fd) 22 28731749 [main] lisp 196 set_flags: flags: binary (0x2) 24 28731773 [main] lisp 196 mount_info::conv_to_win32_path: src_path /proc/196/fd, dst /proc/196/fd, flags 0x2, rc 0 25 28731798 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFE 22 28731820 [main] lisp 196 fhandler_process::exists: exists (/proc/196/fd) 31 28731851 [main] lisp 196 lstat64: entering Here it calls lstat(/proc/196/fd/1), which works, but doesn't resolve the symlink. [...] 23 28732180 [main] lisp 196 stat_worker: 0 = (/proc/196/fd/1,0xDC3B30) 23 28732203 [main] lisp 196 normalize_posix_path: src /proc/196/fd/1 23 28732226 [main] lisp 196 normalize_posix_path: /proc/196/fd/1 = normalize_posix_path (/proc/196/fd/1) 21 28732247 [main] lisp 196 mount_info::conv_to_win32_path: conv_to_win32_path (/proc/196/fd/1) 22 28732269 [main] lisp 196 fhandler_proc::get_proc_fhandler: get_proc_fhandler(/proc/196/fd/1) 21 28732290 [main] lisp 196 set_flags: flags: binary (0x2) 21 28732311 [main] lisp 196 mount_info::conv_to_win32_path: src_path /proc/196/fd/1, dst /proc/196/fd/1, flags 0x2, rc 0 26 28732337 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFE 22 28732359 [main] lisp 196 fhandler_process::exists: exists (/proc/196/fd/1) In fact, it never tried to resolve the symlink up to here. 29 28732388 [main] lisp 196 normalize_posix_path: src /proc/196/fd/. 22 28732410 [main] lisp 196 normalize_posix_path: /proc/196/fd/ = normalize_posix_path (/proc/196/fd/.) ...so what is it doing with /proc/196/fd/. now? [...] 98 28757380 [main] lisp 196 stat64: entering [...] 26 28757895 [main] lisp 196 stat_worker: 0 = (/proc/196/fd,0xDC39E0) Calling stat on it, but what for? 28 28757923 [main] lisp 196 stat64: entering [...] 72 28758456 [main] lisp 196 stat_worker: 0 = (/proc/196/fd,0xDC3A50) ...and again... 26 28758482 [main] lisp 196 open: open(/proc/196/fd/, 0x10601) And now it opend the directory /proc/196/fd ... 88 28759279 [main] lisp 196 open: 4 = open(/proc/196/fd/, 0x18601) gets the descriptor 4 ... 550 28759904 [main] lisp 196 write: write(4, 0xDC2480, 1) 38 28759942 [main] lisp 196 __set_errno: virtual ssize_t fhandler_virtual::write(const void*, size_t):211 setting errno 13 29 28759971 [main] lisp 196 write: -1 = write(4, 0xDC2480, 1), errno 13 ... tries to write to it and *of course* gets an EACCES. I don't know what lisp is trying to do here, but it doesn't look like Cygwin's fault. After all, echo foo /dev/stdout works fine. Also, if descriptor 1 is closed, the error message looks different: $ echo foo 1- /dev/stdout bash: /dev/stdout: No such file or directory 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: Maxima can't write to /dev/stdout
On Jul 26 10:17, Corinna Vinschen wrote: On Jul 26 07:04, Achim Gratz wrote: The following maxima session encounters an EACCESS error that I can't make sense of: (%i1) m: genmatrix (lambda([i,j], i+j-1), 3, 3)$ (%i2) write_data(m, /dev/stdout)$ Maxima encountered a Lisp error: UNIX error 13 (EACCES): Permission denied Automatically continuing. To enable the Lisp debugger set *debugger-hook* to nil. (%i3) The strace corresponding to opening /dev/stdout looks normal to me up until the write fails: [...] 133 28731254 [main] lisp 196 symlink_info::check: 15 = symlink.check(C:\Programs\Cygwin\dev\stdout, 0xDC16B0) (0x3000B) 28 28731282 [main] lisp 196 path_conv::check: this-path(/proc/self/fd/1), has_acls(1) /dev/stdout is a symlink to /proc/self/fd/. /proc/self/fd/1, of course. 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: Maxima can't write to /dev/stdout
Corinna Vinschen corinna-cygwin at cygwin.com writes: And here something goes wrong. If I call `echo foo /dev/stdout' in bash, the above normalize_posix_path calls already handle the path /proc/196/fd/1, not just /proc/196/fd as lisp does. Thanks for having a look, that got me one step further. Maxima uses a (captive) clisp and the standalone clisp makes the same error: [1] (open /dev/stdout) *** - OPEN: File #P/proc/3348/fd/ does not exist So the same thing happens in clisp and it seems to affect only(?) symlinks pointing to /proc, some other symlinks I tried that were pointing to /dev/tty as a test have not had that problem. Is it possible that clisp uses an API that isn't aware of /proc somehow? Regards, Achim -- 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: Maxima can't write to /dev/stdout
On Jul 26 09:23, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: And here something goes wrong. If I call `echo foo /dev/stdout' in bash, the above normalize_posix_path calls already handle the path /proc/196/fd/1, not just /proc/196/fd as lisp does. Thanks for having a look, that got me one step further. Maxima uses a (captive) clisp and the standalone clisp makes the same error: [1] (open /dev/stdout) *** - OPEN: File #P/proc/3348/fd/ does not exist So the same thing happens in clisp and it seems to affect only(?) symlinks pointing to /proc, some other symlinks I tried that were pointing to /dev/tty as a test have not had that problem. Is it possible that clisp uses an API that isn't aware of /proc somehow? That *should* be impossible. The path handling is supposed to be transparently handling all real and virtual paths, regardless of the function calling the path handling stuff. If you can nail that down to the actual calls and decisions clisp is doing, it might help to find the cause. 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: Confusing, but not fatal bug....rmdir removed network dir (rename to .____00000hexnum/)
On Jul 25 13:53, Linda Walsh wrote: Corinna Vinschen wrote: Anyway, I have a fix for that. You didn't explicitely allow to send a test DLL, so I just applied the patch to CVS. Please test the next developer snapshot. Sorry, I thought it would be implicit that I gave you everything you asked for -- [...] So if you want, I'm willing to try a fix, or I can wait...either way is fine.. Just try the latest developer snapshot from http://cygwin.com/snapshots/ It contains the patch. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: install package from cpan report address space needed by ... is already occupied
ping wrote: I'm trying to install App::Asciio in cygwin, but got following error,- please advice, or what info are still needed to proceed, thanks! CPAN: Module::Build loaded ok (v0.3613) CPAN.pm: Going to build N/NK/NKH/App-Asciio-1.02.71.tar.gz 0 [main] perl 6432 child_info_fork::abort: address space needed- by 'Base64.dll' (0xC6) is already occupied 1 [main] perl 3844 child_info_fork::abort: unable to remap- Util.dll to same address as parent (009A) - try running rebaseall 0 [main] perl 10708 child_info_fork::abort: address space needed- by 'Base64.dll' (0xC6) is already occupied 0 [main] perl 11276 child_info_fork::abort: unable to remap- Util.dll to same address as parent (009A) - try running rebaseall 0 [main] perl 1976 child_info_fork::abort: address space needed- by 'Base64.dll' (0xC6) is already occupied Did you try following the instructions in those error messages? -- 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
swig 2.0.7-1 crashes parsing %extend directives
Dear list, I would like to report a bug in the swig 2.0.7-1 package which prevents swig from parsing certain %extend directives, in my case %extend destructor directives. The bug results in swig crashing due to a segmentation fault. The bug has been reported upstream: http://sourceforge.net/tracker/?func=detailaid=3530078group_id=1645atid=101645 and a solution for the issue has been found and committed to the swig repository. Kind regards, Mark Hesselink -- 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: Maxima can't write to /dev/stdout
On Thu, Jul 26, 2012 at 5:46 AM, Corinna Vinschen wrote: On Jul 26 09:23, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: And here something goes wrong. If I call `echo foo /dev/stdout' in bash, the above normalize_posix_path calls already handle the path /proc/196/fd/1, not just /proc/196/fd as lisp does. Thanks for having a look, that got me one step further. Maxima uses a (captive) clisp and the standalone clisp makes the same error: [1] (open /dev/stdout) *** - OPEN: File #P/proc/3348/fd/ does not exist So the same thing happens in clisp and it seems to affect only(?) symlinks pointing to /proc, some other symlinks I tried that were pointing to /dev/tty as a test have not had that problem. Is it possible that clisp uses an API that isn't aware of /proc somehow? That *should* be impossible. The path handling is supposed to be transparently handling all real and virtual paths, regardless of the function calling the path handling stuff. If you can nail that down to the actual calls and decisions clisp is doing, it might help to find the cause. Maybe something to do with the 1 looking like an integer instead of a valid path or directory? Don't know but thought I would give my initial thoughts. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: environment variables mks toolkit - patch opportunity?
On Wed, Jul 25, 2012 at 6:43 PM, M. Sebastian Comella wrote: My question is this: is there an opportunity to patch something in Cygwin's startup chain to detect unsavory environment variables and warn users in some fashion? Create a .bat file that is used in the desktop shortcut to start Cygwin. You can add or remove what ever variables need to be added or removed. Copy the start command from the desktop shortcut to use as the command once the environment is set. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: install package from cpan report address space needed by ... is already occupied
actually I tried...couldn't figure out how. the instruction from rebaseall is quite confusing... [ping@ping-new-laptop ~]$ rebaseall rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). [ping@ping-new-laptop ~]$ [ping@ping-new-laptop ~]$ [ping@ping-new-laptop ~]$ ash [\e[32m\u@\h \e[33m\W\e[0m]$ /bin/rebaseall ash: 1: /bin/rebseall: not found [\e[32m\u@\h \e[33m\W\e[0m]$ exit [ping@ping-new-laptop ~]$ dash.exe [\e[32m\u@\h \e[33m\W\e[0m]$ reba [\e[32m\u@\h \e[33m\W\e[0m]$ rebaseall.exe dash: 2: rebaseall.exe: not found [\e[32m\u@\h \e[33m\W\e[0m]$ /bin/rebaseall.exe dash: 3: /bin/rebaseall.exe: not found [\e[32m\u@\h \e[33m\W\e[0m]$ rebaseall rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). c:\ c:\cd cygwin c:\cygwincd bin c:\cygwin\bin./ash '.' is not recognized as an internal or external command, operable program or batch file. c:\cygwin\binash $ /bin/rebaseall rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). On 07/26/2012 05:46 AM, Adam Dinwoodie wrote: ping wrote: I'm trying to install App::Asciio in cygwin, but got following error,- please advice, or what info are still needed to proceed, thanks! CPAN: Module::Build loaded ok (v0.3613) CPAN.pm: Going to build N/NK/NKH/App-Asciio-1.02.71.tar.gz 0 [main] perl 6432 child_info_fork::abort: address space needed- by 'Base64.dll' (0xC6) is already occupied 1 [main] perl 3844 child_info_fork::abort: unable to remap- Util.dll to same address as parent (009A) - try running rebaseall 0 [main] perl 10708 child_info_fork::abort: address space needed- by 'Base64.dll' (0xC6) is already occupied 0 [main] perl 11276 child_info_fork::abort: unable to remap- Util.dll to same address as parent (009A) - try running rebaseall 0 [main] perl 1976 child_info_fork::abort: address space needed- by 'Base64.dll' (0xC6) is already occupied Did you try following the instructions in those error messages? -- 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: install package from cpan report address space needed by ... is already occupied
On 7/26/2012 9:33 AM, ping wrote: actually I tried...couldn't figure out how. the instruction from rebaseall is quite confusing... You missed some important bits: [ping@ping-new-laptop ~]$ rebaseall rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. ^^^ i.e. You can't start ash or dash from a Cygwin shell or terminal. Execute ash (or dash) from Start/Run... or a cmd or command window. ^^^ Run ash from here _after_stopping_all_Cygwin_processes_and_services_. Execute '/bin/rebaseall' from ash (or dash). -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: install package from cpan report address space needed by ... is already occupied
ping wrote: actually I tried...couldn't figure out how. the instruction from- rebaseall is quite confusing... First, don't top post. Second, help yourself: did you try looking at the FAQ or Google? Third, help us help you: don't tell us you're confused, tell us what you're confused by. Don't make us look through reams of output to try and understand what you're trying to do, cut it down to the minimum that shows the problem. I recommend reading through all of the below (yes, I mean all, and in full) before posting again. Reread if you've already read them once. http://cygwin.com/problems.html http://www.catb.org/~esr/faqs/smart-questions.html http://slash7.com/2006/12/22/vampires/ Currently you're giving me the impression that you want answers handed to you on a plate, that you're not willing to work things out for yourself. If you want help from the Cygwin folk (or pretty much anyone in the Linux world) either learn how to solve simple problems yourself and ask useful questions, or pay someone for tech support. -- 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: VB script error in Cygwin
I usually write a CMD.EXE script that in turn, runs cscript and its *.vbs file. Example: The following lines are a cmd batch file called bar.cmd @echo on echo.This is bar.cmd, a CMD.EXE script, which will be invoked by Cygwin echo.Run a vbscript called foo.vbs cscript foo.vbs echo.foo.vbs is complete echo.Done, now exiting bar.cmd exit ** First ** run bar.cmd within a CMD.EXE window to be sure it and foo.vbs are working properly outside of Cygwin. ** Second** from within Cygwin's bash (or other) shell, run bar.cmd: $ cmd /c bar.cmd Watch for output or results from foo.vbs during the run. == Keith -- 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: VB script error in Cygwin
On 07/26/2012 07:24 AM, Keith Christian wrote: I usually write a CMD.EXE script that in turn, runs cscript and its *.vbs file. Example: The following lines are a cmd batch file called bar.cmd @echo on echo.This is bar.cmd, a CMD.EXE script, which will be invoked by Cygwin echo.Run a vbscript called foo.vbs cscript foo.vbs echo.foo.vbs is complete echo.Done, now exiting bar.cmd exit ** First ** run bar.cmd within a CMD.EXE window to be sure it and foo.vbs are working properly outside of Cygwin. ** Second** from within Cygwin's bash (or other) shell, run bar.cmd: $ cmd /c bar.cmd Watch for output or results from foo.vbs during the run. == Keith There's no need to interject a needless additional process of cmd.exe. You can call cscript directly without a problem: Neptune:cat HelloWorld.vbs option explicit sub display (msg) wscript.echo msg end sub display Hello World from VBS! Neptune:cscript HelloWorld.vbs Microsoft (R) Windows Script Host Version 5.8 Copyright (C) Microsoft Corporation. All rights reserved. Hello World from VBS! Neptune: -- Andrew DeFaria http://defaria.com I put instant coffee in my microwave oven and almost went back in time. -- 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
automatically using pipe_byte for certain EXE's
HI I'm running into the pipe_byte problem while trying to use Visual-Studio's C compiler from inside cygwin. I'm running latest cygwin (from a few days ago). Specifically, I'm building LibreOffice on a 64-bit Windows7 box. Is there any way to trigger the pipe_byte option for certain executables? I'm trying to avoid having to dig around inside the hugely complex LibreOffice build scripts. Thanks, Noel Grandin -- 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: snapshot 20120724 sleep failure
On 7/26/2012 12:22 AM, Christopher Faylor wrote: On Wed, Jul 25, 2012 at 09:52:36PM +0200, marco atzeri wrote: on 1.7.17s(0.262/5/3) 20120724 autoconf test for sleep never completes checking whether sleep is declared... yes checking for working sleep... on 1.7.16 the test take 1 second Should be fixed in the upcoming snapshot. Thanks for the STC. cgf fixed on 20120725. Unfortunately I noticed a different issue, not present in 1.7.16. Running mc the program never rise and the terminal blanks. If the process is killed the terminal output is a mess. It seems some issue with tty control. 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: automatically using pipe_byte for certain EXE's
On 7/26/12 7:47 AM, Noel Grandin wrote: I'm running into the pipe_byte problem while trying to use Visual-Studio's C compiler from inside cygwin. I'm running latest cygwin (from a few days ago). Specifically, I'm building LibreOffice on a 64-bit Windows7 box. Is there any way to trigger the pipe_byte option for certain executables? I'm trying to avoid having to dig around inside the hugely complex LibreOffice build scripts. I still don't know why anyone wouldn't want to use pipe_byte all the time. signature.asc Description: OpenPGP digital signature
RE: automatically using pipe_byte for certain EXE's
Daniel Colascione wrote: I still don't know why anyone wouldn't want to use pipe_byte all the time. I think that was covered pretty explicitly by cgf in reply to you some time ago: http://cygwin.com/ml/cygwin/2012-04/msg00662.html -- 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
Those annoying joe1assis...@gmail.com responses to email sent here
It seems like we're not the only list plagued by the annoying bot responses to random messages sent to the Cygwin mailing list. Debian is seeing them too. I was hoping someone there would have figured out how to stop this stupidity but much of the thread devolved into even more off-topicness than the discussion of this problem. There didn't seem to be any solution that I could see. So, if you receive a message from joe1assis...@gmail.com (email purposely not obscured) in response to something said here then I am sorry. I wish I could figure out how to stop it but, so far, I can't. I asked people to send full headers but they have proved to be worthless. I do see that there seems to be a twitter account for this person though. Maybe we can ask them to stop there. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Maxima can't write to /dev/stdout
Corinna Vinschen writes: If you can nail that down to the actual calls and decisions clisp is doing, it might help to find the cause. I'm trying to, but it seems I still miss some dependencies to actually build clisp with debug information. Unfortunately the build is structured in a way that it tells you each missing dependency piecemeal after an ever increasing amount of stuff that it actually succeeded building. Right now it seems that it specifically wants BDB 4.5 rather than 4.8 even though configure said earlier it found BDB... I'll get there eventually, just not as fast as I had hoped for. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: automatically using pipe_byte for certain EXE's
On 7/26/12 9:34 AM, Adam Dinwoodie wrote: Daniel Colascione wrote: I still don't know why anyone wouldn't want to use pipe_byte all the time. I think that was covered pretty explicitly by cgf in reply to you some time ago: Cygwin still uses message pipes for ptys in pipe_byte mode, so the first of cgf's reasons doesn't apply. As for the way message pipes more closely mimic Linux pipes: I don't see it. What's the difference? And does it matter in practice? Can someone give me an actual example of a problem caused by using byte pipes in the non-pty case? I'm not aware of any. Since message pipes cause problems _in practice_ and byte pipes (which Cygwin lived with for many years) don't seem to cause problems _in practice_, pipe_byte should go away and pipe_byte behavior should be used unconditionally. signature.asc Description: OpenPGP digital signature
RE: automatically using pipe_byte for certain EXE's
Noel Grandin wrote: Is there any way to trigger the pipe_byte option for certain executables? I'm trying to avoid having to dig around inside the hugely complex- LibreOffice build scripts. I'm not sure I follow what you're after. You want Cygwin to recognize when it's setting up a pipe involving a specific executable, and to set that up as if it were using byte pipes rather than message pipes? I would imagine that would be difficult-to-impossible, for the same reason as trying to work out whether an executable links into cygwin1.dll. See cgf's explanation here: http://cygwin.com/ml/cygwin/2012-05/msg00192.html -- 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: environment variables mks toolkit - patch opportunity?
On Wed, Jul 25, 2012 at 5:54 PM, Christopher Faylor wrote: On Wed, Jul 25, 2012 at 05:43:52PM -0500, M. Sebastian Comella wrote: Hi all - I recently lost a good chunk of my day tracking down a Cygwin issue ultimately caused by an installation of IBM InfoSphere. The InfoSphere installer surreptitiously installed MKS Toolkit, which in turn set a bunch of environment variables that left Cygwin in a very unhelpful state: attempting to start Cygwin via its usual mintty shortcut would appear to hang, with mintty showing sh.exe in its title bar and little else. The cause of the issue is unfortunately not very obvious since there is no error message or other form of reporting. If I had realized that MKS Toolkit was being installed I might have had a fighting chance, but without that info I was in the dark. Fortunately, fixing the issue is pretty easy and is a matter of removing some Windows environment variables, as noted in this 2002-vintage thread: http://www.cygwin.com/ml/cygwin/2002-07/msg00734.html My question is this: is there an opportunity to patch something in Cygwin's startup chain to detect unsavory environment variables and warn users in some fashion? I'm not sure what package (or core process) could detect the situation and still get a warning off to the user before everything goes fubar. Putting a check into the installer may also be a viable solution, considering that the first thing I did was run the Cygwin installer again to see if it could repair things. I think I can take care of writing the patch, but I'd like some input on where it even belongs before I give it a shot. If you can provide an exact environment variable which caused a problem we can look into whether this is actually a problem in Cygwin, although it seems unlikely that it is. Cygwin is meant to read environment variables from... its environment. If you set them incorrectly bad things can happen. Cygwin is no different than UNIX in that regard. We're can't add special case handling for a bunch of random environment variables because someone reported that they think they might have caused a problem. We need more details than that. cgf The variables (as defined on my system) definitely caused a problem when attempting to start a Cygwin terminal. While they were present, attempting to open a Cygwin terminal via the usual mintty shortcut left me at an empty console screen with - sh.exe in the title bar, and no CPU or process activity to speak of. Removing them let the shell start normally again. No other changes on my part were necessary. Of the variables mentioned at the link, these variables seemed to be the most troublesome (MKS Toolkit values from my system in parens): SHELL (C:/PROGRA~1/MKSTOO~1/mksnt/sh.exe) TERM (dumb) TERMCAP (C:\PROGRA~1\MKSTOO~1\etc\termcap) TERMINFO (C:\PROGRA~1\MKSTOO~1\usr\lib\terminfo) MKS Toolkit set these variables when it was installed. It also prepended PATH with its own bin directories, so which sh would resolve to MKS's copy. Removing these variables and cleaning up the PATH took care of the core issue, but I decided to remove all of the entries referenced at the link to ensure I wouldn't run into other issues down the line. My concern is that I did not set these variables, an installer (that installed MKS Toolkit) did. Therefore I had no idea that new environment variables were introduced and causing issues, because there was no warning or output from Cygwin to even hint at the cause. I was chasing down everything in the BLODA, rebasing DLLs, etc, before I had the thought that the sh.exe in the terminal title might not be Cygwin's sh.exe. That's how I found the MKS install directory and ultimately that link about MKS-related issues. I'm not blaming cygwin or calling it a bug in cygwin, I'm suggesting that we add an environment sanity check somewhere to warn users if it looks like they've set some things that could cause trouble. It could even be so specific as to check for MKS Toolkit values. Or barring that, maybe it's as simple as adding an entry in the BLODA? Thanks, Sebastian. -- 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: Maxima can't write to /dev/stdout
On Thu, Jul 26, 2012 at 12:57 PM, Achim Gratz wrote: Corinna Vinschen writes: If you can nail that down to the actual calls and decisions clisp is doing, it might help to find the cause. I'm trying to, but it seems I still miss some dependencies to actually build clisp with debug information. Unfortunately the build is structured in a way that it tells you each missing dependency piecemeal after an ever increasing amount of stuff that it actually succeeded building. Right now it seems that it specifically wants BDB 4.5 rather than 4.8 even though configure said earlier it found BDB... I'll get there eventually, just not as fast as I had hoped for. Agreed. But note that clisp already should come with debug info. -g is required for the (disassemble) function to work. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Maxima can't write to /dev/stdout
Reini Urban writes: But note that clisp already should come with debug info. Where to look for it? I'm assuming that I need to step into the open function from the lisp open call via gdb to see where the trailing /1 gets stripped of from the file name pointed to by the symlink, so I'd need to have at least a symbol file with that entry point. -g is required for the (disassemble) function to work. You mean in CFLAGS for the build? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Maxima can't write to /dev/stdout
On Thu, Jul 26, 2012 at 2:10 PM, Achim Gratz wrote:
Reini Urban writes:
But note that clisp already should come with debug info.
Where to look for it? I'm assuming that I need to step into the open
function from the lisp open call via gdb to see where the trailing
/1 gets stripped of from the file name pointed to by the symlink, so
I'd need to have at least a symbol file with that entry point.
Don't know yet. I'm still busy at work.
-g is required for the (disassemble) function to work.
You mean in CFLAGS for the build?
Yes, and
src_install() {
# do not strip for (disassemble)
_CYGPORT_RESTRICT_strip_=1
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
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
regex doesn't work with g++
/tmp
$ cat foo.cpp
#include stdio.h
#include regex
int
main()
{
std::regex e(hello);
}
$ g++ -std=gnu++0x foo.cpp
/tmp/ccS3vCW7.o:foo.cpp:(.text$_ZNSt11basic_regexIcSt12regex_traitsIcEEC1EPKcj[std::basic_regexchar,
std::regex_traitschar ::basic_regex(char const*, unsigned
int)]+0x60): undefined reference to `std::basic_regexchar,
std::regex_traitschar ::_M_compile()'
collect2: ld returned 1 exit status
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure
--srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4
-C --datadir=/usr/share --infodir=/usr/share/info
--mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr
--enable-bootstrap --enable-version-specific-runtime-libs
--libexecdir=/usr/lib --enable-static --enable-shared
--enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld
--with-gnu-as --with-dwarf2 --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++
--enable-graphite --enable-lto --enable-java-awt=gtk --disable-symvers
--enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp
--enable-libada --enable-threads=posix --with-arch=i686
--with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4
CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake
GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.5.3 (GCC)
signature.asc
Description: OpenPGP digital signature
Re: Confusing, but not fatal bug....rmdir removed network dir (rename to .____00000hexnum/)
Corinna Vinschen wrote: Just try the latest developer snapshot from http://cygwin.com/snapshots/ It contains the patch. --- In running the rd * in bot of my Doc and Pictures dir, no dirs were renamed or deleted ... (FWIW, I have a recycle bin setup on my samba server, so the worse that should have happened would have been I'd find the tree removed and find the tree in the recycle bin...but all the dirs gave not-empty error messagesso nothing was deleted...(renamed)... Excellent! Thanks! Happy we were able to solve it... -- 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: Maxima can't write to /dev/stdout
On 2012-07-26 14:36, Reini Urban wrote:
On Thu, Jul 26, 2012 at 2:10 PM, Achim Gratz wrote:
Reini Urban writes:
-g is required for the (disassemble) function to work.
You mean in CFLAGS for the build?
Yes, and
src_install() {
# do not strip for (disassemble)
_CYGPORT_RESTRICT_strip_=1
Don't use internal structures. As documented in the manual, this should
be RESTRICT=strip, and should be defined in the toplevel.
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: regex doesn't work with g++
On 2012-07-26 16:46, Daniel Colascione wrote: $ g++ -std=gnu++0x foo.cpp /tmp/ccS3vCW7.o:foo.cpp:(.text$_ZNSt11basic_regexIcSt12regex_traitsIcEEC1EPKcj[std::basic_regexchar, std::regex_traitschar ::basic_regex(char const*, unsigned int)]+0x60): undefined reference to `std::basic_regexchar, std::regex_traitschar ::_M_compile()' collect2: ld returned 1 exit status GCC 4.5 does not have full support for C++0x. We'll need an upgrade to 4.7 for this to work. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: regex doesn't work with g++
On 7/26/2012 8:03 PM, Yaakov (Cygwin/X) wrote: On 2012-07-26 16:46, Daniel Colascione wrote: $ g++ -std=gnu++0x foo.cpp /tmp/ccS3vCW7.o:foo.cpp:(.text$_ZNSt11basic_regexIcSt12regex_traitsIcEEC1EPKcj[std::basic_regexchar, std::regex_traitschar ::basic_regex(char const*, unsigned int)]+0x60): undefined reference to `std::basic_regexchar, std::regex_traitschar ::_M_compile()' collect2: ld returned 1 exit status GCC 4.5 does not have full support for C++0x. We'll need an upgrade to 4.7 for this to work. That's surprising. The regex header was in TR1, from back in 2005. I'd have expected gcc to support it a long time ago. I'm also surprised to see that the header definition present and the libstdc++ implementation absent. That's what made me think there was something wrong with the toolchain. Thanks. signature.asc Description: OpenPGP digital signature
[ANNOUNCEMENT] Updated: bind-9.9.1-P2-1
The following package has been updated for the Cygwin distribution: *** bind-9.9.1-P2-1 ISC BIND is a suite of Domain Name Service (DNS) utilities. 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: swig 2.0.7-2
The following packages have been updated for the Cygwin distribution: *** swig-2.0.7-2 *** swig-debuginfo-2.0.7-2 SWIG reads annotated C/C++ header files and creates wrapper code (glue code) in order to make the corresponding C/C++ libraries available to the listed languages, or to extend C/C++ programs with a scripting language. This release adds Fedora's patchset to fix a number of issues with stock 2.0.7; version 1.3.40 remains available as the previous release for those who need it. -- 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: libexif-0.6.21-1
The following packages have been updated in the Cygwin distribution: *** libexif12-0.6.21-1 *** libexif-devel-0.6.21-1 *** libexif-debuginfo-0.6.21-1 (NEW) libexif is a C library for reading and writing EXIF metadata from and to image files. This is an update to the latest upstream release, which includes fixes for several security vulnerabilities (CVE-2012-2812, CVE-2012-2813, CVE-2012-2814, CVE-2012-2836, CVE-2012-2837, CVE-2012-2840, CVE-2012-2841). -- 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
Updated: bind-9.9.1-P2-1
The following package has been updated for the Cygwin distribution: *** bind-9.9.1-P2-1 ISC BIND is a suite of Domain Name Service (DNS) utilities. 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: swig 2.0.7-2
The following packages have been updated for the Cygwin distribution: *** swig-2.0.7-2 *** swig-debuginfo-2.0.7-2 SWIG reads annotated C/C++ header files and creates wrapper code (glue code) in order to make the corresponding C/C++ libraries available to the listed languages, or to extend C/C++ programs with a scripting language. This release adds Fedora's patchset to fix a number of issues with stock 2.0.7; version 1.3.40 remains available as the previous release for those who need it. -- 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: libexif-0.6.21-1
The following packages have been updated in the Cygwin distribution: *** libexif12-0.6.21-1 *** libexif-devel-0.6.21-1 *** libexif-debuginfo-0.6.21-1 (NEW) libexif is a C library for reading and writing EXIF metadata from and to image files. This is an update to the latest upstream release, which includes fixes for several security vulnerabilities (CVE-2012-2812, CVE-2012-2813, CVE-2012-2814, CVE-2012-2836, CVE-2012-2837, CVE-2012-2840, CVE-2012-2841). -- 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.
