Re: [ITP] mingw-w64 (32-bit)
On 9/16/2010 9:38 AM, JonY wrote: I have uploaded the 32bit toolchain, I hope there are no thinkos when adapting the cygport files. All packages rebuild from source ok. Packaging looks good; I used them to build a working xz and liblzma with no trouble. genini is happy with the setup.hints (although the -header one pasted inline was incorrect, but the one on the sf site was good). All packages GTG, and uploaded. -- Chuck
Re: [ITP] Onigurama-5.9.2
On Thu, Sep 16, 2010 at 08:12:48PM +, Marco Atzeri wrote: --- Gio 16/9/10, David Sastre ha scritto: On Thu, Sep 16, 2010 at 10:08:54AM +, Marco Atzeri wrote: Hi thinking about packaging slrn I decided to start from its dependency Oniguruma - S-lang - slrn Just in case it could be useful in any way, I've attached a cygport file for S-Lang. AFAICT, it builds and works OK. The only thing to care about is building with -j1, otherwise it fails. David, I guess you are using a patched version of s-lang, but your source is not reachable cygport slang-2.2.2-1.cygport almostall Preparing slang-2.2.2-1 *** ERROR: Cannot find source package slang-2.2.2.tar.bz2 Weird... Wait a second...I know what has happened. You need to get the source first. :-) $ cygport slang-2.2.2-1.cygport get prep --2010-09-17 10:32:13-- ftp://space.mit.edu/pub/davis/slang/v2.2/slang-2.2.2.tar.bz2 = `slang-2.2.2.tar.bz2.tmp' Resolving space.mit.edu (space.mit.edu)... 18.75.0.10 Connecting to space.mit.edu (space.mit.edu)|18.75.0.10|:21... connected. Logging in as anonymous ... Logged in! == SYST ... done.== PWD ... done. == TYPE I ... done. == CWD (1) /pub/davis/slang/v2.2 ... done. == SIZE slang-2.2.2.tar.bz2 ... 1366850 == PASV ... done.== RETR slang-2.2.2.tar.bz2 ... done. Length: 1366850 (1.3M) (unauthoritative) 100%[] 1,366,850387K/s in 3.9s 2010-09-17 10:32:20 (339 KB/s) - `slang-2.2.2.tar.bz2.tmp' saved [1366850] Preparing slang-2.2.2-1 Unpacking source slang-2.2.2.tar.bz2 Preparing working source directory *** Info: applying patch slang-2.2.2-1.cygwin.patch: patching file CYGWIN-PATCHES/devel.hint patching file CYGWIN-PATCHES/modules.hint patching file CYGWIN-PATCHES/runtime.hint patching file CYGWIN-PATCHES/setup.hint patching file CYGWIN-PATCHES/shell.hint patching file CYGWIN-PATCHES/slang.README For what I saw s-lang is built by every distribution with a long list of patches I overlooked that... and moreover I hate a package that use autoconf and does not allow to build in a separate directory from source. My source Aesthetics asks me to make some autoconf/automake cleaning, and to build in a separate directory. I hope it will not take too long. Agree. I wasn't smart enough to do that either. I'm looking forward to see S-Lang in the distro! Thanks. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITP] Onigurama-5.9.2
--- Ven 17/9/10, David Sastre ha scritto: On Thu, Sep 16, 2010 at 08:12:48PM David, I guess you are using a patched version of s-lang, but your source is not reachable cygport slang-2.2.2-1.cygport almostall Preparing slang-2.2.2-1 *** ERROR: Cannot find source package slang-2.2.2.tar.bz2 Weird... Wait a second...I know what has happened. You need to get the source first. :-) $ cygport slang-2.2.2-1.cygport get prep I forgot that almostall don't include get :-( Thanks Marco
New package: mingw64-i686-headers-1.0b_svn3433-1
Version 1.0b_svn3433-1 of mingw64-i686-headers has been uploaded. mingw64-i686-headers contains headers for Windows development. This package is specifically for the 32bit target toolchain. *** 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.
Re: New package: mingw64-i686-headers-1.0b_svn3433-1
Sorry, wrong list, please ignore.
Re: [ITP] mingw-w64 (32-bit)
On 9/17/2010 16:17, Charles Wilson wrote: On 9/16/2010 9:38 AM, JonY wrote: I have uploaded the 32bit toolchain, I hope there are no thinkos when adapting the cygport files. All packages rebuild from source ok. Packaging looks good; I used them to build a working xz and liblzma with no trouble. genini is happy with the setup.hints (although the -header one pasted inline was incorrect, but the one on the sf site was good). All packages GTG, and uploaded. -- Chuck Thanks.
Re: [ITP] mingw-w64 (32-bit)
On Sep 17 04:17, Charles Wilson wrote: On 9/16/2010 9:38 AM, JonY wrote: I have uploaded the 32bit toolchain, I hope there are no thinkos when adapting the cygport files. All packages rebuild from source ok. Packaging looks good; I used them to build a working xz and liblzma with no trouble. genini is happy with the setup.hints (although the -header one pasted inline was incorrect, but the one on the sf site was good). All packages GTG, and uploaded. cygwin-pkg-maint? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[ITA] - base-files base-passwd
Hello,
Regarding the ITA of these packages, and the proposed patches, I have
some thoughts to share and discuss before I repackage them.
1 http://sourceware.org/ml/cygwin/2010-04/msg00521.html
case sensitivity of system32 dir (win7 and vista)
2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html
PS1 not inherited by interactive shells with a non interactive
ancestry
3 http://sourceware.org/ml/cygwin/2010-05/msg0.html
PS1 setting for *ksh shells
4 Merging base-files and base passwd together.
5 http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html
/home security problem
1 This is a simple fix, so it'd be applied.
2 This could be solved by redefinig the skeletal files for every shell
(more below).
3 This one might deserve some discussion:
Because of, as of now, the default shell in cygwin is bash, as I see it,
there are two possible approaches:
a) base-files provides the skel defaults and profile.d/ for the bash shell
and delegates in the other shells' packages the way they want to set PS1,
and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or
/etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system.
(bash-sh, tcsh-csh, mksh-ksh, etc...).
The same would apply for every shell (bash, mksh, tcsh, posh, dash).
This is currently the approach in the case of tcsh (except for
/etc/defaults/etc/profile.d/lang.csh)
b) base-files provides skel defaults and profile.d customizations for
every shell (some are common: i.e. /etc/skel/.profile).
What do you people think?
4 Can we consider this? what are the circular dependencies in that scenario?
AFAICT, including base-passwd in base-files, and afterwards dropping
base-passwd dependencies anywhere else should be harmless.
5 As stated in the referenced thread, there is no way to prevent attackers
to create a user's home dir before she/he logins the first time other than
disallowing anyone but the Administrator to do that.
If the proposed workaround (issuing a warning if $HOME already exists and
is owned by someone else) is considered enough, I'll include it.
I haven't thought of anything better than that.
TIA for the feedback.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] ocaml 3.12.0
On 2010-09-13, at 06:12, Yaakov (Cygwin/X) wrote: gcc3 is deprecated; distro packages should be built with gcc4, and all Ports packages for Cygwin 1.7 are built with gcc4. So OCaml definitely builds with gcc4. I checked and yes it works. How soon can you rebuild ocaml with gcc4 and flexdll-0.25-1? I'm having personal problems right now, so it will likely be two or three weeks. Sorry. -- Damien
Re: [ITA] - base-files base-passwd
On Fri, Sep 17, 2010 at 01:59:32PM +0200, David Sastre wrote: 4 Can we consider this? what are the circular dependencies in that scenario? AFAICT, including base-passwd in base-files, and afterwards dropping base-passwd dependencies anywhere else should be harmless. Unless Corinna disagrees, I'd rather not. I'd rather keep the two separate. cgf
Re: [ITP] mingw-w64 (32-bit)
On Sep 17 10:33, Charles Wilson wrote: On 9/17/2010 7:24 AM, Corinna Vinschen wrote: cygwin-pkg-maint? Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files base-passwd
On Sep 17 13:59, David Sastre wrote:
Hello,
Regarding the ITA of these packages, and the proposed patches, I have
some thoughts to share and discuss before I repackage them.
1 http://sourceware.org/ml/cygwin/2010-04/msg00521.html
case sensitivity of system32 dir (win7 and vista)
2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html
PS1 not inherited by interactive shells with a non interactive
ancestry
3 http://sourceware.org/ml/cygwin/2010-05/msg0.html
PS1 setting for *ksh shells
4 Merging base-files and base passwd together.
5 http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html
/home security problem
1 This is a simple fix, so it'd be applied.
2 This could be solved by redefinig the skeletal files for every shell
(more below).
3 This one might deserve some discussion:
Because of, as of now, the default shell in cygwin is bash, as I see it,
there are two possible approaches:
a) base-files provides the skel defaults and profile.d/ for the bash shell
and delegates in the other shells' packages the way they want to set PS1,
and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or
/etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system.
(bash-sh, tcsh-csh, mksh-ksh, etc...).
The same would apply for every shell (bash, mksh, tcsh, posh, dash).
This is currently the approach in the case of tcsh (except for
/etc/defaults/etc/profile.d/lang.csh)
b) base-files provides skel defaults and profile.d customizations for
every shell (some are common: i.e. /etc/skel/.profile).
Tcsh is somewhat different from the other shells because it's using
an entirly different script syntax.
WHat's wrong with the proposed patch? The only problem I have with it
is the fact that it uses tr and sed to find out what shell it's running
in. There is probably a way to do this without starting more processes.
Like this:
read x /proc/self/exename
case $x in
*/bash)
...
*/dash|*/ash|*/sh)
...
*/ksh)
...
*/zsh)
...
*
...
What do you people think?
4 Can we consider this? what are the circular dependencies in that scenario?
AFAICT, including base-passwd in base-files, and afterwards dropping
base-passwd dependencies anywhere else should be harmless.
I agree with Chris. Let's keep them separate. I can imagine that the
process to create default /etc/passwd and /etc/group files might change
in the future (more intelligent, no such files at all, you name it), and
there's no reason to change base-files in that case.
5 As stated in the referenced thread, there is no way to prevent attackers
to create a user's home dir before she/he logins the first time other than
disallowing anyone but the Administrator to do that.
If the proposed workaround (issuing a warning if $HOME already exists and
is owned by someone else) is considered enough, I'll include it.
I haven't thought of anything better than that.
It's good enough for a start. If we come up with a better solution,
we can still change it, right?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] - base-files base-passwd
On Fri, Sep 17, 2010 at 04:50:40PM +0200, Corinna Vinschen wrote:
On Sep 17 13:59, David Sastre wrote:
Regarding the ITA of these packages, and the proposed patches, I have
some thoughts to share and discuss before I repackage them.
2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html
PS1 not inherited by interactive shells with a non interactive
ancestry
3 http://sourceware.org/ml/cygwin/2010-05/msg0.html
PS1 setting for *ksh shells
4 Merging base-files and base passwd together.
5 http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html
/home security problem
3 This one might deserve some discussion:
Because of, as of now, the default shell in cygwin is bash, as I see it,
there are two possible approaches:
a) base-files provides the skel defaults and profile.d/ for the bash
shell
and delegates in the other shells' packages the way they want to set PS1,
and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or
/etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system.
(bash-sh, tcsh-csh, mksh-ksh, etc...).
The same would apply for every shell (bash, mksh, tcsh, posh, dash).
This is currently the approach in the case of tcsh (except for
/etc/defaults/etc/profile.d/lang.csh)
b) base-files provides skel defaults and profile.d customizations for
every shell (some are common: i.e. /etc/skel/.profile).
Tcsh is somewhat different from the other shells because it's using
an entirly different script syntax.
WHat's wrong with the proposed patch? The only problem I have with it
is the fact that it uses tr and sed to find out what shell it's running
in. There is probably a way to do this without starting more processes.
Like this:
read x /proc/self/exename
case $x in
*/bash)
...
*/dash|*/ash|*/sh)
...
*/ksh)
...
*/zsh)
...
*
...
Absolutely nothing is wrong with the patch. I'm only thinking about
an unified method for supplying skeletal files, regardless the
shell. I mean, currently /etc/profile includes logic to deal with all kinds
of shells; being mksh an example, a /etc/skel/.mkshrc could be supplied,
to source a system-wide /etc/mkshrc provided by the mksh package,
this is a simplified example taken from Debian:
case $KSH_VERSION in
*MIRBSD\ KSH*) ;;
*) return 0 ;;
esac
[[ -s /etc/mkshrc ]] . /etc/mkshrc
This would be my solution to nº2 and nº3 above, i.e. PS1 is correctly
set and inherited, because every shell that needs it, provides a
system-wide *rc file to set PS1 and HOSTNAME, distributed with that
shell's package.
I think this is positive because it frees /etc/profile from a work
that can be done by the shells on-demand. Base-files would only
provide /etc/defaults/etc/skel/.${SHELL}rc files to source
/etc/${SHELL}rc, installed by the packages, unneeded otherwise.
BTW, mksh is the only *ksh shell in the distro, being pdksh orphaned
and unmaintained upstream.
Also, I am curious to know if there is a reason why
/etc/defaults/etc/profile.d/lang.csh is not included in tcsh.
4 Can we consider this? what are the circular dependencies in that scenario?
AFAICT, including base-passwd in base-files, and afterwards dropping
base-passwd dependencies anywhere else should be harmless.
I agree with Chris. Let's keep them separate. I can imagine that the
process to create default /etc/passwd and /etc/group files might change
in the future (more intelligent, no such files at all, you name it), and
there's no reason to change base-files in that case.
OK. No problem.
5 As stated in the referenced thread, there is no way to prevent attackers
to create a user's home dir before she/he logins the first time other than
disallowing anyone but the Administrator to do that.
If the proposed workaround (issuing a warning if $HOME already exists and
is owned by someone else) is considered enough, I'll include it.
I haven't thought of anything better than that.
It's good enough for a start. If we come up with a better solution,
we can still change it, right?
All right.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files base-passwd
On Sep 17 18:47, David Sastre wrote:
On Fri, Sep 17, 2010 at 04:50:40PM +0200, Corinna Vinschen wrote:
What's wrong with the proposed patch? The only problem I have with it
is the fact that it uses tr and sed to find out what shell it's running
in. There is probably a way to do this without starting more processes.
Like this:
read x /proc/self/exename
case $x in
*/bash)
...
*/dash|*/ash|*/sh)
...
*/ksh)
...
*/zsh)
...
*
...
Absolutely nothing is wrong with the patch.
Well, except that it calls tr and sed for a simple job which could be
handled entirely in the shell itself, but we had that already...
I'm only thinking about
an unified method for supplying skeletal files, regardless the
shell. I mean, currently /etc/profile includes logic to deal with all kinds
of shells; being mksh an example, a /etc/skel/.mkshrc could be supplied,
to source a system-wide /etc/mkshrc provided by the mksh package,
this is a simplified example taken from Debian:
case $KSH_VERSION in
*MIRBSD\ KSH*) ;;
*) return 0 ;;
esac
[[ -s /etc/mkshrc ]] . /etc/mkshrc
This would be my solution to nº2 and nº3 above, i.e. PS1 is correctly
set and inherited, because every shell that needs it, provides a
system-wide *rc file to set PS1 and HOSTNAME, distributed with that
shell's package.
I think this is positive because it frees /etc/profile from a work
that can be done by the shells on-demand. Base-files would only
provide /etc/defaults/etc/skel/.${SHELL}rc files to source
/etc/${SHELL}rc, installed by the packages, unneeded otherwise.
That sounds fine, but it requires that all other shell maintainers play
along. I think it makes sense to provide a short term solution which
does not involve changing all shell packages. The aforementioned solution
should be carefully discussed with all (bourne-like) shell maintainers
and released in a collective effort.
Who's affected?
bash Eric Blake
dash Eric Blake
mksh Chris Sutcliffe
posh Jari Aalto
zsh Peter A. Castro
pdksh orphaned (I guess we should remove it from the distro)
BTW, mksh is the only *ksh shell in the distro, being pdksh orphaned
and unmaintained upstream.
Don't forget posh. Oh, and, btw., whatever ksh derivative you use, it's
a ksh. So, IMHO, the startup file for all of them should be /etc/kshrc
or /etc/ksh.kshrc. This in turn speaks for keeping the startup files
centralized in base-files. But that's just me. I'm not affected
anyway, being a long-time tcsh user...
Also, I am curious to know if there is a reason why
/etc/defaults/etc/profile.d/lang.csh is not included in tcsh.
The tcsh package only contains files which are part of the upstream tcsh
package and we don't have a default-lang package, so it seemed quite
natural at the time. There are other packages as well, like openssl,
which provide *.sh and *.csh profiles.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] - base-files base-passwd
On 17 September 2010 15:50, Corinna Vinschen wrote: 5 As stated in the referenced thread, there is no way to prevent attackers to create a user's home dir before she/he logins the first time other than disallowing anyone but the Administrator to do that. If the proposed workaround (issuing a warning if $HOME already exists and is owned by someone else) is considered enough, I'll include it. I haven't thought of anything better than that. It's good enough for a start. If we come up with a better solution, we can still change it, right? I think there's little point in just adding a warning actually, because that wouldn't stop prepared startup scripts in the user's fake home from being sourced. Also, there likely are some users whose home directory is owned by someone else for innocuous reasons, e.g. because they themselves created it when they were logged in as administrator. And of course they wouldn't take kindly to a warning, and even less to a fatal error. If that sounds as if I don't know what should be done about this, that's because I don't. Andy
Re: [ITA] - base-files base-passwd
On Sep 17 21:23, Andy Koppe wrote: On 17 September 2010 15:50, Corinna Vinschen wrote: 5 As stated in the referenced thread, there is no way to prevent attackers to create a user's home dir before she/he logins the first time other than disallowing anyone but the Administrator to do that. If the proposed workaround (issuing a warning if $HOME already exists and is owned by someone else) is considered enough, I'll include it. I haven't thought of anything better than that. It's good enough for a start. If we come up with a better solution, we can still change it, right? I think there's little point in just adding a warning actually, because that wouldn't stop prepared startup scripts in the user's fake home from being sourced. Also, there likely are some users whose home directory is owned by someone else for innocuous reasons, e.g. because they themselves created it when they were logged in as administrator. And of course they wouldn't take kindly to a warning, and even less to a fatal error. Which is not a good idea anyway. The home dir should belong to the user. After all, Cygwin is not Windows(*) but a POSIX system. OpenSSH for instance checks if the home dir belongs to the user and has sufficiently strict permissions. Corinna (*) Yes, yes, I know. Don't rub it in. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[RFU] mintty-0.9b1-1
Please upload: wget http://mintty.googlecode.com/files/mintty-0.9b1-1.tar.bz2 wget http://mintty.googlecode.com/files/mintty-0.9b1-1-src.tar.bz2 wget http://mintty.googlecode.com/svn/tags/0.9-beta1/cygport/setup.hint This is a test release. The postinstall/preremove scripts put setup.exe's new CYGWINFORALL variable to use. Thanks, Andy
Re: [ITA] - base-files base-passwd
On 17 September 2010 21:43, Corinna Vinschen wrote: On Sep 17 21:23, Andy Koppe wrote: On 17 September 2010 15:50, Corinna Vinschen wrote: 5 As stated in the referenced thread, there is no way to prevent attackers to create a user's home dir before she/he logins the first time other than disallowing anyone but the Administrator to do that. If the proposed workaround (issuing a warning if $HOME already exists and is owned by someone else) is considered enough, I'll include it. I haven't thought of anything better than that. It's good enough for a start. If we come up with a better solution, we can still change it, right? I think there's little point in just adding a warning actually, because that wouldn't stop prepared startup scripts in the user's fake home from being sourced. Also, there likely are some users whose home directory is owned by someone else for innocuous reasons, e.g. because they themselves created it when they were logged in as administrator. And of course they wouldn't take kindly to a warning, and even less to a fatal error. Which is not a good idea anyway. The home dir should belong to the user. After all, Cygwin is not Windows(*) but a POSIX system. OpenSSH for instance checks if the home dir belongs to the user and has sufficiently strict permissions. Good point. Andy
Cygwin X causes system pauses
I have a recurring problem with Cygwin-X. First off, I'm my work laptop is running Win XP SP3. In general, the applications I have open are MS Outlook 2007, RealVNC, and of course xterm/xemacs. X1 (email indexing) runs in the background). I'm running some sort of Norton Enterprise Anti-virus (I can't find the icon for it). After some period of time, if I try to type something into an Outlook E-mail message, the text pauses (no echo), then after several/many seconds, it will appear (usually with the typos I didn't see). If I kill XWin.exe, then normal performance is restored. This problem is exacerbated (or happens sooner) if I'm doing a lot of cut/copy/paste in Emacs. A second problem is sometimes I copy text from a Windows app. then try to paste it into Emacs. Instead of the text showing up, I get an XWin hourglass and I'm pretty much hosed at this point (only the X system is hung, the rest of the PC is fine). Killing XWin.exe and restarting fixes this problem. I thought I had added the extra debug to my XWin log, but now I'm not so sure. The Outlook problem just happened a few mins ago, and here is the tail end of the XWin log file (repeated about 25 times): [1317564.000] winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY This has been an ongoing problem for months, it's not something that just started happening. Any idea how to debug this further? -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- 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/
[Fwd: Fw: res_send() doesn't work with osquery enabled]
- Forwarded message from Pierre A. Humblet - Date: Thu, 16 Sep 2010 12:43:33 -0400 From: Pierre A. Humblet Subject: Fw: res_send() doesn't work with osquery enabled To: Corinna Vinschen cori...@vinschen.de Corinna, this has not made it to the list so far, not sure why. I am leaving on a trip and don't have time to investigate, so sending it straight to you. Pierre - Original Message - From: Pierre A. Humblet To: cygwin-patches Sent: Thursday, September 16, 2010 9:52 Subject: Re: res_send() doesn't work with osquery enabled | - Original Message - | From: Corinna Vinschen | To: cygwin-patches | Sent: Friday, September 10, 2010 5:22 | | || Pierre? Ping? || | | Corinna, | | Sorry, an earlier answer was rejected due to inappropriate subject. | | After thinking about it, I don't like mixing calls to the Windows resolver | for res_query and contacting DNS servers directly with res_send, | as proposed. So I have a patch where res_send also uses the Windows | resolver. | | Unfortunately although I can build cygwin1.dll fine, it's broken, | something to do with a NULL stdout (this is from /bin/date) | 1 thread 2588.0x4c0 fputc (ch=10, file=0x0) | at ../../../../../src/newlib/libc/stdio/fputc.c:101 | | Not sure what to do, I already did make clean for cygwin. | | Also minires used to come with a README explaining the effect of | an optional /etc/resolv.conf (e.g. to bypass the Windows resolver). | That information is not present currently [ and nobody asks for it :) ] | I wonder if we should add it and where to place it. One option is the | User's Guide. Another option is a custom resolv.conf man page. | What do you think? | | Pierre - End forwarded message -
Re: [Fwd: Fw: res_send() doesn't work with osquery enabled]
On Sep 17 09:03, Corinna Vinschen wrote: - Forwarded message from Pierre A. Humblet - | Sorry, an earlier answer was rejected due to inappropriate subject. In theory, that should be fixed. | After thinking about it, I don't like mixing calls to the Windows resolver | for res_query and contacting DNS servers directly with res_send, | as proposed. So I have a patch where res_send also uses the Windows | resolver. | | Unfortunately although I can build cygwin1.dll fine, it's broken, | something to do with a NULL stdout (this is from /bin/date) | 1 thread 2588.0x4c0 fputc (ch=10, file=0x0) | at ../../../../../src/newlib/libc/stdio/fputc.c:101 | | Not sure what to do, I already did make clean for cygwin. I don't know either. I have no such problem with CVS HEAD. | Also minires used to come with a README explaining the effect of | an optional /etc/resolv.conf (e.g. to bypass the Windows resolver). | That information is not present currently [ and nobody asks for it :) ] | I wonder if we should add it and where to place it. One option is the | User's Guide. Another option is a custom resolv.conf man page. | What do you think? The User's Guide would be a good place, IMHO. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[ANNOUNCEMENT] New package: Onigurama {libonig2,liboning-devel}-5.9.2
Hi, Onigurama library is now available for cygwin. The version 5.9.2-1 of libonig2 liboning-devel have been uploaded. DESCRIPTION Oniguruma is a regular expressions library. The characteristics of this library is that different character encoding for every regular expression object can be specified. (supported APIs: GNU regex, POSIX and Oniguruma native) Supported character encodings: ASCII, UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, EUC-JP, EUC-TW, EUC-KR, EUC-CN, Shift_JIS, Big5, GB18030, KOI8-R, CP1251, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16 HOMEPAGE http://www.geocities.jp/kosako3/oniguruma/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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. -- 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 + Python: unable to remap
2010/9/17 Mark Geisert: Al writes: 2010/9/16 Mark Geisert: cygncurses5.dll = /home/prefix/gentoo/usr/bin/cygncurses5.dll (0x1000) This one is below the sixty million value that Reini described as suspicious. Now what do I make of that. Do I tell it to be loaded elsewhere? Any helpful link? You want 'rebase' from the 'rebase' package. Use setup.exe to install it if you don't have it already. After installation, it's documented in a text file /usr/share/doc/Cygwin/rebase*README. You get to choose the base address to rebase the dll to. 'rebaseall', from the same package, defaults to seventy million (= 0x7000) so that could be good. If you've built other dlls in the same directory you might as well run rebase or rebaseall on all of them to avoid future issues of this type. It's not that simple :) rebaseall only rebases the exact dll's which were installed from your packager (setup.exe), but not any other dll's used at run-time - shadowing system dll's as in your case, or added dependencies as with perl or python. python or perl are favorites adding additional dll's to your run-time because you can and should simply add external library bindings by yourself. In your case the simpliest fix would be to remove your /home/prefix/gentoo... prefix from your path. Or, if you have to, rebase your added dll to the same address as the original. imagebase: objdump -p $1 |grep ImageBase |cut -c12- -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: distro apache2 will not start
On Sep 16 20:14, Paul McFerrin wrote: Sorry for double posting, went to wrong mailing list!! - Hello: I guess I should have attached my httpd.conf file since I had to make changes in my configuration to avoid more changes.. For the record, both access_log and error_log were empty. I tried using -e 999 and -E /tmp/file but all I got was the help screen. Acts like those options (regardless) aren't in there. I tried everything to get more error info. All other options in the HELP screen seemed to work except for anything that has to do with error_level or -E. Supplying -k start on the httpd2 directly produces the same bad system call error as supplying start to apachectl2. One more thing, running httpd2 in debug mode (-X) produces same error message. Jas anyone else gotten apache 2.2.6 working under cygwin 1.7.7X. It was built over 3 years ago; prior to 1.7? The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. 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
warning messages while deleting cygwin folder
hi, i am trying to completely delete cygwin from my system, as it is taking up too much hard disk space. i followed the instructions at the cygwin.com FAQ by first removing any subscribed services. this worked fine. then, i went on to delete the c:\cygwin folder. but i received 2 warning messages, asking me if i want to delete 'copying' and 'changelog' which are both system files and that deleting them might affect other programs. after choosing not to delete either, the dialog box 'error deleting file or folder' appears, stating 'cannot remove folder help: the directory is not empty'. should i delete these 2? and any other such warnings thereafter? thanks. bobby -- View this message in context: http://old.nabble.com/warning-messages-while-deleting-cygwin-folder-tp29736133p29736133.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin 1.7 / windows2008 R2 : system32 commands not found with cygwin
Hi, I have windows 2008 R2 servers with cygwin 1.7 installed. When i want to execute the cluster.exe command, I have : seber...@flosapptest02 /cygdrive/c/windows/system32 $ ./cluster res bash: ./cluster: No such file or directory On a DOS prompt the command works.. Then I do a 'ls cluster*' in the bash session : seber...@flosapptest02 /cygdrive/c/windows/system32 $ ls cluster* ls: cannot access cluster*: No such file or directory On the CMD session : C:\Windows\System32dir cluster* Volume in drive C is system Volume Serial Number is 8C17-0D89 Directory of C:\Windows\System32 14/07/2009 03:39 216 576 cluster.exe 1 File(s)216 576 bytes 0 Dir(s) 6 198 706 176 bytes free Finally I cd to windows directory and do a find cluster.exe : seber...@flosapptest02 /cygdrive/c/windows $ find . -name cluster.exe ./winsxs/amd64_microsoft-windows-f..rcluster-clusterexe_31bf3856ad364e35_6.1.760 0.16385_none_6edae2036546d986/cluster.exe I added this directory to the PATH variable : seber...@flosapptest02 /cygdrive/c/windows $ PATH=$PATH:$(dirname $(cygpath -ua $(find . -name cluster.exe) )) Then I tried to run the cluster command : seber...@flosapptest02 /cygdrive/c/windows $ cluster res The resource loader cache doesn't have loaded MUI entry. The resource loader cache doesn't have loaded MUI entry. Questions : 1 - Why are some system32 commands seen in a dos session and not in a cygwin bash session ? 2 - Why doesn't the cluster command not working (Error : The resource loader cache doesn't have loaded MUI entry ) I think the cluster command is not the only one missing : Bash : ls /cygdrive/c/windows/system32/*.exe | wc -l == 322 CMD : dir c:\windows\system32\*.exe | wc -l == 427 The cluster command is working as expected on a bash session when I'm on a windows2003 server Thanks for your help Sven-Eric -- 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 + Python: unable to remap
It's not that simple :) rebaseall only rebases the exact dll's which were installed from your packager (setup.exe), but not any other dll's used at run-time - shadowing system dll's as in your case, or added dependencies as with perl or python. Hmmm, that leads to the conclusion, that I have to write a customized rebaseall or a wrapper for it. python or perl are favorites adding additional dll's to your run-time because you can and should simply add external library bindings by yourself. In your case the simpliest fix would be to remove your /home/prefix/gentoo... prefix from your path. My target is to get full controll of the sources, versions and patches. Al -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7 / windows2008 R2 : system32 commands not found with cygwin
On Sep 17 10:57, sven-eric.ber...@sanofi-aventis.com wrote: Hi, I have windows 2008 R2 servers with cygwin 1.7 installed. When i want to execute the cluster.exe command, I have : seber...@flosapptest02 /cygdrive/c/windows/system32 $ ./cluster res bash: ./cluster: No such file or directory On a DOS prompt the command works.. Then I do a 'ls cluster*' in the bash session : seber...@flosapptest02 /cygdrive/c/windows/system32 $ ls cluster* ls: cannot access cluster*: No such file or directory You're on a 64 bit system and the cluster command only exists as 64 bit application in the 64 bit system32 directory. Due to the Windows file redirection for 32 bit processes, if you cd into /cygdrive/c/Windows/System32, you're actually in /cygdrive/c/Windows/SysWOW64. What you want to do is to cd into /cygdrive/c/windows/Sysnative. You'll find the cluster command there. Note that this is not a Cygwin problem, but one of the many weird properties of 64 bit Windows OSes. It would have been so much easier for everyone if the directory containing the 64 bit applications and DLLs would have been named /cygdrive/c/windows/System64, but here we are. See http://msdn.microsoft.com/en-us/library/aa384187%28VS.85%29.aspx for details on the file system redirector. 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: distro apache2 will not start
The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. There is an oss freak in Thuringia, currently working out the idea of a common patch repository to bring the DRY principle to patch maintenance and to lower the work for each Distro. I think the idea is interesting at least and could help in cases like this. http://www.metux.de/download/oss-qm/normalized_repository.pdf Al -- 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
On the new mingw64-i686 packages
First of all, thanks a lot for having added these packages to Cygwin :-). I have installed gcc-core, gfortran and g++ and want to flag the following. I have a few applications which I compile like this on Cygwin: $ gfortran -O3 -Wall -mwindows foo.f90 bar.cpp -lstdc++ -s -o foobar (notice the .f90 and .cpp) where gfortran is the current 4.3.4. The above compiles and runs. Now, I have tried this: $ mingw32-gfortran -O3 -Wall -mwindows foo.f90 bar.cpp -lstdc++ -s -o foobar32 where 'mingw32-gfortran' is a link (in '/usr/local/bin') to '/usr/bin/i686-w64-mingw32-gfortran.exe': mingw32-gfortran - /usr/bin/i686-w64-mingw32-gfortran.exe The above compiles just fine, but: $ ./foobar32 /tmp/foobar32.exe: error while loading shared libraries: libstdc++-6.dll: cannot open shared object file: No such file or directory If I use '-static' option, it rins just fine. So, should I add something to PATH? Ciao, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin + Python: unable to remap
Al, On Fri, Sep 17, 2010 at 11:24:10AM +0200, Al wrote: It's not that simple :) rebaseall only rebases the exact dll's which were installed from your packager (setup.exe), but not any other dll's used at run-time - shadowing system dll's as in your case, or added dependencies as with perl or python. Hmmm, that leads to the conclusion, that I have to write a customized rebaseall or a wrapper for it. The rebase README indicates the following: The following is the rebaseall command line syntax: rebaseall [-b BaseAddress] [-o Offset] [-T FileList | -] [-v] where: -b = base address used by rebase (default: 0x7000) -o = offset between each DLL rebased (default: 0x1) -s = specify DLL suffix, use multiple if necessary (default: dll, so) -T = specify filelist (or stdin) to list additional files -v = verbose (default: off) You just need to use the -T option and specify the addition DLLs to rebase. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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 + Python: unable to remap
The following is the rebaseall command line syntax: rebaseall [-b BaseAddress] [-o Offset] [-T FileList | -] [-v] where: -b = base address used by rebase (default: 0x7000) -o = offset between each DLL rebased (default: 0x1) -s = specify DLL suffix, use multiple if necessary (default: dll, so) -T = specify filelist (or stdin) to list additional files -v = verbose (default: off) You just need to use the -T option and specify the addition DLLs to rebase. Thank you. I didn't read the readme, but I did read the sources. As far as I understand it, it simply can use the -T option to add a list of additional files from a wrapper. Reini suggest to add the dll to the same address of the shadowed packages. If I read the sources right, that is not even necessary, as it bases all files in an incremental way. I am currently working on it. Al -- 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: On the new mingw64-i686 packages
On 9/17/2010 18:48, Angelo Graziosi wrote: First of all, thanks a lot for having added these packages to Cygwin :-). I have installed gcc-core, gfortran and g++ and want to flag the following. I have a few applications which I compile like this on Cygwin: $ gfortran -O3 -Wall -mwindows foo.f90 bar.cpp -lstdc++ -s -o foobar (notice the .f90 and .cpp) where gfortran is the current 4.3.4. The above compiles and runs. Now, I have tried this: $ mingw32-gfortran -O3 -Wall -mwindows foo.f90 bar.cpp -lstdc++ -s -o foobar32 where 'mingw32-gfortran' is a link (in '/usr/local/bin') to '/usr/bin/i686-w64-mingw32-gfortran.exe': mingw32-gfortran - /usr/bin/i686-w64-mingw32-gfortran.exe The above compiles just fine, but: $ ./foobar32 /tmp/foobar32.exe: error while loading shared libraries: libstdc++-6.dll: cannot open shared object file: No such file or directory If I use '-static' option, it rins just fine. So, should I add something to PATH? Ciao, Angelo. Hi, It should be in /usr/i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll. Note that although similarly named, it is not ABI compatible with standard mingw gcc-4 libstdc++-6.dll. -- 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
AW: [bulk] - Re: Some manpages are missing
Moin, Von: Bengt Larsson [] Gesendet: Mittwoch, 15. September 2010 23:16 Betreff: [bulk] - Re: Some manpages are missing DEWI - N. Zacharias wrote: Hi, it seems to me that some manpages are missing: man printf yields the manpage for man 1 printf Actually they are available but there seems to be something wrong with the packaging. There is a combined entry for `sprintf', `fprintf', `printf', `snprintf', `asprintf', `asnprintf', but there is only a filename for sprintf. You can see it with man sprintf. Thanks a lot! Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this 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
[ANNOUNCEMENT] New package: mingw64-i686-headers-1.0b_svn3433-1
Version 1.0b_svn3433-1 of mingw64-i686-headers has been uploaded. mingw64-i686-headers contains headers for Windows development. This package is specifically for the 32bit target toolchain. *** 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. -- 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: mingw64-i686-runtime-20100809-1
Version 20100809-1 of mingw64-i686-runtime has been uploaded. mingw64-i686-runtime provides library to interface with Windows. This package is specifically for the 32bit target toolchain. *** 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. -- 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: mingw64-i686-binutils-2.20.51-1
Version 2.20.51-1 of mingw64-i686-binutils has been uploaded. mingw64-i686-binutils provides binutils support for the 32bit target toolchain. *** 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. -- 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: mingw64-i686-pthreads-20100619-1
Version 20100619-1 of mingw64-i686-pthreads has been uploaded. mingw64-i686-pthreads provides 32bit pthreads support. It is used by GCC for OpenMP. *** 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. -- 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: mingw64-i686-gcc-4.5.1-1
Version 4.5.1-1 of mingw64-i686-gcc has been uploaded. mingw64-i686-gcc contains GCC sources used by the 32bit target toolchain. See mingw64-i686-gcc-core, mingw64-i686-gcc-objc, mingw64-i686-gcc-ada, mingw64-i686-gcc-g++ and mingw64-i686-gcc-fortran for binaries. *** 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. -- 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: mingw64-i686 cross toolchain
The mingw64-i686 cross toolchain set has been uploaded to the Cygwin mirrors. It is used to build 32bit Windows applications and programs. As with all software releases, it may contain bugs, please report bugs to mingw-w64-public [at] lists.sourceforge.net. Notes: Avoid calling the cross compiler as /bin/exec, where exec is the compiler frontend such as i686-w64-mingw32-gcc, this will cause GCC to fail. This is a known issue. Instead call it as /usr/bin/exec or just exec. In the latter case, you'll need to make sure your PATH has /usr/bin searched before /bin, this is normally the case with Cygwin. *** 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. -- 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: On the new mingw64-i686 packages
JonY wrote: It should be in /usr/i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll. Yes, I know this... so, if I have understood, we *need* to add, manually, '/usr/i686-w64-mingw32/sys-root/mingw/bin' to PATH. Right? Perhaps, you have to create a mingw32-stdc++-6.dll to put in /usr/bin (likewise cygstdc++-6.dll) or a postinstall script which does the job (see the lapack packages, for example). Anyway, thanks a lot. Ciao, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: On the new mingw64-i686 packages
On 9/17/2010 19:30, Angelo Graziosi wrote: JonY wrote: It should be in /usr/i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll. Yes, I know this... so, if I have understood, we *need* to add, manually, '/usr/i686-w64-mingw32/sys-root/mingw/bin' to PATH. Right? No, its not a good idea IMHO if we want to support mingw.org and 64-bit mingw-w64 in parallel. They all have the same dll names. This brings us to the next issue... Perhaps, you have to create a mingw32-stdc++-6.dll to put in /usr/bin (likewise cygstdc++-6.dll) or a postinstall script which does the job (see the lapack packages, for example). I made a libtool patch to fixup the dll names sometime ago, but the maintainers were not very happy with creating another new prefix. For now, the best way is to build the program in Cygwin, start a cmd prompt with the correct sys-root added to PATH, and run the program from there. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
ccache dependency
Hi, trying to remove the gcc-3 package I noticed that ccache requires gcc that pulls gcc-3, gcc-mingw-g++, and gcc4. As now we have multiples gcc compilers can we remove the dependency ? Marco PS x cgf : I also noticed that after years of hibernation, ccache is now at 3.x version. -- 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 + Python: unable to remap
The rebase README indicates the following: The following is the rebaseall command line syntax: rebaseall [-b BaseAddress] [-o Offset] [-T FileList | -] [-v] where: -b = base address used by rebase (default: 0x7000) -o = offset between each DLL rebased (default: 0x1) -s = specify DLL suffix, use multiple if necessary (default: dll, so) -T = specify filelist (or stdin) to list additional files -v = verbose (default: off) You just need to use the -T option and specify the addition DLLs to rebase. Jason Thank you very much. It seems to work. I currently recompile python controlled by a python script. It that works in follow it is somewhat selfcontained. To give the future reader of this thread some additional value. I first gave the DLL file itself to the -T parameter resulting in tons of : skipped because nonexistent : skipped because nonexistent That's because it did understand the dll as an input file with a list of dlls. You have to write the dll path into a list file first and give that file as parameter. Al -- 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
simplifying rebaseall
To rebase I currently have to do the following steps: Open a windows command shell (cmd): P:/cygwin/bin/ash /bin/rebaseall exit exit I wonder if there could be a more simple way, i.e. putting it into a *.bat script and binding it to an task icon. I am thinking of something in this sense: P:/cygwin/bin/ash --exec /bin/rebaseall As a longterm Linux user I have few experience with windows scripts. Would be nice to have such a script directly linked into the start menu. Al -- 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: warning messages while deleting cygwin folder
bobby_2010 sent the following at Friday, September 17, 2010 4:19 AM hi, i am trying to completely delete cygwin from my system, as it is taking up too much hard disk space. i followed the instructions at the cygwin.com FAQ by first removing any subscribed services. this worked fine. then, i went on to delete the c:\cygwin folder. but i received 2 warning messages, asking me if i want to delete 'copying' and 'changelog' which are both system files and that deleting them might affect other programs. after choosing not to delete either, the dialog box 'error deleting file or folder' appears, stating 'cannot remove folder help: the directory is not empty'. should i delete these 2? and any other such warnings thereafter? thanks. Yes, delete everything. They only affect cygwin. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: distro apache2 will not start
Al wrote: The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. There is an oss freak in Thuringia, currently working out the idea of a common patch repository to bring the DRY principle to patch maintenance and to lower the work for each Distro. I think the idea is interesting at least and could help in cases like this. http://www.metux.de/download/oss-qm/normalized_repository.pdf Al -- Al: This sounds like the reduce work on future maintenance might be a blessing. As for orphaning the product, I would hate to see that happen..My current version is presently 1.3.22 and I have on many occasions attempted to build a version 2 apache only not to make it. It was only within the past two years I discovered that a version 2 was available so I put this project on my to do list. The MAJOR reason I'm hanging on 1.3.22 for cygwin is that it supports true Unix-style symbolic links. It saves a lot of data movement and/or duplication. If you don't have anyone to volunteer the work on apache 2, I'll just keep my 1.3.22 system. It has been a very reliable product. I don't use any transaction nor SSL.apps. P.S. I can't volunteer any time on this due to my health. -- http://genealogy.mcferrin.org/ # McFerrin Family History, Public View -- 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: simplifying rebaseall
A second thought. I wonder if reabaseall could be improved to run from within bash, without the need to close down all running windows. Then it could even be included into build scripts to be run after each build. Assuming that those DLL which are up and running typically don't need to be rebased, couldn't one simply exclude them from being rebased? I.e. with on option: rebaseall --exclude-loaded Al -- 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: distro apache2 will not start
On 9/17/2010 12:37 AM, Corinna Vinschen wrote: The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. apache2 is a build dependency for subversion, so if you remove it from the distro, I will need to package a copy of the sources with the subversion sources and modify my cygport to build it as well as subversion. I prefer not to do that. I'm don't want to adopt apache2 because I never use it on Cygwin. I might be able to build it, but I couldn't really do justice to answering questions and troubleshooting issues. -- David Rothenberger daver...@acm.org Positive, adj.: Mistaken at the top of one's voice. -- Ambrose Bierce, The Devil's Dictionary -- 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: simplifying rebaseall
On 9/17/2010 10:39 AM, Al wrote: A second thought. I wonder if reabaseall could be improved to run from within bash, without the need to close down all running windows. Then it could even be included into build scripts to be run after each build. No, because the DLLs used by bash are OFTEN the ones that actually DO need to be rebased (because they are used by darn near everything, so we need to ensure that their image base does not conflict with anything else): libintl, libiconv, libncurses, ... Assuming that those DLL which are up and running typically don't need to be rebased, couldn't one simply exclude them from being rebased? I.e. with on option: rebaseall --exclude-loaded You're missing the point of rebaseALL. Murphy says that if you don't rebase dll A, then dll A *will* be the culprit the next time you get that 'unable to remap' error. With regards to your earlier .bat file idea...Meh. You shouldn't need to DO it that often -- certainly not often enough to clutter your start menu or desktop with a shortcut! -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: distro apache2 will not start
On Sep 17 07:43, David Rothenberger wrote: On 9/17/2010 12:37 AM, Corinna Vinschen wrote: The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. apache2 is a build dependency for subversion, so if you remove it from the distro, I will need to package a copy of the sources with the subversion sources and modify my cygport to build it as well as subversion. I prefer not to do that. I'm don't want to adopt apache2 because I never use it on Cygwin. I might be able to build it, but I couldn't really do justice to answering questions and troubleshooting issues. Isn't there some kind of apache2 lib which can be handled as a separate package? If so, and if you would provide only libapache, we're off the hook. No bit-rotten apache2 package, and no unjust maintainance burden for you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: distro apache2 will not start
On 9/17/2010 8:02 AM, Corinna Vinschen wrote: On Sep 17 07:43, David Rothenberger wrote: On 9/17/2010 12:37 AM, Corinna Vinschen wrote: The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. apache2 is a build dependency for subversion, so if you remove it from the distro, I will need to package a copy of the sources with the subversion sources and modify my cygport to build it as well as subversion. I prefer not to do that. I'm don't want to adopt apache2 because I never use it on Cygwin. I might be able to build it, but I couldn't really do justice to answering questions and troubleshooting issues. Isn't there some kind of apache2 lib which can be handled as a separate package? If so, and if you would provide only libapache, we're off the hook. No bit-rotten apache2 package, and no unjust maintainance burden for you. Well, I need apache2-devel. That has a dependency on apache2, but I'm not really sure how much of that I need to *build* subversion. The test suite for subversion does actually start apache2 in order to test the subversion module, but if the distro doesn't provide apache2, I suppose I can try to avoid building the module and running those tests. That might remove the dependency on apache2, too. I'll investigate. -- David Rothenberger daver...@acm.org Mark's Dental-Chair Discovery: Dentists are incapable of asking questions that require a simple yes or no answer. -- 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: simplifying rebaseall
On 9/17/2010 10:50 AM, Charles Wilson wrote: On 9/17/2010 10:39 AM, Al wrote: A second thought. I wonder if reabaseall could be improved to run from within bash, without the need to close down all running windows. Then it could even be included into build scripts to be run after each build. No, because the DLLs used by bash are OFTEN the ones that actually DO need to be rebased (because they are used by darn near everything, so we need to ensure that their image base does not conflict with anything else): libintl, libiconv, libncurses, ... Assuming that those DLL which are up and running typically don't need to be rebased, couldn't one simply exclude them from being rebased? I.e. with on option: rebaseall --exclude-loaded You're missing the point of rebaseALL. Murphy says that if you don't rebase dll A, then dll A *will* be the culprit the next time you get that 'unable to remap' error. With regards to your earlier .bat file idea...Meh. You shouldn't need to DO it that often -- certainly not often enough to clutter your start menu or desktop with a shortcut! And it invites casual use without understanding the what and why. This means more people using it for no reason and more problems using it when it is needed because people don't understand the requirements to make it work (i.e. *nobody* will read the readme... wait, there's a readme? ;-) ). -- 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: simplifying rebaseall
And it invites casual use without understanding the what and why. This means more people using it for no reason and more problems using it when it is needed because people don't understand the requirements to make it work (i.e. *nobody* will read the readme... wait, there's a readme? ;-) ). Hmm, how does information work currently? I found the hint to run rebase somewhere in a blog, when I was hunting down a bug. Others will be told on this list to run rebase all without the hint of a readme. You can verify this be reading the lists archive. The only hint you find in the FAQ is below the topic Terminal Server machine. Who is finding that? I wouldn't even have an idea how to find and read this readme while using ash. I was reading the sources before finding the readme all. I have 10 years of Linux experience and even I didn't expect there was a readme around in this case. If you want to make sure people are informed before running it, it would be an option to display a small text when the script is starting, with the hint to the readme. That would even work with a link from the start menu. If there is a danger that people run rebase all without reading the readme, there is a similar danger that people give up Cygwin, before they ever discover that they could solve their issues by running rebaseall. Al -- 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 + Python: unable to remap
On Fri, Sep 17, 2010 at 02:53:53PM +0200, Al wrote: You just need to use the -T option and specify the addition DLLs to rebase. Thank you very much. You are quite welcome. [snip] To give the future reader of this thread some additional value. I first gave the DLL file itself to the -T parameter resulting in tons of : skipped because nonexistent : skipped because nonexistent That's because it did understand the dll as an input file with a list of dlls. You have to write the dll path into a list file first and give that file as parameter. Or, read from stdin as follows: $ something that generates extra DLL list | rebaseall -T - ... Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: ssh from linux to cygwin + CUI + Ctrl-C
Actually, why do you use cmd? On 2010-09-17 13:58, Andrew DeFaria wrote: On 09/16/2010 12:05 PM, Ilia K. wrote: Have you tried to ssh to cygwin, then run cmd.exe (to get a dos prompt) and then press Ctrl-C? Good lord man! Why would I want to do that?!? In my case this terminates cmd.exe and returns to bash, but this behavior is wrong (try to press Ctrl-C in cmd.exe which is run directly from the desktop, not from ssh session). Stop using cmd. -- 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
Unacceptable behavior -- slowing down script execution
Hi folks. Through fits and starts, and with no more feedback from the list than Dave Korn's self-admitted wild guess about gcclib1 folders etc, my Cygwin is no longer shedding empty shell stack-dump files like dandruff. But certain things are continuing to alarm me. I'll put them in the form of questions and whoever knows the answers, please take the time to do so. 1. Is it normal behavior, once rxvt is launched, for cmd.exe to remain running as a process? 2. Using a batch-to-executable utility, I converted a customized rxvt-launching .bat file into an executable. Should this also stay open as a process in Task Manager once its work is done? 3. Is it normal behavior for one BASH script to spawn more than one subshell? 4. Is it normal for any script to run CPU usage up to 100%? Regarding #4: I have a script that I ran in GNOME Terminal less than an hour ago. I timed it -- the return was 20.6 seconds on the first line (real?). I ran the same script fifteen minutes later, evaluating identical files of the same type, length (5.37kb and 345b ASCII text) and time stamp, and after 7 minutes it was barely one-eighth complete. That's when I checked Task Manager and found my CPU usage was at 100% and three bash.exe's were running simultaneously. Admittedly the script calls on several externals, but considering the difference in completion times -- I estimate that had I not interrupted the process with ctrl-c, the Cygwin run would have taken just under 40 minutes to finish -- _and the fact that it spawned an unusual number of subshells, it doesn't speak highly for Cygwin as a viable option or means for people to keep their hand in w/re their Unix skill-sets. 5. Is this a bug peculiar to this version/build of Cygwin? I don't recall any such issues when running complicated scripts before 1.7.x. Hoping someone can answer any or all of the foregoing. Cheers, SJ Wright -- 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: simplifying rebaseall
On 9/17/2010 12:18 PM, Al wrote: And it invites casual use without understanding the what and why. This means more people using it for no reason and more problems using it when it is needed because people don't understand the requirements to make it work (i.e. *nobody* will read the readme... wait, there's a readme? ;-) ). Hmm, how does information work currently? Almost EVERYTHING in cygwin has a README. Take a look in /usr/share/doc/Cygwin sometime. Furthermore many packages (but not rebase) have additional documentation in /usr/share/doc/$PKG/ -- just like on linux. I found the hint to run rebase somewhere in a blog, when I was hunting down a bug. Others will be told on this list to run rebase all without the hint of a readme. Because most people, when told to 'run rebaseall' will say to themselves I don't know how to run rebaseall. I wonder if it has a help option... $ rebaseall --help rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). No...but that's a pretty descriptive error message. However, I still want more information. Maybe there's a man page: $ man rebaseall No manual entry for rebaseall $ man rebase No manual entry for rebase Info page? $ info rebaseall $ info rebase No. Well, there must be SOME documentation somewhere. I know: I'll look in the /usr/share/doc $ ls /usr/share/doc/*rebase* ls: cannot access /usr/share/doc/*rebase*: No such file or directory No. Well, Cygwin puts some documentation in /usr/share/doc/Cygwin, so I better look there: $ ls /usr/share/doc/Cygwin/*rebase* /usr/share/doc/Cygwin/rebase-3.0.1.README A-HA! Now, surely that is a lot of hunting around -- but I can only assume that many people did so, since you are apparently the first person to fail to locate the documentation when faced with the question How do I run rebaseall? You can verify this be reading the lists archive. The only hint you find in the FAQ is below the topic Terminal Server machine. Who is finding that? Should we put If you have a question about package foo, be sure and look in /usr/share/doc/foo*/ and at /usr/share/doc/Cygwin/foo* for more information in the signature line of every message? I wouldn't even have an idea how to find and read this readme while using ash. See above. Most of that should be very familiar to a person with 10 years of Linux experience -- except for the bit about Cygwin packages often put a cygwin-specific README file in /usr/share/doc/Cygwin/ Maybe THAT tidbit should go in the FAQ...but I doubt the Questioned is Frequently Asked in this form: Where can I find additional information about specific Cygwin packages. No, the question would be asked Where can I get more information about foo or ...rebase or ..gcc or ...wget So, even if the FAQ *did* have the following: Q: Where can I find additional information about specific Cygwin packages? A: Look in /usr/share/doc/Cygwin/. Most cygwin packages put some cygwin-specific information in a README file located in that directory. ...you still wouldn't have found it -- unless you are in the habit of reading FAQs from top-to-bottom (I'm not...). If there is a danger that people run rebase all without reading the readme, there is a similar danger that people give up Cygwin, before they ever discover that they could solve their issues by running rebaseall. Look, we recognize that this rebase issue has cause *you* heartburn. It annoys us too, but thanks to Bill G, we can't really do anything about it. But, what you have to realize is -- it *does not* always occur. Not *every* user is impacted by it. Many users might use cygwin for years and NEVER see the dreaded unable to remap error. Those people would be in danger of accidentally (or curiously) clicking a shortcut called 'rebase'. The pain of THAT far outweighs the tiny convenience, for a small population of unfortunate newbies, that might need to run rebase but are not yet experienced enough to know all about it. (Worse, we simply CAN'T create a shortcut if the rebase problem hits 'bash' -- all such postinstall scripts themselves will fail with the remap error!) -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin + Python: unable to remap
Or, read from stdin as follows: $ something that generates extra DLL list | rebaseall -T - ... As example, something that gernates extra DLL list looks in my case like this. PREFIX=/home/prefix/gentoo find $PREFIX/bin/ -name *.dll -o -name *.so find $PREFIX/lib/ -name *.dll -o -name *.so find $PREFIX/usr/bin -name *.dll -o -name *.so find $PREFIX/usr/lib -name *.dll -o -name *.so It turned out that not all files have write access. So a similar script is required to add write access first. Al -- 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
where was mention of what creates NUL files?
Does anyone recall a mention of what in CygWin (or possibly Emacs) creates files with a simple name of NUL? Thanks, Daniel -- 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: where was mention of what creates NUL files?
On 09/17/2010 11:12 AM, Daniel Barclay wrote: Does anyone recall a mention of what in CygWin (or possibly Emacs) creates files with a simple name of NUL? Windows automagically maps the file named NUL, in any directory, to the equivalent of Unix' /dev/null. Cygwin doesn't create it, but all the same, portable programs should never name a file that case-insensitively matches 'nul', 'aux', or a host of other windows-magic names: http://www.gnu.org/software/autoconf/manual/autoconf.html#File-System-Conventions Meanwhile, cygwin 1.7 has added some magic to use native NT calls to work around these limitations, so that you can have a file that appears to be named NUL from within cygwin, but which is really exploiting some 16-bit values outside of Unicode. But various windows programs that use windows API (rather than lower-level NT API), including your file Explorer, have a hard time figuring out what cygwin did. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simplifying rebaseall
Hi, I appreciate you take the time to contribute all that information. Hope it is not only red by me. Now, surely that is a lot of hunting around -- but I can only assume that many people did so, since you are apparently the first person to fail to locate the documentation when faced with the question How do I run rebaseall? I wasn't faced with that question. I was face with error messages. Google guided me by this messages (and many others) to exactly this blog first: http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html ... not to Cygwin list, not to the readme, not to the FAQ. The blog rather tells how to run rebaseall not much why. The comments document well that many people follow that advice without any knowledge of any readme. You don't even find the word readme on that blog. See above. Most of that should be very familiar to a person with 10 years of Linux experience -- except for the bit about Cygwin packages often put a cygwin-specific README file in /usr/share/doc/Cygwin/ It's familiar that regular programs have a doc, man etc. It's also familiar that small maintenance scripts don't have. Even your posting has more lines the he rebaseall script itself. So you wouldn't really follow the search path for docs you give here. That there is a readme for such a small script is the positive execption. But I have doubts that many people will find it. Al -- 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: simplifying rebaseall
On Fri, Sep 17, 2010 at 07:38:03PM +0200, Al wrote: Hi, Hello, It's familiar that regular programs have a doc, man etc. It's also familiar that small maintenance scripts don't have. Even your posting has more lines the he rebaseall script itself. So you wouldn't really follow the search path for docs you give here. That there is a readme for such a small script is the positive execption. But I have doubts that many people will find it. I guess for many people cygwin is their first contact with a *NIX like environment, but given your previous knowledge in Linux, it could also have been and option to inspect the package contents: cygcheck -l rebase Regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: simplifying rebaseall
I guess for many people cygwin is their first contact with a *NIX like environment, but given your previous knowledge in Linux, it could also have been and option to inspect the package contents: cygcheck -l rebase It's not only that many people have in Cygwin their first contact with the *NIX world. There is always a point when you have your first contact with a new Distro. cygcheck will be self-evident for every Cygwin insider, but it is foreign for every newcomer, even with 30 years *NIX experience. I see it here the first time. Al -- 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
Transfer of installation settings
I have installation of Cygwin that I want to transfer
on another computer with Windows 7 operating system
on both computers (editions are the same).
I would not like to do it item by item.
In my understanding
setup -P {list of packages}
would help, if I have this listBut how to take
list of packages from the first computer?
Is there any simple method, how to transfer onstallation
settings?
TIA
Milos
--
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: Transfer of installation settings
On Fri, Sep 17, 2010 at 08:02:23PM +0200, Milos Puchta wrote:
I have installation of Cygwin that I want to transfer
on another computer with Windows 7 operating system
on both computers (editions are the same).
I would not like to do it item by item.
In my understanding
setup -P {list of packages}
would help, if I have this listBut how to take
list of packages from the first computer?
cygcheck -c | awk '{print $1}'
Is there any simple method, how to transfer onstallation
settings?
I don't quite understand what you mean here.
HTH.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: simplifying rebaseall
On Fri, Sep 17, 2010 at 08:01:23PM +0200, Al wrote: I guess for many people cygwin is their first contact with a *NIX like environment, but given your previous knowledge in Linux, it could also have been and option to inspect the package contents: cygcheck -l rebase It's not only that many people have in Cygwin their first contact with the *NIX world. There is always a point when you have your first contact with a new Distro. cygcheck will be self-evident for every Cygwin insider, but it is foreign for every newcomer, even with 30 years *NIX experience. I see it here the first time. That's true. I used cygwin for a year or so before even noticing cygcheck was there :) I think I started using it after reading http://cygwin.com/problems.html (cygcheck -s -v -r cygcheck.out) But, well, it's more or less the same when you switch from apt/deb to yum/rpm. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: distro apache2 will not start
On Fri, Sep 17, 2010 at 11:43:42AM +0200, Al wrote: The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. There is an oss freak in Thuringia, currently working out the idea of a common patch repository to bring the DRY principle to patch maintenance and to lower the work for each Distro. I think the idea is interesting at least and could help in cases like this. http://www.metux.de/download/oss-qm/normalized_repository.pdf A pdf is not going to cause a maintainer to materialize. Especially when the pdf is unloadable. 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: ccache dependency
On Fri, Sep 17, 2010 at 12:45:16PM +, Marco Atzeri wrote: PS x cgf : I also noticed that after years of hibernation, ccache is now at 3.x version. Yes. I know. 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: simplifying rebaseall
On 9/17/2010 1:38 PM, Al wrote: Hi, I appreciate you take the time to contribute all that information. Hope it is not only red by me. Now, surely that is a lot of hunting around -- but I can only assume that many people did so, since you are apparently the first person to fail to locate the documentation when faced with the question How do I run rebaseall? I wasn't faced with that question. I was face with error messages. Google guided me by this messages (and many others) to exactly this blog first: http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html ... not to Cygwin list, not to the readme, not to the FAQ. The blog rather tells how to run rebaseall not much why. The comments document well that many people follow that advice without any knowledge of any readme. You don't even find the word readme on that blog. But we have no control over that obviously. I think it's important to recognize when you go searching for information, it makes sense to weigh what you find against its source and consider the project's source as a more definitive and complete set of information. Obviously, there's nothing wrong with searching anywhere and everywhere for some clue about a problem. But information that comes from sites that are obviously not the project's site, cygwin.com in this case, is also a clue that further research using the project's resources and the new found data is a good idea. There's no question that there is quite a leap from the error message given to the fact that rebasing is a possible solution (and not the only possible solution - see http://cygwin.com/acronyms/#BLODA for another). A FAQ entry about the remap error message would probably help some at least. Over time, the hope is that package rebuilding helps make this even less of a problem. But it is a pain regardless without a great solution. -- 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: simplifying rebaseall
On Fri, Sep 17, 2010 at 08:01:23PM +0200, Al wrote: I guess for many people cygwin is their first contact with a *NIX like environment, but given your previous knowledge in Linux, it could also have been and option to inspect the package contents: cygcheck -l rebase It's not only that many people have in Cygwin their first contact with the *NIX world. There is always a point when you have your first contact with a new Distro. cygcheck will be self-evident for every Cygwin insider, but it is foreign for every newcomer, even with 30 years *NIX experience. I see it here the first time. If you are using any new distro you have to figure out how to query package information. It is not innate ancestral knowledge that comes from having evolved from hippos. This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. Anyone want to donate some words and suggest where they should go in the FAQ? 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: distro apache2 will not start
A pdf is not going to cause a maintainer to materialize. Especially when the pdf is unloadable. Hm, I did read it with SumatraPDF. A repository of patches will not create a maintainer directly, but it is more likely that somebody takes up the task, if maintenance becomes more easy and eats at not that much of your time. Al -- 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: simplifying rebaseall
This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. -bash-3.2$ /bin/rebaseall --help rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). Maybe that info could include a pointer to the doc? 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: simplifying rebaseall
This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. If words to the FAQ, then: 1.) a matching header 2.) including link to the readme 3.) including the famous error messages people enter into the search machines: *** fatal error - unable to remap to same address as parent : Then I see some chances that it is found. Al -- 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: simplifying rebaseall
On Fri, Sep 17, 2010 at 11:48:47AM -0700, Bill Ross wrote: This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. -bash-3.2$ /bin/rebaseall --help rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). Maybe that info could include a pointer to the doc? You mean the nonexistent FAQ entry mentioned above? I think most people would find that unhelpful. 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: simplifying rebaseall
On Fri, Sep 17, 2010 at 08:49:04PM +0200, Al wrote: This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. If words to the FAQ, then: 1.) a matching header 2.) including link to the readme 3.) including the famous error messages people enter into the search machines: *** fatal error - unable to remap to same address as parent : Then I see some chances that it is found. Hmm. Still no actual *words*. Just the usual propounding. But, yes, if someone does volunteer to write a FAQ entry it should actually be informative. Sorry I didn't make that clear. Next? 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: distro apache2 will not start
On 9/17/2010 8:10 AM, David Rothenberger wrote: On 9/17/2010 8:02 AM, Corinna Vinschen wrote: On Sep 17 07:43, David Rothenberger wrote: On 9/17/2010 12:37 AM, Corinna Vinschen wrote: The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. apache2 is a build dependency for subversion, so if you remove it from the distro, I will need to package a copy of the sources with the subversion sources and modify my cygport to build it as well as subversion. I prefer not to do that. Isn't there some kind of apache2 lib which can be handled as a separate package? If so, and if you would provide only libapache, we're off the hook. No bit-rotten apache2 package, and no unjust maintainance burden for you. Well, I need apache2-devel. That has a dependency on apache2, but I'm not really sure how much of that I need to *build* subversion. The test suite for subversion does actually start apache2 in order to test the subversion module, but if the distro doesn't provide apache2, I suppose I can try to avoid building the module and running those tests. That might remove the dependency on apache2, too. I'll investigate. apache2-devel is not needed by subversion if I don't build the apache2 module. I do need to install a native apache2 instance with subversion support in order to test the http support in the client, but I suppose I can do that. Okay by me to remove apache2 from the distro. I'll try to spin a new subversion release soon without subversion-apache2. I need to get the native apache2/svn server running first. -- David Rothenberger daver...@acm.org If you own a machine, you are in turn owned by it, and spend your time serving it... -- Marion Zimmer Bradley, _The Forbidden Tower_ -- 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: Transfer of installation settings
On 9/17/2010 1:07 PM, David Sastre wrote:
On Fri, Sep 17, 2010 at 08:02:23PM +0200, Milos Puchta wrote:
I have installation of Cygwin that I want to transfer
on another computer with Windows 7 operating system
on both computers (editions are the same).
I would not like to do it item by item.
In my understanding
setup -P {list of packages}
would help, if I have this listBut how to take
list of packages from the first computer?
cygcheck -c | awk '{print $1}'
Is there any simple method, how to transfer onstallation
settings?
I don't quite understand what you mean here.
Most Cygwin configuration information goes into /etc, so if you have
replicated the package installation, you can probably just copy the
contents of /etc to the new system for the most part, replacing any
existing files. You probably need to skip the /etc/postinstall,
/etc/preremove, and /etc/setup directories though since those have
information regarding the setup process you just ran. You may also want
to skip /etc/passwd and /etc/group and just regenerate them in place on
the new system in case there are important differences for some reason.
Other items such as services you have configured (e.g. sshd) will be
easiest to replicate by running their setup/config scripts again as you
did on the original computer. In case you don't remember what Cygwin
services you have installed, you should be able to list Cygwin services
by running the following:
cygrunsrv -L
-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: simplifying rebaseall
-bash-3.2$ /bin/rebaseall --help rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). Maybe that info could include a pointer to the doc? You mean the nonexistent FAQ entry mentioned above? I think most people would find that unhelpful. If that is the only doc to point to, then you are right. Alternatively, the recent archives might point to how hard existing docs are to find. -- 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: simplifying rebaseall
If that is the only doc to point to, then you are right. Alternatively, the recent archives might point to how hard existing docs are to find. Good doc is availble. Unfortunatly it is badly linked. http://www.tishler.net/jason/software/rebase/rebase-2.4.2.README It's not the first thing you run into when entering the error messages. *** fatal error - unable to remap to same address as parent : Meanwhile we are in the first page of google whith this thead, when enteringering the message. Good chances that it will be more easy in future due to this effect. :-) Al -- 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: where was mention of what creates NUL files?
On Sep 17 11:22, Eric Blake wrote: On 09/17/2010 11:12 AM, Daniel Barclay wrote: Does anyone recall a mention of what in CygWin (or possibly Emacs) creates finicking It's Cygwin, not CygWin. /finicking files with a simple name of NUL? Windows automagically maps the file named NUL, in any directory, Meep! The Win32 API, not Windows per se. to the equivalent of Unix' /dev/null. Cygwin doesn't create it, but all the same, portable programs should never name a file that case-insensitively matches 'nul', 'aux', or a host of other windows-magic names: http://www.gnu.org/software/autoconf/manual/autoconf.html#File-System-Conventions Meanwhile, cygwin 1.7 has added some magic to use native NT calls to work around these limitations, so that you can have a file that appears to be named NUL from within cygwin, but which is really exploiting some 16-bit values outside of Unicode. Sorry, but that's not entirely correct. There isn't any magic involved and the resulting filename is actually nul. No mapping to the Unicode private use area. The terrible DOS device name hack, which maps filenames containing substring named like the the old DOS device names (NUL, AUX, PRN, etc) to the actual Windows device, only exists in the Win32 API. Cygwin doesn't use the Win32 API to access files, rather it uses the underlying native NT API. This API allows to create and access actual files like nul or aux.c, just as on any other OS. The DOS device name hack simply doesn't affect us. So, any Cygwin application can create files like nul. It happens, for instance, if you call something like: $ echo foo NUL $ ls -l NUL -rw-r--r-- 1 corinna vinschen 4 Sep 17 21:25 NUL Note: Don't use DOS device names in Cygwin! Wrong: $ echo foo NUL $ echo foo nul $ echo foo nul: Right: $ echo foo /dev/null See here: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-dosdevices and here: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices 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: distro apache2 will not start
On Sep 17 11:55, David Rothenberger wrote: apache2-devel is not needed by subversion if I don't build the apache2 module. I do need to install a native apache2 instance with subversion support in order to test the http support in the client, but I suppose I can do that. So it only makes sense to provide the subversion-apache package if we also provide apache2, right? Okay by me to remove apache2 from the distro. I'll try to spin a new subversion release soon without subversion-apache2. I need to get the native apache2/svn server running first. Sounds good to me. 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: distro apache2 will not start
On 9/17/2010 12:39 PM, Corinna Vinschen wrote: On Sep 17 11:55, David Rothenberger wrote: apache2-devel is not needed by subversion if I don't build the apache2 module. I do need to install a native apache2 instance with subversion support in order to test the http support in the client, but I suppose I can do that. So it only makes sense to provide the subversion-apache package if we also provide apache2, right? That's correct. This package only contains the apache2 module for supporting dav_svn, so no apache2, no module. -- 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: distro apache2 will not start
On Fri, 2010-09-17 at 09:37 +0200, Corinna Vinschen wrote: The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. Apache2 is too important to lose from the distro, so: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=www/apache2 I'm AFK until Sunday, so that's the best I can do right now. 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: Unacceptable behavior -- slowing down script execution
SJ Wright wrote: Hi folks. Through fits and starts, and with no more feedback from the list than Dave Korn's self-admitted wild guess about gcclib1 folders etc, my Cygwin is no longer shedding empty shell stack-dump files like dandruff. But certain things are continuing to alarm me. I'll put them in the form of questions and whoever knows the answers, please take the time to do so. 1. Is it normal behavior, once rxvt is launched, for cmd.exe to remain running as a process? 2. Using a batch-to-executable utility, I converted a customized rxvt-launching .bat file into an executable. Should this also stay open as a process in Task Manager once its work is done? 3. Is it normal behavior for one BASH script to spawn more than one subshell? 4. Is it normal for any script to run CPU usage up to 100%? Regarding #4: I have a script that I ran in GNOME Terminal less than an hour ago. I timed it -- the return was 20.6 seconds on the first line (real?). I ran the same script fifteen minutes later, evaluating identical files of the same type, length (5.37kb and 345b ASCII text) and time stamp, and after 7 minutes it was barely one-eighth complete. That's when I checked Task Manager and found my CPU usage was at 100% and three bash.exe's were running simultaneously. Admittedly the script calls on several externals, but considering the difference in completion times -- I estimate that had I not interrupted the process with ctrl-c, the Cygwin run would have taken just under 40 minutes to finish -- _and the fact that it spawned an unusual number of subshells, it doesn't speak highly for Cygwin as a viable option or means for people to keep their hand in w/re their Unix skill-sets. 5. Is this a bug peculiar to this version/build of Cygwin? I don't recall any such issues when running complicated scripts before 1.7.x. Hoping someone can answer any or all of the foregoing. Cheers, SJ Wright The above message:http://www.cygwin.com/ml/cygwin/2010-09/msg00568.html I have found other messages that discuss the 100% CPU load issue in previous versions of Cygwin. No wonder no one's bothered to answer my questions yet -- evidently one should take it as read that anything fancier than cmd.exe as a terminal emulator will do this. Okay, so here's QUESTION #6: Why should a bash script call up sh.exe, not once but as many as three times, as processes in Task Manager when run in the current version of Cygwin? As for the slowdown in script execution: I've pondered using ssh, scp and ftp to do all my heavier-load script running remotely to my Linux laptop. QUESTION #7: Am I the only one who thinks this shouldn't be necessary? Here's hoping I've piqued someone's interest. Cheers again, SJ Wright -- 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: Unacceptable behavior -- slowing down script execution
On 9/17/2010 6:46 PM, SJ Wright wrote: The above message:http://www.cygwin.com/ml/cygwin/2010-09/msg00568.html I have found other messages that discuss the 100% CPU load issue in previous versions of Cygwin. No wonder no one's bothered to answer my questions yet -- evidently one should take it as read that anything fancier than cmd.exe as a terminal emulator will do this. Okay, so here's QUESTION #6: Why should a bash script call up sh.exe, not once but as many as three times, as processes in Task Manager when run in the current version of Cygwin? As for the slowdown in script execution: I've pondered using ssh, scp and ftp to do all my heavier-load script running remotely to my Linux laptop. QUESTION #7: Am I the only one who thinks this shouldn't be necessary? Here's hoping I've piqued someone's interest. Here's a thought: Problem reports: http://cygwin.com/problems.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: distro apache2 will not start
The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. Apache2 is too important to lose from the distro, so: I agree. I've been using the Apache2 binaries to run servers on laptops and desktop machines under Cygwin and I would hate to loose it in the distribution. It has allowed me to try out changes for larger NIX servers without having to worry about repercussions during product tests or production runs. While I was not able to get the svn modules working under apache2, I believe this is because I've been having trouble running the rebase commands on my systems. I wish I knew of a user group in my area that could help newbies understand what they were missing or doing wrong when they have problems installing or setting up Apache2. -- 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: where was mention of what creates NUL files?
Corinna Vinschen wrote: ... Note: Don't use DOS device names in Cygwin! Wrong: $ echo foo NUL $ echo foo nul $ echo foo nul: Right: $ echo foo /dev/null Yes, I know. I'm not using NUL (or nul or nul:, etc.), but something is. (Now I'm thinking that it's an NTEmacs problem (perhaps thinking it's running commands in a Windows/DOS shell rather than knowing it's running them in Cygwin bash.).) Daniel -- 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: distro apache2 will not start
On 9/17/2010 3:16 PM, Yaakov (Cygwin/X) wrote: On Fri, 2010-09-17 at 09:37 +0200, Corinna Vinschen wrote: The apache2 package is orphaned for this long period of time already. Maybe it's time to pull it from the distro, unless somebody would like to take over maintainership. Apache2 is too important to lose from the distro, so: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=www/apache2 I'm AFK until Sunday, so that's the best I can do right now. I'll continue to include subversion-apache2 in my releases until apache2 is actually removed (if ever). I've confirmed I can build subversion without apache2 and can do some testing of the http client with a native apache2/subversion server, so I'm good to go either way. If apache2 is ever removed, just remove subversion-apache2 as well and I'll adjust on my next release. -- David Rothenberger daver...@acm.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: distro apache2 will not start
I gave up on Cygwin apache2 some time ago, but under Windows 7 it had a tendency to crash the system in its default configuration. http://cygwin.com/ml/cygwin/2010-02/msg00017.html I've been using lighthttp since. Stacey -- 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: awk gsub problem
On 9/16/10, Corinna Vinschen wrote:
On Sep 15 18:30, Lee wrote:
I don't know if this is just a problem with the cygwin version of awk,
me misunderstanding something or what, but it looks like gsub isn't
working correctly in awk:
$ sh /tmp/test.awk
s= ::0:: should = ::S0::
$ cat /tmp/test.awk
awk '
BEGIN {
s=Serial0
gsub([a-z],,s)
printf(s= ::%s:: should = ::S0::\n, s)
exit
} '
I also tried it with IGNORECASE=0 and with awk --traditional - same
results.
$ which awk
/usr/bin/awk
$ awk --version
GNU Awk 3.1.8
Works fine for me:
$ uname -a
CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
$ gawk --version
GNU Awk 3.1.8
Copyright (C) 1989, 1991-2010 Free Software Foundation.
[...]
$ sh //calimero/corinna/test.awk
s= ::S0:: should = ::S0::
$
Thanks for the reply. If it works for you, doesn't work on my home or
work computer upgrading doesn't fix it ... it's probably something I
did. Which it was - I had this bit in my c:\cygwin\cygwin.bat file:
@rem set LANG envar for proper display
@rem ref: http://cygwin.com/cygwin-ug-net/setup-locale.html
set LANG=en_US.UTF-8
Comment out the 'set LANG= and gsub works fine:
$ echo $LANG
C.UTF-8
$ sh /tmp/test.awk
s= ::S0:: should = ::S0::
$ export LANG=en_US.UTF-8
$ sh /tmp/test.awk
s= ::0:: should = ::S0::
So awk gsub works for me again - thank you!
Just out of curiosity, why would setting LANG to en_US break
case-sensitivity in gsub?
Regards,
Lee
--
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: warning messages while deleting cygwin folder
thanks, did as you said and nothing seems amiss. Buchbinder, Barry (NIH/NIAID) [E] wrote: bobby_2010 sent the following at Friday, September 17, 2010 4:19 AM hi, i am trying to completely delete cygwin from my system, as it is taking up too much hard disk space. i followed the instructions at the cygwin.com FAQ by first removing any subscribed services. this worked fine. then, i went on to delete the c:\cygwin folder. but i received 2 warning messages, asking me if i want to delete 'copying' and 'changelog' which are both system files and that deleting them might affect other programs. after choosing not to delete either, the dialog box 'error deleting file or folder' appears, stating 'cannot remove folder help: the directory is not empty'. should i delete these 2? and any other such warnings thereafter? thanks. Yes, delete everything. They only affect cygwin. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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 -- View this message in context: http://old.nabble.com/warning-messages-while-deleting-cygwin-folder-tp29736133p29744165.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
git and ssh issue
using cygwin 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 I have right now an example where I cannot fetch with the following error message: remote: Counting objects: 534, done. remote: Compressing objects: 100% (210/210), done. fatal: The remote end hung up unexpectedly fatal: early EOFs: 39% (141/359) fatal: index-pack failed The repository contains proprietary data so that it cannot be accessed from somebody else but is there still anything I could do that would help to debug this now long standing issue? I am still using 1.5 for production because of this and I would be very much pleased to switch entirely to 1.7! Regards, Frédéric -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
New package: Onigurama {libonig2,liboning-devel}-5.9.2
Hi, Onigurama library is now available for cygwin. The version 5.9.2-1 of libonig2 liboning-devel have been uploaded. DESCRIPTION Oniguruma is a regular expressions library. The characteristics of this library is that different character encoding for every regular expression object can be specified. (supported APIs: GNU regex, POSIX and Oniguruma native) Supported character encodings: ASCII, UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, EUC-JP, EUC-TW, EUC-KR, EUC-CN, Shift_JIS, Big5, GB18030, KOI8-R, CP1251, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16 HOMEPAGE http://www.geocities.jp/kosako3/oniguruma/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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.
New package: mingw64-i686-headers-1.0b_svn3433-1
Version 1.0b_svn3433-1 of mingw64-i686-headers has been uploaded. mingw64-i686-headers contains headers for Windows development. This package is specifically for the 32bit target toolchain. *** 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.
New package: mingw64-i686-runtime-20100809-1
Version 20100809-1 of mingw64-i686-runtime has been uploaded. mingw64-i686-runtime provides library to interface with Windows. This package is specifically for the 32bit target toolchain. *** 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.
New package: mingw64-i686-gcc-4.5.1-1
Version 4.5.1-1 of mingw64-i686-gcc has been uploaded. mingw64-i686-gcc contains GCC sources used by the 32bit target toolchain. See mingw64-i686-gcc-core, mingw64-i686-gcc-objc, mingw64-i686-gcc-ada, mingw64-i686-gcc-g++ and mingw64-i686-gcc-fortran for binaries. *** 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.
New package: mingw64-i686 cross toolchain
The mingw64-i686 cross toolchain set has been uploaded to the Cygwin mirrors. It is used to build 32bit Windows applications and programs. As with all software releases, it may contain bugs, please report bugs to mingw-w64-public [at] lists.sourceforge.net. Notes: Avoid calling the cross compiler as /bin/exec, where exec is the compiler frontend such as i686-w64-mingw32-gcc, this will cause GCC to fail. This is a known issue. Instead call it as /usr/bin/exec or just exec. In the latter case, you'll need to make sure your PATH has /usr/bin searched before /bin, this is normally the case with Cygwin. *** 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.
