src/winsup/cygwin ChangeLog
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-02-26 13:16:41 Modified files: winsup/cygwin : ChangeLog Log message: Fix typo Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6348r2=1.6349
Re: Testers needed: New passwd/group handling in Cygwin
Sorry, I don't grok this. What has a web application server to do with asking a DC for user info? We have one of these that does a lot of DC lookups because it authenticates all users. It's also in a much faster network, so I can check there what the lookup rate could be reasonably expected to be. Erm... how often are you calling id, usually? I'm currently doing this in the login process to figure out whether the prompt should show root powers. I'll have to figure out something else to do instead. Also, we're in the early stages of testing this change. The idea is not that you just switch, the idea is that we *test* this and I get enough feedback to be able to ease the biggest pains. Understood. Until now I had to generate passwd and group files and I was hoping that the need for doing that would go away (I'd also need to talk to our AD folks so they start populating the correct fields). Other than that, I just had an in-shower inspiration how to speed up `id' specificially. The getgroups(2) call is in the center of this and I could probably speed up the stuiff a lot by opening the LDAP connection in getgroups only once. Thursday? :-) Also, more radically, if we drop the functionality to define another group name for a group, we could drop the requirement to open an LDAP connection to fetch group information to the DC entirely(*). This would only affect domain groups, local groups could still have different names. But I'm already wondering for a couple of days if having a Cygwin group name different from the Windows group name is really necessary at all. I added this years ago for fun, but there's no serious reason I can think of which would require to keep up with this. (*) Assuming the group info is cached in the local LSA, which is pretty likely for the groups of the current user. That would also work for me (I don't think I've ever used that feature consciously). Sigh. Testing in this tempo will take ages. Sorry, but that's not my decision to make in this case. I'll see if I can sneak in something until the end of the week. Regards, Achim. -- 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: Maintainer for git?
2014-02-21 1:18 GMT+01:00 Adam Dinwoodie: - Install git-cvs and the assorted dependencies mentioned in its setup.hint, and verify you can clone the Cygwin CVS repository. I've not managed to do this without hitting errors, but I suspect that's because I'm using the tool incorrectly. I've tried this. I have `git cvsimport` seemingly working on the current Git 1.7.9 build, while my build reports the following SHA1 error: Probably not going to solve this issue (I can't anything about CVS in the changelog), but you noticed that 1.9.0 had been released recently? Regards, Frank -- 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: Testers needed: New passwd/group handling in Cygwin
On Feb 26 06:17, Andrey Repin wrote: Greetings, Corinna Vinschen! Other than that, I just had an in-shower inspiration how to speed up `id' specificially. The getgroups(2) call is in the center of this and I could probably speed up the stuiff a lot by opening the LDAP connection in getgroups only once. Isn't local SAM database augmented with domain entries, when machine is part of the domain? No. The local SAM only ever contains local and well-known accounts. Side-effect: Even the supplementary well-known accounts defined in AD are not resolved by LookupAccountSid(NULL, ...). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpCdNtWQK5ab.pgp Description: PGP signature
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 26 08:09, Achim Gratz wrote: Sorry, I don't grok this. What has a web application server to do with asking a DC for user info? We have one of these that does a lot of DC lookups because it authenticates all users. It's also in a much faster network, so I can check there what the lookup rate could be reasonably expected to be. Erm... how often are you calling id, usually? I'm currently doing this in the login process to figure out whether the prompt should show root powers. I'll have to figure out something else to do instead. No, you don't. I'm actually doing the same. Let's keep up with this and try to make Cygwin faster in the first place. Also, we're in the early stages of testing this change. The idea is not that you just switch, the idea is that we *test* this and I get enough feedback to be able to ease the biggest pains. Understood. Until now I had to generate passwd and group files and I was hoping that the need for doing that would go away (I'd also need to talk to our AD folks so they start populating the correct fields). Yup. Feedback from AD admins is greatly appreciated. Other than that, I just had an in-shower inspiration how to speed up `id' specificially. The getgroups(2) call is in the center of this and I could probably speed up the stuiff a lot by opening the LDAP connection in getgroups only once. Thursday? :-) Hmm, probably. Also, more radically, if we drop the functionality to define another group name for a group, we could drop the requirement to open an LDAP connection to fetch group information to the DC entirely(*). This would only affect domain groups, local groups could still have different names. But I'm already wondering for a couple of days if having a Cygwin group name different from the Windows group name is really necessary at all. I added this years ago for fun, but there's no serious reason I can think of which would require to keep up with this. (*) Assuming the group info is cached in the local LSA, which is pretty likely for the groups of the current user. That would also work for me (I don't think I've ever used that feature consciously). Sigh. Testing in this tempo will take ages. Sorry, but that's not my decision to make in this case. I'll see if I can sneak in something until the end of the week. That would be nice. Especially since your mail was the last straw which keeps me from having to do *shudder* more documentation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpEs5SxcBP_R.pgp Description: PGP signature
Re: Cygwin64 ignoring /etc/passwd shell field?
On Feb 25 18:37, Larry Hall (Cygwin) wrote: On 2/25/2014 6:24 PM, Jim Burwell wrote: On 2/25/2014 13:55, Corinna Vinschen wrote: On Feb 25 13:52, Jim Burwell wrote: Hi, I've noticed after installing an update the Cygwin64 appears to ignore the contents of the shell field in /etc/passwd. I normally run /bin/tcsh as my shell, and changing this field used to result in any new login shells running tcsh. Now it just runs bash regardless. Has something changed? No. Works for me. Do you start `mintty -'? Corinna Interestingly, it works as expected with mintty, but not with xterm, uxterm, uterm. Was going to try rxvt, but noticed it's not in Cygwin64. It also works when I ssh into my cygwin. So appears to be a problem with xterm and related? Yes, and it's a conscious change. See https://sourceware.org/ml/cygwin-xfree/2014-02/msg5.html. Weird, I was pretty sure we already have an /etc/shells file installed by default. Apparently not. So, shan't we add one? /bin/sh /bin/bash /bin/dash /bin/mksh /bin/zsh /usr/bin/sh /usr/bin/bash /usr/bin/dash /usr/bin/mksh /usr/bin/zsh The base-files package would be a good place to be. David? -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxQecCvuPNi.pgp Description: PGP signature
Re: How should I report a critical type of Cygwin bug?
On Feb 26 17:00, Shaddy Baddah wrote: Hi, Risking the wrath that I should just report the bug, I would like to just get some advice on how to go about it. I'm encountering a problem with a rather new Cygwin package/feature that if reproducible, has serious consequence on the hosting Windows platform. My concern is that if I list the steps here, readers will blindly try this (rather easily performed) action and break their computer. Cygwin is a user space DLL. It cannot break the OS, unless you do something really terrible like rm -rf in /cygdrive/c with admin rights, but you can do the same with CMD. And we also don't access or try to write UEFI variables, usually. Hmm, /proc/sys, maybe? Should I just whack on a disclaimer and report it? Yes, please. Please see http://cygwin.com/problems.html. A simple testcase would be cool. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgps12QAfz3_2.pgp Description: PGP signature
Re: Running getent in a certain way grows it in memory in critical way.
Hi, On 2014/02/26 22:28+1100, Shaddy Baddah wrote: I need to recompile -O2 - -O0 as the integer counters were optimised out. Then single-stepping through, run --help succeed. But an attempt to run ./getent --help on this non-optimised build encountered the same problem. I had to hard reset to recover. By this I mean that single-stepping through, ./getent --help ran to completion under gdb. But running same build ./getent --help outside of gdb encountered the reported problem. -- Regards, Shaddy -- 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: Running getent in a certain way grows it in memory in critical way.
On Feb 26 22:28, Shaddy Baddah wrote: I noticed getent on my 64-bit install for the first time today. Excited (as I often type it into a Cygwin window, force of habit, to no avail), I successfully ran; getent hosts www.google.com.au. I then decided to check the usage: getent --help It printed the first bit of blurb (taken from a Debian system, as I'm not about to try this again on Cygwin, but it should be equivalent): $ getent --help Usage: getent [OPTION...] database [key ...] Get entries from administrative database. -i, --no-idn disable IDN encoding -s, --service=CONFIG Service configuration to be used -?, --help Give this help list --usageGive a short usage message -V, --version Print program version At this point, there was no more output. Instead the harddrive started thrashing and Windows stalled almost to a standstill. Every now and then I could get the mouse cursor to move. [...] Not believing what I had seen, I downloaded the code and checked it. I inspected more_help() function, and suspecting the for loop my have runaway, I eyed it over. It looks fine to me. I did notice open_memstream(), and because I'm not familiar with its usage, I didn't give it too much thought. I now think the method of dynamically growing memory allocation may be a culprit. But I get ahead of myself. Hmm, I guess that's my fault. While porting getent, I found that the output of `getent --help' was always missing the stuff which was supposed to be following after the -V,--version: Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Supported databases: ahosts ahostsv4 ahostsv6 group hosts initgroups passwd protocols services For bug reporting instructions, please see: http://cygwin.com/problems.html. In my case it didn't run wild, it just omitted the aforementioned text. After some debugging it turned out that newlib's open_memstream functionality had a bug. It neglected to initialize the variable containing the current number of bytes written to the mem buffer to 0. I fixed this bug in newlib, but obviously it's not yet in the released Cygwin version 1.7.28. It will be in 1.7.29, though. So, for the time being, either refrain from calling `getent --help', or update to the latest Cygwin snapshot from http://cygwin.com/snapshots/, which will not have this problem. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnbqKD4vX0X.pgp Description: PGP signature
Re: Running getent in a certain way grows it in memory in critical way.
Hi Corinna, On 2014/02/26 23:33+1100, Corinna Vinschen wrote: On Feb 26 22:28, Shaddy Baddah wrote: snip/ Not believing what I had seen, I downloaded the code and checked it. I inspected more_help() function, and suspecting the for loop my have runaway, I eyed it over. It looks fine to me. I did notice open_memstream(), and because I'm not familiar with its usage, I didn't give it too much thought. I now think the method of dynamically growing memory allocation may be a culprit. But I get ahead of myself. Hmm, I guess that's my fault. While porting getent, I found that the output of `getent --help' was always missing the stuff which was supposed to be following after the -V,--version: Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Supported databases: ahosts ahostsv4 ahostsv6 group hosts initgroups passwd protocols services For bug reporting instructions, please see: http://cygwin.com/problems.html. In my case it didn't run wild, it just omitted the aforementioned text. After some debugging it turned out that newlib's open_memstream functionality had a bug. It neglected to initialize the variable containing the current number of bytes written to the mem buffer to 0. I fixed this bug in newlib, but obviously it's not yet in the released Cygwin version 1.7.28. It will be in 1.7.29, though. So, for the time being, either refrain from calling `getent --help', or update to the latest Cygwin snapshot from http://cygwin.com/snapshots/, which will not have this problem. Phew. Thanks for that. It seemed like one of those problems that may have been to specific to my system and not easily reproducible. I'll wait for 1.7.29. -- Thanks, Shaddy -- 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: checking in = 256k file fatally corrupts rcs file
This is an additional comment on the thread starting with http://cygwin.com/ml/cygwin/2013-10/msg00086.html Recently I was bitten again by this RCS 5.8 bug after I failed to keep RCS at version 5.7 during a Cygwin update. The failure mechanism is described in http://cygwin.com/ml/cygwin/2012-09/msg00331.html I never received a response from Dr. Volker Zell and didn't know how to contact the RCS maintainers. Since RCS 5.8 destroys large files I would prefer Cygwin to keep RCS 5.7 available until 5.8 has been fixed. Or go to 5.9 if that doesn't have the same problem. I've now tried to contact the RCS maintainers by submitting a bug report: http://savannah.gnu.org/bugs/index.php?41707 Regards, Peter Wagemans -- 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
Octave package database update
Hello, I installed the octave package in Cygwin. This works well. But when I install octave-signal and other octave packages, They are not found by octave. At start, octave gives an error: error: save: unable to open output file '/usr/share/octave/octave_packages' error: called from: error: /usr/share/octave/3.8.0/m/pkg/pkg.m at line 498, column 9 error: /usr/share/octave/site/m/startup/octaverc at line 22, column 3 This is apparently a permission issue and I have to login as Administrator and start octave from there each time I install a new package. Shouldn't the package database update be done at installation time of the package from the Cygwin setup, rather than on every start of octave? The setup has the right privileges to do so. Also, this would make octave to start faster. Best regards, Jonas System Information: Windows 7 GNU Octave Version 3.8.0 CYGWIN_NT-6.1 1.7.28(0.271/5/3) 2014-02-09 21:06 x86_64 -- 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: Testers needed: New passwd/group handling in Cygwin
On Feb 26 11:02, Corinna Vinschen wrote: On Feb 26 08:09, Achim Gratz wrote: Sorry, I don't grok this. What has a web application server to do with asking a DC for user info? We have one of these that does a lot of DC lookups because it authenticates all users. It's also in a much faster network, so I can check there what the lookup rate could be reasonably expected to be. Erm... how often are you calling id, usually? I'm currently doing this in the login process to figure out whether the prompt should show root powers. I'll have to figure out something else to do instead. No, you don't. I'm actually doing the same. Let's keep up with this and try to make Cygwin faster in the first place. I just created 400 groups in AD, and added myself as member. An `id' on a 32 bit Windows 7 domain member machine in my tiny network consisting only of a handful of Windows VMs and with me as the only real user takes about 3.6 secs with the latest code from CVS, using a non-optimzed Cygwin DLL. Also, we're in the early stages of testing this change. The idea is not that you just switch, the idea is that we *test* this and I get enough feedback to be able to ease the biggest pains. Understood. Until now I had to generate passwd and group files and I was hoping that the need for doing that would go away (I'd also need to talk to our AD folks so they start populating the correct fields). Yup. Feedback from AD admins is greatly appreciated. Other than that, I just had an in-shower inspiration how to speed up `id' specificially. The getgroups(2) call is in the center of this and I could probably speed up the stuiff a lot by opening the LDAP connection in getgroups only once. Thursday? :-) Hmm, probably. With this patch applied, the aforementioned `id' now takes about 1.9 secs, in an otherwise identical scenario. Also, more radically, if we drop the functionality to define another group name for a group, we could drop the requirement to open an LDAP connection to fetch group information to the DC entirely(*). This would only affect domain groups, local groups could still have different names. But I'm already wondering for a couple of days if having a Cygwin group name different from the Windows group name is really necessary at all. I added this years ago for fun, but there's no serious reason I can think of which would require to keep up with this. (*) Assuming the group info is cached in the local LSA, which is pretty likely for the groups of the current user. That would also work for me (I don't think I've ever used that feature consciously). With this patch applied as well, `id' now takes constantly 0.4 secs. Note that this speedup is only possible when fetching lots of group account information. For user accounts we still need the info from AD, but apart from the getpwent functionality, which can be restricted via the db_enum setting in /etc/nsswitch.conf, there's not very often a good reason to fetch information for hundreds of user accounts. Anyway, if I send you the link to two DLLs with these patches, would you mind to test their speed in your environment? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpMEHmJbgvd0.pgp Description: PGP signature
Problems with new setup
The new setup (32 bit) now requires admin privileges, which I don't have. I've used all of the usual tricks, re-naming to remove setup from the name, copying by cat new_file.exe, moving to a FAT and then back, playing with windows permissions. It is also a lot bigger than the previous version. 730624 2013-11-07 13:45:22 setup-x86.old.exe 2366464 2014-02-25 13:28:35 setup-x86.exe Is that expected or is that an indication something? - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with new setup
On Feb 26 16:08, Buchbinder, Barry (NIH/NIAID) [E] wrote: The new setup (32 bit) now requires admin privileges, which I don't have. I've used all of the usual tricks, re-naming to remove setup from the name, copying by cat new_file.exe, moving to a FAT and then back, playing with windows permissions. It is also a lot bigger than the previous version. 730624 2013-11-07 13:45:22 setup-x86.old.exe 2366464 2014-02-25 13:28:35 setup-x86.exe Is that expected or is that an indication something? Dunno why it's bigger (missing compression maybe) but for the admin problem, try running setup with the -B/--no-admin option. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFlcm857Ulk.pgp Description: PGP signature
cygport bug: doesn't understand DOS line endings
Hello, I was trying to build the waf cygport (i.e.
http://sourceforge.net/p/cygwin-ports/waf/ci/master/tree/ ), and kept getting a
cryptic error message:
*** ERROR: inherit: unknown cygclass python3
Since there was definitely a /usr/share/cygport/cygclass/python3.cygclass file,
this made no sense to me.
I modified /usr/share/cygport/lib/inheritance.cygpart so that line 39 read
error inherit: unknown cygclass ${_privclassdir}/${classname}.cygclass WTF;
And got the interesting error message
.cygclass WTFherit: unknown cygclass /usr/share/cygport/cygclass/python3
That's when I realized that the CR character was being included in the module
name.
I ran dos2unix on the .cygport file and all was well.
You may want to modify cygport to handle DOS-style line-endings.
Thanks,
Steven Boswell
--
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: Problems with new setup
Greetings, Buchbinder, Barry (NIH/NIAID) [E]! The new setup (32 bit) now requires admin privileges, which I don't have. I've used all of the usual tricks, re-naming to remove setup from the name, copying by cat new_file.exe, moving to a FAT and then back, playing with windows permissions. It is also a lot bigger than the previous version. 730624 2013-11-07 13:45:22 setup-x86.old.exe 2366464 2014-02-25 13:28:35 setup-x86.exe Is that expected or is that an indication something? Where did you download it from? + ARCH=x86 ++ uname -m + '[' i686 = x86_64 ']' + LANG=C + wget -N http://cygwin.com/setup-x86.exe --2014-02-26 22:29:25-- http://cygwin.com/setup-x86.exe Resolving cygwin.com (cygwin.com)... 209.132.180.131 Connecting to cygwin.com (cygwin.com)|209.132.180.131|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 742912 (726K) [application/octet-stream] Remote file is newer, retrieving. --2014-02-26 22:29:25-- http://cygwin.com/setup-x86.exe Connecting to cygwin.com (cygwin.com)|209.132.180.131|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 742912 (726K) [application/octet-stream] Saving to: `setup-x86.exe' 100%[===] 742,912 156K/s in 14s 2014-02-26 22:29:41 (51.9 KB/s) - `setup-x86.exe' saved [742912/742912] -- WBR, Andrey Repin (anrdae...@yandex.ru) 26.02.2014, 22:28 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Octave package database update
On 26/02/2014 14:26, jonas.ha...@metas.ch wrote: Hello, I installed the octave package in Cygwin. This works well. But when I install octave-signal and other octave packages, They are not found by octave. At start, octave gives an error: error: save: unable to open output file '/usr/share/octave/octave_packages' error: called from: error: /usr/share/octave/3.8.0/m/pkg/pkg.m at line 498, column 9 error: /usr/share/octave/site/m/startup/octaverc at line 22, column 3 This is apparently a permission issue and I have to login as Administrator and start octave from there each time I install a new package. correct. Same when you remove one Shouldn't the package database update be done at installation time of the package from the Cygwin setup, rather than on every start of octave? The setup has the right privileges to do so. Also, this would make octave to start faster. unfortunately it will create more problem than current solution, and the boot check is very fast. Current solution checks if the package database is older that the package directory and only in that case update the database. Drawback you need the setup permission. See /usr/share/octave/site/m/startup/octaverc If I put the update script on every forge package, and you install 10 (or 50 packages) it will require to start for every package octave, update the database and close. Doing so, the she setup could be very slow and it could likely fail for fork issue as octave is very large and need to lot a lot of directories. Worst if you remove everything the post install script could try to run without octave and failing all the time. Could you check if changing permission with chmod 666 /usr/share/octave/octave_packages the situation improve ? Best regards, Jonas System Information: Windows 7 GNU Octave Version 3.8.0 CYGWIN_NT-6.1 1.7.28(0.271/5/3) 2014-02-09 21:06 x86_64 REgards Marco -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: I just created 400 groups in AD, and added myself as member. An `id' on a 32 bit Windows 7 domain member machine in my tiny network consisting only of a handful of Windows VMs and with me as the only real user takes about 3.6 secs with the latest code from CVS, using a non-optimzed Cygwin DLL. OK, so you do less than 200 lu/s even in that favorable case. Our DC is hit by some four figure number of clients I suppose. I've asked my colleague to check the lookup rate on our test web server and he also gets around 30 lu/s with caching disabled, just like I did via Cygwin. So the network speed isn't the limiting factor. With this patch applied, the aforementioned `id' now takes about 1.9 secs, in an otherwise identical scenario. Sounds interesting. With this patch applied as well, `id' now takes constantly 0.4 secs. Gets even better… :-) Note that this speedup is only possible when fetching lots of group account information. For user accounts we still need the info from AD, but apart from the getpwent functionality, which can be restricted via the db_enum setting in /etc/nsswitch.conf, there's not very often a good reason to fetch information for hundreds of user accounts. Anyway, if I send you the link to two DLLs with these patches, would you mind to test their speed in your environment? Bring it on. I'd need 32bit DLL since I have to keep the 64bit Cygwin running on my machine. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: setup.exe bad signatures?
Michael Ryan writes: I'm trying to verify the signatures on the latest setup.exe files and I'm finding that they don't match: $ gpg --verify setup-x86.exe.sig gpg: Signature made Fri 13 Dec 2013 17:24:37 GMT using DSA key ID 676041BA gpg: BAD signature from Cygwin Cygwin AT cygwin.com $ gpg --verify setup-x86_64.exe.sig gpg: Signature made Fri 13 Dec 2013 17:38:14 GMT using DSA key ID 676041BA gpg: BAD signature from Cygwin cygwin AT cygwin.com $ md5sum setup-x86* 93ee19b4143133ec0d9462a27e5c92cb setup-x86_64.exe 2f2d2a21916b164c9f844810ada0f5f5 setup-x86_64.exe.sig 9b3e9b26fa040763f2673cc3dc0cf229 setup-x86.exe 3afb815ce823e601f999de777ea72885 setup-x86.exe.sig Am I doing something wrong, or...? Probably not, those signatures are still referring to the previous setup.exe files if you believe the date. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Problems with new setup
On 2014-02-26 17:08, Buchbinder, Barry (NIH/NIAID) [E] wrote: It is also a lot bigger than the previous version. 730624 2013-11-07 13:45:22 setup-x86.old.exe 2366464 2014-02-25 13:28:35 setup-x86.exe Is that expected or is that an indication something? I also saw that. I downloaded my copy ~21 hours ago from cygwin.com. The 32-bit version. It identified itself as version 2.844. I didn't try download since or the wget Mr Repin posted. -EL -- 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: Problems with new setup
On 2014-02-26 17:08, Buchbinder, Barry (NIH/NIAID) [E] wrote: It is also a lot bigger than the previous version. 730624 2013-11-07 13:45:22 setup-x86.old.exe 2366464 2014-02-25 13:28:35 setup-x86.exe Is that expected or is that an indication something? Eric Lilja sent the following at Wednesday, February 26, 2014 2:50 PM I also saw that. I downloaded my copy ~21 hours ago from cygwin.com. The 32-bit version. It identified itself as version 2.844. I didn't try download since or the wget Mr Repin posted. Andrey Repin sent the following at Wednesday, February 26, 2014 1:34 PM Where did you download it from? curl -RO http://cygwin.com/setup-x86.exe I downloaded again. 742912 2014-02-26 11:49:56 /tmp/getcygwin.exe 2366464 2014-02-26 10:52:56 /usr/local/bin/getcygwin.exe Both say they are v 2.844. I'd forgotten about -B. I had put it in the shortcut that I use so had forgotten about it. Thanks for reminding me. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Problems with new setup
-Original Message- Sent: Wednesday, February 26, 2014 11:50 AM Subject: Re: Problems with new setup On 2014-02-26 17:08, Buchbinder, Barry (NIH/NIAID) [E] wrote: It is also a lot bigger than the previous version. 730624 2013-11-07 13:45:22 setup-x86.old.exe 2366464 2014-02-25 13:28:35 setup-x86.exe Is that expected or is that an indication something? I also saw that. I downloaded my copy ~21 hours ago from cygwin.com. The 32-bit version. It identified itself as version 2.844. I didn't try download since or the wget Mr Repin posted. Just downloaded from cygwin.com and it looks OK sizewise (times are UTC-0800) -rwx--+ 1 jim.garrison Domain Users 742912 Feb 26 12:10 setup-x86-browser.exe -rwx--+ 1 jim.garrison Domain Users 742912 Feb 26 08:49 setup-x86-curl.exe -rwx--+ 1 jim.garrison Domain Users 730624 Feb 6 10:16 setup-x86-old.exe I also checked the signature with GPG and it looks good. However, it did hit the UAC prompt, but IIRC it's always done this, at least for me. -- 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
sox - package is broken
Hi Cygwin Team, 1st sox problem: in Cygwin 1.7.28 sound is broken. (sox + play) I followed all hints as reply to my first post last week. $ play blip.wav blip.wav: File Size: 1.33k Bit Rate: 94.4k Encoding: Unsigned PCM Channels: 1 @ 8-bit Samplerate: 11025Hz Replaygain: off Duration: 00:00:00.11 In:100% 00:00:00.11 [00:00:00.00] Out:1.25k [==|==]Clip:0 Done. == BUT I DONT HEAR ANYTHING, but same file works with other windows players (== soundcard + driver + speaker = ok). 2nd sox problem: setup for sox* packages seems to be broken too (download incomplete msg). It is the first time I have problems installing cygwin-packages. It is server independent (ftp:*.de). --- Possible solution: Why not using sounder.exe (freeware) which works without any setup and can play RIFF-WAVE-PCM and RIFF-WAVE-MP3 from command line. Together with aplay.exe (my c-code to emulate linux aplay player (using sounder internally). Install this way: -- wget http://www.physik.tu-berlin.de/~aleks/aplay.c wget http://www.elifulkerson.com/projects/downloads/sounder2013/sounder.exe gcc -O1 -o aplay.exe aplay.c cp aplay.exe sounder.exe /usr/bin/ -- -- 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: Cygwin64 ignoring /etc/passwd shell field?
On 2/26/2014 02:07, Corinna Vinschen wrote: On Feb 25 18:37, Larry Hall (Cygwin) wrote: On 2/25/2014 6:24 PM, Jim Burwell wrote: On 2/25/2014 13:55, Corinna Vinschen wrote: On Feb 25 13:52, Jim Burwell wrote: Hi, I've noticed after installing an update the Cygwin64 appears to ignore the contents of the shell field in /etc/passwd. I normally run /bin/tcsh as my shell, and changing this field used to result in any new login shells running tcsh. Now it just runs bash regardless. Has something changed? No. Works for me. Do you start `mintty -'? Corinna Interestingly, it works as expected with mintty, but not with xterm, uxterm, uterm. Was going to try rxvt, but noticed it's not in Cygwin64. It also works when I ssh into my cygwin. So appears to be a problem with xterm and related? Yes, and it's a conscious change. See https://sourceware.org/ml/cygwin-xfree/2014-02/msg5.html. Weird, I was pretty sure we already have an /etc/shells file installed by default. Apparently not. So, shan't we add one? /bin/sh /bin/bash /bin/dash /bin/mksh /bin/zsh /usr/bin/sh /usr/bin/bash /usr/bin/dash /usr/bin/mksh /usr/bin/zsh The base-files package would be a good place to be. David? Well, at least it wasn't a subconscious decision. :-) Thanks for the pointer! I agree. Every distro should have a default /etc/shells with the typical shells in it. - Jim -- 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: Cygwin64 ignoring /etc/passwd shell field?
On 2/26/2014 15:53, Jim Burwell wrote: On 2/26/2014 02:07, Corinna Vinschen wrote: On Feb 25 18:37, Larry Hall (Cygwin) wrote: On 2/25/2014 6:24 PM, Jim Burwell wrote: On 2/25/2014 13:55, Corinna Vinschen wrote: On Feb 25 13:52, Jim Burwell wrote: Hi, I've noticed after installing an update the Cygwin64 appears to ignore the contents of the shell field in /etc/passwd. I normally run /bin/tcsh as my shell, and changing this field used to result in any new login shells running tcsh. Now it just runs bash regardless. Has something changed? No. Works for me. Do you start `mintty -'? Corinna Interestingly, it works as expected with mintty, but not with xterm, uxterm, uterm. Was going to try rxvt, but noticed it's not in Cygwin64. It also works when I ssh into my cygwin. So appears to be a problem with xterm and related? Yes, and it's a conscious change. See https://sourceware.org/ml/cygwin-xfree/2014-02/msg5.html. Weird, I was pretty sure we already have an /etc/shells file installed by default. Apparently not. So, shan't we add one? /bin/sh /bin/bash /bin/dash /bin/mksh /bin/zsh /usr/bin/sh /usr/bin/bash /usr/bin/dash /usr/bin/mksh /usr/bin/zsh The base-files package would be a good place to be. David? Well, at least it wasn't a subconscious decision. :-) Thanks for the pointer! I agree. Every distro should have a default /etc/shells with the typical shells in it. - Jim Or on second thought, the shells themselves should run a post install which add themselves to /etc/shells. - Jim -- 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: Cygwin64 ignoring /etc/passwd shell field?
On 2014-02-27 01:03, Jim Burwell wrote: On 2/26/2014 15:53, Jim Burwell wrote: On 2/26/2014 02:07, Corinna Vinschen wrote: On Feb 25 18:37, Larry Hall (Cygwin) wrote: On 2/25/2014 6:24 PM, Jim Burwell wrote: On 2/25/2014 13:55, Corinna Vinschen wrote: On Feb 25 13:52, Jim Burwell wrote: Hi, I've noticed after installing an update the Cygwin64 appears to ignore the contents of the shell field in /etc/passwd. I normally run /bin/tcsh as my shell, and changing this field used to result in any new login shells running tcsh. Now it just runs bash regardless. Has something changed? No. Works for me. Do you start `mintty -'? Corinna Interestingly, it works as expected with mintty, but not with xterm, uxterm, uterm. Was going to try rxvt, but noticed it's not in Cygwin64. It also works when I ssh into my cygwin. So appears to be a problem with xterm and related? Yes, and it's a conscious change. See https://sourceware.org/ml/cygwin-xfree/2014-02/msg5.html. Weird, I was pretty sure we already have an /etc/shells file installed by default. Apparently not. So, shan't we add one? /bin/sh /bin/bash /bin/dash /bin/mksh /bin/zsh /usr/bin/sh /usr/bin/bash /usr/bin/dash /usr/bin/mksh /usr/bin/zsh The base-files package would be a good place to be. David? Well, at least it wasn't a subconscious decision. :-) Thanks for the pointer! I agree. Every distro should have a default /etc/shells with the typical shells in it. Or on second thought, the shells themselves should run a post install which add themselves to /etc/shells. Really? What if someone doesn't want to allow e.g. /bin/fish for some reason (missing from the list btw). It would be terrible to have it reappear simply because the fish package was updated. Cheers, Peter -- 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: sox - package is broken
On 26/02/2014 22:38, Dr. Alexander Kleinsorge wrote: 1st sox problem: in Cygwin 1.7.28 sound is broken. (sox + play) I followed all hints as reply to my first post last week. $ play blip.wav blip.wav: File Size: 1.33k Bit Rate: 94.4k Encoding: Unsigned PCM Channels: 1 @ 8-bit Samplerate: 11025Hz Replaygain: off Duration: 00:00:00.11 In:100% 00:00:00.11 [00:00:00.00] Out:1.25k [==|==]Clip:0 Done. == BUT I DONT HEAR ANYTHING, but same file works with other windows players (== soundcard + driver + speaker = ok). I've been able to reproduce this using very short wav files (less than 2 seconds in duration); if I use a longer file then it seems to work OK. Please could you try again with a longer wav file and report how you get on. This may be a Cygwin problem (rather than an issue with sox itself), as piping the wav file to /dev/dsp has the same result, i.e. short wav files are not heard. Cheers, Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin64 ignoring /etc/passwd shell field?
On Thu, Feb 27, 2014 at 01:16:28AM +0100, Peter Rosin wrote: On 2014-02-27 01:03, Jim Burwell wrote: On 2/26/2014 15:53, Jim Burwell wrote: On 2/26/2014 02:07, Corinna Vinschen wrote: On Feb 25 18:37, Larry Hall (Cygwin) wrote: On 2/25/2014 6:24 PM, Jim Burwell wrote: On 2/25/2014 13:55, Corinna Vinschen wrote: On Feb 25 13:52, Jim Burwell wrote: Hi, I've noticed after installing an update the Cygwin64 appears to ignore the contents of the shell field in /etc/passwd. I normally run /bin/tcsh as my shell, and changing this field used to result in any new login shells running tcsh. Now it just runs bash regardless. Has something changed? No. Works for me. Do you start `mintty -'? Corinna Interestingly, it works as expected with mintty, but not with xterm, uxterm, uterm. Was going to try rxvt, but noticed it's not in Cygwin64. It also works when I ssh into my cygwin. So appears to be a problem with xterm and related? Yes, and it's a conscious change. See https://sourceware.org/ml/cygwin-xfree/2014-02/msg5.html. Weird, I was pretty sure we already have an /etc/shells file installed by default. Apparently not. So, shan't we add one? /bin/sh /bin/bash /bin/dash /bin/mksh /bin/zsh /usr/bin/sh /usr/bin/bash /usr/bin/dash /usr/bin/mksh /usr/bin/zsh The base-files package would be a good place to be. David? Well, at least it wasn't a subconscious decision. :-) Thanks for the pointer! I agree. Every distro should have a default /etc/shells with the typical shells in it. Or on second thought, the shells themselves should run a post install which add themselves to /etc/shells. Really? What if someone doesn't want to allow e.g. /bin/fish for some reason (missing from the list btw). It would be terrible to have it reappear simply because the fish package was updated. The common case would be for a shell to show up in /etc/shells. Under Fedora adds the shell to /etc/shells when the shell package is installed. I don't see any reason for us to do anything different. So +1 from me on having a per-shell postinstall. I'm surprised that we've gotten by without something like this for so long. 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: Cygwin64 ignoring /etc/passwd shell field?
On Wed, Feb 26, 2014 at 07:26:59PM -0500, Christopher Faylor wrote: The common case would be for a shell to show up in /etc/shells. Under Fedora adds the shell to /etc/shells when the shell package is installed. I don't see any reason for us to do anything different. Rephrasing that in English: Under Fedora, shells add themselves to /etc/shells file when they are installed. 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: Cygwin64 ignoring /etc/passwd shell field?
On 2/26/2014 16:29, Christopher Faylor wrote: On Wed, Feb 26, 2014 at 07:26:59PM -0500, Christopher Faylor wrote: The common case would be for a shell to show up in /etc/shells. Under Fedora adds the shell to /etc/shells when the shell package is installed. I don't see any reason for us to do anything different. Rephrasing that in English: Under Fedora, shells add themselves to /etc/shells file when they are installed. 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 Yep. At least for common shells. If someone is super security conscious, they can police their /etc/shells file. But the most common usage would be to simply allow a shell that's installed, since if a person installed a shell, you can safely presume they want to use it. -- 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: cygport bug: doesn't understand DOS line endings
On 2014-02-26 11:14, Steven Boswell II wrote: You may want to modify cygport to handle DOS-style line-endings. cygport is a bash script, hence this applies: http://cygwin.com/ml/cygwin-announce/2007-05/msg3.html Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin64 ignoring /etc/passwd shell field?
Am 27.02.2014 01:45, schrieb Jim Burwell: On 2/26/2014 16:29, Christopher Faylor wrote: On Wed, Feb 26, 2014 at 07:26:59PM -0500, Christopher Faylor wrote: The common case would be for a shell to show up in /etc/shells. Under Fedora adds the shell to /etc/shells when the shell package is installed. I don't see any reason for us to do anything different. Rephrasing that in English: Under Fedora, shells add themselves to /etc/shells file when they are installed. 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 Yep. At least for common shells. If someone is super security conscious, they can police their /etc/shells file. But the most common usage would be to simply allow a shell that's installed, since if a person installed a shell, you can safely presume they want to use it. -- 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 One remark about /etc/shells The inetutils and inetutils-server packages comes with a file /etc/defaults/etc/shells and the postinstall scripts installs these file into /etc/shells. Regards Dirk -- 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
