Re: Question: Desired owner/group when running setup-1.7.exe
On Apr 18 10:13, Charles Wilson wrote: Corinna Vinschen wrote: owner: Current user. group: The primary group of the account running setup. other: Everyone, as usual. Although current user is Administrator if you launch setup on Vista as an ordinary user, but you have UAC enabled. No, not exactly. You're still your own self, just with the token extended to contain the Administrators group with SE_GROUP_ENABLED flag set in the group list, instead of with SE_GROUP_USE_FOR_DENY_ONLY. But it doesn't really matter. If you're running setup as a user which is member of the Administrators group, on Vista or earlier, you have the Administrators group in your user token. As the discussion in the aforementioned thread shows, this might not be feasible in all environments. OTOH, whatever we do, somebody *will* complain. Yep! I don't think it makes sense to have a setting in setup.exe to choose user and group explicitely. We should make a default setting and everything else is up to the chown tool. I'm not so sure. Your solution would mean that *every* time I update, I would need to do a full recursive chown -R. But not *really* recursive: Why? I mean, why should you have a desire to chown the Cygwin tree? The permissions are the ones from the archive. The owner is the Admin's group (sort of root, which is probably what you want anyway), and the files created by postinstall scripts will get the right owner and permission by the script. In theory, if we do it that way (assuming solution 3), a chown -R should never be necessary. I think setup should accept three new command-line arguments: --change-owner= --change-group= --add-group-write-permission I don't like the idea of additional command line options since it doesn't help 99% of the users, which are using setup.exe as a GUI-only tool. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Question: Desired owner/group when running setup-1.7.exe
On Apr 18 09:52, Karl M wrote: [ ] If the current user is an administrative user, make Administrators the owner of the files: owner: Administrators. group: The primary group of the account running setup. Comment: I like number 3 the best. I generally use Administrators none and 755 for everything but individual users files and special files that specific permissions for sshd and such. I currently run a script that hammers the permissions and ownership after each run of setup.exe. I usually just turn execute permissions on for everything, but I wouldn't mind doing a better job on that. What about having setup look at a special file and use the ACL as a template for what it does? Then, once a user has installed and configued, setup.exe won't bork it later. The only reason that I run a script after each setup is to fixup mounts and permissions. What for? Solution 3 should be universal enough to not require running chown afterwards at all. Or only for very specific company needs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Question: Desired owner/group when running setup-1.7.exe
On Apr 19 10:27, Julio Costa wrote: [X ] If the current user is an administrative user, make Administrators the owner of the files: owner: Administrators. group: The primary group of the account running setup. Comment: [...] I'm also more inclined to the 3rd option, although I've not taken that decision easily, because user foo would not see his/her files as foo's but as Admins's (actually root). But seems to be the more compatible solution. The least harm law... WHy do you think that? Setup.exe has nothing to do with the Cygwin DLL as far as file ownership is concerned. The files installed from the distro will be owned by Administrators, the files created within Cygwin will be owned by the user itself. And I would add another rule: If the installing user is not Admin, but the primary group is 'Domain Users', change gid to 'Users', so that an instalation don't be inaccessible for local users. I don't think that's necessary. Either you're an admin and you want to install for everyone, or you are a user just installing for yourself. There's no other option and no need for another option. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU 1.7] mpfr-2.4.1-3
On Apr 18 22:09, David Billinghurst wrote: mpfr-2.4.1-3 for cygwin-1.7 is available for upload. This is a rebuild using the new gmp-4.3.0-1 and compiled with gcc-4. I suggest that we keep mpfr-2.4.1-2 and delete the older versions inherited from cygwin-1.5. Uploaded. I removed 2.3.1-1 and 2.3.2-1. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP 1.7] PPL - The Parma Polyhedra Library 0.10.2
On Apr 18 22:18, David Billinghurst wrote: Parma Polyhedra Library (PPL) is needed to build GCC with the Graphite loop optimizations - http://gcc.gnu.org/install/prerequisites.html. As the GMP maintainer, I'd like to provide ppl-0.10.2 for cygwin-1.7. It builds OOTB with gcc-4 and gmp-4.3.0-1. I don't think ppl is (yet) provided by many linux distributions, so we need a vote. +1. 5 votes, afaics. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU 1.7] gmp-4.3.0-1
On Apr 18 22:09, David Billinghurst wrote: A build of gmp-4.3.0-1 for cygwin 1.7 is available for upload. This is the first build using gcc-4. I have bumped the C++ DLL version number from 3 to 4. The C DLL is binary compatible with the previous release. I have marked updated gmp/libgmpxx3/setup.hint to mark the library as obsolete, and provided a renamed gmp-4.2.4-2-src.tar.bz2 as libgmpxx3-4.2.4-2-src.tar.bz2 We should keep gmp-4.2.4-2 but the older versions - inherited from cygwin-1.5 - can be deleted. Uploaded. I removed 4.2.2-1 and 4.2.3-1. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Question: Desired owner/group when running setup-1.7.exe
On Mon, Apr 20, 2009 at 11:07, Corinna Vinschen wrote: On Apr 19 10:27, Julio Costa wrote: [X ] If the current user is an administrative user, make Administrators the owner of the files: owner: Administrators. group: The primary group of the account running setup. Comment: [...] I'm also more inclined to the 3rd option, although I've not taken that decision easily, because user foo would not see his/her files as foo's but as Admins's (actually root). But seems to be the more compatible solution. The least harm law... WHy do you think that? Setup.exe has nothing to do with the Cygwin DLL as far as file ownership is concerned. The files installed from the distro will be owned by Administrators, the files created within Cygwin will be owned by the user itself. I know that setup.exe is independent of cygwin.dll but - now I'm confused - are you saying that ONLY files installed by setup.exe will follow this new ownership rule, but subsequent executions / copying / file creations, etc, *inside* Cygwin environments will still use Admin:None or whatever for ownership? Are you saying that the proposed changes will be only at the *packaging* level, forced to have owner uid to that of Admins? In that case, how will you enforce ownership on pos-instalation scripts? That doesn't make much sense... and it's not even coherent behavior. And surely will break things in the long run. And I would add another rule: If the installing user is not Admin, but the primary group is 'Domain Users', change gid to 'Users', so that an instalation don't be inaccessible for local users. I don't think that's necessary. Either you're an admin and you want to install for everyone, or you are a user just installing for yourself. There's no other option and no need for another option. Yes, you're right. Fair enough. Never mind my (not so) bright idea :) -- ___ Julio Costa
Re: Question: Desired owner/group when running setup-1.7.exe
On Apr 20 14:26, Julio Costa wrote: On Mon, Apr 20, 2009 at 11:07, Corinna Vinschen wrote: On Apr 19 10:27, Julio Costa wrote: [X ] If the current user is an administrative user, make Administrators the owner of the files: owner: Administrators. group: The primary group of the account running setup. Comment: [...] I'm also more inclined to the 3rd option, although I've not taken that decision easily, because user foo would not see his/her files as foo's but as Admins's (actually root). But seems to be the more compatible solution. The least harm law... WHy do you think that? Setup.exe has nothing to do with the Cygwin DLL as far as file ownership is concerned. The files installed from the distro will be owned by Administrators, the files created within Cygwin will be owned by the user itself. I know that setup.exe is independent of cygwin.dll but - now I'm confused - are you saying that ONLY files installed by setup.exe will follow this new ownership rule, but subsequent executions / copying / file creations, etc, *inside* Cygwin environments will still use Admin:None or whatever for ownership? Sure. If you don't like the default group, change it in /etc/passwd(*). If you don't like the owner, use chown. Are you saying that the proposed changes will be only at the *packaging* level, forced to have owner uid to that of Admins? Yes. In that case, how will you enforce ownership on pos-instalation scripts? That's the job of the script. That doesn't make much sense... and it's not even coherent behavior. And surely will break things in the long run. I don't think so. And I dislike the idea extremly that files created by a user foo are owned by the admins group, just because the user is a member of the admins group. That's not the default anymore in Windows since at least XP, if not Windows 2000. Also, many postinstall files are user files. You wouldn't want the files in your own homedir being owned by the admins group. Other than that, Cygwin is still a POSIX environment, not some native Windows tool. Along these lines, the second suggestion (owner: user, group: admins) might be more correct. Corinna (*) I take it for granted that you read the User's Guide. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Question: Desired owner/group when running setup-1.7.exe
On Apr 20 09:41, Charles Wilson wrote: Corinna Vinschen wrote: On Apr 18 10:13, Charles Wilson wrote: Corinna Vinschen wrote: owner: Current user. group: The primary group of the account running setup. other: Everyone, as usual. Although current user is Administrator if you launch setup on Vista as an ordinary user, but you have UAC enabled. No, not exactly. You're still your own self, just with the token extended to contain the Administrators group with SE_GROUP_ENABLED flag set in the group list, instead of with SE_GROUP_USE_FOR_DENY_ONLY. But it doesn't really matter. If you're running setup as a user which is member of the Administrators group, on Vista or earlier, you have the Administrators group in your user token. ??? I normally run setup using Run as administrator -- but then, of course, the process is not REALLY elevated until UAC kicks in. I'm not in a domain. So: $ getfacl /usr/bin/[.exe # file: /usr/bin/[.exe # owner: Administrator # group: None Ok, we're talking two different approaches I guess. When *I* use an elevated shell, the files are still owned by me, because my account is a member of the admins group. From the above I take it that you're running under a normal user account and elevate to the real Administrator. user::rwx group::r-x mask:rwx other:r-x Is exactly what you'd expect. But the Administrators group is nowhere present. How does that jibe with the 'token extended to contain the Administrators group'? Shouldn't there then be an additional entry for the Administrators group? Why? I wasn't talking about file ownership or ACL entries, I was talking about the user token of the process. Just because a group is in your token's group list doesn't mean it's used to create an ACL. Why? I mean, why should you have a desire to chown the Cygwin tree? The permissions are the ones from the archive. The owner is the Admin's group (sort of root, which is probably what you want anyway), and the files created by postinstall scripts will get the right owner and permission by the script. No, in the existing setup, given the case above, the owner is the actual user used to run setup (in this case, 'Administrator' via the 'Run as Administrator'. NOT the AdministratorS group. I thought we were talking about the situation after setup has been changed to create files owned by Administrators. In theory, if we do it that way (assuming solution 3), a chown -R should never be necessary. Well, assuming solution 3...wasn't there a lot of confusion in the 1.3.x days when if you created a file as Administrator it was always owned by AdministratorS? If there were no problems with that behavior, why was it changed? That had never anything to do with the Cygwin release since back to 1.0 days. Old Windows NT versions created files with the owner set to administrators if your account was a member of the admins group. Sorry, but this is getting too complicated. I thought I'm asking a simple question. I was just trying to help this along so that the least number of people have trouble with the default file permissions. Here's another simple approach: Keep all ownership as it is. Just add an ACE for the administrators group with rw- access rights to the ACL of files created/unpacked by setup. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP 1.7] PPL - The Parma Polyhedra Library 0.10.2
On Apr 18 22:18, David Billinghurst wrote: Parma Polyhedra Library (PPL) is needed to build GCC with the Graphite loop optimizations - http://gcc.gnu.org/install/prerequisites.html. As the GMP maintainer, I'd like to provide ppl-0.10.2 for cygwin-1.7. It builds OOTB with gcc-4 and gmp-4.3.0-1. I don't think ppl is (yet) provided by many linux distributions, so we need a vote. For the impatient, a test package is available from http://billinghurst.customer.netspace.net.au/cygwin-1.7/ppl I need to do a final check of the packaging, and I may not get to it for a few days. David
[ITP][1.7] CLooG-PPL version 0.15
CLooG-PPL version 0.15 - http://www.cloog.org/ is needed to build GCC 4.4 with the Graphite loop optimizations http://gcc.gnu.org/install/prerequisites.html. I'd like to provide cloog-ppl-0.15.3 for cygwin-1.7. It requires the Parma Polyhedra Library (PPL), which is already on the way. This also requires a vote. I plan to provide 3 packages: cloog-ppl, libcloog0 and libcloog-devel cloog-ppl usr/bin/cloog.exe usr/share/doc/cloog-ppl/ usr/share/doc/cloog-ppl/COPYING usr/share/doc/cloog-ppl/LICENSE usr/share/doc/cloog-ppl/README usr/share/doc/Cygwin/ usr/share/doc/Cygwin/cloog-ppl.README usr/share/info/cloog.info.gz libcloog0 usr/bin/cygcloog-0.dll libcloog-devel usr/include/cloog/*.h usr/lib/libcloog.dll.a usr/lib/libcloog.la A first pass at a package is available from http://billinghurst.customer.netspace.net.au/cygwin-1.7/cloog-ppl
Re: [ITP][1.7] CLooG-PPL version 0.15
On Apr 21 01:00, David Billinghurst wrote: CLooG-PPL version 0.15 - http://www.cloog.org/ is needed to build GCC 4.4 with the Graphite loop optimizations http://gcc.gnu.org/install/prerequisites.html. I'd like to provide cloog-ppl-0.15.3 for cygwin-1.7. It requires the Parma Polyhedra Library (PPL), which is already on the way. This also requires a vote. +1 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Question: Desired owner/group when running setup-1.7.exe
On Mon, Apr 20, 2009 at 14:58, Corinna Vinschen wrote: Sorry, but this is getting too complicated. I thought I'm asking a simple question. I was just trying to help this along so that the least number of people have trouble with the default file permissions. Here's another simple approach: Keep all ownership as it is. Just add an ACE for the administrators group with rw- access rights to the ACL of files created/unpacked by setup. I like that one too. Maybe even more simple would be to assign that ACE to the cygwin root, in the first install, and let it be inherited throughout all cygwin tree. PS: It really should be rwx, right? ___ Julio Costa
Re: Question: Desired owner/group when running setup-1.7.exe
Corinna Vinschen wrote: Sorry, but this is getting too complicated. I thought I'm asking a simple question. I was just trying to help this along so that the least number of people have trouble with the default file permissions. You're right. Sorry for muddying the waters; that wasn't my intention. Here's another simple approach: Keep all ownership as it is. Just add an ACE for the administrators group with rw- access rights to the ACL of files created/unpacked by setup. Yep, I think that would address most people's concerns. -- Chuck
Re: [ITP][1.7] CLooG-PPL version 0.15
David Billinghurst wrote: CLooG-PPL version 0.15 - http://www.cloog.org/ is needed to build GCC 4.4 with the Graphite loop optimizations http://gcc.gnu.org/install/prerequisites.html. I'd like to provide cloog-ppl-0.15.3 for cygwin-1.7. It requires the Parma Polyhedra Library (PPL), which is already on the way. This also requires a vote. +1 -- Chuck
Re: Question: Desired owner/group when running setup-1.7.exe
On Apr 20 17:38, Julio Costa wrote: On Mon, Apr 20, 2009 at 14:58, Corinna Vinschen wrote: Here's another simple approach: Keep all ownership as it is. Just add an ACE for the administrators group with rw- access rights to the ACL of files created/unpacked by setup. I like that one too. Maybe even more simple would be to assign that ACE to the cygwin root, in the first install, and let it be inherited throughout all cygwin tree. No, we don't inherit. The idea is to use POSIX semantics in the first place, not Windows semantics. PS: It really should be rwx, right? Not really. The execute permssion would be determined by group and other permissions. Oh well, the longer I think about it, the less necessary this all gets in my mind. Given the way Cygwin opens files, all administrative users will have read/write permissions on all files anyway, just like your average root account. There should be not the faintest reason to add explicit permissions for administrative users. The longer I think about this the more sense makes solution 2: If the current user is an administrative user, make Administrators the group of the files: owner: Current user. group: Administrators. This reflects default POSIX permissions on the non-user files in a Cygwin installation most closely. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Question: Desired owner/group when running setup-1.7.exe
On Apr 20 13:03, Charles Wilson wrote: Corinna Vinschen wrote: Sorry, but this is getting too complicated. I thought I'm asking a simple question. I was just trying to help this along so that the least number of people have trouble with the default file permissions. You're right. Sorry for muddying the waters; that wasn't my intention. No worries. Here's another simple approach: Keep all ownership as it is. Just add an ACE for the administrators group with rw- access rights to the ACL of files created/unpacked by setup. Yep, I think that would address most people's concerns. I just re-thought the problem and came to a different idea. The whole problem seems tyo boil down to other administrators not bein able to manipulate Cygwin files in, say, /bin or /usr. But that's not really a problem since all Admin users have the right to manipulate all files, same as the root user on POSIX systems. There's actually no reason to add an ACE for administrators. However, given that all users are in the group None, using this group for the default group ownership for files is rather insecure. On a POSIX system the files in the system directories are owned by a group which only sys admins are member of. In our case, that would be most closely resembled by the Admins group. So, actually I'm now rather leaning towards solution two. Sorry for the to and fro :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Question: Desired owner/group when running setup-1.7.exe
Corinna Vinschen wrote: However, given that all users are in the group None, using this group for the default group ownership for files is rather insecure. On a POSIX system the files in the system directories are owned by a group which only sys admins are member of. In our case, that would be most closely resembled by the Admins group. So, actually I'm now rather leaning towards solution two. Well, *I* am fine with the current behavior, and am okay with running a shell as local admin whenever I need to manipulate those files. None of the proposed solutions break my usage patterns. So I really have no dog in this hunt. If solution 2 solves the problem that spawned this thread, and doesn't cause any significant foreseeable additional problems... Sorry for the to and fro :} g -- Chuck
Re: [ITP][1.7] CLooG-PPL version 0.15
Charles Wilson schrieb: David Billinghurst wrote: CLooG-PPL version 0.15 - http://www.cloog.org/ is needed to build GCC 4.4 with the Graphite loop optimizations http://gcc.gnu.org/install/prerequisites.html. I'd like to provide cloog-ppl-0.15.3 for cygwin-1.7. It requires the Parma Polyhedra Library (PPL), which is already on the way. This also requires a vote. +1 -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: Question: Desired owner/group when running setup-1.7.exe
On Mon, Apr 20, 2009 at 18:30, Corinna Vinschen wrote: I just re-thought the problem and came to a different idea. The whole problem seems tyo boil down to other administrators not bein able to manipulate Cygwin files in, say, /bin or /usr. But that's not really a problem since all Admin users have the right to manipulate all files, same as the root user on POSIX systems. There's actually no reason to add an ACE for administrators. You know, I thought that when I saw the ACE proposal... but then I decided it would be better to send you a telepathic message rather than an email g However, given that all users are in the group None, using this group for the default group ownership for files is rather insecure. On a POSIX system the files in the system directories are owned by a group which only sys admins are member of. In our case, that would be most closely resembled by the Admins group. So, actually I'm now rather leaning towards solution two. As long as it isn't the do-nothing solution, I'm already happy :) And thinking more on the subject, it seems that it is really for the better, because with the solution number 2, there is a coherence between what you see (group ownership) and what you get (root-admin-like permissions). BUT, may I make one last wish? I think that if this is important enough to change in setup.exe, I think it is equally important to maintain after installation, by implementing the same algorith in (at least) mkpasswd to avoid incoherence. The change (if solution 2) is in the algorithm for determining gid - instead of blindly take the primary group, add some tests for admins and act accordingly; this same algorithm should be in mkpasswd, so that all would be transparent and coherent after the deploy of packages. PS: I know, we can always edit passwd by hand. But this is more a question of why should we, when we already identified that there's a need for change in the gid algorithm? Sorry for the to and fro :} Sorry for being sticky - but I still believe these kind of changes are for the best on Cygwin's interoperability. -- ___ Julio Costa
Re: [ITP][1.7] CLooG-PPL version 0.15
David Billinghurst wrote: I'd like to provide cloog-ppl-0.15.3 for cygwin-1.7. It requires the Parma Polyhedra Library (PPL), which is already on the way. This also requires a vote. +1
src/winsup/cygwin ChangeLog flock.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-04-20 17:13:20 Modified files: winsup/cygwin : ChangeLog flock.cc Log message: * flock.cc (lf_setlock): Handle border case which results in WFMO loop exiting with ret == WAIT_TIMEOUT gracefully. Add a system_printf to uncover other potential problems with WFMO loop. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4468r2=1.4469 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/flock.cc.diff?cvsroot=srcr1=1.20r2=1.21
BFD 2.17.50 20061004 assertion fail
Hy guys, when iam try to compile ffmpeg for wince with cegcc under cygwin i get this error: ove_extradata_bsf.o libavcodec/armv4l/dsputil_arm.o libavcodec/armv4l/mpegvideo_ arm.o libavcodec/armv4l/jrevdct_arm.o libavcodec/armv4l/simple_idct_arm.o libavc odec/armv4l/dsputil_arm_s.o libavutil/libavutil.so -lavutil -lm 7 [main] ld 5096 _cygtls::handle_exceptions: Error while dumping state (pr obably corrupted stack) collect2: ld terminated with signal 11 [Segmentation fault], core dumped libavutil/libavutil.so: In function `DllMainCRTStartup': /cygdrive/e/pedro/cegcc/0.50/src/mingw/dllcrt1.c:60: multiple definition of `Dll MainCRTStartup' /opt/mingw32ce/lib/gcc/arm-wince-mingw32ce/4.1.0/../../../../arm-wince-mingw32ce /lib/dllcrt3.o:/cygdrive/e/pedro/cegcc/0.50/src/mingw/dllcrt1.c:60: first define d here /opt/mingw32ce/lib/gcc/arm-wince-mingw32ce/4.1.0/../../../../arm-wince-mingw32ce /bin/ld: BFD 2.17.50 20061004 assertion fail /cygdrive/e/pedro/cegcc/0.50/src/bi nutils/bfd/coff-arm.c:2040 make: *** [libavcodec/libavcodec.so.51] Error 1 What iam doing wrong? Is this a bug in ffmpeg, cygwin, cegcc or ld??? Greatz mccoffein -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: bash-completion-1.0-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Yaakov (Cygwin/X) on 4/18/2009 9:10 PM: As cygport is Cygwin-specific, I think shipping it with cygport makes more sense. If I just grab the file from the previous release, will any changes be necessary for the current version? Not that I can see. I just tried the older /etc/bash_completion.d/cygport with the newer bash_completion, and it still worked. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknsYosACgkQ84KuGfSFAYCSugCeOwtR0E00wPThh2LCBP3jCSft ZIIAn1X/4mUXKdAmj/9kAM15XEZ21avY =l5S5 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: BFD 2.17.50 20061004 assertion fail
i...@torsten-klinger wrote: when iam try to compile ffmpeg for wince with cegcc under cygwin i get this error: ove_extradata_bsf.o libavcodec/armv4l/dsputil_arm.o libavcodec/armv4l/mpegvideo_ arm.o libavcodec/armv4l/jrevdct_arm.o libavcodec/armv4l/simple_idct_arm.o libavc odec/armv4l/dsputil_arm_s.o libavutil/libavutil.so -lavutil -lm ^^^ This looks incorrect, listing the library both by its full path and as a -l option will cause these multiple definition errors, but I can't guess how the Makefile got that way; is there an ffmpeg group to ask about this? Hmm, I googled for ffpmeg libavutil multiple definitions, and found a link: http://www.mail-archive.com/libav-u...@mplayerhq.hu/msg01661.html that suggests you have to make sure your mingw runtime is up-to-date, and (other post in same thread) that you might want to try adding --enable-shared to your configure line. Beyond that, I dunno, you'll have to take it up on a suitable ffpmeg mailing list. 7 [main] ld 5096 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) collect2: ld terminated with signal 11 [Segmentation fault], core dumped libavutil/libavutil.so: In function `DllMainCRTStartup': /cygdrive/e/pedro/cegcc/0.50/src/mingw/dllcrt1.c:60: multiple definition of `Dll MainCRTStartup' /opt/mingw32ce/lib/gcc/arm-wince-mingw32ce/4.1.0/../../../../arm-wince-mingw32ce /lib/dllcrt3.o:/cygdrive/e/pedro/cegcc/0.50/src/mingw/dllcrt1.c:60: first defined here /opt/mingw32ce/lib/gcc/arm-wince-mingw32ce/4.1.0/../../../../arm-wince-mingw32ce /bin/ld: BFD 2.17.50 20061004 assertion fail /cygdrive/e/pedro/cegcc/0.50/src/binutils/bfd/coff-arm.c:2040 What iam doing wrong? Is this a bug in ffmpeg, cygwin, cegcc or ld??? Well, it's definitely a bug that LD crashed, even if presented with bad data, and you should report that to the cegcc people. On the other hand, I'm confused by this: /bin/ld: BFD 2.17.50 20061004 assertion fail That. worries me. Either the path /bin/ld is just displayed wrong, or you've somehow overwritten your system native ld with the cegcc version? When you run /bin/ld --version at the command line, do you get 2.17.50? cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] perl5 changes: split debug, peflags, ...
For the forthcoming perl5 update for 1.7 I'm testing this:
1. compilation with gcc4.3 against shared libgcc_s
2. I'm testing to split the debug sections into the /usr/lib/debug path,
with a seperate perl_debug package.
Yaakov, did you already envisioned that for cygport?
I use this function in my build script (dir = topdir)
strip_debug() {
echo ## seperate debug symbols into extra /usr/lib/debug/path/file.dbg
find -type f -name \*.exe $dir/strip.lst
find -type f -name \*.dll $dir/strip.lst
strippath=/usr/lib/debug
for f in $(cat $dir/strip.lst); do
d=$(dirname $f)
s=$(basename $f .exe)
s=$(basename $s .dll)
mkdir -p ${dir}/inst${strippath}/$d
objcopy --only-keep-debug $f ${dir}/inst${strippath}/$d/$s.dbg
objcopy --strip-debug $f
objcopy --add-gnu-debuglink=${strippath}/$d/$s.dbg $f
done
true
}
If not, I think that would be a worthwhile addition to automatically
create a ${PN}-debug package,
unless NO_DEBUGPKG or such. I don't know the ebuild conventions for this.
Or just define a ADD_DEBUGPKG=1
3. I changed the perl archname from i686-cygwin to i686-cygwin-1.7
for easier coexistance, and getting cleaner bugreports. There's no
perl version bump,
just gcc4 (with the new libgcc_s dep) and cygwin-1.7.
For cygwin-1.7 I added utf-8 - wchar pathname conversions, but just for
Cygwin::win_to_posix_path and Cygwin::posix_to _win_to_path, not yet
for the full IO API.
wchar support for the full IO API is a major task, and not yet
envisioned even for win32.
Say I wanted ActivePerl to step ahead :)
4. I added some new modules to vendor_perl:
ActivePerl ships CPAN::Inject, so I added it also with the following
dependencies:
Text::Glob Number::Compare File::Find::Rule Data::Compare
CPAN::Checksums File::Remove File::chmod
Params::Util Test::Script CPAN::Checksums CPAN::Inject
IO::Compress::Bzip2 is also new.
Most other vendor modules are updates to its latest CPAN version.
5. the need to rebase might get better from vista onwards, as I use now
rebase_all() {
echo ## set proper peflags, no rebasing
echo ./perl.exe $dir/rebase.lst
find -type f -name \*.exe | grep -v perl.exe $dir/rebase.lst
peflags -t1 -T $dir/rebase.lst
find -type f -name \*.dll $dir/rebase.lst
peflags -d1 -T $dir/rebase.lst
true
}
and -Wl,--enable-auto-image-base.
But a better rebasebase address for Vista would also help. I have no
Vista to test.
Currently I'm using 0x5200 upwards, but it looks like there's a
conflict with some vista dll sitting there.
6. the change for the linker step in all makefiles from CC to LD not yet.
We will need that for llvm but I leave that to a new update, need to
check it upstream and my llvm tests first.
Note that perl uses LD=g++ or LD=gcc and not LD=ld. And the main
makefile even ignores LD at all and
uses CC in a lot of places. This forbids the use of llvm, with a speed
advantage of 5-20% due to link optimizations.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[1.7] Backslash incorrectly triggers DOS style path warning
I just installed the bash-completion package. To see how it worked, I typed
$ ssh TAB
This yielded:
$ ssh cygwin warning:
MS-DOS style path detected: BEGIN {FS=,}
/^\s*[^|\#]/ {for (i=1; i=2; ++i) { \
gsub( .*$, , $i); \
if ($i ~ /
Preferred POSIX equivalent is: BEGIN {FS=,}
/^/s*[^|/#]/ {for (i=1; i=2; ++i) { /
gsub( .*$, , $i); /
if ($i ~ /
CYGWIN environment variable option nodosfilewarning turns off this
warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Apparently a line continuation backslash in /etc/bash_completion was
misinterpreted as an attempt to use DOS style paths.
Ken
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [1.7] Backslash incorrectly triggers DOS style path warning
On 4/20/2009 9:29 AM, Ken Brown wrote:
I just installed the bash-completion package. To see how it worked, I
typed
$ ssh TAB
This yielded:
$ ssh cygwin warning:
MS-DOS style path detected: BEGIN {FS=,}
/^\s*[^|\#]/ {for (i=1; i=2; ++i) { \
gsub( .*$, , $i); \
if ($i ~ /
Preferred POSIX equivalent is: BEGIN {FS=,}
/^/s*[^|/#]/ {for (i=1; i=2; ++i) { /
gsub( .*$, , $i); /
if ($i ~ /
CYGWIN environment variable option nodosfilewarning turns off this
warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Apparently a line continuation backslash in /etc/bash_completion was
misinterpreted as an attempt to use DOS style paths.
Sorry, it might not have been the line continuation backslash. There
are earlier backslashes in the line.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [1.7] Updated: OpenSSH-5.2p1-2
I've just updated the Cygwin 1.7 version of OpenSSH to 5.2p1-2. This is a minor update to allow a more sophisticated selection of the user running the sshd service. For that reason, a new option has been added to the ssh-host-config script: -u SERVICE-USER-ACCOUNT This allows to overwrite the default behaviour of the script in choosing the service account, and, in conjunction with the -y or -n options, a fully automatic installation without enforced user interaction. Note that this release relies on the latest csih package release 0.1.9-2. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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=3d3dyourdomain@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. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] {gmp/libgmp3/libgmpxx4/libgmp-devel}-4.3.0-1 for cygwin-1.7
Version 4.3.0-1 of gmp, libgmp3, libgmpxx4 and libgmp-devel have been uploaded. This release for cygwin-1.7 is the first compiled with gcc-4 and g++-4 PACKAGE DESCRIPTION === Homepage: http://gmplib.org/ License : GNU LGPL GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. There is no practical limit to the precision except the ones implied by the available memory in the machine GMP runs on. GMP has a rich set of functions, and the functions have a regular interface. CHANGES SINCE LAST RELEASE == The DLL for the C++ binding has been bumped from cyggmpxx-3.dll to cyggmpxx-4.dll, due to the change from g++-3 to g++-4. INSTALL OR UPGRADE NOTES Standard install. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] mpfr-2.4.1-3 for cygwin-1.7
Version 2.4.1-3 of mpfr/libmpfr1/libmpfr-devel for cygwin-1.7 has been uploaded. The is a rebuild using gcc-4 against gmp-4.3.0. The DLL is binary compatible with previous releases. PACKAGE DESCRIPTION === Homepage: http://www.mpfr.org License : GNU LGPL 2.1 or later The MPFR library is a C library for multiple-precision floating-point computations with exact rounding (also called correct rounding). It is based on the GMP multiple-precision library. The main goal of MPFR is to provide a library for multiple-precision floating-point computation which is both efficient and has a well-defined semantics. It copies the good ideas from the ANSI/IEEE-754 standard for double-precision floating-point arithmetic. CHANGES SINCE LAST RELEASE == Minor upstream bug fixes. http://www.mpfr.org/mpfr-current/#changes INSTALL OR UPGRADE NOTES Standard install. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
User account problem
Hi, I need to use a different named user account on Cygwin, ie one without a space. I am using Vista and Cygwin. I have an account created by default called 'Aaron Gray', what I need is an account called 'ang'. How can I go about changing my default account to be 'ang', if this is possible at all ? Many thanks in advance, Aaron -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] flock change breaks autotools 'make -j2'
Corinna Vinschen corinna-cygwin at cygwin.com writes: I'd prefer a testcase in C. So would I. I'm not even sure whether perl was using flock or lockf/fcntl. Do you still need me to try and write a STC, or at least test how perl behaves with your first patch? I checked in a patch which hopefully solves both problems. The lock.pl testcase now works, at least. Can you test if the original scenario works now as well? If not, I'd really need another testcase. Nope; with snapshot 20090418 I'm still seeing the 'make -j2' failures. I'll see if I can come up with a C program that can be run as two processes to simulate the failure as a simpler test case. I did verify via strace that perl is using flock(fd, LOCK_EX). -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: User account problem
On Apr 20 15:32, Aaron Gray wrote: Hi, I need to use a different named user account on Cygwin, ie one without a space. I am using Vista and Cygwin. I have an account created by default called 'Aaron Gray', what I need is an account called 'ang'. How can I go about changing my default account to be 'ang', if this is possible at all ? Just change your user name in /etc/passwd to ang(*). Corinna (*) http://cygwin.com/1.7/cygwin-ug-net/ntsec.html#ntsec-files -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: bash-completion-1.0-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric Blake wrote: Not that I can see. I just tried the older /etc/bash_completion.d/cygport with the newer bash_completion, and it still worked. Thanks; committed r6446. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAknslLYACgkQpiWmPGlmQSPxmgCdG6WnWUsutvuWMgpNb17zbQyy JMAAoKL/MhWhZ+Ds3JOYnQoqZHrz/evZ =y1R8 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: User account problem
On Apr 20 15:32, Aaron Gray wrote: Hi, I need to use a different named user account on Cygwin, ie one without a space. I am using Vista and Cygwin. I have an account created by default called 'Aaron Gray', what I need is an account called 'ang'. How can I go about changing my default account to be 'ang', if this is possible at all ? Just change your user name in /etc/passwd to ang(*). Many thanks Corinna, Aaron (*) http://cygwin.com/1.7/cygwin-ug-net/ntsec.html#ntsec-files -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] flock change breaks autotools 'make -j2'
On Apr 20 15:14, Eric Blake wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
I'd prefer a testcase in C.
So would I. I'm not even sure whether perl was using flock or
lockf/fcntl. Do you still need me to try and write a STC, or at least
test how perl behaves with your first patch?
I checked in a patch which hopefully solves both problems. The lock.pl
testcase now works, at least. Can you test if the original scenario
works now as well? If not, I'd really need another testcase.
Nope; with snapshot 20090418 I'm still seeing the 'make -j2' failures. I'll
Too bad.
see if I can come up with a C program that can be run as two processes to
simulate the failure as a simpler test case. I did verify via strace that
perl
is using flock(fd, LOCK_EX).
Yes, I saw this already while debugging the lock.pl testcase.
Whatever it is, it must be more complicated than this:
#include stdio.h
#include sys/file.h
int
main ()
{
int fd = open (flock.c, O_RDWR);
if (fd = 0)
{
printf (About to call flock\n);
if (!flock (fd, LOCK_EX))
{
printf (flock succeeded. Waiting...\n);
getchar ();
close (fd);
}
else
perror (flock);
}
return 0;
}
Because this testcase works fine. I hope it's not trying to do this:
parent opens file
fork
child calls flock()
exit
fork
second child relies on the lock.
because this is exactly the scenario which doesn't work with flock
right now. I have it on my TODO list, but so far I'm at a loss as
to how to implement it.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [1.7] flock change breaks autotools 'make -j2'
On Apr 20 17:34, Corinna Vinschen wrote: On Apr 20 15:14, Eric Blake wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: I'd prefer a testcase in C. So would I. I'm not even sure whether perl was using flock or lockf/fcntl. Do you still need me to try and write a STC, or at least test how perl behaves with your first patch? I checked in a patch which hopefully solves both problems. The lock.pl testcase now works, at least. Can you test if the original scenario works now as well? If not, I'd really need another testcase. Nope; with snapshot 20090418 I'm still seeing the 'make -j2' failures. I'll Too bad. I just checked in another fix. My central blocking WaitForMultipleObject expression had a definition hole big as a barn door. I could trigger it easily with a slightly tweaked testcase as sent in my previous reply. Before you're going to write your own testcase, it might be worth to give the latest from CVS another try with your automake scenario. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] flock change breaks autotools 'make -j2'
Corinna Vinschen corinna-cygwin at cygwin.com writes: Because this testcase works fine. I hope it's not trying to do this: parent opens file fork child calls flock() exit fork second child relies on the lock. because this is exactly the scenario which doesn't work with flock right now. I have it on my TODO list, but so far I'm at a loss as to how to implement it. As far as I can tell, the original case doesn't look like that. From the strace I ran, flock was only called on the fd obtained several lines earlier by the same perl process, and I don't see any child processes trying to perform flock manipulations on the fd inherited from the parent. But I'm still trying to figure out what is different between the 'make -j2' case and my simpler C program (which I wrote before I saw this mail, but which looked awfully similar to yours). I did notice that flock only seems to protect processes spawned in the same cygwin process hierarchy - using strace to spawn my test program created a new hierarchy, and thus did not see the lock held by the old hierarchy. That does not affect the original testcase, where all processes involved are in the same hierarchy. And I guess it makes sense - since we aren't modifying the inodes of the actual file system, the cygwin notion of an inode (where BSD flock locking takes place) is necessarily limited to the shared memory among a cygwin process hierarchy, and we shouldn't have to worry about independent process hierarchies. But it does mean that it is harder to debug the issue, because it is no longer a simple matter of using strace or gdb to run the test app, but instead requires process attachment to keep the test programs within the same process hierarchy. Maybe we should teach strace to output when an flock release occurs due to closing the last handle to a file, to see if that sheds any more insight. Perhaps also an strace line just before a process blocks because it detects that some other process already holds a lock; if nothing else, so that we can see how long the flock call blocks? -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] flock change breaks autotools 'make -j2'
On Apr 20 17:45, Eric Blake wrote: I did notice that flock only seems to protect processes spawned in the same cygwin process hierarchy - using strace to spawn my test program created a new hierarchy, and thus did not see the lock held by the old hierarchy. That does not affect the original testcase, where all processes involved are in the same hierarchy. And I guess it makes sense Sorry, but I don't understand what you mean. The flock code neither uses shared memory, nor is it restricted to a user session. Rather, it uses mutexes and event objects in the global NT namespace for synchronizing. Every file for which one of the lock functions is called gets its own directory in the global NT namespace, based on the inode number. When I implemented the advisory locking code I also tested locking the same file from within different user sessions and it worked (apart from the bugs we found testing 1.7 so far). - since we aren't modifying the inodes of the actual file system, the cygwin notion of an inode (where BSD flock locking takes place) is necessarily limited to the shared memory among a cygwin process hierarchy, and we shouldn't have to worry about independent process hierarchies. Cygwin's global shared memory is not restricted to a user session anymore starting with 1.7, due to the way it's using the global NT namespace. process hierarchies. But it does mean that it is harder to debug the issue, because it is no longer a simple matter of using strace or gdb to run the test app, but instead requires process attachment to keep the test programs within the same process hierarchy. Again, I don't understand the actual problem you're referring to. The process hierarchy shouldn't matter at all... ...uhm... ...unless you're talking about actual BSD flock(2) semantics and how flock locks are bound to the file descriptor, rather than to the process. I guess I start to understand your problem. Sure, the flock lock is inherited to the child process but starting a Cygwin child process via a debugger breaks inheriting the data attached to the descriptor. Thus also the fact that this is a descriptor with an active flock lock is forgotten in GDB's child process. Yeah, nothing I can do about that. Attaching to the running process is necessary to debug this. Maybe we should teach strace to output when an flock release occurs due to closing the last handle to a file, to see if that sheds any more insight. Perhaps also an strace line just before a process blocks because it detects that some other process already holds a lock; if nothing else, so that we can see how long the flock call blocks? Since you're building your own Cygwin anyway, feel free to add that code yourself. The actual wait occurs in flock.cc, function lf_setlock, lines 941ff. Core of the unlocking code is the method lockf_t::del_lock_obj flock.cc lines 583ff. Closing a descriptor (close, close-on-exec) trigger a call to fhandler_base::del_my_locks, flock.cc lines 346ff. Apart from that, I tried to document the code in flock.cc excessivly because this synchronization stuff is usually tricky enough to forget even your own code after a while... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7: snprintf() with gcc -std=c99: warning about implicit declaration
On Mon, 20 Apr 2009, Dave Korn wrote: I wonder how many other functions would need the same treatment, do you happen to have an idea? vsnprintf, vscanf, vsscanf and vfscanf have similar situation. Markus Rinne -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: DOS programs under screen
James Calfee jcal...@xxx.xxx wrote on 04/20/2009 02:02:33 PM: Hi Andrew. I have change request for screen.exe under cygwin. I did not get any response from the cygwin mailing list. I guess the request is a bit too specific. Do you know where I might direct the request? In case your wondering, we are running a server program that has a DOS interface. It does not work under screen. This program is very similar to the DOS edit program which also does NOT work under screen. So, my question would be, what is required to fix screen so it will work with the DOS edit program? Thanks for your help, Jimmy Jimmy, I saw the thread on the cygwin list. I didn't answer there because I didn't have anything to add. In fact, you did get a response there from Matt Wozniski, who I thought covered it as well as I could: In general, non-cygwin programs can't be run reliably inside of an application that uses cygwin PTYs, including xterm, rxvt, and screen. Maybe someone knows a solution to this, but I don't. Although I maintain screen for Cygwin, I know almost nothing of the details of how terminals work. I could imagine some kind of a DOS-to-Unix terminal wrapper program, but I've never seen one and have no idea how it would work. Please note that http://cygwin.com/problems.html asks you not to send problem reports to maintainers' personal email addresses. Such reports should go to the Cygwin list, so that everyone can contribute to and benefit from the discussion. If you want to call someone's attention to a thread, you can append e.g. [ping Andrew Schulman] to the subject. But at least in my case, it's not necessary: I have my news client set to automatically flag anything that has screen in the subject. Sorry I couldn't help. Good luck, Andrew. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: DOS programs under screen
On Mon, Apr 20, 2009 at 03:56:16PM -0400, Andrew Schulman wrote: James Calfee jcal...@xxx.xxx wrote on 04/20/2009 02:02:33 PM: Hi Andrew. I have change request for screen.exe under cygwin. I did not get any response from the cygwin mailing list. I guess the request is a bit too specific. Do you know where I might direct the request? In case your wondering, we are running a server program that has a DOS interface. It does not work under screen. This program is very similar to the DOS edit program which also does NOT work under screen. So, my question would be, what is required to fix screen so it will work with the DOS edit program? Thanks for your help, Jimmy Jimmy, I saw the thread on the cygwin list. I didn't answer there because I didn't have anything to add. In fact, you did get a response there from Matt Wozniski, who I thought covered it as well as I could: In general, non-cygwin programs can't be run reliably inside of an application that uses cygwin PTYs, including xterm, rxvt, and screen. Maybe someone knows a solution to this, but I don't. Although I maintain screen for Cygwin, I know almost nothing of the details of how terminals work. I could imagine some kind of a DOS-to-Unix terminal wrapper program, but I've never seen one and have no idea how it would work. ...and if one was possible why wouldn't the techniques that it incorporates be part of cygwin? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Backslash incorrectly triggers DOS style path warning
On Mon, Apr 20, 2009 at 09:37:01AM -0400, Ken Brown wrote:
On 4/20/2009 9:29 AM, Ken Brown wrote:
I just installed the bash-completion package. To see how it worked, I
typed
$ ssh TAB
This yielded:
$ ssh cygwin warning:
MS-DOS style path detected: BEGIN {FS=,}
/^\s*[^|\#]/ {for (i=1; i=2; ++i) { \
gsub( .*$, , $i); \
if ($i ~ /
Preferred POSIX equivalent is: BEGIN {FS=,}
/^/s*[^|/#]/ {for (i=1; i=2; ++i) { /
gsub( .*$, , $i); /
if ($i ~ /
CYGWIN environment variable option nodosfilewarning turns off this
warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Apparently a line continuation backslash in /etc/bash_completion was
misinterpreted as an attempt to use DOS style paths.
Sorry, it might not have been the line continuation backslash. There are
earlier backslashes in the line.
It isn't really erroneous. Something (awk) is trying to open a filename
with that includes backslashes, so cygwin1.dll thinks that it is trying
to open a DOS path.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Error opening terminal
Sorry, I guess I mean to point out that when I download the binaries of programs that use ncurses from the setup.exe program, I get the error Error opening terminal: cygwin. Programs for example that I get this for. $ cygcheck -c ctris lynx ninvaders Cygwin Package Information Package VersionStatus ctris0.42-1 OK lynx 2.8.5-4OK ncurses 5.7-5 OK ninvaders0.1.1-1OK terminfo 5.7_20090228-1 OK When I use the cygwin terminal I get the error (TERM=cygwin) but when I use like rxvt (TERM=xterm) then it works. Also, if I compile the sources myself then the programs work in the cygwin terminal. Does it have something to do with TERMINFO? Thanks, Colin - Original Message From: Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com To: cygwin@cygwin.com Sent: Saturday, April 18, 2009 10:24:04 PM Subject: Re: Error opening terminal On Sat, Apr 18, 2009 at 01:49:28PM -0700, Colin Diesh wrote: Sorry -- I used the setup.exe cygwin program to download the packages and their distributions of it don't work. I actually just downloaded and compiled ctris and ninvaders myself and they work fine (not as awesome as I wanted but heh whatever :) I am curious why the binary I got from the setup.exe would give me this error message in the first place then? That would, again, fall into the category of your not supplying enough information. See: -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problems Installing Cygwin on Win XP Pro
I finally carved out some time to install CygWin on my Win XP machine via the RedHat Cygwin official installation facility. I downloaded rhsetup.exe to start. I requested install via the internet, and it died somewhere along the line. I then tried again, requesting download instead. I now have about 120 folders in my download folder for cygwin. I don't see any indication it installed. I was expecting some (exe) install program somewhere. Maybe it installed. However, I see no trace of anything on the Win Start-All Prog menu of its existence, nor do I see an icon on my desktop. Looking at the folder where the download took place, I see a top level folder called ...\ftp%3a%2f%2fftp.ges.redhat.com%2fprivate%2freleng%2fcygwin-latest There are two files: setup.log and setup.log.full The last lines in setup.log are: 2009/04/18 23:54:35 note: Download Complete 2009/04/18 23:54:35 Ending cygwin install The last lines in ...log.full are: 2009/04/18 23:54:35 note: Download Complete 2009/04/18 23:54:35 Ending cygwin instal Below folder ftp%... is the release folder. In it is setup.ini. Below release are some 100+ folders. The first is called alternatives. Others are gcc, db, cvs, bash, ... Comments? -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet All the neutrons, and protons in the human body occupy a cube whose side is 5.52*10**-6 meters (tiny!). That adds up to a 150 pound person. It's not a surprise that we are mostly space. (Calculation by WTW) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems Installing Cygwin on Win XP Pro
On Mon, Apr 20, 2009 at 08:06:57PM -0700, Wayne Watson wrote: I finally carved out some time to install CygWin on my Win XP machine via the RedHat Cygwin official installation facility. I downloaded rhsetup.exe to start. Sorry but you don't get support for Red Hat's version of Cygwin here. We *do* support the Cygwin distribution that you get by downloading from http://cygwin.com/setup.exe. You should contact one of the places mentioned at the Red Hat site for support for Red Hat's version of Cygwin. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: login-1.10-1
login is a utility that authenticates signing on to a system. It is used by ftpd, telnetd, rshd, and various other servers. This is a routine update. [[ compiled using gcc-3.4.4-999 ]] This will most likely be the final login update for the cygwin-1.5 distribution; future development will continue with login-1.10-10 for cygwin-1.7. CHANGES (from login-1.9-8) === o Some build system modifications o Added to cygwin-apps repository on sourceware; bumped version number to 1.10 and incorporated all earlier src patches from 1.9-8. o No code changes (other than using GNU indent). Charles Wilson volunteer login maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: ssmtp-2.62-2
ssmtp is an extremely simple sendmail replacement, which forwards messages to a mailhub (e.g., your ISP's outgoing mail server), and does nothing else. This is a bugfix release, and an update to the latest debian source and patchlevel (2.62-3, 2009-01-31). This release is compiled with SSL/TLS support, provided by openssl. Use the included ssmtp-config script to configure the service; see /usr/share/doc/Cygwin/ssmtp-2.62.README and 'man ssmtp.conf' for more information. Note that the ssmtp-config script will /not/ automatically configure SSL/TLS support -- you must do that manually. [[ compiled using gcc-3.4.4-999 ]] This will most likely be the final ssmtp update for the cygwin-1.5 distribution; future development will continue with ssmtp-2.62-10 for cygwin-1.7. CHANGES (from ssmtp-2.62-1) === o updated to latest debian patchset (Debian pkg 2.62-3) - fixes CVE-2008-3962 (which we had already fixed in cygwin release 2.62-1 thanks to Pierre A. Humblett). - fixes Debian bug #345780 o rebuild against latest openssl -- Charles Wilson volunteer ssmtp maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [1.7] Updated: ssmtp-2.62-10
ssmtp is an extremely simple sendmail replacement, which forwards messages to a mailhub (e.g., your ISP's outgoing mail server), and does nothing else. This is a bugfix release, and an update to the latest debian source and patchlevel (2.62-3, 2009-01-31). This release is compiled with SSL/TLS support, provided by openssl. Use the included ssmtp-config script to configure the service; see /usr/share/doc/Cygwin/ssmtp.README and 'man ssmtp.conf' for more information. Note that the ssmtp-config script will /not/ automatically configure SSL/TLS support -- you must do that manually. [[ compiled using gcc-3.4.4-999 ]] This is the first release specific for cygwin-1.7; the only differences between this package and the simultaneously-released ssmtp-2.62-2 for cygwin-1.5 are documentation related (the README references cygport-0.9.5 and cygwin-1.7.0-45, and the /usr/share/doc/ layout is influenced by the cygport changes between 0.4.x and 0.9.x). CHANGES (from ssmtp-2.62-1) === o Fork for cygwin-1.7 development o updated to latest debian patchset (Debian pkg 2.62-3) - fixes CVE-2008-3962 (which we had already fixed in cygwin release 2.62-1 thanks to Pierre A. Humblett). - fixes Debian bug #345780 o rebuild against latest openssl -- Charles Wilson volunteer ssmtp maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [1.7] Updated: login-1.10-10
login is a utility that authenticates signing on to a system. It is used by ftpd, telnetd, rshd, and various other servers. This is a routine update. [[ compiled using gcc-3.4.4-999 ]] This is the first release specific for cygwin-1.7; the only differences between this package and the simultaneously-released login-1.10-1 for cygwin-1.5 are documentation related (the README references cygport-0.9.5 and cygwin-1.7.0-45, and the /usr/share/doc/ layout is influenced by the cygport changes between 0.4.x and 0.9.x). CHANGES (from login-1.9-8) === o Fork for cygwin-1.7 development o Some build system modifications o Added to cygwin-apps repository on sourceware; bumped version number to 1.10 and incorporated all earlier src patches from 1.9-8. o No code changes (other than using GNU indent). Charles Wilson volunteer login maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] Updated: OpenSSH-5.2p1-2
I've just updated the Cygwin 1.7 version of OpenSSH to 5.2p1-2. This is a minor update to allow a more sophisticated selection of the user running the sshd service. For that reason, a new option has been added to the ssh-host-config script: -u SERVICE-USER-ACCOUNT This allows to overwrite the default behaviour of the script in choosing the service account, and, in conjunction with the -y or -n options, a fully automatic installation without enforced user interaction. Note that this release relies on the latest csih package release 0.1.9-2. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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=3d3dyourdomain@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. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
{gmp/libgmp3/libgmpxx4/libgmp-devel}-4.3.0-1 for cygwin-1.7
Version 4.3.0-1 of gmp, libgmp3, libgmpxx4 and libgmp-devel have been uploaded. This release for cygwin-1.7 is the first compiled with gcc-4 and g++-4 PACKAGE DESCRIPTION === Homepage: http://gmplib.org/ License : GNU LGPL GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. There is no practical limit to the precision except the ones implied by the available memory in the machine GMP runs on. GMP has a rich set of functions, and the functions have a regular interface. CHANGES SINCE LAST RELEASE == The DLL for the C++ binding has been bumped from cyggmpxx-3.dll to cyggmpxx-4.dll, due to the change from g++-3 to g++-4. INSTALL OR UPGRADE NOTES Standard install.
[1.7] Updated: ssmtp-2.62-10
ssmtp is an extremely simple sendmail replacement, which forwards messages to a mailhub (e.g., your ISP's outgoing mail server), and does nothing else. This is a bugfix release, and an update to the latest debian source and patchlevel (2.62-3, 2009-01-31). This release is compiled with SSL/TLS support, provided by openssl. Use the included ssmtp-config script to configure the service; see /usr/share/doc/Cygwin/ssmtp.README and 'man ssmtp.conf' for more information. Note that the ssmtp-config script will /not/ automatically configure SSL/TLS support -- you must do that manually. [[ compiled using gcc-3.4.4-999 ]] This is the first release specific for cygwin-1.7; the only differences between this package and the simultaneously-released ssmtp-2.62-2 for cygwin-1.5 are documentation related (the README references cygport-0.9.5 and cygwin-1.7.0-45, and the /usr/share/doc/ layout is influenced by the cygport changes between 0.4.x and 0.9.x). CHANGES (from ssmtp-2.62-1) === o Fork for cygwin-1.7 development o updated to latest debian patchset (Debian pkg 2.62-3) - fixes CVE-2008-3962 (which we had already fixed in cygwin release 2.62-1 thanks to Pierre A. Humblett). - fixes Debian bug #345780 o rebuild against latest openssl -- Charles Wilson volunteer ssmtp maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
[1.7] Updated: login-1.10-10
login is a utility that authenticates signing on to a system. It is used by ftpd, telnetd, rshd, and various other servers. This is a routine update. [[ compiled using gcc-3.4.4-999 ]] This is the first release specific for cygwin-1.7; the only differences between this package and the simultaneously-released login-1.10-1 for cygwin-1.5 are documentation related (the README references cygport-0.9.5 and cygwin-1.7.0-45, and the /usr/share/doc/ layout is influenced by the cygport changes between 0.4.x and 0.9.x). CHANGES (from login-1.9-8) === o Fork for cygwin-1.7 development o Some build system modifications o Added to cygwin-apps repository on sourceware; bumped version number to 1.10 and incorporated all earlier src patches from 1.9-8. o No code changes (other than using GNU indent). Charles Wilson volunteer login maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
