[RFC] cygport: cross-compiling to embedded systems
Previous discussions (and my examples) on cross-compiling were focused
on other operating systems: MinGW, Linux, and Solaris. But there is
another use of cross-compiling: bare metal embedded systems.
Yesterday I built my first example of such: the AVR toolchain, a sample
build of which is now alongside the others:
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW/
Two issues arose when dealing with AVR:
1) cygport had been fully canonicalizing triplets, so avr became the
oh-so-informative avr-unknown-none. Fedora and Debian both use just
avr, as that naming is expected by the toolchain. These seem to be
common with embedded systems, so I changed cygport to remove -unknown
and -none from triplets.
2) While sysroots make sense for full-OS cross-compiles, where one needs
a location to hold a number of cross-compiled libraries arranged as if
on a native system, it seems not to be the case for embedded systems.
AFAICS with AVR, programs are more unique to the board and most
general-purpose software isn't meant to compile against avr-libc (or is
it the other way around?).
So having /usr/avr/sys-root/usr/{include,lib} seemed wrong for two
reasons: a) there is no comparable native /usr/{include,lib} on a
bare-metal system, and b) using a sysroot just for avr-libc seemed a bit
overkill. The alternative is to not build binutils/gcc with sysroots,
configure avr-libc (and same goes for newlib on $cpu-elf embeddeds) with
--prefix=/usr and let them install into /usr/$arch/{include,lib} as they
are designed. This is also how they are packaged on Fedora and Debian
(even though Fedora does use sysroots for mingw*).
Now I have ZERO experience with embedded systems, so I could be way off
on my assessments here. Can anybody that *does* have some experience
with these provide some further insight? Furthermore, for which systems
should this apply?
Yaakov
bug tracker discussion
Can I get a show of hands? How many package maintainers would like to have a bug tracker? One problem that I see immediately is that if we publicly adopt a bug tracker EVERY maintainer will have to use it. We can't expect a normal user to understand that they send email to the mailing list for binutils but use the bug tracker for screen. Another thing that I think is important is that we would have to adopt a standard for how we treat bugs. I'm not really keen on using the bug tracker as a knowledge base for end-user ssh problems. I don't think that's what a bug tracker is for. That's what a FAQ is for. And, in that line, how about per-package FAQs on the cygwin site? cg
Re: bug tracker discussion
2010/8/20 Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com: Can I get a show of hands? How many package maintainers would like to have a bug tracker? 1+ Yes, it's a lot more work for all parties, the server maintainer, the package maintainer and the user. And I believe it will suffer from the same problems as the almost unusable perl core tracker - everybody uses the mailing list for serious bugs. But at least it's an access point for other types of users, and maybe we'll get patches also. setup.exe got a lot of patches this way. And did I say I really like the github, google and trac trackers (issue lists), and hate RT and bugzilla. -- Reini Urban
Re: bug tracker discussion
On 8/20/2010 11:01 AM, Christopher Faylor wrote: Can I get a show of hands? How many package maintainers would like to have a bug tracker? -0 (Not in favor, but I'll monitor it if it's implemented.) We're still going to have to monitor the mailing list, so this just adds burden AFAICT. Does anyone really think we'll get fewer duplicate reports or better reports with a bug tracker? I don't. I expect it'll either not get used or get so full of cruft that it'll become unusable. And, in that line, how about per-package FAQs on the cygwin site? Isn't that what the /usr/share/doc/Cygwin files are for? What's the advantage of having a FAQ section on the cygwin site? How will it be maintained? -- David Rothenberger daver...@acm.org This is a test of the emergency broadcast system. Had there been an actual emergency, then you would no longer be here.
Re: bug tracker discussion
On Fri, Aug 20, 2010 at 08:11:31PM +0200, Reini Urban wrote: 2010/8/20 Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com: Can I get a show of hands? ?How many package maintainers would like to have a bug tracker? 1+ Yes, it's a lot more work for all parties, the server maintainer, the package maintainer and the user. And I believe it will suffer from the same problems as the almost unusable perl core tracker - everybody uses the mailing list for serious bugs. But at least it's an access point for other types of users, and maybe we'll get patches also. setup.exe got a lot of patches this way. I just read the bugzilla entries for bugzilla. I'm wondering why the then maintainer thought it was necessary to add patches to bugzilla. That's pretty nonstandard. And did I say I really like the github, google and trac trackers (issue lists), and hate RT and bugzilla. Once again, I'm not going to consider implementing something new for Cygwin. The rest of sourceware uses bugzilla and that's what we'll be using. cgf
Re: bug tracker discussion
On Fri, Aug 20, 2010 at 11:22:46AM -0700, David Rothenberger wrote: On 8/20/2010 11:01 AM, Christopher Faylor wrote: Can I get a show of hands? How many package maintainers would like to have a bug tracker? -0 (Not in favor, but I'll monitor it if it's implemented.) We're still going to have to monitor the mailing list, so this just adds burden AFAICT. Does anyone really think we'll get fewer duplicate reports or better reports with a bug tracker? I don't. I expect it'll either not get used or get so full of cruft that it'll become unusable. I agree with you 100% I personally think it's going to be a maintenance burden for me personally. If this is going to be useful, someone has to monitor it and keep it clean. And we'll have people clamoring for accounts. And people claiming that they can't get in. And, I'll see all of the same non-problems in the bug reports that we see in the list except when I close something as WONTFIX it will be reopened by some cranky user. That's just more stomach acid for me. However, if we can get someone to take on some of this burden, I'm willing to do what's necessary to tweak bugzilla. I don't want to stand in the way of progress if we everyone thinks this is a good idea. I respect the opinions of the maintainers here because they have demonstrated that they know what they are doing. I don't automatically give credence to random internet voices because they stress their points in insulting or forceful ways, no matter how much they want to be seen as experts. So, if a majority of maintainers think this is a good idea I'm much more likely to be convinced. (I don't speak for Corinna here, of course) And, in that line, how about per-package FAQs on the cygwin site? Isn't that what the /usr/share/doc/Cygwin files are for? What's the advantage of having a FAQ section on the cygwin site? How will it be maintained? Just a URL you can point to. cgf
Re: bug tracker discussion
On Fri, Aug 20, 2010 at 02:24:31PM -0400, Christopher Faylor wrote: On Fri, Aug 20, 2010 at 08:11:31PM +0200, Reini Urban wrote: 2010/8/20 Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com: Can I get a show of hands? ?How many package maintainers would like to have a bug tracker? 1+ Yes, it's a lot more work for all parties, the server maintainer, the package maintainer and the user. And I believe it will suffer from the same problems as the almost unusable perl core tracker - everybody uses the mailing list for serious bugs. But at least it's an access point for other types of users, and maybe we'll get patches also. setup.exe got a lot of patches this way. I just read the bugzilla entries for bugzilla. I'm wondering why the then setup.exe maintainer thought it was necessary to add patches to bugzilla. That's pretty nonstandard.
Re: bug tracker discussion
On Aug 20 14:31, Christopher Faylor wrote: On Fri, Aug 20, 2010 at 11:22:46AM -0700, David Rothenberger wrote: On 8/20/2010 11:01 AM, Christopher Faylor wrote: Can I get a show of hands? How many package maintainers would like to have a bug tracker? -0 (Not in favor, but I'll monitor it if it's implemented.) We're still going to have to monitor the mailing list, so this just adds burden AFAICT. Does anyone really think we'll get fewer duplicate reports or better reports with a bug tracker? I don't. I expect it'll either not get used or get so full of cruft that it'll become unusable. I agree with you 100% I personally think it's going to be a maintenance burden for me personally. If this is going to be useful, someone has to monitor it and keep it clean. And we'll have people clamoring for accounts. And people claiming that they can't get in. And, I'll see all of the same non-problems in the bug reports that we see in the list except when I close something as WONTFIX it will be reopened by some cranky user. That's just more stomach acid for me. However, if we can get someone to take on some of this burden, I'm willing to do what's necessary to tweak bugzilla. I don't want to stand in the way of progress if we everyone thinks this is a good idea. I respect the opinions of the maintainers here because they have demonstrated that they know what they are doing. I don't automatically give credence to random internet voices because they stress their points in insulting or forceful ways, no matter how much they want to be seen as experts. So, if a majority of maintainers think this is a good idea I'm much more likely to be convinced. (I don't speak for Corinna here, of course) You do, you just didn't know it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: bug tracker discussion
On Fri, 2010-08-20 at 14:01 -0400, Christopher Faylor wrote: Can I get a show of hands? How many package maintainers would like to have a bug tracker? Depends on how we use it. Don't get me wrong -- I like working with Bugzilla, and we do use it *internally* for Cygwin/X, but the list is still the support forum for end-users. It doesn't take much imagination to see what would happen if bugzilla was where users went first for support: it would be a full-time job (hmm...) just bug wrangling (translate: marking almost all the bugs RESOLVED NOTABUG, which is just a nice way of saying PEBKAC :-). The list is a better way of handling these sort of queries, where more people (including other end-users with more experience) are around to address them. OTOH, I do sometimes miss things on the main list due to the signal-to-noise ratio, which I imaging would be even greater for a maintainer with only a small number of packages. So using Bugzilla internally would be helpful. IOW: * Mailing list remains support forum for users. * All package maintainers have bugzilla accounts. 1) User sends issue to mailing list. 2) First responder (any maintainer who regularly answers questions on list) finds legitimate package bug. 3) First responder opens bug, pointing to ML with any further observations, assigned to relevant package maintainer (and maybe CC's OP if necessary). 4) Package maintainer addresses issue and closes bug. Using bugzilla also allows us to see if issues aren't being handled. If a bug is opened but maintainer does not respond, then that should give us an idea that the maintainer is MIA or the package is orphaned. Another thing that I think is important is that we would have to adopt a standard for how we treat bugs. I'm not really keen on using the bug tracker as a knowledge base for end-user ssh problems. I don't think that's what a bug tracker is for. That's what a FAQ is for. Agreed, especially as most end-user ssh problems aren't bugs in ssh. And, in that line, how about per-package FAQs on the cygwin site? That might very well be helpful. Yaakov
Re: bug tracker discussion
On Fri, 2010-08-20 at 13:51 -0500, Yaakov (Cygwin/X) wrote: OTOH, I do sometimes miss things on the main list due to the signal-to-noise ratio, which I imaging would be even greater for a maintainer with only a small number of packages. So using Bugzilla internally would be helpful. IOW: * Mailing list remains support forum for users. * All package maintainers have bugzilla accounts. 1) User sends issue to mailing list. 2) First responder (any maintainer who regularly answers questions on list) finds legitimate package bug. 3) First responder opens bug, pointing to ML with any further observations, assigned to relevant package maintainer (and maybe CC's OP if necessary). 4) Package maintainer addresses issue and closes bug. Then again, does this do anything that using cygwin-apps doesn't do? I'm not sure that it does. Yaakov
X Server no longer launches urxvtc-X
I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Today I upgraded my cygwin install and all my menu items like the above no longer work. (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X If, however, I open up a command window using rxvt and then enter the above Line (by copy and paste) it works fine. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. Does anyone know what has changed in cygwin and/or cygwinX that would cause this? Could this be related to the change to the windows working directory? TIA, Jay -- 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: X Server no longer launches urxvtc-X
On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Today I upgraded my cygwin install and all my menu items like the above no longer work. (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X If, however, I open up a command window using rxvt and then enter the above Line (by copy and paste) it works fine. My first guess was that the urxvt daemon (urxvtd-X) was not running, so the client failed. But if you can launch the client using some incantation, then that means the daemon is running. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. Ah. Here's the clue: launching a native win32 program fails. I bet this is related to the change in cygwin-1.7.6 where the cygwin current working directory and the win32 CWD are no longer automatically kept in sync (there are good reasons for this new behavior). This change has caused a number of problems, and it is not yet clear how they will be resolved. Stay tuned to the main cygwin list -- and meanwhile, revert to cygwin-1.7.5. -- Chuck -- 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: X Server no longer launches urxvtc-X
Chuck - thanks for the reply. This is what I had concluded but it's nice to get some confirmation. For the next few days I can live with 'manually' starting urxvtc-X via individual batch files. Thanks, Jay -Original Message- From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Charles Wilson Sent: Friday, August 20, 2010 10:54 AM To: cygwin-xfree@cygwin.com Subject: Re: X Server no longer launches urxvtc-X On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Today I upgraded my cygwin install and all my menu items like the above no longer work. (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X If, however, I open up a command window using rxvt and then enter the above Line (by copy and paste) it works fine. My first guess was that the urxvt daemon (urxvtd-X) was not running, so the client failed. But if you can launch the client using some incantation, then that means the daemon is running. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. Ah. Here's the clue: launching a native win32 program fails. I bet this is related to the change in cygwin-1.7.6 where the cygwin current working directory and the win32 CWD are no longer automatically kept in sync (there are good reasons for this new behavior). This change has caused a number of problems, and it is not yet clear how they will be resolved. Stay tuned to the main cygwin list -- and meanwhile, revert to cygwin-1.7.5. -- Chuck -- 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/ -- 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: X Server no longer launches urxvtc-X
On Aug 20 10:54, Charles Wilson wrote: On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Today I upgraded my cygwin install and all my menu items like the above no longer work. (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X If, however, I open up a command window using rxvt and then enter the above Line (by copy and paste) it works fine. My first guess was that the urxvt daemon (urxvtd-X) was not running, so the client failed. But if you can launch the client using some incantation, then that means the daemon is running. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. Ah. Here's the clue: launching a native win32 program fails. I bet this is related to the change in cygwin-1.7.6 where the cygwin current working directory and the win32 CWD are no longer automatically kept in sync (there are good reasons for this new behavior). Maybe that's related, but why? Does urxvtc-X start applications using CreateProcess? I'm asking because if they are started via fork/exec, the cwd for the child process gets set to the Cygwin cwd if the child is a native Win32 process, like Notepad. Cygwin executables OTOH shouldn't be affected, unless, again, they use native Win32 calls. And that also doesn't answer the question why starting /bin/urxvtc-X in the menu entries at the start of the mail are not working anymore, at least unless /bin/urxvtc-X is not a Cygwin application. This change has caused a number of problems, and it is not yet clear how they will be resolved. In the first place: http://cygwin.com/ml/cygwin/2010-08/msg00554.html and http://cygwin.com/ml/cygwin/2010-08/msg00562.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: X Server no longer launches urxvtc-X
Another data point, when I try: black EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -i rxvt successfully starts up but displays: /bin/find: failed to restore initial working directory: No such file or directory Before .bash_profile is invoked -Original Message- From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Friday, August 20, 2010 1:57 PM To: cygwin-xfree@cygwin.com Subject: Re: X Server no longer launches urxvtc-X On Aug 20 10:54, Charles Wilson wrote: On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Today I upgraded my cygwin install and all my menu items like the above no longer work. (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X If, however, I open up a command window using rxvt and then enter the above Line (by copy and paste) it works fine. My first guess was that the urxvt daemon (urxvtd-X) was not running, so the client failed. But if you can launch the client using some incantation, then that means the daemon is running. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. Ah. Here's the clue: launching a native win32 program fails. I bet this is related to the change in cygwin-1.7.6 where the cygwin current working directory and the win32 CWD are no longer automatically kept in sync (there are good reasons for this new behavior). Maybe that's related, but why? Does urxvtc-X start applications using CreateProcess? I'm asking because if they are started via fork/exec, the cwd for the child process gets set to the Cygwin cwd if the child is a native Win32 process, like Notepad. Cygwin executables OTOH shouldn't be affected, unless, again, they use native Win32 calls. And that also doesn't answer the question why starting /bin/urxvtc-X in the menu entries at the start of the mail are not working anymore, at least unless /bin/urxvtc-X is not a Cygwin application. This change has caused a number of problems, and it is not yet clear how they will be resolved. In the first place: http://cygwin.com/ml/cygwin/2010-08/msg00554.html and http://cygwin.com/ml/cygwin/2010-08/msg00562.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X Server no longer launches urxvtc-X
Please dont top-post. On Aug 20 14:14, Jay Goldman wrote: Another data point, when I try: black EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -i rxvt successfully starts up but displays: /bin/find: failed to restore initial working directory: No such file or directory Before .bash_profile is invoked Works for me without such a message. Do you know from where find is called? -Original Message- From: Corinna Vinschen On Aug 20 10:54, Charles Wilson wrote: On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Doesn't work for me either, but has apparently nothing to do with the CWD issue. This looks more like a rebase problem. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. I tried this as well now, and both menu entries work for me. Maybe the difference is the Cygwin DLL. Can you please try the latest Cygwin DLL from the developer snapshots at http://cygwin.com/snapshots/ and report back if this works better for you? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: X Server no longer launches urxvtc-X
When I just replace the cygwin1.dll bash, \bin\bash.exe -login -i From cmd window results in: The procedure entry point CreateProcessAsUserW could not be located in the dynamic link library KERNEL32.dll I have no idea where find is being invoked when I execute rxvt, since it is invoked before .bash_profile is invoked. -Original Message- On August 20, 2010 3:06 PM, Corinna Vinschen wrote: Please dont top-post. On Aug 20 14:14, Jay Goldman wrote: Another data point, when I try: black EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -i rxvt successfully starts up but displays: /bin/find: failed to restore initial working directory: No such file or directory Before .bash_profile is invoked Works for me without such a message. Do you know from where find is called? -Original Message- From: Corinna Vinschen On Aug 20 10:54, Charles Wilson wrote: On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Doesn't work for me either, but has apparently nothing to do with the CWD issue. This looks more like a rebase problem. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. I tried this as well now, and both menu entries work for me. Maybe the difference is the Cygwin DLL. Can you please try the latest Cygwin DLL from the developer snapshots at http://cygwin.com/snapshots/ and report back if this works better for you? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog fhandler_disk_file ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-20 08:52:25 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc syscalls.cc Log message: * fhandler_disk_file.cc (fhandler_disk_file::fstatvfs): Revert usage of get_stat_handle () to get_handle (). Add comment to explain why. * syscalls.cc (statvfs): Drop using PC_KEEP_HANDLE. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4999r2=1.5000 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.332r2=1.333 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.563r2=1.564
src/winsup/cygwin ChangeLog fhandler_disk_file ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-20 11:18:58 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc path.cc Log message: * fhandler_disk_file.cc (readdir_check_reparse_point): Rename from is_volume_mountpoint. Return valid d_type value for underlying reparse point type. (readdir_get_ino): Don't rely on the handle set in pc.check. Open file here if pc.handle() is NULL. (fhandler_disk_file::readdir_helper): Try to set a correct d_type value more diligent. (fhandler_disk_file::readdir): Don't reset dirent_set_d_ino unless we're really sure it's due to an untrusted FS. Simplify usage of FileAttributes, which is 0 if buf is NULL, anyway. Set d_type correctly for faked . and .. entries. Improve debug output. * path.cc (symlink_info::check): Don't keep handle to volume mount point open. Explain why. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5000r2=1.5001 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.333r2=1.334 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.601r2=1.602
src/winsup/cygwin ChangeLog include/endian.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-20 12:18:47 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include: endian.h Log message: * endian.h (htobe16, htobe32, htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64, le16toh, le32toh, le64toh): Define. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5001r2=1.5002 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/endian.h.diff?cvsroot=srcr1=1.5r2=1.6
src/winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-20 14:29:56 Modified files: winsup/cygwin : ChangeLog path.cc Log message: * path.cc (path_conv::check): Close handle in conv_handle if we're following a symlink. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5002r2=1.5003 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.602r2=1.603
winsup/cygwin ChangeLog cygthread.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-08-20 15:28:28 Modified files: cygwin : ChangeLog cygthread.cc Log message: * cygthread.cc: Update copyright. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5003r2=1.5004 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/cygthread.cc.diff?cvsroot=uberbaumr1=1.81r2=1.82
Re: [ANNOUNCEMENT] Updated: vim-7.3.003-1
On Aug 19 15:17, David Rothenberger wrote: On 8/19/2010 11:54 AM, Corinna Vinschen wrote: I have updated the version of vim on cygwin.com to 7.3.003-1. This is an update to the new upstream version 7.3, including the first three patchsets. Cygwin Vim builds from the vanilla sources. After updating, /usr/bin/vi no longer exists. Is this intentional? No. If you look into the vim-7.3.003-1 tar archive, you'll see that there's still a symlink called vi: bash$ tar tvjf vim-7.3.003-1.tar.bz2 usr/bin drwxr-xr-x corinna/vinschen 0 2010-08-19 13:24 usr/bin/ lrwxrwxrwx corinna/vinschen 0 2010-08-19 13:24 usr/bin/vi - vim-nox.exe -rwxr-xr-x corinna/vinschen 2084 2010-08-19 13:23 usr/bin/vimtutor lrwxrwxrwx corinna/vinschen0 2010-08-19 13:24 usr/bin/ex - vim-nox.exe -rwxr-xr-x corinna/vinschen 13838 2010-08-19 13:24 usr/bin/xxd.exe -rwxr-xr-x corinna/vinschen 1548814 2010-08-19 13:23 usr/bin/vim-nox.exe I don't know why it disappeared for 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: cygwin 1.7.6: df shows wrong (different?) drive information
On Aug 19 23:14, Rolf Campbell wrote: When I run df -h dir where dir is part of a native-NTFS-mounted-drive, then df prints details about the root drive (not the mounted drive). That should be fixed in CVS now. Thanks for the report, 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: rlwrap is ancient -- maintained?
On Aug 19 17:11, Larry Hall (Cygwin) wrote: On 8/19/2010 5:02 PM, Daniel Colascione wrote: The version of rlwrap in Cygwin is very old; the manpage dates it to 2005. Is the package still maintained? If not, does it need a new maintainer? :) The listed maintainer is Mauricio Antune but my admittedly limited search for any recent activity on the list from him didn't turn up anything. Perhaps he's moved on. Or maybe he's still here lurking. It makes sense to check. Mauricio, you here? If so, are you willing to update rlwrap? Would you prefer Daniel take over? Mauricio only ever provided the rlwrap package back in 2006, and there was no mail from him after 2006. I Bcc'ed him, in case he wants to chime in. Other than that, if we don't hear from Mauricio within 7 days, you can take over maintainership, Daniel. 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 tracker
On 19.08.2010 23:11, Eric Blake wrote: On 08/19/2010 01:59 PM, Jeremy Bopp wrote: Of course the quality of the defect tracker is directly related to the effort the maintainers put in to keep it relatively pruned and organized. Maybe that is too much to expect for most maintainers at this time. Bingo. That's why I'm perfectly happy with mailing lists and no extra burden of a web-based tracker for the packages I maintain on my spare time. Why add overhead to a process that already works for me? Agree. I use Thunderbird as MUA. It allow filtering message by many condition. For example if I interesting in Bash or Emacs I make filter that check Subject for entry 'bash' or 'emacs' keyword and STAR this letter in folder to get more attention and copy to 'Important' folder as I always chech this directory. So if someone properly report issue/news I get attention. For search for already reported issue I use GMANE: http://dir.gmane.org/gmane.os.cygwin or in google: site:http://blog.gmane.org/gmane.os.cygwin KEYWORD site:http://news.gmane.org/gmane.os.cygwin KEYWORD So with mail list you can be NOTIFIED in realtime and effectively SEARCH for already reported issue. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etex pdfetex language.def-translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). -- http://rrt.sc3d.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: [ANNOUNCEMENT] Updated: vim-7.3.003-1
* Corinna Vinschen (Fri, 20 Aug 2010 10:24:33 +0200) On Aug 19 15:17, David Rothenberger wrote: On 8/19/2010 11:54 AM, Corinna Vinschen wrote: I have updated the version of vim on cygwin.com to 7.3.003-1. This is an update to the new upstream version 7.3, including the first three patchsets. Cygwin Vim builds from the vanilla sources. After updating, /usr/bin/vi no longer exists. Is this intentional? No. If you look into the vim-7.3.003-1 tar archive, you'll see that there's still a symlink called vi: bash$ tar tvjf vim-7.3.003-1.tar.bz2 usr/bin drwxr-xr-x corinna/vinschen 0 2010-08-19 13:24 usr/bin/ lrwxrwxrwx corinna/vinschen 0 2010-08-19 13:24 usr/bin/vi - vim-nox.exe -rwxr-xr-x corinna/vinschen 2084 2010-08-19 13:23 usr/bin/vimtutor lrwxrwxrwx corinna/vinschen0 2010-08-19 13:24 usr/bin/ex - vim-nox.exe -rwxr-xr-x corinna/vinschen 13838 2010-08-19 13:24 usr/bin/xxd.exe -rwxr-xr-x corinna/vinschen 1548814 2010-08-19 13:23 usr/bin/vim-nox.exe I don't know why it disappeared for you. Weird. On two installations (Windows XP and 2008 R2) vi and ex exist. On my main Windows 7 it's gone (not that I ever used vi for vim). I got a warning during setup that setup.exe could not unpack these files because they were in use (but they weren't) and after clicking on retry the installation continued. In setup.log.full I can see: unlink F:\cygwin\bin/vi unlink F:\cygwin\bin/ex [...] Installing file cygfile:///usr/bin/vi io_stream::mklink (cygfile:///usr/bin/vi-cygfile://vim-nox.exe) Installing file cygfile:///usr/bin/ex io_stream::mklink (cygfile:///usr/bin/ex-cygfile://vim-nox.exe) ...but that's excactly what I see on the two other installations, too. The only difference I can see is that the other installations are on a NTFS volume and this on is FAT32. Thorsten -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 8/20/2010 5:29 AM, Reuben Thomas wrote: On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etex pdfetex language.def-translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). We don't need no stinkin' issue tracker. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On Aug 19 18:11, Rolf Campbell wrote: On 2010-08-19 13:05, Corinna Vinschen wrote: For further testing purposes I have uploaded a new cygwin1.dll which a) adds debug output in readdir() which prints DOS attributes as well as evaluated d_type value for each readdir entry to strace, and b) which is heavily tweaked to try harder to get a useful d_type value without compromising speed. The patch is attached, for the records. Rolf, please try the following Cygwin DLL: [...] It still fails in the exact same way. I attached strace output. Thanks for the new strace. After some more experimenting I was finally able to reproduce the issue. The other problem you reported, about df(*), lead me onto the right track. I've checked my changes in to CVS. For testing I provided another test DLL: http://cygwin.de/cygwin-ug-177/new-cygwin1.dll.bz2 (md5sum compressed 3a354b276e1506548bf382620ef26e82) (md5sum uncompressed 605c25c83ba9cd32bcebe77b7dfec99c) Thanks, Corinna (*) http://cygwin.com/ml/cygwin/2010-08/msg00611.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 8/20/2010 7:53 AM, Steve Holden wrote: On 8/20/2010 5:29 AM, Reuben Thomas wrote: On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etexpdfetex language.def -translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). We don't need no stinkin' issue tracker. It struck me that this remark might be ambiguous, or even be regarded as offensive by some. My intention was to highlight the fact that issues will (eventually) be re-raised thanks to the phenomenal group memory of this list. But of course the issue might have had attention (or at least been resolved as wontfix with appropriate discussion) in an issue tracker. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
On Aug 19 19:31, Pedro Izecksohn wrote: ChangeLog entry: 2010-08-19 Pedro Izecksohn pedro.izecks...@... * endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32) (htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64) (le16toh, le32toh, le64toh): Macros defined. I modified endian.h again: Thanks. On second thought I redefined _BSD_SOURCE to __USE_BSD and disabled it, same as a few lines above. Patch applied. 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: [ANNOUNCEMENT] Updated: vim-7.3.003-1
On Aug 20 13:53, Thorsten Kampe wrote: * Corinna Vinschen (Fri, 20 Aug 2010 10:24:33 +0200) On Aug 19 15:17, David Rothenberger wrote: On 8/19/2010 11:54 AM, Corinna Vinschen wrote: I have updated the version of vim on cygwin.com to 7.3.003-1. This is an update to the new upstream version 7.3, including the first three patchsets. Cygwin Vim builds from the vanilla sources. After updating, /usr/bin/vi no longer exists. Is this intentional? No. If you look into the vim-7.3.003-1 tar archive, you'll see that there's still a symlink called vi: bash$ tar tvjf vim-7.3.003-1.tar.bz2 usr/bin drwxr-xr-x corinna/vinschen 0 2010-08-19 13:24 usr/bin/ lrwxrwxrwx corinna/vinschen 0 2010-08-19 13:24 usr/bin/vi - vim-nox.exe -rwxr-xr-x corinna/vinschen 2084 2010-08-19 13:23 usr/bin/vimtutor lrwxrwxrwx corinna/vinschen0 2010-08-19 13:24 usr/bin/ex - vim-nox.exe -rwxr-xr-x corinna/vinschen 13838 2010-08-19 13:24 usr/bin/xxd.exe -rwxr-xr-x corinna/vinschen 1548814 2010-08-19 13:23 usr/bin/vim-nox.exe I don't know why it disappeared for you. Weird. On two installations (Windows XP and 2008 R2) vi and ex exist. On my main Windows 7 it's gone (not that I ever used vi for vim). I got a warning during setup that setup.exe could not unpack these files because they were in use (but they weren't) and after clicking on retry the installation continued. In setup.log.full I can see: unlink F:\cygwin\bin/vi unlink F:\cygwin\bin/ex [...] Installing file cygfile:///usr/bin/vi io_stream::mklink (cygfile:///usr/bin/vi-cygfile://vim-nox.exe) Installing file cygfile:///usr/bin/ex io_stream::mklink (cygfile:///usr/bin/ex-cygfile://vim-nox.exe) ...but that's excactly what I see on the two other installations, too. The only difference I can see is that the other installations are on a NTFS volume and this on is FAT32. Strange. I just created a FAT32 partition on W7 and did a base install including vim. Then I started setup again and reinstalled just the vim package. That worked fine as well. So it has nothing to do with the FS, nor with the OS. 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: cron fails to start as a service in Win2k3R2 64bit
- Original Message - From: Blaine Miller To: cygwin Sent: Thursday, August 19, 2010 17:47 | The only way I've been able to get cron running is manually by starting | the crond via execution of cron.exe. | | Attached are my cygcheck.txt and crontab. | | I get the following error after I install and start the cron service... | | cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: Did you use cron-config to configure cron? If the problem persists run cronbug and send the output as an attachment. Pierre -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 08/20/2010 06:00 AM, Steve Holden wrote: My intention was to highlight the fact that issues will (eventually) be re-raised thanks to the phenomenal group memory of this list. But of course the issue might have had attention (or at least been resolved as wontfix with appropriate discussion) in an issue tracker. Or, more likely, sat for four years with no change in status, because the same person who hasn't had time to fix the tex package also hasn't had time to visit a tracker web page. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: vim-7.3.003-1
* Corinna Vinschen (Fri, 20 Aug 2010 14:37:08 +0200) I just created a FAT32 partition on W7 and did a base install including vim. Then I started setup again and reinstalled just the vim package. That worked fine as well. So it has nothing to do with the FS, nor with the OS. I reinstalled vim and got the exact same message again (Unable to extract /usr/bin/vi -- the file is use.). A simultaneous process monitor log shows that CreateFile operations result in DELETE PENDING (Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a). Clicking two times on Retry (without changing anything else) let's the installation continue. I ran Process Explorer and it looks like zsh has handles open to vi, vim, view and vimdiff - although these executables are definitely not running. Thorsten -- 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: [ANNOUNCEMENT] Updated: vim-7.3.003-1
On 8/20/2010 9:38 AM, Thorsten Kampe wrote: * Corinna Vinschen (Fri, 20 Aug 2010 14:37:08 +0200) I just created a FAT32 partition on W7 and did a base install including vim. Then I started setup again and reinstalled just the vim package. That worked fine as well. So it has nothing to do with the FS, nor with the OS. I reinstalled vim and got the exact same message again (Unable to extract /usr/bin/vi -- the file is use.). A simultaneous process monitor log shows that CreateFile operations result in DELETE PENDING (Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a). Clicking two times on Retry (without changing anything else) let's the installation continue. I ran Process Explorer and it looks like zsh has handles open to vi, vim, view and vimdiff - although these executables are definitely not running. The shell has probably cached them to speed up command lookup and dispatch. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 8/20/2010 9:22 AM, Eric Blake wrote: On 08/20/2010 06:00 AM, Steve Holden wrote: My intention was to highlight the fact that issues will (eventually) be re-raised thanks to the phenomenal group memory of this list. But of course the issue might have had attention (or at least been resolved as wontfix with appropriate discussion) in an issue tracker. Or, more likely, sat for four years with no change in status, because the same person who hasn't had time to fix the tex package also hasn't had time to visit a tracker web page. Yes, ultimately it's all down to the availability of effort. We have similar problems in the Python world (where we use roundup). Though a small team has recently started to address the question of stalled issues, there just isn't enough effort to get to everything that comes in and still keep the language moving forward. I'd like to take this opportunity to say how much I personally appreciate the availability of Cygwin - I use it daily, and it makes the computing experience on Windows far more bearable and productive than it otherwise would be. I'll happily overlook the occasional crabby reply to a thoughtless comment, given the amazing work that the team collectively produces. regards Steve -- Steve HoldenChairman, Python Software Foundation The Python Community Conference http://python.org/psf/ Watch PyCon on video now! http://pycon.blip.tv/ -- 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: [ANNOUNCEMENT] Updated: vim-7.3.003-1
* Thorsten Kampe (Fri, 20 Aug 2010 15:38:26 +0200) I reinstalled vim and got the exact same message again (Unable to extract /usr/bin/vi -- the file is use.). A simultaneous process monitor log shows that CreateFile operations result in DELETE PENDING (Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a). Clicking two times on Retry (without changing anything else) let's the installation continue. I ran Process Explorer and it looks like zsh has handles open to vi, vim, view and vimdiff - although these executables are definitely not running. Okay, coming closer (and getting weirder): type jed[1] creates handles to vi, vim, view and vimdiff (but not in bash). Zsh is the latest available one via setup.exe (zsh 4.3.10-dev-2). It still doesn't explain why only the creation of the symlinks (vi and ex) fails and not the replacement of vim itself. Thorsten [1] Part of... type jed /dev/null DEFAULT_EDITOR=jed || DEFAULT_EDITOR=vim ...im my .zshrc -- 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: [ANNOUNCEMENT] Updated: vim-7.3.003-1
On Aug 20 16:21, Thorsten Kampe wrote: * Thorsten Kampe (Fri, 20 Aug 2010 15:38:26 +0200) I reinstalled vim and got the exact same message again (Unable to extract /usr/bin/vi -- the file is use.). A simultaneous process monitor log shows that CreateFile operations result in DELETE PENDING (Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a). Clicking two times on Retry (without changing anything else) let's the installation continue. I ran Process Explorer and it looks like zsh has handles open to vi, vim, view and vimdiff - although these executables are definitely not running. Okay, coming closer (and getting weirder): Not weird at all. I could track this down to a point in Cygwin where it neglects to close a handle to a symlink when instructed to follow symlinks to their target. I checked in a patch. Please test the DLL I uploaded at http://cygwin.de/cygwin-ug-177/newer-cygwin1.dll.bz2 (md5sum compressed 5eab6680538279206bf23c54244825d2) (md5sum uncompressed e4833a601edad1571a9c6e0352a8e381) which contains the fix. This should not leave the stray handles to vi, vim, etc in zsh. And the side-effect should be that setup.exe does not complain anymore in the original scenario. 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: [ANNOUNCEMENT] Updated: vim-7.3.003-1
* Corinna Vinschen (Fri, 20 Aug 2010 16:33:17 +0200) On Aug 20 16:21, Thorsten Kampe wrote: * Thorsten Kampe (Fri, 20 Aug 2010 15:38:26 +0200) I reinstalled vim and got the exact same message again (Unable to extract /usr/bin/vi -- the file is use.). A simultaneous process monitor log shows that CreateFile operations result in DELETE PENDING (Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a). Clicking two times on Retry (without changing anything else) let's the installation continue. I ran Process Explorer and it looks like zsh has handles open to vi, vim, view and vimdiff - although these executables are definitely not running. Okay, coming closer (and getting weirder): Not weird at all. I could track this down to a point in Cygwin where it neglects to close a handle to a symlink when instructed to follow symlinks to their target. I checked in a patch. Please test the DLL I uploaded at http://cygwin.de/cygwin-ug-177/newer-cygwin1.dll.bz2 (md5sum compressed 5eab6680538279206bf23c54244825d2) (md5sum uncompressed e4833a601edad1571a9c6e0352a8e381) which contains the fix. This should not leave the stray handles to vi, vim, etc in zsh. And the side-effect should be that setup.exe does not complain anymore in the original scenario. Yes, the evil handles are gone. Thanks, Thorsten -- 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: cron fails to start as a service in Win2k3R2 64bit
Pierre, I'm trying it now. No, I didn't know this was the preferred method of installing cron as a service. I've been installing/reinstalling everything from the cygwin *setup.exe*. I've looked at the log files and they seem pretty unremarkable. I'll run cronbug after I try the cron-config command. Thanks very much for your time and support... Blaine Pierre A. Humblet wrote: - Original Message - From: Blaine Miller To: cygwin Sent: Thursday, August 19, 2010 17:47 | The only way I've been able to get cron running is manually by starting | the crond via execution of cron.exe. | | Attached are my cygcheck.txt and crontab. | | I get the following error after I install and start the cron service... | | cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: Did you use cron-config to configure cron? If the problem persists run cronbug and send the output as an attachment. Pierre -- 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
Cygwin 1.7 problems on Windows XP SP2
Hi, I recently installed the latest version of cygwin after using previous (1.5) versions without problems. Almost nothing works on 1.7 and even after reinstalling my machine I still have the same problem. My machine runs Windows XP SP2. My install.log.full has a lot of errors like this one: 3879146 [main] bash 3716 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 4 [main] bash 3872 C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x6D, top 0x74, reserve_size 454656, allocsize 458752, page_const 4096 This doesn't only happen with bash, it was also happening with other apps such as rsync before I reinstalled the operating system. Any ideas or hints for diagnosing this? Can I acquire an older setup.exe and try installing a previous version of cygwin? Full log is at http://foo.is/~baldur/setup.log.full.gz Baldur -- 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: [ANNOUNCEMENT] Updated: vim-7.3.003-1
On Aug 20 17:09, Thorsten Kampe wrote: * Corinna Vinschen (Fri, 20 Aug 2010 16:33:17 +0200) On Aug 20 16:21, Thorsten Kampe wrote: * Thorsten Kampe (Fri, 20 Aug 2010 15:38:26 +0200) I reinstalled vim and got the exact same message again (Unable to extract /usr/bin/vi -- the file is use.). A simultaneous process monitor log shows that CreateFile operations result in DELETE PENDING (Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a). Clicking two times on Retry (without changing anything else) let's the installation continue. I ran Process Explorer and it looks like zsh has handles open to vi, vim, view and vimdiff - although these executables are definitely not running. Okay, coming closer (and getting weirder): Not weird at all. I could track this down to a point in Cygwin where it neglects to close a handle to a symlink when instructed to follow symlinks to their target. I checked in a patch. Please test the DLL I uploaded at http://cygwin.de/cygwin-ug-177/newer-cygwin1.dll.bz2 (md5sum compressed 5eab6680538279206bf23c54244825d2) (md5sum uncompressed e4833a601edad1571a9c6e0352a8e381) which contains the fix. This should not leave the stray handles to vi, vim, etc in zsh. And the side-effect should be that setup.exe does not complain anymore in the original scenario. Yes, the evil handles are gone. Thanks for testing, 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: cron fails to start as a service in Win2k3R2 64bit
Pierre, I tried using cron-config and it failed. Please find attached my cronbug.txt... Thanks again for your continued time and assistance. Blaine Pierre A. Humblet wrote: - Original Message - From: Blaine Miller To: cygwin Sent: Thursday, August 19, 2010 17:47 | The only way I've been able to get cron running is manually by starting | the crond via execution of cron.exe. | | Attached are my cygcheck.txt and crontab. | | I get the following error after I install and start the cron service... | | cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: Did you use cron-config to configure cron? If the problem persists run cronbug and send the output as an attachment. Pierre -- 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 Current version -rwxr-xr-x 1 Administrator root 5304 2010-02-15 18:14 /usr/share/doc/Cygwin/cron-4.1-59.README Running crons: 2116 12116 2116? 500 13:49:24 /usr/sbin/cron I366421162116 3664? 500 05:00:01 /usr/sbin/cron I389621162116 3896? 500 05:00:01 /usr/sbin/cron I346421162116 3464? 500 06:00:01 /usr/sbin/cron Sendmail: lrwxrwxrwx 1 Administrator None 16 2010-08-11 09:48 /usr/sbin/sendmail - /usr/bin/cronlog Crontabs: -rw-r- 1 Administrator root 599 2010-08-19 14:17 /var/cron/tabs/Administrator -rw-r- 1 500 0 599 2010-08-19 14:17 /var/cron/tabs/Administrator cron.log: -rw-r--r-- 1 SYSTEM root 2456 2010-08-19 14:42 /var/log/cron.log cron.pid: -rw-r--r-- 1 Administrator None 5 2010-08-19 13:49 /var/run/cron.pid Crontab: # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.yRr11boUdm installed on Thu Aug 19 14:17:23 2010) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) 00 05 * * * /cygdrive/c/scripts/xfer_vvm_mysql.sh 00 05 * * * /cygdrive/c/scripts/xfer_vvm_ora.sh 00 05 * * * /cygdrive/c/scripts/xfer_nab_vnnab.sh 00 10 * * * /cygdrive/c/scripts/xfer_nab_csnab.sh 00 06 * * * /cygdrive/c/scripts/xfer_dellsrv20.sh 00 06 * * * /cygdrive/c/scripts/xfer_directory.sh 00 06 * * * /cygdrive/c/scripts/xfer_perforce.sh 00 06 * * 2 /cygdrive/c/scripts/xfer_fileserv.sh Windows Application Events log: 2010/08/11 09:48:28 [Administrator] crontab: PID 1736: (Administrator) LIST (Administrator) 2010/08/13 13:50:48 [Administrator] crontab: PID 1904: (Administrator) LIST (Administrator) 2010/08/13 13:59:11 [Administrator] crontab: PID 1900: (Administrator) BEGIN EDIT (Administrator) 2010/08/13 14:14:47 [Administrator] crontab: PID 1900: (Administrator) REPLACE (Administrator) 2010/08/13 14:14:47 [Administrator] crontab: PID 1900: (Administrator) END EDIT (Administrator) 2010/08/13 14:24:51 [Administrator] crontab: PID 680: (Administrator) BEGIN EDIT (Administrator) 2010/08/13 14:30:18 [Administrator] crontab: PID 680: (Administrator) REPLACE (Administrator) 2010/08/13 14:30:18 [Administrator] crontab: PID 680: (Administrator) END EDIT (Administrator) 2010/08/13 14:30:47 [Administrator] crontab: PID 2972: (Administrator) LIST (Administrator) 2010/08/13 15:09:48 [Administrator] crontab: PID 1028: (Administrator) LIST (Administrator) 2010/08/14 15:13:12 [Administrator] crontab: PID 3916: (Administrator) LIST (Administrator) 2010/08/14 15:17:12 [Administrator] crontab: PID 2732: (Administrator) BEGIN EDIT (Administrator) 2010/08/14 15:17:31 [Administrator] crontab: PID 2732: (Administrator) REPLACE (Administrator) 2010/08/14 15:17:31 [Administrator] crontab: PID 2732: (Administrator) END EDIT (Administrator) 2010/08/16 06:16:42 [Administrator] crontab: PID 368: (Administrator) LIST (Administrator) 2010/08/16 06:31:33 [Administrator] crontab: PID 3648: (Administrator) LIST (Administrator) 2010/08/16 07:43:33 [Administrator] crontab: PID 4008: (Administrator) LIST (Administrator) 2010/08/17 08:04:30 [Administrator] crontab: PID 2604: (Administrator) LIST (Administrator) 2010/08/17 08:04:51 [Administrator] crontab: PID 2468: (Administrator) BEGIN EDIT (Administrator) 2010/08/17 08:05:12 [Administrator] crontab: PID 2468: (Administrator) REPLACE (Administrator) 2010/08/17 08:05:12 [Administrator] crontab: PID 2468: (Administrator) END EDIT (Administrator) 2010/08/17 08:52:31 [Administrator] crontab: PID 3236: (Administrator) LIST (Administrator) 2010/08/17 08:52:40 [Administrator] crontab: PID 640: (Administrator) BEGIN EDIT (Administrator) 2010/08/17 08:53:31 [Administrator] crontab: PID 640: (Administrator) REPLACE (Administrator) 2010/08/17 08:53:31 [Administrator] crontab: PID 640: (Administrator) END EDIT (Administrator) 2010/08/17 08:54:16 [Administrator] crontab: PID 2668: (Administrator) LIST (Administrator) 2010/08/17 08:54:52 [Administrator] crontab: PID 3512: (Administrator) BEGIN EDIT
Re: Cygwin 1.7 problems on Windows XP SP2
On 8/20/2010 11:28 AM, Baldur Gislason wrote: Hi, I recently installed the latest version of cygwin after using previous (1.5) versions without problems. Almost nothing works on 1.7 and even after reinstalling my machine I still have the same problem. My machine runs Windows XP SP2. My install.log.full has a lot of errors like this one: 3879146 [main] bash 3716 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 4 [main] bash 3872 C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x6D, top 0x74, reserve_size 454656, allocsize 458752, page_const 4096 This doesn't only happen with bash, it was also happening with other apps such as rsync before I reinstalled the operating system. Any ideas or hints for diagnosing this? Can I acquire an older setup.exe and try installing a previous version of cygwin? Full log is at http://foo.is/~baldur/setup.log.full.gz If you look in the email archives for messages with similar complaints, you'll find that this kind of problem is most commonly the result of one of two things: 1. You need to install the rebase package, read its README, and run rebaseall as prescribed. 2. http://cygwin.com/acronyms/#BLODA -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ 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: Cygwin: texi2dvi stumbles over texinfo.tex
On Fri, Aug 20, 2010 at 08:00:14AM -0400, Steve Holden wrote: On 8/20/2010 7:53 AM, Steve Holden wrote: On 8/20/2010 5:29 AM, Reuben Thomas wrote: On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etex pdfetex language.def -translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). We don't need no stinkin' issue tracker. It struck me that this remark might be ambiguous, or even be regarded as offensive by some. I found it tedious actually, and wondered if you were going to now start jumping up and down in every message where it seems remotely possible that an issue tracker was the solution to a problem. 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: Cygwin: texi2dvi stumbles over texinfo.tex
On Fri, Aug 20, 2010 at 10:14:29AM -0400, Steve Holden wrote: I'd like to take this opportunity to say how much I personally appreciate the availability of Cygwin - I use it daily, and it makes the computing experience on Windows far more bearable and productive than it otherwise would be. I'll happily overlook the occasional crabby reply to a thoughtless comment, given the amazing work that the team collectively produces. I just want to assure everyone that I put a lot of thought into my crabby replies. 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: cron fails to start as a service in Win2k3R2 64bit
- Original Message - From: Blaine Miller To: cygwin Sent: Friday, August 20, 2010 11:33 | Pierre, | | I tried using cron-config and it failed. Please find attached my | cronbug.txt... OK, I see that you are running cron as yourself (Administrator). The problem is that you have several cron running, probably from the time when you were running cron manually 2116 1 2116 2116 ? 500 13:49:24 /usr/sbin/cron I 3664 2116 2116 3664 ? 500 05:00:01 /usr/sbin/cron I 3896 2116 2116 3896 ? 500 05:00:01 /usr/sbin/cron I 3464 2116 2116 3464 ? 500 06:00:01 /usr/sbin/cron Kill them all and run cron-config again, keeping (not removing) the existing service. Pierre -- 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 login slow after upgrade to cygwin 1.7
On 2010-08-20 7:50, Jeremy Ramer wrote: After upgrading from cygwin 1.5 to cygwin 1.7 starting a bash shell is much slower. It usually takes around 4 seconds before I get a prompt. On cygwin 1.5 it was only around 1 second. I captured some logs from the startup using this process: - Open cmd shell cd C:\cygwin\bin bash --login -i -x 1 C:\startlog.txt 21 The log is attached. I don't see anything strange except that it seems pretty long. The same process on cygwin 1.5 gives much less output. I can provide that log if needed. Any ideas? It's the loading of all the bashcompletion scripts. Move the directory /etc/bash_completion.d away and you'll see it's a lot faster. -- 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 tracker
2010/8/19 Andrew Schulman: The question is if the maintainers really want that, and cgf and I are just 2 out of ~60 maintainers, maintaining over 1400 packages. From these ~60 maintainers we have quite a few who either don't reply to any mail about their package, or who only reply after some nudging. Agreed, but OTOH I'd guess that half of all of the bugs reported on this list are for just two packages: cygwin and setup.exe. If the maintainers of those two packages think a bug tracker would be useful, we should make one. If they don't, it's probably not worth bothering. setup already has a tracker, using the official sourceware bugzilla. http://www.sourceware.org/bugzilla/ used rarely Product cygwin - Component setup.exe http://www.sourceware.org/bugzilla/buglist.cgi?product=cygwincomponent=setup.exe I have no idea how one can interface bugzilla or any other tracker to our package - maintainer list: http://cygwin.com/cygwin-pkg-maint -- Reini Urban -- 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 tracker
On Fri, Aug 20, 2010 at 07:47:33PM +0200, Reini Urban wrote: 2010/8/19 Andrew Schulman: The question is if the maintainers really want that, and cgf and I are just 2 out of ~60 maintainers, maintaining over 1400 packages. ?From these ~60 maintainers we have quite a few who either don't reply to any mail about their package, or who only reply after some nudging. Agreed, but OTOH I'd guess that half of all of the bugs reported on this list are for just two packages: cygwin and setup.exe. ?If the maintainers of those two packages think a bug tracker would be useful, we should make one. ?If they don't, it's probably not worth bothering. setup already has a tracker, using the official sourceware bugzilla. http://www.sourceware.org/bugzilla/ used rarely Product cygwin - Component setup.exe http://www.sourceware.org/bugzilla/buglist.cgi?product=cygwincomponent=setup.exe I have no idea how one can interface bugzilla or any other tracker to our package - maintainer list: http://cygwin.com/cygwin-pkg-maint Just to be clear: The above URL is not intended as a mechanism for people to send private messages to package maintainers. 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: ImageMagick: More insufficient package dependencies
2010/8/18 Andy Koppe: On 18 August 2010 21:50, Corinna Vinschen wrote: On Aug 18 21:32, William Blunn wrote: On 18/08/2010 19:26, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote: My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. Actually, this is the defined way to report bugs in a cygwin package. A I see. It's /defined/ to be mediocre. Rather than attempting to solve the problem head-on, redefine the problem domain so that the problem is already solved. Inspired. Is there something in the water lately, which makes people on the list more aggressive than usual? It hasn't been redefined at all. It's the common way of reporting problems for a long time: http://cygwin.com/problems.html If you don't like it, I'm sorry. Are you going to volunteer to maintain a Cygwin packages bug-tracking system? Besides, thanks to the magic of mail filters, grabbing the attention of a package maintainer isn't the problem anyway. The issue is whether there's an active maintainer in the first place. Andy Yes, ImageMagick IS special. Well, I've been active on that lately, but I didn't want to maintain it. Do I really have to debug now emacs building from source. Sigh. I'm busy with other things. Volker Quetschke is officially still the maintainer. Can someone please take over maintainership and check the two problems. -- Reini Urban -- 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 and DBUS
2010/8/14 Ken Brown kbr...@cornell.edu: On 8/12/2010 10:36 PM, nyc4...@aol.com wrote: Can the Cygwin Emacs maintainer compile an Emacs binary (emacs-X11, emacs-nox, etc) with D-BUS? It appears that the cygdbus-1-3.dll should be able to be available for Cygwin Emacs support. Yes, I've just checked that it builds with D-Bus. I'll upload a test release in a few days. BTW, the configure script gives the following warning: D-Bus integration has been tested for GNU/Linux only. So I don't know if it will work. I added dbus support to clisp, tested it and it works fine. Yaakov also uses it. So dbus on cygwin works fine. It would be nice to have it in emacs also. -- Reini Urban -- 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 login slow after upgrade to cygwin 1.7
On 20 August 2010 18:20, Nahor wrote: On 2010-08-20 7:50, Jeremy Ramer wrote: After upgrading from cygwin 1.5 to cygwin 1.7 starting a bash shell is much slower. It usually takes around 4 seconds before I get a prompt. On cygwin 1.5 it was only around 1 second. I captured some logs from the startup using this process: - Open cmd shell cd C:\cygwin\bin bash --login -i -x 1 C:\startlog.txt 21 The log is attached. I don't see anything strange except that it seems pretty long. The same process on cygwin 1.5 gives much less output. I can provide that log if needed. Any ideas? It's the loading of all the bashcompletion scripts. Move the directory /etc/bash_completion.d away and you'll see it's a lot faster. Perhaps bash completion shouldn't be enabled just by installing it, because lots of people seem to install everything just in case. Andy -- 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 and DBUS
On 8/20/2010 2:14 PM, Reini Urban wrote: 2010/8/14 Ken Brownkbr...@cornell.edu: On 8/12/2010 10:36 PM, nyc4...@aol.com wrote: Can the Cygwin Emacs maintainer compile an Emacs binary (emacs-X11, emacs-nox, etc) with D-BUS? It appears that the cygdbus-1-3.dll should be able to be available for Cygwin Emacs support. Yes, I've just checked that it builds with D-Bus. I'll upload a test release in a few days. BTW, the configure script gives the following warning: D-Bus integration has been tested for GNU/Linux only. So I don't know if it will work. I added dbus support to clisp, tested it and it works fine. Yaakov also uses it. So dbus on cygwin works fine. It would be nice to have it in emacs also. It's in the latest (experimental) release. Can you test it and see if it works? Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Postinstall script errors
Hello, It works now, I was able to install gcc 4.3.4. Thanks! Tilman On Fri, 13 Aug 2010 11:48:04 +0200, Corinna Vinschen wrote: On Aug 12 19:50, Tilman Hausherr wrote: On Thu, 12 Aug 2010 11:59:30 +0200, Corinna Vinschen wrote: That's probably a fault in the postinstall scripts. It would be nice if you could provide more details about what fails exactly in the script, or better, what in the script has a non-0 exit code. That would help us lazy maintainers to fix the scripts faster. Keep in mind that the dialog providing info about failing postinstall scripts is very new. I'm quite sure that we have a couple of scripts which return with a non-0 exit code but the maintainers just don't know it yet, and I don't take myself out of the picture. I'm not sure if these faulty postinstall scripts are really THAT important, I got zero reaction on a bug report with details http://sourceware.org/ml/cygwin/2010-08/msg00158.html and I found out in the meantime that it was already reported in january and was already a known error at that time. http://old.nabble.com/gcc-command-not-found-td27393452.html#a27395128 I reported this myself a couple of days ago on the cygwin-apps list. http://cygwin.com/ml/cygwin-apps/2010-08/msg00074.html Dave? Any word on this? 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: Cygwin 1.7 problems on Windows XP SP2
On 8/20/2010 11:34 AM, Larry Hall (Cygwin) wrote: On 8/20/2010 11:28 AM, Baldur Gislason wrote: Hi, I recently installed the latest version of cygwin after using previous (1.5) versions without problems. Almost nothing works on 1.7 and even after reinstalling my machine I still have the same problem. My machine runs Windows XP SP2. My install.log.full has a lot of errors like this one: 3879146 [main] bash 3716 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 4 [main] bash 3872 C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x6D, top 0x74, reserve_size 454656, allocsize 458752, page_const 4096 This doesn't only happen with bash, it was also happening with other apps such as rsync before I reinstalled the operating system. Any ideas or hints for diagnosing this? Can I acquire an older setup.exe and try installing a previous version of cygwin? Full log is at http://foo.is/~baldur/setup.log.full.gz If you look in the email archives for messages with similar complaints, you'll find that this kind of problem is most commonly the result of one of two things: 1. You need to install the rebase package, read its README, and run rebaseall as prescribed. 2. http://cygwin.com/acronyms/#BLODA Supplementary: what do you do when rebaseall fails to work? I've tried to post my cygcheck output a couple of times, but perhaps gmane has volume limits. Guess I could use e-mail ... regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On 8/20/2010 11:43 AM, Christopher Faylor wrote: On Fri, Aug 20, 2010 at 08:00:14AM -0400, Steve Holden wrote: On 8/20/2010 7:53 AM, Steve Holden wrote: On 8/20/2010 5:29 AM, Reuben Thomas wrote: On Thu 25 May 2006, Karl Berry wrote: This line in fmtutil.cnf indicates the problem: etex pdfetex language.def -translate-file=cp227.tcx *etex.ini Either (1) the second word should be changed to etex, or (2) it should be arranged for etex in invoke pdfetex instead of etex. E.g., make etex a link to pdfetex, instead of its own binary. We do (2) for TeX Live. Please could this fix be applied? I just ran into the same problem, four years later, and I'm not the only one since then (I notice another thread from 2007). We don't need no stinkin' issue tracker. It struck me that this remark might be ambiguous, or even be regarded as offensive by some. I found it tedious actually, and wondered if you were going to now start jumping up and down in every message where it seems remotely possible that an issue tracker was the solution to a problem. Oh, no. I think the issue has been adequately exercised already, and I have no skin in that particular game. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- 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 login slow after upgrade to cygwin 1.7
On 08/20/2010 12:24 PM, Andy Koppe wrote: On 20 August 2010 18:20, Nahor wrote: On 2010-08-20 7:50, Jeremy Ramer wrote: After upgrading from cygwin 1.5 to cygwin 1.7 starting a bash shell is much slower. It usually takes around 4 seconds before I get a prompt. On cygwin 1.5 it was only around 1 second. I captured some logs from the startup using this process: - Open cmd shell cd C:\cygwin\bin bash --login -i -x 1 C:\startlog.txt 21 The log is attached. I don't see anything strange except that it seems pretty long. The same process on cygwin 1.5 gives much less output. I can provide that log if needed. Any ideas? It's the loading of all the bashcompletion scripts. Move the directory /etc/bash_completion.d away and you'll see it's a lot faster. Perhaps bash completion shouldn't be enabled just by installing it, because lots of people seem to install everything just in case. On Fedora, bash-completion is not installed by default. The mere act of installing enables it (although admittedly, since forks are so much faster on Linux, you don't notice the speed penalties of loading all the completion stuff). I see no reason why cygwin has to be any different - if you installed it, you must want it. Then again, not as many people try to install _everything_ on Fedora, as what seems to be the case with people using setup.exe to install _everything_ whether it is needed or not. Also, I know that the upstream bash-completion developers are working on loadable modules. Right now, everything is loaded up front (and the bulk of the loading time is spent on PATH searches: if app A exists, install completion function _A, and so on for loads of apps). But in the future, the startup will be (for all registered apps, install a dummy loader completion without any forking or PATH searches; then on first invocation of command A, the dummy will take care of loading the real completion function _A). If anyone wants to help that process move along, please join the upstream bash-completion development team. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org volunteer cygwin bash-completion maintainer signature.asc Description: OpenPGP digital signature
Re: Cygwin 1.7 problems on Windows XP SP2
On 8/20/2010 3:31 PM, Steve Holden wrote: On 8/20/2010 11:34 AM, Larry Hall (Cygwin) wrote: On 8/20/2010 11:28 AM, Baldur Gislason wrote: Hi, I recently installed the latest version of cygwin after using previous (1.5) versions without problems. Almost nothing works on 1.7 and even after reinstalling my machine I still have the same problem. My machine runs Windows XP SP2. My install.log.full has a lot of errors like this one: 3879146 [main] bash 3716 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 4 [main] bash 3872 C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x6D, top 0x74, reserve_size 454656, allocsize 458752, page_const 4096 This doesn't only happen with bash, it was also happening with other apps such as rsync before I reinstalled the operating system. Any ideas or hints for diagnosing this? Can I acquire an older setup.exe and try installing a previous version of cygwin? Full log is at http://foo.is/~baldur/setup.log.full.gz If you look in the email archives for messages with similar complaints, you'll find that this kind of problem is most commonly the result of one of two things: 1. You need to install the rebase package, read its README, and run rebaseall as prescribed. 2.http://cygwin.com/acronyms/#BLODA Supplementary: what do you do when rebaseall fails to work? I've tried to post my cygcheck output a couple of times, but perhaps gmane has volume limits. Guess I could use e-mail ... What's email? ;-) If rebaseall is failing, then that makes me think that some kind of BLODA is your real issue. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ 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: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On 2010-08-20 07:56, Corinna Vinschen wrote: Thanks for the new strace. After some more experimenting I was finally able to reproduce the issue. The other problem you reported, about df(*), lead me onto the right track. I've checked my changes in to CVS. For testing I provided another test DLL: I tried both df and find using the new test dll and everything worked perfectly. Thanks for the quick response. -- 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
Using ssmtp called in a script called by a crontab entry...
Hello, I have a need for ssmtp to send out a *job completed* email from within a script that is called as an entry in a cron table. I've read all I can from the *Installing and configuring ssmtp* man pages as well as the Knowledgebase and FAQ's on the cygwin site. From what I gather it should be possible to do this. Admittedly, I am not even close to an expert with sendmail. However, as sendmail is included on my UNIX/linux boxes, I'm stymied on how to get the same functionality out of ssmtp on cygwin. I've run ssmtp-config and accepted the defaults where indicated. However, when I type *mail* at the command prompt I get *command could not be found*. All of my single line scripts from linux for simply mailing completion and initilization of processes don't work. I'm getting very confused with the esoteric discussion of ssmtp, it's configuration and getting it to work with something called mutt (?). All I need is a simple, line by line checklist of things to do to emulate the functionality of sendmail as I described above. Briefly, the scenario is a cron table entry that calls a script. The script runs a few scp's and then exits. I want it to then send out a *completion* email and exit. Your time and consideration is appreciated and valued. Blaine Miller -- 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: Using ssmtp called in a script called by a crontab entry...
- Original Message - From: Blaine Miller To: cygwin Sent: Friday, August 20, 2010 17:51 | Hello, | | I have a need for ssmtp to send out a *job completed* email from within | a script that is called as an entry in a cron table. I've read all I can | from the *Installing and configuring ssmtp* man pages as well as the | Knowledgebase and FAQ's on the cygwin site. From what I gather it should | be possible to do this. Seen from the cron point of view, if the cron job produces any output on stdout or stderr, the output will be placed in an e-mail sent to you (you can configure the address in the MAILTO variable). As as recall, the ssmtp-config script will ask you if you want sendmail to point to ssmtp. If you answer yes, cron will use ssmtp to send the e-mail. Pierre -- 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: Using ssmtp called in a script called by a crontab entry...
Pierre, First of all, let me thank you for your very quick response. I believe we're getting closer. when I execute: */usr/sbin/ssmtp blaine.mil...@smithmicro.com* I get this for a response... ssmtp: Cannot open exchange.smsi.com:25 I would guess that either I've got the wrong mailhub name, the wrong port, both are wrong or the mailhub doesn't allow forwarding??? I won't be able to check with the person who runs our mail system until next Wednesday, the 25th. I'd like to check in with you then just to see if it all works once I have the kinks ironed out. Thanks for your time, patience and speedy responses... Blaine Pierre A. Humblet wrote: - Original Message - From: Blaine Miller To: cygwin Sent: Friday, August 20, 2010 17:51 | Hello, | | I have a need for ssmtp to send out a *job completed* email from within | a script that is called as an entry in a cron table. I've read all I can | from the *Installing and configuring ssmtp* man pages as well as the | Knowledgebase and FAQ's on the cygwin site. From what I gather it should | be possible to do this. Seen from the cron point of view, if the cron job produces any output on stdout or stderr, the output will be placed in an e-mail sent to you (you can configure the address in the MAILTO variable). As as recall, the ssmtp-config script will ask you if you want sendmail to point to ssmtp. If you answer yes, cron will use ssmtp to send the e-mail. Pierre -- 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: Using ssmtp called in a script called by a crontab entry...
Blaine Miller wrote: [snip] I've run ssmtp-config and accepted the defaults where indicated. However, when I type *mail* at the command prompt I get *command could not be found*. There is no mail on the package ssmtp. Try first 'man ssmtp' and see if the description is enough to do what you want, typically something like 'ssmtp my_recipi...@my_domain.com -f my_addr...@my_domain.com EOF Subject: This is a test This is the message contents. EOF' is enough. I you want something more complicated then perhaps you need to install email. -- 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: Cygwin 1.7 problems on Windows XP SP2
On 8/20/2010 4:04 PM, Larry Hall (Cygwin) wrote: On 8/20/2010 3:31 PM, Steve Holden wrote: [...] If rebaseall is failing, then that makes me think that some kind of BLODA is your real issue. Hmm, I didn't check hard enough - it was Spybot. Thanks. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- 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: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On 08/19/2010 11:13 AM, Charles Wilson wrote: libtirpc is an updated version of the Sun RPC library. As such, it replaces part of the (orphaned) sunrpc package -- just as on linux, it replaces the built-in RPC routines in glibc: http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php You should update sunrpc, if installed, to 4.0-4 or above. The headers are installed into /usr/lib/tirpc/rpc/* and not /usr/lib/rpc/ As a consequence, developers must add -I/usr/lib/tirpc when compiling RPC clients and servers on cygwin. Similarly, linking requires -ltirpc. However, this is the same procedure used on linux -- so any client that has already been taught how to accept tirpc on linux will be fine on cygwin. (Hmm - libvirt hasn't yet learned how to use tirpc on Linux, since rpc/rpc.h is directly in /usr/include on Fedora as part of glibc-headers; so I had to run 'make CFLAGS=-I/usr/include/tirpc LDFLAGS=-ltirpc', but that's an issue for the libvirt mailing list). Meanwhile, this warning is a bit annoying; and did not happen with the older sunrpc headers. Any chance you can silence them in a -2 release? In file included from ././remote/qemu_protocol.h:9, from remote/qemu_protocol.c:7: /usr/include/tirpc/rpc/rpc.h:84: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:21: warning: previous declaration of 'bindresvport' was here /usr/include/tirpc/rpc/rpc.h:95: warning: redundant redeclaration of 'bindresvport_sa' [-Wredundant-decls] /usr/include/netinet/in.h:22: warning: previous declaration of 'bindresvport_sa' was here But in spite of the warnings, I was still able to build libvirt on cygwin after today's upgrade, so good job on the release. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
Corinna Vinschen wrote: - Improve performance of stat and a few other functions. ls(1) should be up to 30% faster I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'. When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files. Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects. The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM. Ciao, Angelo. -- 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: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On 8/20/2010 8:35 PM, Eric Blake wrote: (Hmm - libvirt hasn't yet learned how to use tirpc on Linux, since rpc/rpc.h is directly in /usr/include on Fedora as part of glibc-headers; so I had to run 'make CFLAGS=-I/usr/include/tirpc LDFLAGS=-ltirpc', but that's an issue for the libvirt mailing list). Meanwhile, this warning is a bit annoying; and did not happen with the older sunrpc headers. Any chance you can silence them in a -2 release? In file included from ././remote/qemu_protocol.h:9, from remote/qemu_protocol.c:7: /usr/include/tirpc/rpc/rpc.h:84: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:21: warning: previous declaration of 'bindresvport' was here /usr/include/tirpc/rpc/rpc.h:95: warning: redundant redeclaration of 'bindresvport_sa' [-Wredundant-decls] /usr/include/netinet/in.h:22: warning: previous declaration of 'bindresvport_sa' was here Well, looking at linux, the declarations in netinet/in.h are guarded by #if defined __USE_MISC || defined __USE_GNU These symbols are activated in (linux's) features.h by: #if defined _BSD_SOURCE || defined _SVID_SOURCE # define __USE_MISC 1 #endif #ifdef _GNU_SOURCE # define __USE_GNU 1 #endif Given that the only *SOURCE flags supported by cygwin's headers are: _BSD_SOURCE _POSIX_SOURCE _XOPEN_SOURCE _GNU_SOURCE (and, the newlib headers don't employ the __USE_* indirection), I think the correct fix is to modify cygwin's netinet/in.h to add the following guard around the declaration of bindresvport and bindresvport_sa: #if defined(_BSD_SOURCE) || defined(_GNU_SOURCE) If you concur, I'll post a patch to that effect to cygwin-patches (we use our own header, not newlib's, for netinet/in.h). -- Chuck -- 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
