Re: [ITP] geda-gaf-1.6.1-1
The packages were rebuilt using cygport and updated: http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/geda-gaf-1.6.1-1-src.tar.bz2 http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/geda-gaf-1.6.1-1.tar.bz2 http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/setup.hint Alberto 2010/3/3 Marco Atzeri marco_atz...@yahoo.it: --- Mer 3/3/10, Alberto Maccioni ha scritto: Hello, I propose to include the gEDA-gaf package. It is a collection of programs to design and simulate electronic circuits. They are already in the Debian repository: http://packages.debian.org/search?keywords=geda I have uploaded the packages on: http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/geda-gaf-1.6.1-1-src.tar.bz2 http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/geda-gaf-1.6.1-1.tar.bz2 http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/setup.hint Alberto Alberto, the source package is not ready for a off the shelf compilation, installation , packaging as we expect for a cygwin source package. Moreover the binary package is deployed in /usr/local and this is not acceptable for a cygwin package. I suggest the usage of cygport to make it. If you need help I can help you, or you can find plenty of examples in http://sourceware.org/cygwinports/ Regards Marco
Re: genini: support multiple compression formats
Charles Wilson wrote: OK, I've tested the following. Better? 2010-03-11 Charles Wilson ... * genini (parsedir): Support tarballs whose name ends in gz, lzma, and xz in addition to bz2. (tarball): Test for existence of tarballs to determine which compression format/extension is used. If not found, default to .bz2. (addfiles): Ripple from changes to tarball(). forgot to remove one useless line: +my @exts = qw(bz2 xz gz lzma); is obsolete, and should not be in the patch. consider it removed... -- Chuck
Re: genini: support multiple compression formats
On Thu, Mar 11, 2010 at 06:16:29PM -0500, Charles Wilson wrote: Charles Wilson wrote: OK, I've tested the following. Better? 2010-03-11 Charles Wilson ... * genini (parsedir): Support tarballs whose name ends in gz, lzma, and xz in addition to bz2. (tarball): Test for existence of tarballs to determine which compression format/extension is used. If not found, default to .bz2. (addfiles): Ripple from changes to tarball(). forgot to remove one useless line: +my @exts = qw(bz2 xz gz lzma); is obsolete, and should not be in the patch. consider it removed... My email was down today after a catastrophic simple upgrade of spamassassin which pulled in perl 5.10.1 so I haven't seen the previous patch yet but, from the archives, it looks ok to me. Thanks for the patch. Please check in. cgf
Re: genini: support multiple compression formats
Christopher Faylor wrote: My email was down today after a catastrophic simple upgrade of spamassassin which pulled in perl 5.10.1 so I haven't seen the previous patch yet but, from the archives, it looks ok to me. sorry to hear that. Thanks for the patch. Please check in. Done. I have a separate local workaround for another issue, related to the recent message: support, but I'll raise that in a new thread. -- Chuck
genini: message field always emitted
AFAIK, the new message: field in setup.hint is not intended to be a required field. However, if it is missing from the setup.hint, genini complains. Fine, I can work around this by (always...) using --okmissing=message. However, if I do that, then I get a setup.ini like the following: ... @ test-data sdesc: test package ldesc: test package category: Utils message: version: 0.1-2 install: release/test-data/test-data-0.1-2.tar.xz 116920 e69dda662fde6b02644d4562c1ed0541 source: release/test-data/test-data-0.1-2-src.tar.xz 108 7f06fdbf4fd1eff94c1c85068c155c1c ... And when I run setup.exe, I get a popup with the following message: C:\cygwin-1.7\usr\src\devel\setup\test/setup.ini line 10: syntax error, unexpected NL, expecting STRING C:\cygwin-1.7\usr\src\devel\setup\test/setup.ini line 10: unrecognized line 11 (do you have the latest setup?) It appears there are three separate problems here. 1) It'd be nice if genini didn't assume that all of the keywords it knows about are required. E.g. pre-seed okmissing with (list of optional keywords)? 2) Failing that, since message is optional, then if the data structure for a particular package has no entry for 'message', then...genini should not print out an useless 'message: ' line. 3) Finally, setup.exe's behavior when seeing this entry...is this a bug? If you have message: or even message: should setup.exe treat that like an empty requires:, and just ignore it? Or do we assume that if a message: entry is present then there WILL be a message popup...and it better have a non-empty string value? No patch yet, because I'm not sure what the correct action should be. -- Chuck
Re: genini: message field always emitted
On Thu, Mar 11, 2010 at 07:18:45PM -0500, Charles Wilson wrote: AFAIK, the new message: field in setup.hint is not intended to be a required field. However, if it is missing from the setup.hint, genini complains. Fine, I can work around this by (always...) using --okmissing=message. However, if I do that, then I get a setup.ini like the following: ... @ test-data sdesc: test package ldesc: test package category: Utils message: version: 0.1-2 install: release/test-data/test-data-0.1-2.tar.xz 116920 e69dda662fde6b02644d4562c1ed0541 source: release/test-data/test-data-0.1-2-src.tar.xz 108 7f06fdbf4fd1eff94c1c85068c155c1c ... And when I run setup.exe, I get a popup with the following message: C:\cygwin-1.7\usr\src\devel\setup\test/setup.ini line 10: syntax error, unexpected NL, expecting STRING C:\cygwin-1.7\usr\src\devel\setup\test/setup.ini line 10: unrecognized line 11 (do you have the latest setup?) It appears there are three separate problems here. 1) It'd be nice if genini didn't assume that all of the keywords it knows about are required. E.g. pre-seed okmissing with (list of optional keywords)? 2) Failing that, since message is optional, then if the data structure for a particular package has no entry for 'message', then...genini should not print out an useless 'message: ' line. 3) Finally, setup.exe's behavior when seeing this entry...is this a bug? If you have message: or even message: should setup.exe treat that like an empty requires:, and just ignore it? Or do we assume that if a message: entry is present then there WILL be a message popup...and it better have a non-empty string value? genini shouldn't assume that message is required and setup.exe shouldn't have to care about blank messages. Btw, the syntax is (or should be): message keyword something That's why you're seeing a syntax error. cgf
Re: genini: message field always emitted
Christopher Faylor wrote:
genini shouldn't assume that message is required and setup.exe shouldn't
have to care about blank messages.
Btw, the syntax is (or should be):
message keyword something
That's why you're seeing a syntax error.
Thx. So, the attached works for me...OK?
2010-03-11 Charles Wilson ...
* genini: Add new array variables to hold and categorize
keywords. Add the optional keywords to okmissing. Use the
keyword arrays when iterating.
(get): For message keyword, only attempt to process $val
if non-empty. Also, explicitly parse $val, not $_.
--
Chuck
Index: genini
===
RCS file: /cvs/cygwin-apps/genini/genini,v
retrieving revision 1.10
diff -u -p -r1.10 genini
--- genini 11 Mar 2010 23:50:29 - 1.10
+++ genini 12 Mar 2010 02:19:15 -
@@ -18,11 +18,17 @@ sub usage();
my @okmissing;
my ($outfile, $help, $recursive);
my @cmp_fmts = qw(gz bz2 lzma xz);
+my @required_pkgkeys = qw(sdesc ldesc category requires);
+my @optional_pkgkeys = qw(message);
+my @pkgkeys = (@required_pkgkeys, @optional_pkgkeys);
+my @verkeys = qw(version install source);
+
GetOptions('okmissing=s'=\...@okmissing, 'output=s'=\$outfile, 'help'=\$help, 'recursive'=\$recursive) or usage;
$help and usage;
@main::okmissi...@okmissing} = @okmissing;
+...@main::okmissi...@optional_pkgkeys} = @optional_pkgkeys;
if (defined($outfile)) {
open(STDOUT, '', $outfile) or die $0: can't open $outfile - $!\n;
@@ -51,7 +57,7 @@ print $main::setup_version\n if $main:
undef $main::curfile;
for my $p (sort keys %pkg) {
print \n@ $p\n;
-for my $key ('sdesc', 'ldesc', 'category', 'requires', 'message') {
+for my $key (@pkgkeys) {
my $val = $pkg{$p}{''}{$key};
if (!defined($val) $pkg{$p}{''}{'install'} !~ /_obsolete/o) {
mywarn package $p is missing a $key field
@@ -74,7 +80,7 @@ for my $p (sort keys %pkg) {
for my $what ('', [prev]\n, [test]\n) {
$pkg{$p}{$what} or next;
print $what;
- for my $key ('version', 'install', 'source') {
+ for my $key (@verkeys) {
my $val = $pkg{$p}{$what}{$key} or next;
print $key: , $val, \n;
}
@@ -87,8 +93,10 @@ sub get {
my $val = shift;
if ($keyhint eq 'message') {
- my ($kw, $rest) = /^(\S+)\s+(.*)$/;
- return $kw . ' ' . get($FH, 'ldesc', $rest);
+ if ($val) {
+ my ($kw, $rest) = $val =~ /^(\S+)\s+(.*)$/;
+ return $kw . ' ' . get($FH, 'ldesc', $rest);
+ }
} elsif (substr($val, 0, 1) ne '') {
$val = ''. $val . '' if $keyhint eq 'ldesc' || $keyhint eq 'sdesc';
} else {
@@ -99,7 +107,7 @@ sub get {
s/(\S)\s+$/$1/;
$val .= \n . $_;
}
-}
+}
$val =~ s/(.)(.)/$1'$2/mog;
return $val;
}
Re: genini: message field always emitted
On Thu, Mar 11, 2010 at 09:26:38PM -0500, Charles Wilson wrote:
Christopher Faylor wrote:
genini shouldn't assume that message is required and setup.exe shouldn't
have to care about blank messages.
Btw, the syntax is (or should be):
message keyword something
That's why you're seeing a syntax error.
@@ -87,8 +93,10 @@ sub get {
my $val = shift;
if ($keyhint eq 'message') {
- my ($kw, $rest) = /^(\S+)\s+(.*)$/;
- return $kw . ' ' . get($FH, 'ldesc', $rest);
+ if ($val) {
+ my ($kw, $rest) = $val =~ /^(\S+)\s+(.*)$/;
+ return $kw . ' ' . get($FH, 'ldesc', $rest);
+ }
This should be checking that $val exists and issuing a syntax error
if not. Otherwise, it looks ok.
cgf
Incorrect Cygwin/X behavior leads to .X0-lock related fatal error
Here is tool behavior that seems like a bug in 1.7.1 related to the Cygwin/X FAQ item 3.4 (A2)called Fatal server error: Can't read lock file /tmp/.X0-lock. I am posting this, because the faq item states that the buggy behavior happens For reasons which are not well understood at present. This post presents what I consider to be incorrect behavior that leads to this error. If I log on as a user without admin rights (on Windows XP), and I start Cygwin/X using the XWin Server program shortcut, the referenced lock file gets created and gives me read/write access. The Everyone user just has read access. When I then close my XWin session, the lock file remains. I log out of Windows, then someone else logs on (also without admin rights), and they get the fatal error as described in the FAQ item, since they do not have write access to the lock file. If, however, I had originally started Cygwin/X by opening a Cygwin window then entering startx, when I eventually end my Cygwin session, the lock file gets deleted. So in this scenario, the next person to log on will not get the fatal error, since Cygwin didn't leave the lock file behind. My opinion is that the startx scenario behaves correctly, and the XWin Server shortcut scenario presents a bug, namely, it leaves behind the lock file after the session is ended. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/doc ChangeLog faq-using.xml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-03-11 10:22:34 Modified files: winsup/doc : ChangeLog faq-using.xml Log message: * faq-using.xml (faq.using.bloda): Add Credant Guardian Shield. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.285r2=1.286 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-using.xml.diff?cvsroot=srcr1=1.30r2=1.31
Re: 1.7 - Problem installing perl modules
On Tue, Mar 9, 2010 at 8:12 PM, Robert Slater wrote: Hi there, In the process of installing perl modules to get an IRC bot working via cygwin, I'm encountering a problem with make installing ExtUtils::CBuilder and thus the modules that depend upon it. The make / install goes through fine, but cygwin doesn't seem to detect it afterwards. cc1: error: unrecognized command line option -fstack-protector This is a command line option which only GCC 4 understands. You only have GCC 3 installed. You need to install the gcc-4 package. You may also need to change the default gcc to gcc-4 using the alternatives tool (man alternatives), or force Perl to use GCC 4. This may work (untested) CC=gcc-4 perl Build.pl -- Life is complex, with real and imaginary parts -- 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: redirect-append () creates garbage-y file
2010/3/9 William Lebow I've diagnosed this problem further. It is an interaction between cygwin and a security package called Credant Guardian Shield that my company installs on all of its laptops. I can't say specifically that it is a cygwin bug, but this bad behavior is not present in earlier versions. New entry to the BLODA ? Thomas Wolff wrote: It would be interesting to check whether it only occurs if you append to a file from the command line or also if an application opens a file in append mode, William, try this: echo foo | tail -a test3.txt -- Life is complex, with real and imaginary parts -- 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: Concurrency Issue with Shared State Initialization
On Mar 11 00:22, Schmidt, Oliver wrote: Hi, I'll test the snapshot asap! The final patch is from cgf. It's probably more performant since it drops the requirement for an additional spinlock. The snapshot contains try #3 on getting the locking right. Thank you both for clarifying. I was already aware of that by browsing through the CVS commits but my statement above was far from clear on that :-( No worries. Does the patch help? 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: gcc cannot find stdio.h
On Wed, Mar 10, 2010 at 10:41 PM, Jacob Jacobson wrote: Larry Hall (Cygwin) wrote: (snip) You are missing a few entries, though it's not clear why you don't have them. Reinstall the 'cygwin' package. Thanks. I reinstalled cygwin package and gcc works now. I also noticed that the message about regtool went away. This sounds like http://sourceware.org/ml/cygwin/2010-01/msg00562.html -- Life is complex, with real and imaginary parts -- 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: mtr under cygwin
On Mar 10 18:24, Brian Minton wrote:
I'm having the same issue. I just tried it with mtr 0.75 under cygwin
1.7.1 and it is still not working.
On Wed, Jan 21, 2009 at 5:55 PM, David Arnstein arnst...@panix.com wrote:
I am able to compile mtr 0.75 under Cygwin, see
http://www.bitwizard.nl/mtr/.
But mtr is not working. Using ddd, I see that the call
getsockname (recvsock, name, len);
does not seem to be filling in name correctly, when recvsock=3. It
fills in name-sa_family = 0.
Any suggestions?
Did socket creation succeed? mtr uses raw sockets and those can only be
created by admin users since XP. Since Vista, you must also run the
application in an elevated shell. I just tested to create such a socket
and getsockname works fine for me:
bash$ cat sockname.c EOF
#include stdio.h
#include string.h
#include errno.h
#include sys/socket.h
int
main (int argc, char **argv)
{
int fd;
int ret;
int val;
socklen_t siz;
struct sockaddr sa;
fd = socket(AF_INET, SOCK_RAW, 0);
if (fd = 0)
{
ret = getsockname (fd, sa, (siz = sizeof sa, siz));
if (!ret)
printf (family: %d\n, sa.sa_family);
else
printf (errno: %d (%s)\n, errno, strerror (errno));
close (fd);
}
return 0;
}
EOF
bash$ gcc -o sockname sockname.c
bash$ ./sockname
family: 2
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: Possible Documentation Inconsistency
On Mar 10 22:17, Buchbinder, Barry (NIH/NIAID) [E] wrote: http://cygwin.com/cygwin-ug-net/using-effectively.html#using-shortcuts By default, Cygwin uses a mechanism that creates symbolic links that are compatible with standard Microsoft .lnk files. http://cygwin.com/cygwin-ug-net/using-cygwinenv.html#cygwinenv-implemented-options (no)winsymlinks ... Defaults to not set since plain file symlinks are faster to write and faster to read. Thanks for the heads-up. Somehow the text doesn't fit well anymore. Is that better? Another problem area is between Unix-style links, which link one file to another, and Microsoft .lnk files, which provide a shortcut to a file. They seem similar at first glance but, in reality, are fairly different. By default, Cygwin does not create symlinks as .lnk files, but there's an option to do that, see xref: CYGWIN environment variable These symlink .lnk files are compatible with Windows-created .lnk files, but they are still different. They do not include much of the information that is available in a standard Microsoft shortcut, such as the working directory, an icon, etc. The cygutils package includes a mkshortcut utility for creating standard native Microsoft .lnk files. But here's the problem. If Cygwin handled these native shortcuts like any other symlink, [...] I'm open for suggestions to phrase that more eloquently. 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: redirect-append () creates garbage-y file
On Mar 11 10:09, Csaba Raduly wrote: 2010/3/9 William Lebow I've diagnosed this problem further. It is an interaction between cygwin and a security package called Credant Guardian Shield that my company installs on all of its laptops. I can't say specifically that it is a cygwin bug, but this bad behavior is not present in earlier versions. New entry to the BLODA ? Yep. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7: Concurrency Issue with Shared State Initialization
Hi Corrina, Does the patch help? I've right now no access to my dev box. I'll be able to provide feedback (either positive or negative) tomorrow... Regards, Oliver -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7 - Problem installing perl modules
cc1: error: unrecognized command line option -fstack-protector This is a command line option which only GCC 4 understands. You only have GCC 3 installed. You need to install the gcc-4 package. You may also need to change the default gcc to gcc-4 using the alternatives tool (man alternatives), or force Perl to use GCC 4. This may work (untested) CC=gcc-4 perl Build.pl Thanks for your help, Csaba, this works now. -Robert Slater -- 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: gcc cannot find stdio.h
On 03/11/2010 04:24 AM, Csaba Raduly wrote: On Wed, Mar 10, 2010 at 10:41 PM, Jacob Jacobson wrote: Larry Hall (Cygwin) wrote: (snip) You are missing a few entries, though it's not clear why you don't have them. Reinstall the 'cygwin' package. Thanks. I reinstalled cygwin package and gcc works now. I also noticed that the message about regtool went away. This sounds like http://sourceware.org/ml/cygwin/2010-01/msg00562.html Yes. That's exactly what happened. Should have paid more attention to the missing regtool message. Thanks -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7 - Problem installing perl modules
On 11/03/2010 08:58, Csaba Raduly wrote: You need to install the gcc-4 package. You may also need to change the default gcc to gcc-4 using the alternatives tool (man alternatives), Or use one of /usr/bin/set-gcc-default-3.sh or /usr/bin/set-gcc-default-4.sh, which saves learning the syntax and makes sure that all the related language compilers get switched at once (though owing to a packaging error in the current release you'll need to chmod +x them first, doh, sorry about that!) cheers, DaveK -- 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: MIT krb5 on cygwin?
Alec Kloss-17 wrote: FYI, I did submit some fixed to make heimdal work under cygwin... depending on what you're trying to accomplish with LDAP heimdal should be sufficient. Thanks! At least, it was enough for me to build GSSAPI-0.26. I had however to add -heimsqlite to the value of $lib_flags in krb5-config. This in order to avoid link errors such as e.g.: /home/emagiro/tmp/heimdal-1.3.2rc2/lib/krb5/scache.c:1379: undefined reference to `_sqlite3_bind_text' A bit surprised that building GSSAPI would rebuild sources under heimdal...? I had installed it under /usr/heimdal (default), and passed this to: GSSAPI-0.26 perl Makefile.PL --gssapiimpl /usr/heimdal Marc -- View this message in context: http://old.nabble.com/MIT-krb5-on-cygwin--tp27846278p27863939.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
Re: Possible Documentation Inconsistency
On 3/11/2010 5:20 AM, Corinna Vinschen wrote: On Mar 10 22:17, Buchbinder, Barry (NIH/NIAID) [E] wrote: http://cygwin.com/cygwin-ug-net/using-effectively.html#using-shortcuts By default, Cygwin uses a mechanism that creates symbolic links that are compatible with standard Microsoft .lnk files. http://cygwin.com/cygwin-ug-net/using-cygwinenv.html#cygwinenv-implemented-options (no)winsymlinks ... Defaults to not set since plain file symlinks are faster to write and faster to read. Thanks for the heads-up. Somehow the text doesn't fit well anymore. Is that better? Another problem area is between Unix-style links, which link one file to another, and Microsoft .lnk files, which provide a shortcut to a file. They seem similar at first glance but, in reality, are fairly different. By default, Cygwin does not create symlinks as .lnk files, but there's an option to do that, seexref: CYGWIN environment variable These symlink .lnk files are compatible with Windows-created .lnk files, but they are still different. They do not include much of the information that is available in a standard Microsoft shortcut, such as the working directory, an icon, etc. The cygutils package includes a mkshortcut utility for creating standard native Microsoft .lnk files. But here's the problem. If Cygwin handled these native shortcuts like any other symlink, [...] I'm open for suggestions to phrase that more eloquently. Looks good to me. -- 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
[ANNOUNCEMENT] Updated [experimental]: coreutils-8.4-1
For those people testing cygwin snapshots, a new release of coreutils, 8.4-1, has been uploaded. 7.0-2 remains current, because the 8.4-1 release depends on features available only in recent snapshots (that is, don't upgraded if you are still using the current cygwin 1.7.1). NEWS: = This is a new upstream release, which I had been neglecting to track for a while. Among other upstream highlights, it adds a new nproc(1) utility, overhauled rm(1) to be more reliable, improved touch(1) to alter symlink timestamps, improved mktemp(1) to allow user-specified suffixes, and in general fixed a number of bugs. A full NEWS summary will be attached when this version is promoted to current after cygwin 1.7.2 is released. This particular build also adds cygwin-specific code to try and fix the bugs reported about cp and install not sticking an .exe suffix on the target, when the source was specified without a suffix. If you encounter a regression, please report it here rather than upstream. See also the upstream documentation in /usr/share/doc/coreutils/. Help in porting the stdbuf utility to cygwin would be appreciated. DESCRIPTION: GNU coreutils provides a collection of commonly used utilities essential to a standard POSIX environment. It comprises the former textutils, sh-utils, and fileutils packages. The following executables are included: [ arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold gkill groups head hostid hostname id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stty su sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes UPDATE: === To update your installation, first install the 20100309 snapshot or newer. Then click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions, select the 'Exp' radio button, and look for 'coreutils' in the 'Base' category (it should already be selected). DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin coreutils maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. signature.asc Description: OpenPGP digital signature
gettext/libiconv and libtool problem
gettext has a requirement on libiconv2. libiconv2 contains only the cygiconv dll and nothing else. OK. So we have a typical (libtooled) autoconf/automake configure which has a AM_GNU_GETTEXT([external]). Fine, the configure proceeds and produces something like - checking for GNU gettext in libc... no checking for iconv... no, consider installing GNU libiconv checking for GNU gettext in libintl... yes checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... -lintl etc. Also fine. We then do the make which blows up with - libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled argument `/usr/lib/libiconv.la' It looks to me as though libiconv2 should be supplying libiconv.la as the gettext libintl.la has these lines - # Libraries that this one depends upon. dependency_libs=' -L/usr/lib /usr/lib/libiconv.la' In fact I wonder whether or not gettext should require libiconv instead of/as well as libiconv2. Roger -- 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: gettext/libiconv and libtool problem
On 3/11/2010 12:29 PM, Roger While wrote: gettext has a requirement on libiconv2. libiconv2 contains only the cygiconv dll and nothing else. OK. So we have a typical (libtooled) autoconf/automake configure which has a AM_GNU_GETTEXT([external]). Fine, the configure proceeds and produces something like - checking for GNU gettext in libc... no checking for iconv... no, consider installing GNU libiconv checking for GNU gettext in libintl... yes checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... -lintl etc. Also fine. We then do the make which blows up with - libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled argument `/usr/lib/libiconv.la' It looks to me as though libiconv2 should be supplying libiconv.la as the gettext libintl.la has these lines - # Libraries that this one depends upon. dependency_libs=' -L/usr/lib /usr/lib/libiconv.la' In fact I wonder whether or not gettext should require libiconv instead of/as well as libiconv2. You must be missing 'libiconv' then: http://cygwin.com/cgi-bin2/package-grep.cgi?grep=libiconv.la -- 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: redirect-append () creates garbage-y file
On Thu, Mar 11, 2010 at 6:46 PM, William Lebow wrote: Hi Csaba, Thank you very much for the reply. I've downgraded my version of cygwin so I need to wait and do the test when I have a few minutes to reinstall the newer one. Is the command you sent correct? I don't think tail has a -a option. That's because it should have been echo foo | tee -a test3.txt :( -- Life is complex, with real and imaginary parts -- 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: redirect-append () creates garbage-y file
echo foo | tee -a test3.txt : terminal output is okay but test3.text starts with 3 characters of garbage before the string foo echo foo | tee test4.txt : terminal output is okay and test4.txt is okay too So tee -a has the same issue as when creating a new file. BTW, I believe that the garbage characters that precede the text is an encrypted version of the text in the file. This Credant software is protecting my txt files by encrypting them. -- Bill -Original Message- From: Csaba Raduly [mailto:rcs...@gmail.com] Sent: Thursday, March 11, 2010 1:00 PM To: William Lebow Cc: cygwin@cygwin.com Subject: Re: redirect-append () creates garbage-y file On Thu, Mar 11, 2010 at 6:46 PM, William Lebow wrote: Hi Csaba, Thank you very much for the reply. I've downgraded my version of cygwin so I need to wait and do the test when I have a few minutes to reinstall the newer one. Is the command you sent correct? I don't think tail has a -a option. That's because it should have been echo foo | tee -a test3.txt :( -- Life is complex, with real and imaginary parts -- 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: redirect-append () creates garbage-y file
On Mar 11 13:12, William Lebow wrote: echo foo | tee -a test3.txt : terminal output is okay but test3.text starts with 3 characters of garbage before the string foo echo foo | tee test4.txt : terminal output is okay and test4.txt is okay too So tee -a has the same issue as when creating a new file. BTW, I believe that the garbage characters that precede the text is an encrypted version of the text in the file. This Credant software is protecting my txt files by encrypting them. And it's doing something blatantly wrong. Quite obviously, Cygwin only writes the data once. If it's in the file twice, once encrypted and once unencrypted, then this Credant software does not understand native NT writing with append mode(*). You should report this as a bug. Corinna (*) http://msdn.microsoft.com/en-us/library/ms804364.aspx, see the ByteOffset description, last paragraph, the FILE_WRITE_TO_END_OF_FILE offset value. -- 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: git stopped working with 1.7.1
Brian L. br...@blucz.com wrote: From this thread I gather that little or no progress has been made on addressing the root cause of this issue. It still seems to be broken with the latest 1.7 series packages. What is the proper method for getting this bug in front of the guys who maintain the openssh package? The cygwin website suggests that the mailing list is the proper channel, but it doesn't seem like anyone's seriously looking into this as an openssh issue. It's clearly affecting more than a few users and the workaround, while reliable, is quite lame. Can this please get a little bit more priority? and another month goes by... If there is work going on behind the scenes, it would be nice to hear from the developer(s) working on it. If it is not being worked on... I agree with Brian. This is a serious impediment to using Cygwin 1.7. I would think it would be of top priority. Thanks. Kevin -- 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
compiling apache2.2.6 package fails on cygwin 1.7
Hello, we are trying to compile apache2 from the cygwin-supplied source tree using the apache2-2.2.6-1.sh script. The reason I want to compile an own apache is that we need some additional modules not available from the cygwin repositories. After success, I plan to publish these for the community. I think we have all the necessary packages such as apr, apr-util, ldap, ssl and the respective devel packages. This cygwin runs on a w2k3 server (64 bit). The compile step goes well, in the linker phase we get an error in the final step: make[1]: Entering directory `/usr/src/httpd-2.2.6/.build' /usr/share/apr/build-1/libtool --silent --mode=link gcc -O2 -L/usr/lib -o httpd2 -export-dynamic */usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_winm...@16'* collect2: ld returned 1 exit status make[1]: *** [httpd2] Error 1 make[1]: Leaving directory `/usr/src/httpd-2.2.6/.build' make: *** [all-recursive] Error 1 The only reference to this error that I could find refers to a missing main() or Winmain() function: http://www.bloodshed.net/dev/faq.html#winmain But as obviously this package has succseefully been compiled under cygwin this cannot be the real problem.. Does anybody have a hint what is going wrong here? Thanks for a hint, Jakob Curdes -- 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
cron-config has a debug set -x
The current cron-config has as the second line: set -x So when you run it: lemon:~$ cron-config + PATH='/usr/bin:/home/tschutter/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Program Files/CollabNet Subversion Client:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/Microsoft SQL Server/90/Tools/binn/:/cygdrive/c/Program Files/WinZip:/cygdrive/c/Program Files/Dell/SysMgt/oma/bin:/cygdrive/c/Program Files/Dell/SysMgt/oma/oldiags/bin:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0:/cygdrive/c/Python26' ++ id -un + USER=tschutter + get_temp_dir and on and on and on... -- Tom Schutter First American Spatial Solutions 303-440-7272 x6822 512-977-6822 -- 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: git stopped working with 1.7.1
On 3/11/2010 1:50 PM, Kevin Layer wrote: Brian L.br...@blucz.com wrote: From this thread I gather that little or no progress has been made on addressing the root cause of this issue. It still seems to be broken with the latest 1.7 series packages. What is the proper method for getting this bug in front of the guys who maintain the openssh package? The cygwin website suggests that the mailing list is the proper channel, but it doesn't seem like anyone's seriously looking into this as an openssh issue. It's clearly affecting more than a few users and the workaround, while reliable, is quite lame. Can this please get a little bit more priority? and another month goes by... If there is work going on behind the scenes, it would be nice to hear from the developer(s) working on it. If it is not being worked on... I agree with Brian. This is a serious impediment to using Cygwin 1.7. I would think it would be of top priority. As always, it's worth noting that one way to jump-start activity in an area of open source that is of interest to you is dig in and offer some insights to the problem that's affecting you. I guess this goes without saying though, sometimes, it's beneficial to say things that don't need to be said. ;-) -- 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: compiling apache2.2.6 package fails on cygwin 1.7
On 3/11/2010 2:26 PM, Jakob Curdes wrote: But as obviously this package has succseefully been compiled under cygwin this cannot be the real problem.. Does anybody have a hint what is going wrong here? Are you using the scripts/process from the Cygwin source tarball? If not, take a look there to see if that offers some insights. -- 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: 1.7 - Problem installing perl modules
Robert Slater schrieb: In the process of installing perl modules to get an IRC bot working via cygwin, I'm encountering a problem with make installing ExtUtils::CBuilder and thus the modules that depend upon it. The make / install goes through fine, but cygwin doesn't seem to detect it afterwards. Same problems as for most perl users here. You try to compile an extension with gcc-3, but you need gcc-4. ExtUtils::CBuilder is not really a XS extension, so you get diffeent errors as most others, but ExtUtils::CBuilder is a tool to build XS extensions so you also need the current gcc, which is gcc-4. -- 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: Close==SIGHUP
Andy Koppe schrieb: Hallo Thomas, Ich habe den Close==SIGHUP Wunsch auf trunk implementiert. Wär toll, wenn Du das einem Härtetest unterziehen könntest, auch in Verbindung mit --hold=always und --hold=error. Looks like 6-beta3 is not good. Two mintty sessions with just bash doing nothing keep the CPU busy with 50% per bash, so that I even cannot successfully open a google chrome url. -- 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: cron-config has a debug set -x
- Original Message - From: Tom Schutter To: cygwin Sent: Thursday, March 11, 2010 14:36 | The current cron-config has as the second line: | | set -x Thanks for the report. I will fix that this evening. Pierre -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
mintty 0.6-beta3 problem (was: Re: Close==SIGHUP)
Reini Urban: Looks like 6-beta3 is not good. Two mintty sessions with just bash doing nothing keep the CPU busy with 50% per bash, so that I even cannot successfully open a google chrome url. Thanks. This won't be to do with the Close==SIGHUP thing, since that's not in beta3. And of course I need more detail: - What Cygwin and Windows versions are you running? - How did you start the mintty instances? - Does the issue occur straight away or was there something that might have triggered it? - Is it the mintty or the bash processes that occupy the CPU? Perhaps we should take this to the mintty issue tracker, since the beta isn't shipped with Cygwin. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gcc cannot find stdio.h
On Thu, Mar 11, 2010 at 07:08:56AM -0500, Jacob Jacobson wrote: On 03/11/2010 04:24 AM, Csaba Raduly wrote: On Wed, Mar 10, 2...@10:41 PM, Jacob Jacobson wrote: Larry Hall (Cygwin) wrote: (snip) You are missing a few entries, though it's not clear why you don't have them. Reinstall the 'cygwin' package. Thanks. I reinstalled cygwin package and gcc works now. I also noticed that the message about regtool went away. This sounds like http://sourceware.org/ml/cygwin/2010-01/msg00562.html Yes. That's exactly what happened. Should have paid more attention to the missing regtool message. This particular problem has been fixed in setup.exe for a couple of months so it should not have been an issue unless you were using two month old version of setup.exe. 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: compiling apache2.2.6 package fails on cygwin 1.7
On 11/03/2010 19:26, Jakob Curdes wrote: The compile step goes well, in the linker phase we get an error in the final step: make[1]: Entering directory `/usr/src/httpd-2.2.6/.build' /usr/share/apr/build-1/libtool --silent --mode=link gcc -O2 -L/usr/lib -o httpd2 -export-dynamic */usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_winm...@16'* collect2: ld returned 1 exit status make[1]: *** [httpd2] Error 1 make[1]: Leaving directory `/usr/src/httpd-2.2.6/.build' make: *** [all-recursive] Error 1 That's bizarre. Something's gone wrong in the Makefile generation probably, but for whatever reason, there aren't any .o files listed on that supposed final link commandline. Or any libraries. You're going to have to look in the makefile, find out where that commandline comes from, and figure out how it expects to get object files defined and why it's not happening. cheers, DaveK -- 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: compiling apache2.2.6 package fails on cygwin 1.7
But as obviously this package has succseefully been compiled under cygwin this cannot be the real problem.. Does anybody have a hint what is going wrong here? Are you using the scripts/process from the Cygwin source tarball? If not, take a look there to see if that offers some insights. Yes, I used the apache2-2.2.6-1.sh script from the cygwin source tarball for apache2.2.6. (package apache2/apache2-2.2.6-1-src). I also read /usr/share/doc/Cygwin/*apache*2-2.2.6.README but there are no hints or special instructions. This is why I am wondering; maybe the maintainer can tell if this is a general problem that he overcame in some way or if this seems to be pinned to this installation. Might this be a problem with a 64 bit Windows operating system? Best regards, Jakob Curdes (snip) Hello, we are trying to compile apache2 from the cygwin-supplied source tree using the apache2-2.2.6-1.sh script. The reason I want to compile an own apache is that we need some additional modules not available from the cygwin repositories. After success, I plan to publish these for the community. I think we have all the necessary packages such as apr, apr-util, ldap, ssl and the respective devel packages. This cygwin runs on a w2k3 server (64 bit). The compile step goes well, in the linker phase we get an error in the final step: make[1]: Entering directory `/usr/src/httpd-2.2.6/.build' /usr/share/apr/build-1/libtool --silent --mode=link gcc -O2 -L/usr/lib -o httpd2 -export-dynamic */usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_winm...@16'* collect2: ld returned 1 exit status make[1]: *** [httpd2] Error 1 make[1]: Leaving directory `/usr/src/httpd-2.2.6/.build' make: *** [all-recursive] Error 1 The only reference to this error that I could find refers to a missing main() or Winmain() function: http://www.bloodshed.net/dev/faq.html#winmain But as obviously this package has succseefully been compiled under cygwin this cannot be the real problem.. Does anybody have a hint what is going wrong here? Thanks for a hint, Jakob Curdes -- 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: gettext/libiconv and libtool problem
Roger While wrote: gettext has a requirement on libiconv2. libiconv2 contains only the cygiconv dll and nothing else. OK. So we have a typical (libtooled) autoconf/automake configure which has a AM_GNU_GETTEXT([external]). Fine, the configure proceeds and produces something like - checking for GNU gettext in libc... no checking for iconv... no, consider installing GNU libiconv checking for GNU gettext in libintl... yes checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... -lintl etc. Also fine. We then do the make which blows up with - libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled argument `/usr/lib/libiconv.la' This means that the libiconv development files are a *build-time* dependency of whatever you're compiling. They are not *run-time* dependencies of any of the binaries in the gettext package. gettext.exe works just fine, without libiconv.la ditto ngettext.exe ditto ditto envsubst.exe The cygwin setup.hint requires: flag is used to represent *run-time* dependencies, not stuff that would probably be nice to have installed along with package A, IF you are using package A in /this/ particular way, and then later run all this other stuff while compiling package C. The gettext binaries run without error. They may, perhaps, leave traces in configure scripts -- such that when you run that configure script, and then later run make, which runs gcc, which runs ld, you may find that at THAT time, you'd need libiconv.la. No way is that a run-time requirement of the original gettext binaries. -- 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: git stopped working with 1.7.1
Kevin Layer wrote: Brian L. wrote: It's clearly affecting more than a few users and the workaround, while reliable, is quite lame. Can this please get a little bit more priority? and another month goes by... If there is work going on behind the scenes, it would be nice to hear from the developer(s) working on it. If it is not being worked on... I agree with Brian. This is a serious impediment to using Cygwin 1.7. I would think it would be of top priority. Only people who experience the problem can diagnose, debug, and fix it. git works fine for me under cygwin-1.7.1 (Vista, NTFS), so... Has the cygwin git maintainer been able to verify/reproduce the error? If not, then there's no way he can help you. -- 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: git stopped working with 1.7.1
On 03/11/2010 04:03 PM, Charles Wilson wrote: If it is not being worked on... I agree with Brian. This is a serious impediment to using Cygwin 1.7. I would think it would be of top priority. Only people who experience the problem can diagnose, debug, and fix it. git works fine for me under cygwin-1.7.1 (Vista, NTFS), so... Has the cygwin git maintainer been able to verify/reproduce the error? If not, then there's no way he can help you. I have sometimes seen the problem, but it has never been a show-stopper for me (I fall back to http cloning), and, so far, it has not percolated high enough to the top of my TODO list to be worth the investment of my time on it. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org volunteer cygwin git maintainer signature.asc Description: OpenPGP digital signature
Re: compiling apache2.2.6 package fails on cygwin 1.7
Jakob Curdes wrote: But as obviously this package has succseefully been compiled under cygwin this cannot be the real problem.. cygwin's apache2 package has not been rebuilt since Sep 17 2007, and it is now orphaned. Translation: bit rot. there have been a LOT of changes in cygwin and many of the other libraries, but this frozen-in-amber version of apache2 has not been updated as (may be) required. Frankly, I think you'd have better luck starting with cygwin-ports version: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ but...even that might be tricky, as the cygwin-ports buildscript for apache2 may assume the presence of other packages from cygwin-ports, which are not yet available in the main distro. YMMV. -- 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
genini: message field always emitted
AFAIK, the new message: field in setup.hint is not intended to be a required field. However, if it is missing from the setup.hint, genini complains. Fine, I can work around this by (always...) using --okmissing=message. However, if I do that, then I get a setup.ini like the following: ... @ test-data sdesc: test package ldesc: test package category: Utils message: version: 0.1-2 install: release/test-data/test-data-0.1-2.tar.xz 116920 e69dda662fde6b02644d4562c1ed0541 source: release/test-data/test-data-0.1-2-src.tar.xz 108 7f06fdbf4fd1eff94c1c85068c155c1c ... And when I run setup.exe, I get a popup with the following message: C:\cygwin-1.7\usr\src\devel\setup\test/setup.ini line 10: syntax error, unexpected NL, expecting STRING C:\cygwin-1.7\usr\src\devel\setup\test/setup.ini line 10: unrecognized line 11 (do you have the latest setup?) It appears there are three separate problems here. 1) It'd be nice if genini didn't assume that all of the keywords it knows about are required. E.g. pre-seed okmissing with (list of optional keywords)? 2) Failing that, since message is optional, then if the data structure for a particular package has no entry for 'message', then...genini should not print out an useless 'message: ' line. 3) Finally, setup.exe's behavior when seeing this entry...is this a bug? If you have message: or even message: should setup.exe treat that like an empty requires:, and just ignore it? Or do we assume that if a message: entry is present then there WILL be a message popup...and it better have a non-empty string value? No patch yet, because I'm not sure what the correct action should be. -- 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: genini: message field always emitted
Charles Wilson wrote: AFAIK, the new message: field in setup.hint is not intended to be a Sorry. Wrong list. -- 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: allow executing a path in backslash notation
On Mar 10 10:25, Corinna Vinschen wrote:
execv (argv[1], args);
bash$ gcc -o exec exec.c
bash$ ./exec /bin/echo
abc
bash$ ./exec C:\\cygwin\\bin\\echo
abc
Thanks for trying a test case. I am attaching a new test case that
shows that the trouble was with execvp(), not exec(). Only execvp()
calls find_exec() which fails to find a file in backslash notation,
find_exec (path, buf, PATH=, FE_NNF)
Another call to find_exec in spawnvpe() seems to succeed,
find_exec (file, buf)
So, perhaps, another way to address the issue is to call find_exec()
without the 2 extra parameters. I find it confusing that the
function did not work despite its numerous options and its usage of
isdrive() implying attempts to handle Windows native paths.
--
#include process.h// for spawnvpe() (not specified by The Open Group)
#include unistd.h // for execvp()
#include stdio.h // for printf()
#include errno.h // for errno
#include string.h // for strdup(), strerror()
#include stdlib.h // for getenv()
int
main (int argc, const char *argv[])
{
const char const *args[3];
char *mutable_args[3];
// See http://c-faq.com/ansi/constmismatch.html explaining that a promise
// of constness of values pointed to by pointer elements requires constness
// of pointers as well. In other words, a const char** parameter cannot
// accept a char ** argument.
const char *envp[2];
const char *pathvalue = NULL;
char *pathenv = NULL;
int ec;
if ( argc 2 ) {
return 2;
}
args[ 0 ] = argv[1];
args[ 1 ] = abc;
args[ 2 ] = NULL;
mutable_args[ 0 ] = strdup( args[ 0 ] );
mutable_args[ 1 ] = strdup( args[ 1 ] );
mutable_args[ 2 ] = NULL;
pathvalue = getenv( PATH );
if (pathvalue) {
int pathlen = strlen( pathvalue );
pathenv = malloc( 5 + pathlen + 1 );
if ( pathenv ) {
memcpy( pathenv, PATH=, 5 );
memcpy( pathenv + 5, pathvalue, pathlen + 1 );
}
}
envp[ 0 ] = pathenv;
envp[ 1 ] = NULL;
setbuf( stdout, NULL );
setbuf( stderr, NULL );
printf( Spawning %s with search in $PATH and a limited environment...\n,
args[ 0 ] );
ec = spawnvpe( _P_WAIT, args[ 0 ], args, envp );
printf( Exit code: %d\n\n, ec );
printf( Loading %s with search in $PATH and inherited environment...\n,
args[ 0 ] );
// The prototype in unistd.h differs from the one in process.h. The former
// does not promise to keep the pointers intact.
execvp( args[ 0 ], mutable_args );
ec = errno;
printf( Load error: %s (%d)\n, strerror( ec ), ec );
return ec;
}
C:\WORK.\exec.exe ..\echo.exe
Spawning ..\echo.exe with search in $PATH and a limited environment...
abc
Exit code: 0
Loading ..\echo.exe with search in $PATH and inherited environment...
Load error: No such file or directory (2)
C:\WORKcopy \cygwin\bin\cygwin1.dll.new \cygwin\bin\cygwin1.dll
Overwrite \cygwin\bin\cygwin1.dll? (Yes/No/All): y
1 file(s) copied.
C:\WORK.\exec.exe ..\echo.exe
Spawning ..\echo.exe with search in $PATH and a limited environment...
abc
Exit code: 0
Loading ..\echo.exe with search in $PATH and inherited environment...
abc
C:\WORK
--
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: allow executing a path in backslash notation
constness of pointers Err, I meant constness of rvalue. But this is not related. -- -- 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: compiling apache2.2.6 package fails on cygwin 1.7
On 2010-03-11 17:10, Charles Wilson wrote: Frankly, I think you'd have better luck starting with cygwin-ports version: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ I just updated this for the latest stable release. I'm having some trouble actually starting it, but that could easily be a configuration issue. This should get you started though. but...even that might be tricky, as the cygwin-ports buildscript for apache2 may assume the presence of other packages from cygwin-ports, which are not yet available in the main distro. YMMV. AFAICS here are the deps, all of which are in the distro: crypt libapr1-devel libaprutil1-devel libpcre-devel openldap-devel openssl-devel zlib-devel HTH, 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
fork problems on x64
I have the same problems with multiple apps - Exim and UW-ipop. They both fail with the same faults: fork: Resource temporarily unavailable The Exim will send a few mails, but will fail after a few minutes use. UW-ipop fails the first time its called into use. Both are loaded as services into an x64 2008 R2 server. I notice the mail list has other x64 fork problem reports. My suspicion is the fault is in the core cygwin dll. Any thoughts please? -- Regards -- Ross Hemingway -- 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: compiling apache2.2.6 package fails on cygwin 1.7
Frankly, I think you'd have better luck starting with cygwin-ports version: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ I just updated this for the latest stable release. I'm having some trouble actually starting it, but that could easily be a configuration issue. This should get you started though. but...even that might be tricky, as the cygwin-ports buildscript for apache2 may assume the presence of other packages from cygwin-ports, which are not yet available in the main distro. YMMV. AFAICS here are the deps, all of which are in the distro: crypt libapr1-devel libaprutil1-devel libpcre-devel openldap-devel openssl-devel zlib-devel That sounds great and the fact that the mainstream package has not been touched for a long time might explain a lot. I have all the dependencies anyway and will try the ports package ASAP. Report goes back to the list. Thanks for now, Jakob Curdes -- 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
