Re: [PATCH] inform user if any postinstall script failed to run
On 12/08/2010 06:44, Andy Koppe wrote: On 23 July 2010 18:45, Jon TURNEY wrote: Here's a small patch for setup.exe which causes setup to indicate if a postinstall script didn't run successfully. This should help avoid the situation where the postinstall scripts fail to run and the user has a broken installation, but they don't notice until they try to run something which relies on postinstall scripts, e.g [1] and I'm sure there are other examples. [1] http://cygwin.com/ml/cygwin-xfree/2010-07/msg00084.html ChangeLog: * postinstall.cc : Note if any postinstall script fails and tell the user with an error messagebox * script.cc (run): Don't rename script as .done if it didn't run successfully Shall we tone down the error box here a little bit? A postinstall failure in some obscure package that might only have been installed due to the user selecting 'All' won't actually impact on the use of Cygwin. I think the current wording will unnecessarily scare off unexperienced users who wouldn't know how to correct these failures. Suggestion below. Andy Index: postinstallresults.cc === RCS file: /cvs/cygwin-apps/setup/postinstallresults.cc,v retrieving revision 1.1 diff -u -r1.1 postinstallresults.cc --- postinstallresults.cc 29 Jul 2010 13:09:04 - 1.1 +++ postinstallresults.cc 12 Aug 2010 05:39:21 - @@ -57,10 +57,10 @@ // one or more postinstall scripts failed to run successfully // installation may be broken MessageBox (NULL, - You will need to investigate and correct these errors - before your Cygwin installation will function properly.\n - Check setup.log for details., - ERROR - postinstall scripts failed, + The affected packages and those that depend\n + on them may not function properly.\n + Check /var/log/setup.log for details., + ERROR - postinstall script failures, MB_OK | MB_ICONERROR | MB_SETFOREGROUND | MB_TOPMOST); return IDD_DESKTOP; I agree, I was going to suggest something like this. I'm afraid I just copied and adjusted the text from the dependencies declined dialog. It might be better to point to setup.log.full since it seems that contains the actual output from the failing command, and only from the most recent run of setup.
Re: [PATCH] inform user if any postinstall script failed to run
On Aug 12 11:10, Jon TURNEY wrote: On 12/08/2010 06:44, Andy Koppe wrote: Shall we tone down the error box here a little bit? A postinstall failure in some obscure package that might only have been installed due to the user selecting 'All' won't actually impact on the use of Cygwin. I think the current wording will unnecessarily scare off unexperienced users who wouldn't know how to correct these failures. Suggestion below. Andy Index: postinstallresults.cc === RCS file: /cvs/cygwin-apps/setup/postinstallresults.cc,v retrieving revision 1.1 diff -u -r1.1 postinstallresults.cc --- postinstallresults.cc 29 Jul 2010 13:09:04 - 1.1 +++ postinstallresults.cc 12 Aug 2010 05:39:21 - @@ -57,10 +57,10 @@ // one or more postinstall scripts failed to run successfully // installation may be broken MessageBox (NULL, - You will need to investigate and correct these errors - before your Cygwin installation will function properly.\n - Check setup.log for details., - ERROR - postinstall scripts failed, + The affected packages and those that depend\n + on them may not function properly.\n + Check /var/log/setup.log for details., + ERROR - postinstall script failures, MB_OK | MB_ICONERROR | MB_SETFOREGROUND | MB_TOPMOST); return IDD_DESKTOP; I agree, I was going to suggest something like this. I'm afraid I just copied and adjusted the text from the dependencies declined dialog. It might be better to point to setup.log.full since it seems that contains the actual output from the failing command, and only from the most recent run of setup. Yes, that sounds like a good idea to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: NOTICE for all package maintainers with faulty post-install scripts
Thanks to Jon Turney's recent patch we've discovered that many post-install packages were previously failing silently. Failing silently... so what is the preferred protocol in case a post-install script fails? Emit a message to stderr, which will be caught and shown to the user? If a post-install script fails in an ignorable way, then does this mean it's not acceptable to allow the script to exit with a non-zero status? That is, we have to either exit 0, or else exit non-zero and emit a useful message? If a post-install script succeeds (and exits with status 0) but still emits text to stderr or even stdout, will that text also be caught and shown to the user? Do the answers to all of the above also apply to preremove scripts? Sorry if some of this has already been discussed. I haven't followed all of the discussion of this new feature. Thanks, Andrew.
Re: NOTICE for all package maintainers with faulty post-install scripts
On Thu, Aug 12, 2010 at 09:56:49AM -0400, Andrew Schulman wrote: Thanks to Jon Turney's recent patch we've discovered that many post-install packages were previously failing silently. Failing silently... so what is the preferred protocol in case a post-install script fails? Emit a message to stderr, which will be caught and shown to the user? There is apparently a disconnect here. setup.exe now lets you know if a script fails. Scripts are not supposed to fail. Some scripts are routinely failing and should be fixed. If your script fails for a valid reason then of course exiting with a non-zero status is the way to go. That is what the new dialog box was intended to catch. If one of your scripts does fail then you should work out why with the affected user and take steps to make sure that it doesn't fail. cgf
Re: [PATCH] inform user if any postinstall script failed to run
On Thu, Aug 12, 2010 at 12:26:33PM +0200, Corinna Vinschen wrote: On Aug 12 11:10, Jon TURNEY wrote: On 12/08/2010 06:44, Andy Koppe wrote: Shall we tone down the error box here a little bit? A postinstall failure in some obscure package that might only have been installed due to the user selecting 'All' won't actually impact on the use of Cygwin. I think the current wording will unnecessarily scare off unexperienced users who wouldn't know how to correct these failures. Suggestion below. Andy Index: postinstallresults.cc === RCS file: /cvs/cygwin-apps/setup/postinstallresults.cc,v retrieving revision 1.1 diff -u -r1.1 postinstallresults.cc --- postinstallresults.cc 29 Jul 2010 13:09:04 - 1.1 +++ postinstallresults.cc 12 Aug 2010 05:39:21 - @@ -57,10 +57,10 @@ // one or more postinstall scripts failed to run successfully // installation may be broken MessageBox (NULL, - You will need to investigate and correct these errors - before your Cygwin installation will function properly.\n - Check setup.log for details., - ERROR - postinstall scripts failed, + The affected packages and those that depend\n + on them may not function properly.\n + Check /var/log/setup.log for details., + ERROR - postinstall script failures, MB_OK | MB_ICONERROR | MB_SETFOREGROUND | MB_TOPMOST); return IDD_DESKTOP; I agree, I was going to suggest something like this. I'm afraid I just copied and adjusted the text from the dependencies declined dialog. It might be better to point to setup.log.full since it seems that contains the actual output from the failing command, and only from the most recent run of setup. Yes, that sounds like a good idea to me. I think that wording will still cause consternation. Maybe we need something like: This does not necessarily mean that the affected package will fail to function properly but if you do notice problems please check /var/log/setup.log.full . cgf
Re: NOTICE for all package maintainers with faulty post-install scripts
Am 12.08.2010 01:15, schrieb Christopher Faylor: Thanks to Jon Turney's recent patch we've discovered that many post-install packages were previously failing silently. Now we know exactly which packages are failing because people are reporting them to the cygwin list. These need to be fixed and I implore you to make it a priority. Otherwise we're doing a disservice to our user community. I know we all lack tuits but I really hope that all of the affected packages will take time to fix their problems. Just look at the cygwin mailing list (which you're all monitoring anyway) for errors and, if your package has an error, consider rolling a -N+1 release with a fix. Oh, and please, no add 'exit 0' nonsense at the end of scripts, as I've just seen fly by on cygwin@ [1] - this will make matters worse and hide the now-noisy-and-formerly-silent failures more deeply in the system so that they're even harder to find, report, and fix. I also urgently seek those with upload privileges to refuse such fixes. _ [1] http://www.cygwin.com/ml/cygwin/2010-08/msg00291.html and references -- Matthias Andree
Re: NOTICE for all package maintainers with faulty post-install scripts
On Thu, Aug 12, 2010 at 04:19:44PM +0200, Matthias Andree wrote: Am 12.08.2010 01:15, schrieb Christopher Faylor: Thanks to Jon Turney's recent patch we've discovered that many post-install packages were previously failing silently. Now we know exactly which packages are failing because people are reporting them to the cygwin list. These need to be fixed and I implore you to make it a priority. Otherwise we're doing a disservice to our user community. I know we all lack tuits but I really hope that all of the affected packages will take time to fix their problems. Just look at the cygwin mailing list (which you're all monitoring anyway) for errors and, if your package has an error, consider rolling a -N+1 release with a fix. Oh, and please, no add 'exit 0' nonsense at the end of scripts, as I've just seen fly by on cygwin@ [1] - this will make matters worse and hide the now-noisy-and-formerly-silent failures more deeply in the system so that they're even harder to find, report, and fix. I also urgently seek those with upload privileges to refuse such fixes. Yes. What he said. Silently succeeding is not a fix for this problem. cgf
Re: NOTICE for all package maintainers with faulty post-install scripts
On Thu, Aug 12, 2010 at 09:56:49AM -0400, Andrew Schulman wrote: Thanks to Jon Turney's recent patch we've discovered that many post-install packages were previously failing silently. Failing silently... so what is the preferred protocol in case a post-install script fails? Emit a message to stderr, which will be caught and shown to the user? There is apparently a disconnect here. setup.exe now lets you know if a script fails. Scripts are not supposed to fail. Some scripts are routinely failing and should be fixed. If your script fails for a valid reason then of course exiting with a non-zero status is the way to go. That is what the new dialog box was intended to catch. If one of your scripts does fail then you should work out why with the affected user and take steps to make sure that it doesn't fail. Let me be sure first that I understand the new functionality. By fail we mean exiting with a non-zero status, correct? So when a postinstall or preremove script exits non-zero, the user will be alerted of that fact? And maybe output to stderr and/or stdout provided, in the hope that it will help to diagnose the problem? I may just be confused by your phrase failing silently. I'm just trying to figure out how if at all I need to adjust my postinstall/preremove scripts to check for non-zero exit statuses and try to provide useful output about them. Most of those scripts are short, but some contain multiple commands, any of which could fail for any number of reasons that are hard to predict. Once a problem is well-known I can add code to check for it and provide a useful message, but until then, either silence or a possibly not very enlightening error message is going to be the usual mode of failure. Anyway, I agreed that failure shouldn't happen routinely, it's good that failures are now going to be brought to our attention, and packagers should fix those problems when they get reported, which I guess was your main point. Andrew.
Re: NOTICE for all package maintainers with faulty post-install scripts
Am 12.08.2010 16:35, schrieb Andrew Schulman: On Thu, Aug 12, 2010 at 09:56:49AM -0400, Andrew Schulman wrote: Thanks to Jon Turney's recent patch we've discovered that many post-install packages were previously failing silently. Failing silently... so what is the preferred protocol in case a post-install script fails? Emit a message to stderr, which will be caught and shown to the user? There is apparently a disconnect here. setup.exe now lets you know if a script fails. Scripts are not supposed to fail. Some scripts are routinely failing and should be fixed. If your script fails for a valid reason then of course exiting with a non-zero status is the way to go. That is what the new dialog box was intended to catch. If one of your scripts does fail then you should work out why with the affected user and take steps to make sure that it doesn't fail. Let me be sure first that I understand the new functionality. By fail we mean exiting with a non-zero status, correct? Either that, or (hopefully) exit with a signal. So when a postinstall or preremove script exits non-zero, the user will be alerted of that fact? There's an error popup, but I don't know which details it reports other than pointing to setup.log.full or thereabouts. And maybe output to stderr and/or stdout provided, in the hope that it will help to diagnose the problem? I may just be confused by your phrase failing silently. I'm just trying failing silently means that it was logged to some file but not alerted through the GUI, so that many users were unaware that the postinstall script had failed somehow. to figure out how if at all I need to adjust my postinstall/preremove scripts to check for non-zero exit statuses and try to provide useful output about them. Most of those scripts are short, but some contain multiple commands, any of which could fail for any number of reasons that are hard to predict. Once a problem is well-known I can add code to check for it and provide a useful message, but until then, either silence or a possibly not very enlightening error message is going to be the usual mode of failure. My primary concern is that packagers don't just write :, true, or exit 0 at the end of their postinstall scripts to mask/hide the failure. My secondary concern is general quality of shell scripts (this is not relating to Cygwin postinstall scripts, which I've never looked at). Few people seem to be capable of writing solid shell scripts, because many people often just copy paste snippets from Google without understanding the details. Shell scripts are a nuisance to some, and proper training material is hard to find on the web (there's a truckload of mediocre and incomplete stuff though), and so I often see unquoted variable expansions (that break on blanks in filenames already or empty variables), people treating (a) foo bar and (b) if foo ; then bar ; fi as synonymous (abusively!) to accomodate their convenience, when in fact the exit semantics are different; if eats failures of its immediate condition command, whereas foo will emit the failure status. Note that some older shell implementations (including older Almqvist and BSD shells) got some of these semantics wrong (meaning violating POSIX). -- Matthias Andree
Re: NOTICE for all package maintainers with faulty post-install scripts
On Thu, Aug 12, 2010 at 10:35:12AM -0400, Andrew Schulman wrote: Let me be sure first that I understand the new functionality. By fail we mean exiting with a non-zero status, correct? Yes. On Windows and on Unix a failing program means a program which exits with a non-zero status. For more details read the error reports in the Cygwin mailing list. If your package is failing it will be reported there. It may not have your package name in the subject, though, since several packages may be showing up in the dialog box. In theory my original message shouldn't even be needed but I'm not seeing a lot of responses from affected package maintainers on this issue so I wanted to make sure that it was understood that this needs to be addressed. cgf
Re: [PATCH] inform user if any postinstall script failed to run
On 12 August 2010 15:03, Christopher Faylor wrote:
On Thu, Aug 12, 2010 at 12:26:33PM +0200, Corinna Vinschen wrote:
On Aug 12 11:10, Jon TURNEY wrote:
On 12/08/2010 06:44, Andy Koppe wrote:
Shall we tone down the error box here a little bit? A postinstall
failure in some obscure package that might only have been installed
due to the user selecting 'All' won't actually impact on the use of
Cygwin. I think the current wording will unnecessarily scare off
unexperienced users who wouldn't know how to correct these failures.
I agree, I was going to suggest something like this. I'm afraid I
just copied and adjusted the text from the dependencies declined
dialog.
It might be better to point to setup.log.full since it seems that
contains the actual output from the failing command, and only from
the most recent run of setup.
Yes, that sounds like a good idea to me.
I think that wording will still cause consternation.
Maybe we need something like:
This does not necessarily mean that the affected package will fail to
function properly but if you do notice problems please check
/var/log/setup.log.full .
How about removing the popup box and amending the postinstall results
page along those lines?
Andy
Index: postinstallresults.cc
===
RCS file: /cvs/cygwin-apps/setup/postinstallresults.cc,v
retrieving revision 1.1
diff -u -r1.1 postinstallresults.cc
--- postinstallresults.cc 29 Jul 2010 13:09:04 - 1.1
+++ postinstallresults.cc 12 Aug 2010 17:52:09 -
@@ -54,15 +54,6 @@
long
PostInstallResultsPage::OnNext ()
{
- // one or more postinstall scripts failed to run successfully
- // installation may be broken
- MessageBox (NULL,
- You will need to investigate and correct these errors
- before your Cygwin installation will function properly.\n
- Check setup.log for details.,
- ERROR - postinstall scripts failed,
- MB_OK | MB_ICONERROR | MB_SETFOREGROUND | MB_TOPMOST);
-
return IDD_DESKTOP;
}
Index: res.rc
===
RCS file: /cvs/cygwin-apps/setup/res.rc,v
retrieving revision 2.88
diff -u -r2.88 res.rc
--- res.rc 6 Aug 2010 18:56:12 - 2.88
+++ res.rc 12 Aug 2010 17:52:10 -
@@ -433,7 +433,10 @@
ICONIDI_CYGWIN,IDC_HEADICON,SETUP_HEADICON_X,0,21,20
LTEXT Postinstall script errors,IDC_STATIC_HEADER_TITLE
,7,0,258,8,NOT WS_GROUP
-LTEXT The following errors occured executing
postinstall scripts,
+LTEXT Affected packages and those depending on them may not
+work correctly.\n
+If you notice problems please check
+/var/log/setup.log.full.,
IDC_STATIC,21,9,239,16,NOT WS_GROUP
EDITTEXTIDC_POSTINSTALL_EDIT,7,41,303,124,WS_VSCROLL | WS_HSCROLL |
ES_LEFT | ES_MULTILINE | ES_READONLY | ES_AUTOHSCROLL |
Re: [PATCH] inform user if any postinstall script failed to run
On Thu, Aug 12, 2010 at 06:53:47PM +0100, Andy Koppe wrote: On 12 August 2010 15:03, Christopher Faylor wrote: On Thu, Aug 12, 2010 at 12:26:33PM +0200, Corinna Vinschen wrote: On Aug 12 11:10, Jon TURNEY wrote: On 12/08/2010 06:44, Andy Koppe wrote: Shall we tone down the error box here a little bit? A postinstall failure in some obscure package that might only have been installed due to the user selecting 'All' won't actually impact on the use of Cygwin. I think the current wording will unnecessarily scare off unexperienced users who wouldn't know how to correct these failures. I agree, I was going to suggest something like this. ??I'm afraid I just copied and adjusted the text from the dependencies declined dialog. It might be better to point to setup.log.full since it seems that contains the actual output from the failing command, and only from the most recent run of setup. Yes, that sounds like a good idea to me. I think that wording will still cause consternation. Maybe we need something like: This does not necessarily mean that the affected package will fail to function properly but if you do notice problems please check /var/log/setup.log.full . How about removing the popup box and amending the postinstall results page along those lines? I think removing the MessageBox is a good idea but I still think we should be slightly more reassuring about the errors. This might just be a temporary thing as package maintainers fix the problems in their scripts; assuming that they actually do that. So far the response has not been overwhelming. But assuming that the problems are all fixed then we can drop the assurance in a couple of months. cgf
Re: [PATCH] inform user if any postinstall script failed to run
On 12 August 2010 19:13, Christopher Faylor wrote:
I think that wording will still cause consternation.
Maybe we need something like:
This does not necessarily mean that the affected package will fail to
function properly but if you do notice problems please check
/var/log/setup.log.full .
How about removing the popup box and amending the postinstall results
page along those lines?
I think removing the MessageBox is a good idea but I still think we
should be slightly more reassuring about the errors. This might just
be a temporary thing as package maintainers fix the problems in their
scripts; assuming that they actually do that. So far the response has
not been overwhelming.
But assuming that the problems are all fixed then we can drop the
assurance in a couple of months.
Take three:
Index: res.rc
===
RCS file: /cvs/cygwin-apps/setup/res.rc,v
retrieving revision 2.88
diff -u -r2.88 res.rc
--- res.rc 6 Aug 2010 18:56:12 - 2.88
+++ res.rc 12 Aug 2010 19:27:22 -
@@ -433,7 +433,9 @@
ICONIDI_CYGWIN,IDC_HEADICON,SETUP_HEADICON_X,0,21,20
LTEXT Postinstall script errors,IDC_STATIC_HEADER_TITLE
,7,0,258,8,NOT WS_GROUP
-LTEXT The following errors occured executing
postinstall scripts,
+LTEXT These don't necessarily mean that affected packages will
+fail to function properly, but if you do notice problems
+please check /var/log/setup.log.full.,
IDC_STATIC,21,9,239,16,NOT WS_GROUP
EDITTEXTIDC_POSTINSTALL_EDIT,7,41,303,124,WS_VSCROLL | WS_HSCROLL |
ES_LEFT | ES_MULTILINE | ES_READONLY | ES_AUTOHSCROLL |
Index: postinstallresults.cc
===
RCS file: /cvs/cygwin-apps/setup/postinstallresults.cc,v
retrieving revision 1.1
diff -u -r1.1 postinstallresults.cc
--- postinstallresults.cc 29 Jul 2010 13:09:04 - 1.1
+++ postinstallresults.cc 12 Aug 2010 19:27:22 -
@@ -54,15 +54,6 @@
long
PostInstallResultsPage::OnNext ()
{
- // one or more postinstall scripts failed to run successfully
- // installation may be broken
- MessageBox (NULL,
- You will need to investigate and correct these errors
- before your Cygwin installation will function properly.\n
- Check setup.log for details.,
- ERROR - postinstall scripts failed,
- MB_OK | MB_ICONERROR | MB_SETFOREGROUND | MB_TOPMOST);
-
return IDD_DESKTOP;
}
(Turns out a line break is inserted automatically into the message, so
no need for \n.)
Andy
Re: [PATCH] inform user if any postinstall script failed to run
On Thu, Aug 12, 2010 at 08:31:24PM +0100, Andy Koppe wrote: On 12 August 2010 19:13, Christopher Faylor wrote: Index: res.rc === RCS file: /cvs/cygwin-apps/setup/res.rc,v retrieving revision 2.88 diff -u -r2.88 res.rc --- res.rc 6 Aug 2010 18:56:12 - 2.88 +++ res.rc 12 Aug 2010 19:27:22 - @@ -433,7 +433,9 @@ ICONIDI_CYGWIN,IDC_HEADICON,SETUP_HEADICON_X,0,21,20 LTEXT Postinstall script errors,IDC_STATIC_HEADER_TITLE ,7,0,258,8,NOT WS_GROUP -LTEXT The following errors occured executing postinstall scripts, I think you still need something like the above describing what is going on. +LTEXT These don't necessarily mean that affected packages will +fail to function properly, but if you do notice problems +please check /var/log/setup.log.full., Could this be put on the bottom? Does anyone else have opinions here? cgf
CygwinX at MS Terminalserver?
Does anyone has experiences running CygwinX at an MS Terminalserver? We like to use it at one based on Windows Server 2003 with NTFS. Is it possible to run multiple XWin instances for multiple user sessions in parallel? Any suggestions how to setup the rights in /tmp, /var/log, /var/run, etc.? Steffen -- 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/
Bo nurkowanie jest fajne!
Klub Płetwonurków pisze: Czy jesteście Państwo zainteresowani otrzymaniem informacji handlowej, dotyczącej: 1. Nauki nurkowania 2. Turystyki rekreacyjno - nurkowej 3. Kursów nurkowych Jeżeli tak, prosimy o odesłanie zgody na dostanie informacji dotyczącej powyższych tematów na adres nadawcy. Niniejsze zapytanie nie jest informacją handlową, a jedynie zapytaniem o zgodę na przesyłanie informacji handlowych drogą elektroniczną, zgodnie z art. 10 ustawy z dnia 18 lipca 2002r. o świadczeniu usług drogą elektroniczną. (Dz.U. z 2002r. Nr 144, poz 1204 z późn. zm.) -- 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/
xterm and 7-bit control codes
Hi all, I'm running into a strange one... At some point in the past (on linux because I didn't know about cygwin yet), xterm used to send the following control sequence for a mouse click at row 1, col 250 ESC [ M SPC \303\206 ! ESC [ M # \303\206 ! From what I could piece together, the formula for the x position was: \40+x (x 96) \300+X/64 \200+X%64 (otherwise) In other words, the first 96 characters were encoded as single octets, with all later ones encoded as an octet pair. I recently got back to using a wide monitor for the first time in years, and discovered that my hacks to emacs' xterm-mouse-mode no longer worked well because the two-octet code has been replaced by zero: ESC [ M SPC \000 ! ESC [ M # \000 ! This makes it hard to use the mouse on the right side of a large terminal window... I've verified that it's not emacs doing this (nor bash) by running directly (xterm -e) a small C utility which sends the mouse activation sequence and then converts stdin to an octet stream. Mouse clicks arrive just as emacs reported. Am I smoking something or has something about this control sequence changed in the last 5-6 years? I wonder if it has something to do with UTF-8 handling and if X changed somehow... The xfree86 control sequence documentation is less than helpful here [1]. For normal tracking mode it says: On button press or release, xterm sends CSI M C b C x C y . The low two bits of C b encode button information: 0=MB1 pressed, 1=MB2 pressed, 2=MB3 pressed, 3=release. The next three bits encode the modifiers which were down when the button was pressed and are added together: 4=Shift, 8=Meta, 16=Control. Note however that the shift and control bits are normally unavailable because xterm uses the control modifier with mouse for popup menus, and the shift modifier is used in the default translations for button events. The Meta modifier recognized by xterm is the mod1 mask, and is not necessarily the Meta key (see xmodmap). C x and C y are the x and y coordinates of the mouse event, encoded as in X10 mode. In X10 mode: On button press, xterm sends CSI M C b C x C y (6 characters). C b is button−1. C x and C y are the x and y coordinates of the mouse when the button was pressed. I remember reading the same thing all those years ago and being annoyed even then because it was so vague. Clearly the terminal was sending more than 6 octets (who knows how many characters that's supposed to be), and the spec doesn't mention the fact that all coordinates are offset by \40. How UTF-8, Unicode, and other encoding complexities fit in I have no clue... This may turn out to have nothing to do with cygwin/X; if so I'd appreciate ideas on where to send it next... Ideas? Ryan [1] http://www.xfree86.org/current/ctlseqs.html#Mouse%20Tracking -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 10/08/2010 06:48, Ryan Johnson wrote: On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: I was overjoyed to see that the release notes for the new X server release mention support for resizing the X desktop with the windows desktop. Unfortunately, it didn't work :( I modified the xwin windows shortcut to run as follows: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -resize You need to quote the entire command you are passing to bash after -c i.e, try C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -resize Then started the server at 1920x1200x32bpp while my ThinkPad was attached to an external LCD. When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. Oh dear. Well it seems I only thought I added code to only enable resize support in multiwindow mode when requested, so it's always on for multiwindow mode at the moment. That wouldn't be so bad, but it also seems that the -resize code completely fails to correctly handle a change of colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this segfault. Unfortunately, fixing this looks to be quite complex :-( Thanks for testing, anyhow :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 8/12/2010 5:46 PM, Jon TURNEY wrote: On 10/08/2010 06:48, Ryan Johnson wrote: On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. Oh dear. Well it seems I only thought I added code to only enable resize support in multiwindow mode when requested, so it's always on for multiwindow mode at the moment. That wouldn't be so bad, but it also seems that the -resize code completely fails to correctly handle a change of colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this segfault. Unfortunately, fixing this looks to be quite complex :-( Thanks for testing, anyhow :-) So... does that mean I have to roll back or face a seg fault after every commute? Or is there a way to explicitly disable it? Ryan -- 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: CygwinX at MS Terminalserver?
On 12/08/2010 08:31, Steffen Sledz wrote: Does anyone has experiences running CygwinX at an MS Terminalserver? We like to use it at one based on Windows Server 2003 with NTFS. Is it possible to run multiple XWin instances for multiple user sessions in parallel? Any suggestions how to setup the rights in /tmp, /var/log, /var/run, etc.? You shouldn't change the rights on any of these, as this could affect the security or functioning of other cygwin apps. Fortunately, you shouldn't need to, as, provided each X server instance has a unique display number, everything should work :-) Where you may experience problems is if the X server crashes whilst being run by an Administrator, and then a non-Adminstrator user tries to run X server using the same display number, which will fail due being unable to remove the stale lock file and unix socket. Unfortunately, there is no obvious way to fix that without introducing a security hole (not that it is known to be secure anyhow) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 12/08/2010 16:49, Ryan Johnson wrote: On 8/12/2010 5:46 PM, Jon TURNEY wrote: On 10/08/2010 06:48, Ryan Johnson wrote: On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. Oh dear. Well it seems I only thought I added code to only enable resize support in multiwindow mode when requested, so it's always on for multiwindow mode at the moment. That wouldn't be so bad, but it also seems that the -resize code completely fails to correctly handle a change of colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this segfault. Unfortunately, fixing this looks to be quite complex :-( Thanks for testing, anyhow :-) So... does that mean I have to roll back or face a seg fault after every commute? Or is there a way to explicitly disable it? I'm afraid so. As I say, I meant to add a means to disable -resize in -multiwindow mode to avoid exactly this kind of situation. Since it's the transition from 32bpp to 16bpp which breaks this, one possible workaround would be to run your large monitor at 16bpp, which might also give you working resize. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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 hardware acceleration still flaky?
On 10/08/2010 12:00, l.w...@surrey.ac.uk wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 5736.0x16c4] 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll (gdb) bt #0 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll #1 0x6fb97205 in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll #2 0x6fb77245 in pixman_fill () from /usr/bin/cygpixman-1-0.dll #3 0x0044924b in fbFill (pDrawable=0x109306f8, pGC=0x10936530, x=657, y=367, width=450, height=450) at fbfill.c:48 #4 0x0044746f in fbPolyFillRect (pDrawable=0x109306f8, pGC=0x10936530, nrect=0, prect=0x1096791c) at fbfillrect.c:77 #5 0x0052728f in damagePolyFillRect (pDrawable=0x109306f8, pGC=0x10936530, nRects=1, pRects=0x10967914) at damage.c:1404 #6 0x005504c3 in ProcPolyFillRectangle (client=0x106bd4f0) at dispatch.c:1939 #7 0x0054c56e in Dispatch () at dispatch.c:439 #8 0x005465af in main (argc=3, argv=0x61227b64, envp=0x104300f8) at main.c:286 Thanks. With the details provided in the last couple of emails, I have managed to reproduce what I think is the same problem as you are seeing. 1) Start geomview 2) Cause the geomview camera window to start animating, e.g. by loading one of the demo scenes and making the camera rotate, or by opening SaVi and starting simulated time running 3) Move the camera window away from it's original position up or to the left (observe if you move it a small amount to the right or down, the area of scene being drawn in it which is updated is constrained to the original window position) This has nothing to do with 'hardware acceleration' or OpenGL, it seems that the particular way this application draws it's output (into a same-size child window of the camera window) interacts with the composite extension to expose a bug in the XWin code. You should be able to workaround the crash by starting the X server with '-extension Composite' to disable the composite extension. I've uploaded a build with an attempt at fixing this at [1]. Perhaps you could try it out and see if it works for you? I'm not sure why the image flickers so badly, a double buffered OpenGL visual seems to be being used, so only a complete frame should be transferred to the display, but I can see elements of the scene being drawn. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100812-git-7180c693de178032.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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 hardware acceleration still flaky?
Jon, thanks for looking into this. I can confirm that under the current Cygwin release, with your original XWin debug code and geomview running with opengl support enabled and SaVi animating the Geomview window and forcing camera updates: moving the geomview window up and/or to the left causes the crash, while moving it down and/or to the left constrains the updated area to the overlap of the current window position with the original viewport (if that's the right term) - hard to spot amongst the flickering, and I missed that. Apologies. So, yes, it's not related to use of a second monitor; I was moving the geomview camera up to that monitor to get the crash. I can confirm that your replacement code drop (url below) appears to fix this crash problem. However, I have a question about your conclusion that this has nothing to do with opengl. If you start geomview under a buggy crashing XWin server with: geomview -noopengl (one dash, note spelling) there's no flickering or crashing; drawing is always slow and reliable, even under a buggy XWin. From that, it's a pretty easy conclusion to presume that OpenGL is somehow involved? Or is only one of the geomview drawing methods (the one that just happens to use OpenGL) at fault with the composite extension? somewhat enlightened but also somewhat puzzled, thanks, L. SaVi satellite constellation visualization: http://savi.sf.net/ -Original Message- From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: 12 August 2010 18:51 To: cygwin-xfree@cygwin.com Cc: Wood L Dr (Electronic Eng) Subject: Re: X hardware acceleration still flaky? Importance: High On 10/08/2010 12:00, l.w...@surrey.ac.uk wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 5736.0x16c4] 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll (gdb) bt #0 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll #1 0x6fb97205 in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll #2 0x6fb77245 in pixman_fill () from /usr/bin/cygpixman-1-0.dll #3 0x0044924b in fbFill (pDrawable=0x109306f8, pGC=0x10936530, x=657, y=367, width=450, height=450) at fbfill.c:48 #4 0x0044746f in fbPolyFillRect (pDrawable=0x109306f8, pGC=0x10936530, nrect=0, prect=0x1096791c) at fbfillrect.c:77 #5 0x0052728f in damagePolyFillRect (pDrawable=0x109306f8, pGC=0x10936530, nRects=1, pRects=0x10967914) at damage.c:1404 #6 0x005504c3 in ProcPolyFillRectangle (client=0x106bd4f0) at dispatch.c:1939 #7 0x0054c56e in Dispatch () at dispatch.c:439 #8 0x005465af in main (argc=3, argv=0x61227b64, envp=0x104300f8) at main.c:286 Thanks. With the details provided in the last couple of emails, I have managed to reproduce what I think is the same problem as you are seeing. 1) Start geomview 2) Cause the geomview camera window to start animating, e.g. by loading one of the demo scenes and making the camera rotate, or by opening SaVi and starting simulated time running 3) Move the camera window away from it's original position up or to the left (observe if you move it a small amount to the right or down, the area of scene being drawn in it which is updated is constrained to the original window position) This has nothing to do with 'hardware acceleration' or OpenGL, it seems that the particular way this application draws it's output (into a same-size child window of the camera window) interacts with the composite extension to expose a bug in the XWin code. You should be able to workaround the crash by starting the X server with '-extension Composite' to disable the composite extension. I've uploaded a build with an attempt at fixing this at [1]. Perhaps you could try it out and see if it works for you? I'm not sure why the image flickers so badly, a double buffered OpenGL visual seems to be being used, so only a complete frame should be transferred to the display, but I can see elements of the scene being drawn. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100812-git-7180c693de178032.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: xterm and 7-bit control codes
On Thu, 12 Aug 2010, Ryan Johnson wrote: Hi all, I'm running into a strange one... At some point in the past (on linux because I didn't know about cygwin yet), xterm used to send the following control sequence for a mouse click at row 1, col 250 ESC [ M SPC \303\206 ! ESC [ M # \303\206 ! From what I could piece together, the formula for the x position was: \40+x (x 96) \300+X/64 \200+X%64 (otherwise) In other words, the first 96 characters were encoded as single octets, with all later ones encoded as an octet pair. As far as I know, xterm's never sent more than one byte for either x/y in a button event. Ditto for rxvt. It sounds like a useful idea, except that it would of course be incompatible with the existing applications. So it would have to be enabled by a new control sequence. (On the other hand, whatever application you were using at the time may have translated the characters in that manner). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Incomplete installation of subversion
Greetings, Larry Hall (Cygwin)! On 8/11/2010 4:51 PM, Andrey Repin wrote: Greetings, Andy Koppe! Setup.exe 2.712 with a fix for this and a few additional tweaks to the Unmet dependencies page has been uploaded to http://cygwin.com. Can't download it - server not sending file size, causing download to abort. Works fine for me from here. http://cygwin.com/setup.exe Sounds like something is getting in the way. Proxy? stdout:curl -iI -H Accept-Encoding: gzip -s -- http://cygwin.com/setup.exe; HTTP/1.1 200 OK Date: Thu, 12 Aug 2010 06:59:40 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT ETag: 18e01b8-a7413-9f101340 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Cache-Control: max-age=0 Expires: Thu, 12 Aug 2010 06:59:40 GMT Content-Type: application/octet-stream -- WBR, Andrey Repin (anrdae...@freemail.ru) 12.08.2010, 10:56 Sorry for my terrible english... -- 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: Incomplete installation of subversion
On Thu, Aug 12, 2010 at 9:02 AM, Andrey Repin wrote: (snip) stdout:curl -iI -H Accept-Encoding: gzip -s -- http://cygwin.com/setup.exe; HTTP/1.1 200 OK Date: Thu, 12 Aug 2010 06:59:40 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT ETag: 18e01b8-a7413-9f101340 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Cache-Control: max-age=0 Expires: Thu, 12 Aug 2010 06:59:40 GMT Content-Type: application/octet-stream Works for me with wget: $ wget -d http://cygwin.com/setup.exe DEBUG output created by Wget 1.11.4 on cygwin. --2010-08-12 10:01:42-- http://cygwin.com/setup.exe Resolving proxy. Caching proxy. Connecting to proxy...|:8080... connected. Created socket 3. Releasing 0x00dc09b8 (new refcount 1). ---request begin--- GET http://cygwin.com/setup.exe HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: cygwin.com ---request end--- Proxy request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Date: Thu, 12 Aug 2010 08:01:43 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT ETag: 18e01b8-a7413-9f101340 Accept-Ranges: bytes Vary: Accept-Encoding Cache-Control: max-age=0 Expires: Thu, 12 Aug 2010 08:01:43 GMT Content-Type: application/octet-stream Content-Length: 685075 Connection: close Age: 0 ---response end--- 200 OK Length: 685075 (669K) [application/octet-stream] Saving to: `setup.exe' Note the Content-Length header -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Aug 12 06:54, Andy Koppe wrote: On 11 August 2010 20:55, John Carey wrote: On Aug 11 01:49 Corinna Vinschen wrote: there's no Win32-safe way to set a new directory handle as cwd in Vista and later anymore. Since there's no official API to set the cwd using a directory handle, there's no way to set the Win32 cwd to a directory with restricted permissions. This *is* frustrating. I'll look into another solution. Probably we will have to call SetCurrentDirectory again and ignore any error. I don't accept the aforementioned restriction for POSIX calls. So is your idea that if SetCurrentDirectory() fails because of path length or permissions, then Cygwin would just accept the failure and keep an internal record the POSIX current working directory and use that for all Cygwin calls, not the Win32 notion of current directory? Yes. The question then becomes what to do about the Win32 working directory in that case. Actually, Cygwin accepts *any* directory it can open as CWD: - Directories which can only be opened under SE_BACKUP_NAME. - Directories with a length up to 32768 chars. - Virtual directories, which don't exist at all as filesystem-based paths, like /proc, /cygdrive, etc. 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: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]
On Tue, Aug 10, 2010 at 9:57 AM, Eric Blake ebl...@redhat.com wrote: On 08/09/2010 07:19 PM, Chiheng Xu wrote: As far as I know, Cygwin now use Windows shortcut to implement symlink. This work well with native apps. Not true. Cygwin can read windows shortcuts as symlinks, but does not generate windows shortcuts to hold new symlinks because windows shortcuts are inherently limited in such a way that they cannot serve as true POSIX symlinks. http://en.wikipedia.org/wiki/Symbolic_link#Cygwin_symbolic_links -- Chiheng Xu Wuhan,China -- 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 Security Performance Issues
On Thu, Aug 12, 2010 at 1:36 AM, David Law wrote: (snip) Firstly, I was wondering if SUA maybe has a reputation for bad performance, or could it maybe be the architecture of desktop contra server pc's? Would you expect better performance from cygwin? I was involved in porting a project with a Unix background (Solaris, then Cygwin and Linux, and even FreeBSD) to SUA. I was expecting SUA to be slightly faster than Cygwin since it has its own subsystem rather than being implemented on top of Win32. However compilation times (for a bit over 200k lines of C++) were almost identical. Unfortunately, our project uses poll(), which on SUA does not work (except for /proc). Note that SUA has a rather BSD-ish flavor (for instance, bash is not even present in the default install); whereas Cygwin is very much like the GNU system. -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]
On Aug 12 17:09, Chiheng Xu wrote: On Tue, Aug 10, 2010 at 9:57 AM, Eric Blake ebl...@redhat.com wrote: On 08/09/2010 07:19 PM, Chiheng Xu wrote: As far as I know, Cygwin now use Windows shortcut to implement symlink. This work well with native apps. Not true. Cygwin can read windows shortcuts as symlinks, but does not generate windows shortcuts to hold new symlinks because windows shortcuts are inherently limited in such a way that they cannot serve as true POSIX symlinks. http://en.wikipedia.org/wiki/Symbolic_link#Cygwin_symbolic_links This is old info. Better trust the original source of information: http://www.cygwin.com/cygwin-ug-net/highlights.html#ov-hi-files 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 Security Performance Issues
On Aug 12 11:24, Csaba Raduly wrote: On Thu, Aug 12, 2010 at 1:36 AM, David Law wrote: (snip) Firstly, I was wondering if SUA maybe has a reputation for bad performance, or could it maybe be the architecture of desktop contra server pc's? Would you expect better performance from cygwin? I was involved in porting a project with a Unix background (Solaris, then Cygwin and Linux, and even FreeBSD) to SUA. I was expecting SUA to be slightly faster than Cygwin since it has its own subsystem rather than being implemented on top of Win32. However compilation times (for a bit over 200k lines of C++) were almost identical. Unfortunately, our project uses poll(), which on SUA does not work (except for /proc). Huh, I would never have expected that, especially given the fact that Cygwin has to go to great lengths on fork(), while SUA has a native fork implementation. Note that SUA has a rather BSD-ish flavor (for instance, bash is not even present in the default install); whereas Cygwin is very much like the GNU system. Really? As far as I understood from the docs, SUA is rather styled after SVR4. 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: Postinstall script errors
On Aug 11 09:18, Jeremy Ramer wrote: I recently upgraded from cygwin 1.5 to 1.7. At the end of the install there were errors with some of the postinstall scripts. From the setup.full.log: 2010/08/11 08:39:53 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/bash.sh ln: creating symbolic link `/dev/stdin': File exists 2010/08/11 08:39:54 abnormal exit: exit code=1 2010/08/11 08:39:54 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/passwd-grp.sh 2010/08/11 08:39:55 abnormal exit: exit code=1 I tried manually running the scripts with mixed results $ bash --norc --noprofile /etc/postinstall/bash.sh ; echo $? 0 $ bash --norc --noprofile /etc/postinstall/passwd-grp.sh ; echo $? 1 I tired manually running the commands inside passwd-grp.sh and they all return 0. So I'm not sure what exactly is failing. Is there anything I should do to investigate? 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. 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: OpenSSH: 5791 [main] sshd 9288! spawn_guts: CreateDesktop failed, Win32 error 8
On Aug 11 16:14, carsten.porz...@spb.de wrote: Dear Cygwin community, unfortunately we got on some of our Windows 2003 servers this error message while logging on by using OpenSSH 5791 [main] sshd 9288! spawn_guts: CreateDesktop failed, Win32 error 8 bash$ net helpmsg 8 Not enough storage is available to process this command. This is a good hint. I didn't see this for quite some time. I can't tell you why that occurs in your case, but not generally. But there's a potential workaround: http://support.microsoft.com/kb/126962 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: find on /proc/registry/HKEY_CLASSES_ROOT/CLSID report Bad address
On Aug 6 16:24, Oleksandr Gavenko wrote:
$ find /proc/registry/HKEY_CLASSES_ROOT/CLSID -type f
find: `/proc/registry/HKEY_CLASSES_ROOT/CLSID/CLSID': Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{002F---C000-0046}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0100--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0101--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0103--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0104--0010-8000-00AA006D2EA4}':
Bad address
Works with current CVS. Try the latest developer's snapshot at
http://cygwin.com/snapshots/
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
On Aug 12 00:48, Dave Cottlehuber wrote: On 7/15/2010 11:44 AM, Ernest Mueller wrote: Michael, did you ever find a fix for this? I had to give up on cygwin on the Amazon 64-bit and instead cobbled together freesshd and random freewares. Larry or others - what's the right way to report this as a bug? I think working on newer 64-bit OSes is pretty important... And it should be trivial to reproduce since the Amazon instances are publicly available; nobody has to actually buy them expensive licenses... Reporting this issue on the list is the right way to report the bug. -- Larry Hall http://www.rfk.com I have found 1 more piece of the puzzle - unfortunately not a complete solution but it does seem to helpa. Any further ideas? http://support.microsoft.com/kb/956607 This KB article refers to Cygwin 1.5. At the time of writing Cygwin 1.7 was not released. I have local Cygwin test installations of all Windows OSes since NT4, including all 64 bit OSes. Well, admittedly only workstation releases of NT4 and 2000, no server, but otherwise every later OS. However, all the servers are so called Standard servers, no Enterprise or Datacenter editions. For testing, I went out of my way and installed a local x64 Windows Server 2008 Datacenter machine. Apart from updating to SP2 plus all the latest Microsoft patches and configuring to match my environment, I have not changed anything else, nor did I install any third-party software. Then I installed a Cygwin Base install using the latest setup.exe. It went 100% well. No fails in postinstall scripts. An interactive bash started just fine. Then I removed every trace of Cygwin from the machine and installed Terminal Services, which is known to interfere badly with Cygwin applications which don't have the TS-awareness flag set in the PE/COFF header. I also installed any Then I installed a Cygwin Base install using the latest setup.exe. It went 100% well. No fails in postinstall scripts. An interactive bash started just fine. http://dch.posterous.com/cygwin-dumps-core-on-windows-2008-r1sp2-on-ec So, this muse-ing of yours is not correct. To me this implies that the Amazon Cloud VMs have some BLODA installed by default. I'm not going to check this voluntarily. I suggest that somebody who wants to run Cygwin on such a machine investigates this further, or just asks Amazon to fix this and hope for the best. 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 Security amp; Performance Issues
Did anyone have any thoughts about the security side of the question: do I have more, less or exactly the same rights? Best regards, DaveLaw - original message Subject: CygWin Security Performance Issues Sent: Thu, 12 Aug 2010 From: David Lawdavid@apconsult.de Hello List, about 18 months ago we recommended cygwin as a unix-like environment for a Windows 2003 Server to our Admin. This was turned down on the grounds that it did not satisfy the security requirements of our organisation. (unfortunately I don't know the details as I wasn't involved in the process) Instead, the Subsystem for Unix-based Applications was chosen. I am now trying to port a fairly simple shell script to SUA and find massive performance problems: under cygwin the script runs for about 20 minutes on my notebook, but under SUA it takes about 2 days on our Zillion-core 2003 Server!! Firstly, I was wondering if SUA maybe has a reputation for bad performance, or could it maybe be the architecture of desktop contra server pc's? Would you expect better performance from cygwin? Secondly, how do you see cygwin's compliance with a Windows Server security infrastructure? Is a user limited to just the same as under windows or can they somehow access other users data they otherwise couldn't? I noticed in cygwin 1.7 there is something called LSA Authentication. Does this address these issues? Thanks in advance, DaveLaw -- 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 --- original message end -- 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 Security amp; Performance Issues
Please don't http://cygwin.com/acronyms/#TOFU On Aug 12 14:33, David Law wrote: Did anyone have any thoughts about the security side of the question: do I have more, less or exactly the same rights? Yes. Cygwin is just a user space DLL, not an OS. If you're an admin user not running under UAC or in an elevated shell, it *might* appear that you have more rights than other, native Win32 apps. However, that's not the case. The native apps just don't use their rights effectively. 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: find on /proc/registry/HKEY_CLASSES_ROOT/CLSID report Bad address
On 12.08.2010 13:12, Corinna Vinschen wrote:
On Aug 6 16:24, Oleksandr Gavenko wrote:
$ find /proc/registry/HKEY_CLASSES_ROOT/CLSID -type f
find: `/proc/registry/HKEY_CLASSES_ROOT/CLSID/CLSID': Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{002F---C000-0046}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0100--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0101--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0103--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0104--0010-8000-00AA006D2EA4}':
Bad address
Works with current CVS. Try the latest developer's snapshot at
http://cygwin.com/snapshots/
I replace my current cygwin1.dll (which come with Cygwin 1.7.5, built
2010-04-12 19:07)
with cygwin1-20100809.dll.bz2 and now find properly work!
Its usual take snapshot in production or need wait when cygwin1.dll
comes with update?
--
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: Incomplete installation of subversion
Greetings, Csaba Raduly! On Thu, Aug 12, 2010 at 9:02 AM, Andrey Repin wrote: (snip) stdout:curl -iI -H Accept-Encoding: gzip -s -- http://cygwin.com/setup.exe; HTTP/1.1 200 OK Date: Thu, 12 Aug 2010 06:59:40 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT ETag: 18e01b8-a7413-9f101340 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Cache-Control: max-age=0 Expires: Thu, 12 Aug 2010 06:59:40 GMT Content-Type: application/octet-stream Works for me with wget: Of course. It's just you can't launch it after wget - file don't have rights to execute it. Note the Content-Length header I noted. Look again at headers sent to server. However, I can tell my download manager to not request compressed data, and it will work, but why should I, when it's clearly an error at server end? -- WBR, Andrey Repin (anrdae...@freemail.ru) 12.08.2010, 17:23 Sorry for my terrible english... -- 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: find on /proc/registry/HKEY_CLASSES_ROOT/CLSID report Bad address
On Aug 12 16:20, Oleksandr Gavenko wrote:
On 12.08.2010 13:12, Corinna Vinschen wrote:
On Aug 6 16:24, Oleksandr Gavenko wrote:
$ find /proc/registry/HKEY_CLASSES_ROOT/CLSID -type f
find: `/proc/registry/HKEY_CLASSES_ROOT/CLSID/CLSID': Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{002F---C000-0046}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0100--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0101--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0103--0010-8000-00AA006D2EA4}':
Bad address
find:
`/proc/registry/HKEY_CLASSES_ROOT/CLSID/{0104--0010-8000-00AA006D2EA4}':
Bad address
Works with current CVS. Try the latest developer's snapshot at
http://cygwin.com/snapshots/
I replace my current cygwin1.dll (which come with Cygwin 1.7.5,
built 2010-04-12 19:07)
with cygwin1-20100809.dll.bz2 and now find properly work!
Its usual take snapshot in production or need wait when cygwin1.dll
comes with update?
If it works for you, just use it. 1.7.6 is due really soon now, though.
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: Incomplete installation of subversion
On Aug 12 17:27, Andrey Repin wrote: Greetings, Csaba Raduly! On Thu, Aug 12, 2010 at 9:02 AM, Andrey Repin wrote: (snip) stdout:curl -iI -H Accept-Encoding: gzip -s -- http://cygwin.com/setup.exe; HTTP/1.1 200 OK Date: Thu, 12 Aug 2010 06:59:40 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT ETag: 18e01b8-a7413-9f101340 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Cache-Control: max-age=0 Expires: Thu, 12 Aug 2010 06:59:40 GMT Content-Type: application/octet-stream Works for me with wget: Of course. It's just you can't launch it after wget - file don't have rights to execute it. chmod +x ? 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: Postinstall script errors
On Thu, Aug 12, 2010 at 3:59 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 11 09:18, Jeremy Ramer wrote: I recently upgraded from cygwin 1.5 to 1.7. At the end of the install there were errors with some of the postinstall scripts. From the setup.full.log: 2010/08/11 08:39:53 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/bash.sh ln: creating symbolic link `/dev/stdin': File exists 2010/08/11 08:39:54 abnormal exit: exit code=1 2010/08/11 08:39:54 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/passwd-grp.sh 2010/08/11 08:39:55 abnormal exit: exit code=1 I tried manually running the scripts with mixed results $ bash --norc --noprofile /etc/postinstall/bash.sh ; echo $? 0 $ bash --norc --noprofile /etc/postinstall/passwd-grp.sh ; echo $? 1 I tired manually running the commands inside passwd-grp.sh and they all return 0. So I'm not sure what exactly is failing. Is there anything I should do to investigate? 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. The issue with the passwd-grp.sh script seems to be the last two lines. [ $created_passwd = yes ] /bin/chgrp --silent root /etc/passwd [ $created_group = yes ] /bin/chgrp --silent root /etc/group I verified that $created_passwd and $created_group were both no so both conditionals will fail. But because the last conditional is the last thing run, the script returns 1. Adding an exit 0 to the script fixes it, but I'm not sure if that accomplishes what you want from the script. Jeremy -- 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: abnormal exit codes
On Wed, Aug 11, 2010 at 4:42 PM, Stephen Dewey stepheneliotde...@gmail.com wrote: Hi, I am trying to install Cygwin (latest version, 1.7.5-1) on a Windows XP Professional computer, and I keep getting errors that certain scripts exited with abnormal codes. Specifically: Package: libglade2.0_0 libglade2.0.sh exit code 2 Package: mined mined.sh exit code 1 Package: No package libglade2.0.sh exit code 2 mined.sh exit code 1 I have checked and these are selected during the Cygwin install process. I have made sure that all dependencies are selected (or at least, the ones detected by the Cygwin installer). Generally I'm doing the basic installation but adding the Perl, Python, Database, Shell, and Net packages (roughly). These packages aren't crucial to what I'm doing, but I'd feel better about a clean install. Unfortunately, setup.log doesn't tell me anything new, just (partially): 2010/08/11 18:00:22 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libncurses-devel.sh 2010/08/11 18:00:23 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libglade2.0.sh 2010/08/11 18:00:23 abnormal exit: exit code=2 2010/08/11 18:00:23 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/gq.sh 2010/08/11 18:00:26 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/grepmail.sh 2010/08/11 18:00:26 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/gv.sh 2010/08/11 18:00:26 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/vim.sh 2010/08/11 18:00:26 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/gvim.sh 2010/08/11 18:00:29 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/inetutils.sh 2010/08/11 18:00:44 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/irssi.sh 2010/08/11 18:00:45 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/joe.sh 2010/08/11 18:00:45 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/lftp.sh 2010/08/11 18:00:45 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb2-devel.sh 2010/08/11 18:00:45 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb3.1-devel.sh 2010/08/11 18:00:46 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb3.3-devel.sh 2010/08/11 18:00:46 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb4.0-devel.sh 2010/08/11 18:00:46 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb4.1-devel.sh 2010/08/11 18:00:46 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb4.2-devel.sh 2010/08/11 18:00:46 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb4.3-devel.sh 2010/08/11 18:00:47 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb4.4-devel.sh 2010/08/11 18:00:47 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libdb4.5-devel.sh 2010/08/11 18:00:47 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/post-texmf.sh 2010/08/11 18:02:51 can't run /etc/postinstall/post-texmf.sh: No such file 2010/08/11 18:02:51 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/lyx.sh/lyx.sh 2010/08/11 18:02:51 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/maradns.sh 2010/08/11 18:02:51 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/mined.sh 2010/08/11 18:02:51 abnormal exit: exit code=1 2010/08/11 18:02:51 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/mintty.sh 2010/08/11 18:02:52 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/wget.sh 2010/08/11 18:02:52 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/openldap.sh 2010/08/11 18:02:52 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/pdksh.sh 2010/08/11 18:02:52 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/proftpd.sh 2010/08/11 18:02:53 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/rsh.sh 2010/08/11 18:02:53 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/rsnapshot.sh 2010/08/11 18:02:53 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/rxvt.sh 2010/08/11 18:02:54 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/rxvt-unicode-common.sh 2010/08/11 18:02:55 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/rxvt-unicode-X.sh 2010/08/11 18:02:55 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/sendxmpp.sh 2010/08/11 18:02:55 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/tcp_wrappers.sh 2010/08/11 18:02:56 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/tcsh.sh 2010/08/11 18:02:56 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/ted.sh
Re: git and openssh issue (eblake?)
On 8/2/2010 10:08 AM, Bill Hoffman wrote: On 7/23/2010 12:27 PM, Christopher Faylor wrote: Cygwin Package Information Package Version Status cygwin 1.7.5-1 OK git 1.7.1-1 OK openssh 5.5p1-2 OK I haven't tried the other configurations I mentioned yet, but if there is someone who has the ability to debug this in more depth, this looks like a quick and readily reproducible test case. I checked this out and it looks like something in git is overflowing and scriblling on the stack. I was hoping that it would be a cygwin problem which I could fix (and I wouldn't be surprised if it eventually turned out to be) but I didn't see much evidence of the DLL causing this problem. It looks like it is git itself doing something wrong. Eric do you have the cycles to check this out? It is pretty easy to reproduce. How did you come to the conclusion that it was a stack overwrite? I would be willing to look at this a bit(not that I know much about git internals). However, it would be helpful if I could see how you came to that conclusion? Is anyone looking at this? Thanks. -Bill -- 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: Re: CygWin Security amp;amp; Performance Issues
Please don't... ... waste peoples time with meaningless acronyms. Best regards, DaveLaw - original message Subject: Re: CygWin Security amp; Performance Issues Sent: Thu, 12 Aug 2010 From: Corinna Vinschencorinna-cyg...@cygwin.com Please don't http://cygwin.com/acronyms/#TOFU On Aug 12 14:33, David Law wrote: Did anyone have any thoughts about the security side of the question: do I have more, less or exactly the same rights? Yes. Cygwin is just a user space DLL, not an OS. If you're an admin user not running under UAC or in an elevated shell, it *might* appear that you have more rights than other, native Win32 apps. However, that's not the case. The native apps just don't use their rights effectively. 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 --- original message end -- 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: Re: CygWin Security amp;amp; Performance Issues
On Aug 12 15:51, David Law wrote: Please don't... ... waste peoples time with meaningless acronyms. Best regards, DaveLaw - original message Subject: Re: CygWin Security amp; Performance Issues Sent: Thu, 12 Aug 2010 From: Corinna Vinschen... Ok, I'll not waste my time and reply to you another time. That makes both of us happy. 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: Postinstall script errors
On Aug 12 07:37, Jeremy Ramer wrote: On Thu, Aug 12, 2010 at 3:59 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 11 09:18, Jeremy Ramer wrote: I recently upgraded from cygwin 1.5 to 1.7. At the end of the install there were errors with some of the postinstall scripts. From the setup.full.log: 2010/08/11 08:39:53 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/bash.sh ln: creating symbolic link `/dev/stdin': File exists 2010/08/11 08:39:54 abnormal exit: exit code=1 2010/08/11 08:39:54 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/passwd-grp.sh 2010/08/11 08:39:55 abnormal exit: exit code=1 I tried manually running the scripts with mixed results $ bash --norc --noprofile /etc/postinstall/bash.sh ; echo $? 0 $ bash --norc --noprofile /etc/postinstall/passwd-grp.sh ; echo $? 1 I tired manually running the commands inside passwd-grp.sh and they all return 0. So I'm not sure what exactly is failing. Is there anything I should do to investigate? 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. The issue with the passwd-grp.sh script seems to be the last two lines. [ $created_passwd = yes ] /bin/chgrp --silent root /etc/passwd [ $created_group = yes ] /bin/chgrp --silent root /etc/group I verified that $created_passwd and $created_group were both no so both conditionals will fail. But because the last conditional is the last thing run, the script returns 1. Adding an exit 0 to the script fixes it, but I'm not sure if that accomplishes what you want from the script. Thanks, I think it will. John, that's your script. Would you mind to update it? 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: Postinstall script errors
Am 12.08.2010 15:37, schrieb Jeremy Ramer: On Thu, Aug 12, 2010 at 3:59 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 11 09:18, Jeremy Ramer wrote: I recently upgraded from cygwin 1.5 to 1.7. At the end of the install there were errors with some of the postinstall scripts. From the setup.full.log: 2010/08/11 08:39:53 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/bash.sh ln: creating symbolic link `/dev/stdin': File exists 2010/08/11 08:39:54 abnormal exit: exit code=1 2010/08/11 08:39:54 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/passwd-grp.sh 2010/08/11 08:39:55 abnormal exit: exit code=1 I tried manually running the scripts with mixed results $ bash --norc --noprofile /etc/postinstall/bash.sh ; echo $? 0 $ bash --norc --noprofile /etc/postinstall/passwd-grp.sh ; echo $? 1 I tired manually running the commands inside passwd-grp.sh and they all return 0. So I'm not sure what exactly is failing. Is there anything I should do to investigate? 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. The issue with the passwd-grp.sh script seems to be the last two lines. [ $created_passwd = yes ] /bin/chgrp --silent root /etc/passwd [ $created_group = yes ] /bin/chgrp --silent root /etc/group I verified that $created_passwd and $created_group were both no so both conditionals will fail. But because the last conditional is the last thing run, the script returns 1. Adding an exit 0 to the script fixes it, but I'm not sure if that accomplishes what you want from the script. PLEASE DON'T. Adding an exit 0 will mask the error and just reinstate the former state of silently failing postinstall scripts more rigidly. This is not desirable. The proper way to fix this is: set -e # this is providing that the whole script is written properly. # it causes immediate exit after one command (outside if, and # outside || or lists) fails - usually desirable, but takes more # work because you can't write the scripts as sloppily as the # snippet you've just shown from passwd-grp.sh. # # ...other work... # if [ $created_passwd = yes ] ; then /bin/chgrp --silent root /etc/passwd fi if [ $created_group = yes ] ; then /bin/chgrp --silent root /etc/group fi -- Matthias Andree -- 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 Security amp;amp; Performance Issues
Please don't... ... waste peoples time with meaningless acronyms. The meaning is perfectly clear, and posted on cygwin.com. Corinna even kindly provided the link, to make it trivial for you to go and find out what it meant. The meaning expresses one of the standard requirements of the Cygwin mailing lists, which list participants are expected to abide by. A polite reminder is entirely appropriate. -- 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
On Aug 12 16:10, Matthias Andree wrote: Am 12.08.2010 15:37, schrieb Jeremy Ramer: I verified that $created_passwd and $created_group were both no so both conditionals will fail. But because the last conditional is the last thing run, the script returns 1. Adding an exit 0 to the script fixes it, but I'm not sure if that accomplishes what you want from the script. PLEASE DON'T. Adding an exit 0 will mask the error and just reinstate the former state of silently failing postinstall scripts more rigidly. This is not desirable. The proper way to fix this is: set -e # this is providing that the whole script is written properly. # it causes immediate exit after one command (outside if, and # outside || or lists) fails - usually desirable, but takes more # work because you can't write the scripts as sloppily as the # snippet you've just shown from passwd-grp.sh. # # ...other work... # if [ $created_passwd = yes ] ; then /bin/chgrp --silent root /etc/passwd fi if [ $created_group = yes ] ; then /bin/chgrp --silent root /etc/group fi I misinterpreted the `chgrp --silent'. I thought it would result in an exit code of 0 from chgrp, but it just suppresses the error messages. Sorry about that. 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 Security Performance Issues
Here is the so-called definition of TOFU: Text Over, Full-quote Under (or, in the original German, Text Oben, Fullquote Unten). A combination of top posting and full quoting, which makes the messages hard to read (accoring to RFC 1855). Often combined with raw e-mail addresses in quoted messages (see PCYMTNQREAIYR). Added after repeated requests from Corinna Vinschen Ah, now everything is clear: Added after REPEATED REQUESTS from Corinna Vinschen Who apparently asked over over over again until they finally capitulated. Well, whatever that jibberish was supposed to mean, it would seem someone has a bee in her bonnet about it!! (Oh, by the way, for those of you who don't speak German, Text Oben, Fullquote Unten is just as meaningless) Schoene Gruesse aus dem Odenwald, DaveLaw - original message Subject: Re: CygWin Security amp;amp; Performance Issues Sent: Thu, 12 Aug 2010 From: Andrew Schulmanschulman.and...@epamail.epa.gov Please don't... ... waste peoples time with meaningless acronyms. The meaning is perfectly clear, and posted on cygwin.com. Corinna even kindly provided the link, to make it trivial for you to go and find out what it meant. The meaning expresses one of the standard requirements of the Cygwin mailing lists, which list participants are expected to abide by. A polite reminder is entirely appropriate. -- 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 --- original message end -- 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 Security Performance Issues
Yes, go waste someone elses time instead. I got exactly the information I needed for my meeting tomorrow. Goodbye, DaveLaw - original message Subject: Re: Re: CygWin Security amp;amp; Performance Issues Sent: Thu, 12 Aug 2010 From: Corinna Vinschencorinna-cyg...@cygwin.com On Aug 12 15:51, David Law wrote: Please don't... ... waste peoples time with meaningless acronyms. Best regards, DaveLaw - original message Subject: Re: CygWin Security Performance Issues Sent: Thu, 12 Aug 2010 From: Corinna Vinschen... Ok, I'll not waste my time and reply to you another time. That makes both of us happy. 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 --- original message end -- 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 Security Performance Issues
On Aug 12 16:47, David Law wrote: (Oh, by the way, for those of you who don't speak German, Text Oben, Fullquote Unten is just as meaningless) http://de.wikipedia.org/wiki/TOFU http://en.wikipedia.org/wiki/TOFU 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: Postinstall script errors
Am 12.08.2010 16:40, schrieb Corinna Vinschen: On Aug 12 16:10, Matthias Andree wrote: Am 12.08.2010 15:37, schrieb Jeremy Ramer: I verified that $created_passwd and $created_group were both no so both conditionals will fail. But because the last conditional is the last thing run, the script returns 1. Adding an exit 0 to the script fixes it, but I'm not sure if that accomplishes what you want from the script. PLEASE DON'T. Adding an exit 0 will mask the error and just reinstate the former state of silently failing postinstall scripts more rigidly. This is not desirable. The proper way to fix this is: set -e # this is providing that the whole script is written properly. # it causes immediate exit after one command (outside if, and # outside || or lists) fails - usually desirable, but takes more # work because you can't write the scripts as sloppily as the # snippet you've just shown from passwd-grp.sh. # # ...other work... # if [ $created_passwd = yes ] ; then /bin/chgrp --silent root /etc/passwd fi if [ $created_group = yes ] ; then /bin/chgrp --silent root /etc/group fi I misinterpreted the `chgrp --silent'. I thought it would result in an exit code of 0 from chgrp, but it just suppresses the error messages. Sorry about that. And you're missing the other point that I've just explained on cygwin-apps@, see http://www.cygwin.com/ml/cygwin-apps/2010-08/msg00116.html [ $blah = foo ] ... is usually suspicious and often triggers bogus failures or premature exit, depends on if running under set +e (default) or set -e (advised). -- Matthias Andree -- 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
On Aug 12 16:52, Matthias Andree wrote: Am 12.08.2010 16:40, schrieb Corinna Vinschen: On Aug 12 16:10, Matthias Andree wrote: Am 12.08.2010 15:37, schrieb Jeremy Ramer: I verified that $created_passwd and $created_group were both no so both conditionals will fail. But because the last conditional is the last thing run, the script returns 1. Adding an exit 0 to the script fixes it, but I'm not sure if that accomplishes what you want from the script. PLEASE DON'T. Adding an exit 0 will mask the error and just reinstate the former state of silently failing postinstall scripts more rigidly. This is not desirable. The proper way to fix this is: set -e # this is providing that the whole script is written properly. # it causes immediate exit after one command (outside if, and # outside || or lists) fails - usually desirable, but takes more # work because you can't write the scripts as sloppily as the # snippet you've just shown from passwd-grp.sh. # # ...other work... # if [ $created_passwd = yes ] ; then /bin/chgrp --silent root /etc/passwd fi if [ $created_group = yes ] ; then /bin/chgrp --silent root /etc/group fi I misinterpreted the `chgrp --silent'. I thought it would result in an exit code of 0 from chgrp, but it just suppresses the error messages. Sorry about that. And you're missing the other point that I've just explained on cygwin-apps@, see http://www.cygwin.com/ml/cygwin-apps/2010-08/msg00116.html No, I didn't. 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 Security Performance Issues
On 8/12/2010 9:48 AM, David Law wrote: Yes, go waste someone elses time instead. I got exactly the information I needed for my meeting tomorrow. Is it too much to hope that what you got is, Don't use Cygwin. They had the nerve to *ask* me to conform to their list posting rules, and that hurt my feelings and made me irrationally angry? -Jeremy -- 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
Am 12.08.2010 16:54, schrieb Corinna Vinschen: On Aug 12 16:52, Matthias Andree wrote: Am 12.08.2010 16:40, schrieb Corinna Vinschen: On Aug 12 16:10, Matthias Andree wrote: Am 12.08.2010 15:37, schrieb Jeremy Ramer: I verified that $created_passwd and $created_group were both no so both conditionals will fail. But because the last conditional is the last thing run, the script returns 1. Adding an exit 0 to the script fixes it, but I'm not sure if that accomplishes what you want from the script. PLEASE DON'T. Adding an exit 0 will mask the error and just reinstate the former state of silently failing postinstall scripts more rigidly. This is not desirable. The proper way to fix this is: set -e # this is providing that the whole script is written properly. # it causes immediate exit after one command (outside if, and # outside || or lists) fails - usually desirable, but takes more # work because you can't write the scripts as sloppily as the # snippet you've just shown from passwd-grp.sh. # # ...other work... # if [ $created_passwd = yes ] ; then /bin/chgrp --silent root /etc/passwd fi if [ $created_group = yes ] ; then /bin/chgrp --silent root /etc/group fi I misinterpreted the `chgrp --silent'. I thought it would result in an exit code of 0 from chgrp, but it just suppresses the error messages. Sorry about that. And you're missing the other point that I've just explained on cygwin-apps@, see http://www.cygwin.com/ml/cygwin-apps/2010-08/msg00116.html No, I didn't. Sorry to be so unrelenting, but you are still missing the point. Please re-read Jeremy's analysis at http://cygwin.com/ml/cygwin/2010-08/msg00285.html. NOTE: *chgrp was not ever run* in the failing scenario, so whatever you pass as chgrp arguments, --silent or not, is irrelevant. What actually happened was: created_group=no ... [ $created_group = yes ] # remainder short-circuited, failure stands And since this [ ] line was the last in the script, the failure from the [ (= test) command propagated through to the caller and finally through setup.exe which duly reported it. -- Matthias Andree -- 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: Re: CygWin Security Performance Issues
You're fighting a battle thats already lost. :-) (as you would know if you had understood the german wiki) Best Regards, DaveLaw - original message Subject: Re: CygWin Security Performance Issues Sent: Thu, 12 Aug 2010 From: Corinna Vinschencorinna-cyg...@cygwin.com On Aug 12 16:47, David Law wrote: (Oh, by the way, for those of you who don't speak German, Text Oben, Fullquote Unten is just as meaningless) http://de.wikipedia.org/wiki/TOFU http://en.wikipedia.org/wiki/TOFU 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 --- original message end -- 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
On Aug 12 17:04, Matthias Andree wrote: Am 12.08.2010 16:54, schrieb Corinna Vinschen: On Aug 12 16:52, Matthias Andree wrote: Am 12.08.2010 16:40, schrieb Corinna Vinschen: I misinterpreted the `chgrp --silent'. I thought it would result in an exit code of 0 from chgrp, but it just suppresses the error messages. Sorry about that. And you're missing the other point that I've just explained on cygwin-apps@, see http://www.cygwin.com/ml/cygwin-apps/2010-08/msg00116.html No, I didn't. Sorry to be so unrelenting, but you are still missing the point. No, I didn't. Think about it. And whatever I missed or not missed, can we please stop a moot discussion? 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: Re: CygWin Security Performance Issues
On Aug 12 17:06, David Law wrote: You're fighting a battle thats already lost. :-) (as you would know if you had understood the german wiki) David, I don't care. Use my reply to your OP in your meeting and be happy. You're welcome, 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 Security Performance Issues
Yes, go waste someone elses time instead. So your time was wasted, and yet ... I got exactly the information I needed for my meeting tomorrow. ... with never a word of thanks, only insults. -- 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 Security Performance Issues
On Thu, Aug 12, 2010 at 10:00:02AM -0500, Jeremy Bopp wrote: On 8/12/2010 9:48 AM, David Law wrote: Yes, go waste someone elses time instead. I got exactly the information I needed for my meeting tomorrow. Is it too much to hope that what you got is, Don't use Cygwin. They had the nerve to *ask* me to conform to their list posting rules, and that hurt my feelings and made me irrationally angry? And remember You won't like us when you're angry. 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: Postinstall script errors
Am 12.08.2010 17:15, schrieb Corinna Vinschen: On Aug 12 17:04, Matthias Andree wrote: Am 12.08.2010 16:54, schrieb Corinna Vinschen: On Aug 12 16:52, Matthias Andree wrote: Am 12.08.2010 16:40, schrieb Corinna Vinschen: I misinterpreted the `chgrp --silent'. I thought it would result in an exit code of 0 from chgrp, but it just suppresses the error messages. Sorry about that. And you're missing the other point that I've just explained on cygwin-apps@, see http://www.cygwin.com/ml/cygwin-apps/2010-08/msg00116.html No, I didn't. Sorry to be so unrelenting, but you are still missing the point. No, I didn't. Think about it. And whatever I missed or not missed, can we please stop a moot discussion? I thought about it and reviewed the messages, my opinion still stands, but I agree to quit a discussion that isn't proceeding to anywhere. -- Matthias Andree -- 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 UNIX FILE PATH LEAVES FILES UNDELETABLE THROUGH WIN7
I'm a new user and just recently tried to install cygwin 1.7.5, after installing JAVA NetBeans. I wanted to install the C++ packages along with Python. Below is a sample of what occurred. copied from the output of... cygcheck -s -v -r cygcheck.out - 2010/08/08 06:44:15 running: D:\Cplus\bin\bash.exe --norc --noprofile /etc/postinstall/gcc4-core.sh 2010/08/08 06:44:19 abnormal exit: exit code=126 2010/08/08 06:48:34 running: D:\Cplus\bin\bash.exe --norc --noprofile /etc/postinstall/gtk2.0.sh 2010/08/08 06:48:44 abnormal exit: exit code=127 2010/08/08 07:11:53 running: D:\Cplus\bin\bash.exe --norc --noprofile /etc/postinstall/post-texmf.sh 2010/08/08 07:40:39 can't run /etc/postinstall/post-texmf.sh: No such file 2010/08/08 07:41:00 running: D:\Cplus\bin\bash.exe --norc --noprofile /etc/postinstall/gcc4-core.sh 2010/08/08 07:41:03 abnormal exit: exit code=126 2010/08/08 07:41:03 running: D:\Cplus\bin\bash.exe --norc --noprofile /etc/postinstall/gtk2.0.sh 2010/08/08 07:41:12 abnormal exit: exit code=127 2010/08/08 07:41:12 Changing gid to Administrators 2010/08/08 08:25:10 note: Installation Complete 2010/08/08 08:25:10 Ending cygwin install - I had uninstalled the total cygwin package by deleting all the directories made for this software, because cygwin did not show in the list of installed programs in the Control Panel utility Programs Features in Windows 7 OS. After the deletions, only one directory and file were unable to be deleted, the file named nul in the directory dev . A popup window notified me of the problem but was not specific. After much brainstorming, I booted up into a LINUX environment, located the /my Cplus dir/dev/nul directory and file. Using the file manager, I was able to delete the items. I have read browsed much of the documentation, at the moment, that's possible and tried to be sure this issue hasn't been covered. I believe that is the case. I'm a retired NASA contractor. UNIX System Administrator for Real-Time Systems being one of my task, I hope this has given me enough knowledge to know when I need further assistance. I tried to subscribe to the cygwin.com mailing list. But the email returned with an unknown address error. I have recheck this address cygwin-subscr...@cygwin.com and still returns a failure notice. Thank You for your time for reading this and any assistance you may offer. Richard Stern -- 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
Mintty versus xterm colors in Vim
Hello, Consider a .vimrc containing only the following line: syntax on Consider the following test.f fortran file: __ c Version 1.0 *deck main c Following comments when not preceded by a blank line character nvarbeta*8,nvarnhug*8,nvarpfus*8,nvarflux*8 parameter (nbtnap=51,nbrnnap=51) external f0tfnpadd,fntaudiv,fnigana,f0gdadureeflux, f0fhetauhesenflux,f0fhetauhesedureenflux,f0fhetauhesedureetflux, f0tigpfus,f0f1igpfus,f0gdhigpfus,f0fhetauhesengdh common/coalphabetatilde/alphantilde,alphattilde,betattilde,nbit, info common/coonetwo/one,two common/coidrhopedballoon/irhopedballoon common/cocd/gamacd10,gamacd20 common/cogdq/gdq ___ 1/ Launch the XWin server shortcut to get an xterm terminal Type: vim test.f test.f opens with the following colors: *, =, / are in a readable dark brown Continuation is in yellow 2/ Open a Mintty terminal with black foreground and white background Type vim test.f test.f opens with the following colors: *, =, / are in a difficultly readable light brown Continuation is in yellowish gray It is possible to have xterm colors in Mintty? Best regards Jean Johner -- 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 UNIX FILE PATH LEAVES FILES UNDELETABLE THROUGH WIN7
On Thu, Aug 12, 2010 at 11:53 AM, Richard Stern wrote: I had uninstalled the total cygwin package by deleting all the directories made for this software, because cygwin did not show in the list of installed programs in the Control Panel utility Programs Features in Windows 7 OS. After the deletions, only one directory and file were unable to be deleted, the file named nul in the directory dev . A popup window notified me of the problem but was not specific. After much brainstorming, I booted up into a LINUX environment, located the /my Cplus dir/dev/nul directory and file. Using the file manager, I was able to delete the items. I have read browsed much of the documentation, at the moment, that's possible and tried to be sure this issue hasn't been covered. I believe that is the case. I'm a retired NASA contractor. UNIX System Administrator for Real-Time Systems being one of my task, I hope this has given me enough knowledge to know when I need further assistance. I tried to subscribe to the cygwin.com mailing list. But the email returned with an unknown address error. I have recheck this address cygwin-subscr...@cygwin.com and still returns a failure notice. Thank You for your time for reading this and any assistance you may offer. Richard Stern http://cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all best steps to follow to completely remove it http://cygwin.com/faq/faq-nochunks.html#faq.using.dos-filenames brief mention of using special file names like AUX, COM, etc http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-dosdevices another mention of those special file names -- 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
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 Tilman -- 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: vi and vim
On 2010-08-11, Larry Hall (Cygwin) wrote: On 8/11/2010 12:22 PM, Dave Robison wrote: Hello, At the risk of bringing down a cascade of derision, is there any way to use vi instead of vim in cygwin? I really prefer vi, but I can't seem to find a binary for it which isn't linked to one iteration or another of vim. If not, c'est la vie. Cygwin provides the vim package, which creates a link to 'vim-nox.exe' called 'vi'. Unless you set 'nocompatible' in your ~/.vimrc, you will get a vi-compatible version of vim. Actually, just the presence of ~/.vimrc will set 'nocompatible'. See :help compatible-default If you want a vi-compatible vim, name your rc file .exrc and not .vimrc. Regards, Gary -- 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 Security amp;amp; Performance Issues
On 8/12/2010 10:02 AM, Corinna Vinschen wrote: Ok, I'll not waste my time and reply to you another time. That makes both of us happy. Is this what passes for professional behavior at Red Hat? -- Rob -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New package: {libsigc2.0/libsigc2.0_0/libsigc2.0-devel/libsigc2.0-doc}-2.2.8-1
Version 2.2.8-1 of libsigc has been uploaded. libsigc++ implements a typesafe callback system for standard C++. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New package: {libtorrent/libtorrent11/libtorrent-devel}-0.12.6-1
Version 0.12.6-1 of libtorrent has been uploaded. LibTorrent is a BitTorrent library written in C++ for *nix, with a focus on high performance and good code. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New package: rtorrent-0.8.6-1
Version 0.8.6-1 of rtorrent has been uploaded. rtorrent is an ncurses based bittorrent client. It is ideal for use with screen or dtach. It supports saving of sessions and allows the user to add and remove torrents. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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 Security ; Performance Issues
On Thu, Aug 12, 2010 at 02:29:27PM -0400, Robert Jacobson wrote: On 8/12/2010 10:02 AM, Corinna Vinschen wrote: Ok, I'll not waste my time and reply to you another time. That makes both of us happy. Is this what passes for professional behavior at Red Hat? This is off-topic. If you want to pursue the issue of professional behavior further then please use the cygwin-talk mailing list. That's what it is for. I'll be posting my reply there. Please do not reply further in this vein in the cygwin list. 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 Security amp;amp; Performance Issues
* On Thu, Aug 12, 2010 at 02:29:27PM -0400 Robert Jacobson wrote: On 8/12/2010 10:02 AM, Corinna Vinschen wrote: Ok, I'll not waste my time and reply to you another time. That makes both of us happy. Is this what passes for professional behavior at Red Hat? You mean, the co-leader of the project should let herself be insulted from a person who got his answers, but did not even give a thank you? Note also that this is the open Cygwin list. That is, this is not a paid support channel. I would consider it more like some people give advice for free, and not necessarily with the hat of Red Hat. I'll go back in lurk mode again... Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.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: CygWin Security amp;amp; Performance Issues
On 8/12/2010 3:15 PM, Spiro Trikaliotis wrote: * On Thu, Aug 12, 2010 at 02:29:27PM -0400 Robert Jacobson wrote: On 8/12/2010 10:02 AM, Corinna Vinschen wrote: Ok, I'll not waste my time and reply to you another time. That makes both of us happy. Is this what passes for professional behavior at Red Hat? You mean, the co-leader of the project should let herself be insulted from a person who got his answers, but did not even give a thank you? Note also that this is the open Cygwin list. That is, this is not a paid support channel. I would consider it more like some people give advice for free, and not necessarily with the hat of Red Hat. I'll go back in lurk mode again... Please, let's close down this off-topic thread as Chris requested: http://cygwin.com/ml/cygwin/2010-08/msg00316.html -- 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: Mintty versus xterm colors in Vim
On 12 August 2010 18:30, JOHNER Jean 066030 wrote: Hello, Consider a .vimrc containing only the following line: syntax on Consider the following test.f fortran file: __ c Version 1.0 *deck main c Following comments when not preceded by a blank line character nvarbeta*8,nvarnhug*8,nvarpfus*8,nvarflux*8 parameter (nbtnap=51,nbrnnap=51) external f0tfnpadd,fntaudiv,fnigana,f0gdadureeflux, f0fhetauhesenflux,f0fhetauhesedureenflux,f0fhetauhesedureetflux, f0tigpfus,f0f1igpfus,f0gdhigpfus,f0fhetauhesengdh common/coalphabetatilde/alphantilde,alphattilde,betattilde,nbit, info common/coonetwo/one,two common/coidrhopedballoon/irhopedballoon common/cocd/gamacd10,gamacd20 common/cogdq/gdq ___ 1/ Launch the XWin server shortcut to get an xterm terminal Type: vim test.f test.f opens with the following colors: *, =, / are in a readable dark brown Continuation is in yellow 2/ Open a Mintty terminal with black foreground and white background Type vim test.f test.f opens with the following colors: *, =, / are in a difficultly readable light brown Continuation is in yellowish gray Looks like vim automatically enables 256-color mode in xterm. Invoke vim with TERM=xterm-256color to enable it in mintty too. (You can set that variable on the 'Output' page of mintty's options. Requires a restart of mintty to take effect.) 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: CygWin Security Performance Issues
Maybe the co-leader of the project should channel her efforts into just that, rather than getting peoples backs up with unnecessary nitpicking about how she thinks they should structure their emails. Best Regards, DaveLaw On 12.08.2010 21:15, Spiro Trikaliotis wrote: * On Thu, Aug 12, 2010 at 02:29:27PM -0400 Robert Jacobson wrote: On 8/12/2010 10:02 AM, Corinna Vinschen wrote: Ok, I'll not waste my time and reply to you another time. That makes both of us happy. Is this what passes for professional behavior at Red Hat? You mean, the co-leader of the project should let herself be insulted from a person who got his answers, but did not even give a thank you? Note also that this is the open Cygwin list. That is, this is not a paid support channel. I would consider it more like some people give advice for free, and not necessarily with the hat of Red Hat. I'll go back in lurk mode again... Regards, Spiro. -- 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 Security Performance Issues
On Thu, Aug 12, 2010 at 10:17:44PM +0200, DaveLaw wrote: Maybe the co-leader of the project should channel her efforts into just that, rather than getting peoples backs up with unnecessary nitpicking about how she thinks they should structure their emails. Welcome to the cygwin mailing list deny list. Any other takers? 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 UNIX FILE PATH LEAVES FILES UNDELETABLE THROUGH WIN7
The directory D:\Cplus I created during setup. the \dev\ directory was created by the installation along with the file named nul. Is it possible that setup misnamed this file nul when it should have reflected the POSIX \dev\null WIN32 substitute? Also, in my last email I listed some errors which were cut form your reply, concerning abnormal exit: exit code=126 abnormal exit: exit code=127 What are these errors? I wouldn't bother you with this but I found no definitive answers while searching through the cygwin mail archives. In addition I need to resolve the problem I'm having with subscribing to the email message board. Is the following address correct? cygwin-subscr...@cygwin.com Regards... Richard See http://www.cygwin.com/ml/cygwin/2010-04/msg01047.html for suggestions on why you are getting the abnormal exit codes. Also, this http://www.google.com/search?q=site%3Acygwin.com%20inurl%3Aml%2F%20abnormal%20exit I don't know why are having problems subscribing to the list. I don't know why you had the problem with /dev/nul -Jason -- 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
diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
I hope this list accepts attachments. endian.h.diff Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
On Thu, Aug 12, 2010 at 07:56:31PM -0300, Pedro Izecksohn wrote: I hope this list accepts attachments. It does but the list mind-reading gizmo is on the fritz. -- 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 08/12/2010 04:58 PM, Christopher Faylor wrote: On Thu, Aug 12, 2010 at 07:56:31PM -0300, Pedro Izecksohn wrote: I hope this list accepts attachments. It does but the list mind-reading gizmo is on the fritz. Translation - a ChangeLog entry justifying your changes, a diff in unified or context format (-u or -c) rather than the default ed format, and attaching the patch inline with a text/plain MIME type instead of base64 encoded, are all necessary before anyone is likely to act on your proposed patch. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: CYGWIN UNIX FILE PATH LEAVES FILES UNDELETABLE THROUGH WIN7
After the deletions, only one directory and file were unable to be deleted, the file named nul in the directory dev . This is well known (if you're an old timer - think cp/m, then DOS) as it's a reserved word. CON: NUL: LPT!: are all examples of this. The solution is easy: :: for files del \\.\c:\cygwin\dev\nul :: for dirs rd \\.\c:\cygwin\dev\con more info @ http://support.microsoft.com/kb/120716 cheers, Dave -- 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
--- Eric Blake wrote: Christopher Faylor wrote: I wrote: I hope this list accepts attachments. It does but the list mind-reading gizmo is on the fritz. Translation - a ChangeLog entry justifying your changes, a diff in unified or context format (-u or -c) rather than the default ed format, and attaching the patch inline with a text/plain MIME type instead of base64 encoded, are all necessary before anyone is likely to act on your proposed patch. Defines macros for to convert the endianness of 16, 32 and 64 bits integer types. diff -c /usr/include/endian.orig.h /usr/include/endian.h *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 12 19:40:20 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,82 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #ifdef _BSD_SOURCE + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #include byteswap.h + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #else /* __BYTE_ORDER == __BIG_ENDIAN */ + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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
bash postinstall script returns an error
I was going to mention passwd-grp.sh, but I see there's already a thread for that, so I'll move right on to the next one. When I run setup.exe I always get an error for the bash.sh postinstall script, it seems to be on the line of: /bin/test -e /dev/stdin || ln -s /proc/self/fd/0 /dev/stdin || result=1 I'm not so clear as to why this fails. test returns a status of 1 when the script is run by the installer, and yet /dev/stdin does exist. setup.log.full contains a predictable ln: creating symbolic link `/dev/stdin': File exists. If I run the postinstall script manually, test gives a status of 0, stdin is left alone and the script runs to the end successfully - it only fails when run from inside the installer (2.712) for me. I've tried invoking bash for the script using the same switches as those reported in setup.log.full, but it still runs fine when done manually. If I remove /dev/stdin /dev/stdout and /dev/stderr the installer runs through fine. The result isn't a big problem since the files exist, but it does seem odd. Paul -- 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
--- I wrote: Defines macros for to convert the endianness of 16, 32 and 64 bits integer types. diff -c /usr/include/endian.orig.h /usr/include/endian.h My previous diff is wrong. The right one follows: *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 12 21:28:01 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,83 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #ifdef _BSD_SOURCE + + #include byteswap.h + + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #else /* __BYTE_ORDER == __BIG_ENDIAN */ + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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
Emacs and DBUS
Hi, 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. Thanks. -- 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
libpng14-devel does not provide libpng.dll.a
Chuck, libpng14-devel provides libpng.a and libpng.la symlinks, but no libpng.dll.a symlink. I presume this is unintentional? Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: libpng-1.4.3-1; NEW: {libpng14/libpng14-devel}-1.4.3-1
On Sun, 2010-08-08 at 00:39 -0400, Charles Wilson wrote: The libpng packages offer the standard libraries for manipulating PNG files, a turbo-studly lossless image format. This is a major update to the libpng-1.4.x series. [[ compiled using gcc-4.3.4-3 ]] CHANGES (since 1.2.44-1) o update to latest official release of libpng-1.4.x o ABI change upstream so DLL is now provided by the new libpng14 package. FYI, package maintainers: A number of (obsolete) APIs were dropped from 1.4, meaning that a lot of packages may not build OOTB with libpng14. Here is a summary of the API changes in 1.4 to guide you in porting your packages: http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt Do also note that the Linux distros may also have a patch for their corresponding package, in which case you can add that to your PATCH_URI. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
For testing, I went out of my way and installed a local x64 Windows
Server 2008 Datacenter machine. Apart from updating to SP2 plus all the
latest Microsoft patches and configuring to match my environment, I have
not changed anything else, nor did I install any third-party software.
Then I installed a Cygwin Base install using the latest setup.exe.
It went 100% well. No fails in postinstall scripts. An interactive
bash started just fine.
Then I removed every trace of Cygwin from the machine and installed
Terminal Services, which is known to interfere badly with Cygwin
applications which don't have the TS-awareness flag set in the PE/COFF
header. I also installed any
Then I installed a Cygwin Base install using the latest setup.exe.
It went 100% well. No fails in postinstall scripts. An interactive
bash started just fine.
http://dch.posterous.com/cygwin-dumps-core-on-windows-2008-r1sp2-on-ec
So, this muse-ing of yours is not correct.
To me this implies that the Amazon Cloud VMs have some BLODA installed
by default. I'm not going to check this voluntarily. I suggest that
somebody who wants to run Cygwin on such a machine investigates this
further, or just asks Amazon to fix this and hope for the best.
Corinna
Thanks Corinna. I've not got w2008 server datacenter version to
install so that's pretty useful correlation - there must be something
funny in the EC2 AMI builds.
Others have encountered this too blamed a Xen bug - not sure if this
is a good interpretation but I can confirm that msys also fails with a
similar issue.
http://article.gmane.org/gmane.comp.emulators.xen.devel/73667
http://developer.amazonwebservices.com/connect/message.jspa?messageID=163059tstart=0
All that aside, I have done some further testing to see what security
features that are disabled in Windows 7/Vista are enabled in WS2008
DC edition:
- disabling the annoying UAC
- disabling DEP via bcdedit.exe /set {current} nx AlwaysOff
- disabling SEHOP (MS kb956607)
- disabling ASLR (ref
http://www.google.com/search?q=aslr+moveimages+%2Bsite:microsoft.com)
After toggling these settings on a standard virtualised windows 7
enterprise, I can't replicate the crash either on those OS so am
assuming there's something else.
Any other suggestions from the list of things that would be worth trying?
The muse-ing will be tweaked to be clear that this bug is only on the
publically available EC2 install I'll see how I get on with asking
amazon for a fix.
For reference here is the event log entry generated by bash.exe -
0xc005 presumably being a memory access violation, another one
from sh.exe, and a similar one from cmd.exe which is clearly not
cygwin related.
Log Name: Application
Source:Application Error
Date: 8/13/2010 2:05:30 AM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: ip-0AC1368F
Description:
Faulting application bash.exe, version 0.0.0.0, time stamp 0x4a18506d,
faulting module unknown, version 0.0.0.0, time stamp 0x,
exception code 0xc005, fault offset 0x75ba9b89, process id 0xa3c,
application start time 0x01cb3a839fa7f602.
and a similar one in sh.exe provides this stack dump:
Exception: STATUS_ACCESS_VIOLATION at eip=77574381
eax= ebx=0040 ecx= edx= esi=00F800F0 edi=0027C7C4
ebp=0027C778 esp=0027C760 program=C:\cygwin\bin\sh.exe, pid 2432, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0027C778 77574381 (0013, 00F800F0, 0040, 0027C7C4)
00FB8770 610341EE (, , , )
3 [main] sh 2432 exception::handle: Error while dumping state
(probably corrupted stack)
Event Xml:
Event xmlns=http://schemas.microsoft.com/win/2004/08/events/event;
System
Provider Name=Application Error /
EventID Qualifiers=01000/EventID
Level2/Level
Task100/Task
Keywords0x80/Keywords
TimeCreated SystemTime=2010-08-13T01:05:30.000Z /
EventRecordID876/EventRecordID
ChannelApplication/Channel
Computerip-0AC1368F/Computer
Security /
/System
EventData
Databash.exe/Data
Data0.0.0.0/Data
Data4a18506d/Data
Dataunknown/Data
Data0.0.0.0/Data
Data/Data
Datac005/Data
Data75ba9b89/Data
Dataa3c/Data
Data01cb3a839fa7f602/Data
/EventData
/Event
I have also managed to get a similar symptom crash on windows own cmd.exe -
Log Name: Application
Source:Application Error
Date: 8/13/2010 3:00:41 AM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: ip-0AC1368F
Description:
Faulting application cmd.exe, version 6.0.6001.18000, time stamp
0x47919317, faulting module ntdll.dll, version 6.0.6002.18005, time
stamp 0x49e0421d, exception code 0xc005, fault offset
0x000468a7, process id 0x348, application
New package: {libsigc2.0/libsigc2.0_0/libsigc2.0-devel/libsigc2.0-doc}-2.2.8-1
Version 2.2.8-1 of libsigc has been uploaded. libsigc++ implements a typesafe callback system for standard C++. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
New package: {libtorrent/libtorrent11/libtorrent-devel}-0.12.6-1
Version 0.12.6-1 of libtorrent has been uploaded. LibTorrent is a BitTorrent library written in C++ for *nix, with a focus on high performance and good code. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
