Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 12 23:42, Thomas Wolff wrote: With cygwin-devel 1.7.34-002, the following test program (2 lines): #define _BSD_SOURCE #include stdlib.h produces this error: In file included from test.c:2:0: /usr/include/stdlib.h:258:23: error: expected string literal before ‘__ASMNAME’ __asm__ (__ASMNAME (__bsd_qsort_r)); ^ Thanks. Try adding #include sys/cdefs.h This include is missing in stdlib.h, but it's required to get the definition of __ASMNAME. I'll fix that upstream. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3oMIo8enK_.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
With cygwin-devel 1.7.34-002, the following test program (2 lines): #define _BSD_SOURCE #include stdlib.h produces this error: In file included from test.c:2:0: /usr/include/stdlib.h:258:23: error: expected string literal before ‘__ASMNAME’ __asm__ (__ASMNAME (__bsd_qsort_r)); ^ -- Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 10, 2014, at 9:37 PM, Alexey Pavlov alex...@gmail.com wrote: Also we switch to use real /usr folder and just create virtual mount for /bin folder that needed for some programs. You’re fighting the prevailing trend in Unix/Linux OS design by doing that. Solaris, Red Hat, and probably others also alias /usr/bin and /bin, and /usr/lib and /lib. It isn’t some weird Cygwin-only practice. The reason for this separation goes back to the days when it made sense to have separate physical volumes for the OS root and the “user space”. Now that you can get 64 gigs on a chip the size of your fingernail, this Unix design principle is about to follow UUCP into the dustbin of history. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Thu, Dec 11, 2014 at 5:41 PM, Warren Young w...@etr-usa.com wrote: On Dec 10, 2014, at 9:37 PM, Alexey Pavlov alex...@gmail.com wrote: Also we switch to use real /usr folder and just create virtual mount for /bin folder that needed for some programs. You’re fighting the prevailing trend in Unix/Linux OS design by doing that. Solaris, Red Hat, and probably others also alias /usr/bin and /bin, and /usr/lib and /lib. It isn’t some weird Cygwin-only practice. We're sticking as close as we can to real Linux. From my Arch Linux installation: ls -l / drwxr-xr-x 13 root root 4096 Oct 31 12:12 usr lrwxrwxrwx 1 root root 7 Oct 25 19:41 bin - usr/bin .. so Linux has a real /usr folder like we do, and they use symlinks for /bin and /lib. Since symlinks on Windows aren't always possible we opted to use mounts instead. The reason for this separation goes back to the days when it made sense to have separate physical volumes for the OS root and the “user space”. Now that you can get 64 gigs on a chip the size of your fingernail, this Unix design principle is about to follow UUCP into the dustbin of history. -- 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 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On 12/10/2014 07:28, Angelo Graziosi wrote: Corinna Vinschen wrote: How nice. We have all the work and they simple grab it and don't give anything back to their upstream project. ...the *Dark* side of free (GPL?) software... I guess.. No, this is exactly how GPL is supposed to work, now that it has been corrected, anyone can grab the MSYS2 sources. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 9 15:05, Warren Young wrote: On Dec 9, 2014, at 3:56 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Dec 8 15:14, Warren Young wrote: On Dec 6, 2014, at 12:49 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: - Cygwin can now generate passwd/group entries directly from Windows don’t use AD here, and /etc/passwd suffices for my purposes You can still benefit, I hope. Even when using only the local SAM, the process startups should be a tad bit faster than when every exec'ed process has to read /etc/passwd and /etc/group files: Challenge…accepted. I decided to do the nastiest thing I could think of to Cygwin: run a configure script. ;) In my Windows 10 Technical Preview test VM, Cygwin 64 1.7.33 runs the iperf3 configure script in 20 seconds. On upgrading to 1.7.34-002, without doing anything to nsswitch.conf, the time remained the same. On making the suggested change to nsswitch.conf, configure time went *up* to 21 seconds. So, I moved the new nsswitch.conf back out of the way, relaunched MinTTY, and configure time dropped its extra second. Hmm. Indeed, hmm. I see a tiny loss in performance myself. It's puzzeling. During the entire configure run only at the end are a few minor (but unnecessary) requests for account information. I'll investigate this in the next couple of days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDAe4seu1zb.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 10 17:47, JonY wrote: On 12/10/2014 07:28, Angelo Graziosi wrote: Corinna Vinschen wrote: How nice. We have all the work and they simple grab it and don't give anything back to their upstream project. ...the *Dark* side of free (GPL?) software... I guess.. No, this is exactly how GPL is supposed to work, now that it has been corrected, anyone can grab the MSYS2 sources. ACK. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKF4FlvivZG.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 10 08:36, Alexey Pavlov wrote: [...] Our changes to Cygwin runtime as we talk in the past are not acceptable to Cygwin upstream because have a different philosophy and have break some posix features. About half a year ago we talk about how integrate MSYS functionality into Cygwin upstream. As a result of this discussion was added this code: https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212 To try make MSYS functionality separate from original Cygwin DLL. But as our team is small and we have our real work too, we don't have time and in some parts necessary knowledges to finish this work. As you may have noticed, our team is pretty small as well. It looks a lot like it's smaller than yours. Also I think some changes can't be easily separated into external dll. So we open minded to incorporate with Cygwin if anyone will help with finishing this work. The problem is not that your changes can or can't be implemented using cgf's suggested change, the problem is that you simply never discussed it. Cgf started a discussion of what changes might be required on 2013-07-30: https://cygwin.com/ml/cygwin-developers/2013-07/msg00075.html As you may have noticed, the mail explicitely mention that this was supposed to be a discussion. He then checked in a preliminary patch to a branch: https://cygwin.com/ml/cygwin-developers/2013-07/msg00076.html The result: Nothing. You could have heard the crickets chirping in the thread. No. Reply. At. All. Until 2013-10-21, almost three months later, cgf asked if nobody is interested to pick up: https://cygwin.com/ml/cygwin-developers/2013-10/msg7.html Reply: We're just busy. Then... nothing. Crickets again, the thread collecting dust and cobwebs. Another four months later, cgf pinged you guys and the result: https://cygwin.com/ml/cygwin-developers/2014-02/msg1.html Then... nothing. How do you expect any progress if you don't at least **discuss what's necessary, and eventually code up and test changes? Both of us definitely lost interest after Feb-2014, because, apparently you weren't able to come up with anything. You have your solution, which is a bunch of patches, and that's apparently enough for you. There's no interest to follow up on a better solution, from what I see. In contrast with Cygwin developers, we don't have any problems with Arch Linux developers You don't have interoperability issues with Arch Linux. I explained what we were thinking of pretty detailed on the mingw-w64-public mailing list. Without going into much detail now, the idea would have been basically to keep the MSYS2 distro based on the latest Cygwin packages, and have the behavioral change hidden behind the MSYS2 hook. You could have a seamless integration between all of the Cygwin distro and the few parts of the MSYS2 distro which really needed a patch. Basically MSYS2 could have been a subset or even an integral part of a Cygwin distro, which would have (probably) benefitted all of us. So if you want to grab or rip-off (as you wish) our pacman, feel free to get it and use under Cygwin. We don't have any problems with it. It's not really feasible because it requires to rebuild all packages. We're also relying on an infrastructure which is kind of bound to the setup and upset tools so far. Also, does pacman work without a basic MSYS2 installed already, or do you have to have an MSYS2 install to be able to run pacman? If we could make pacman work with setup.ini, I wouldn't be unhappy to have this as an accompanying CLI tool for installing Cygwin packages. And if somebody thinks setup and the whole infrastructure is bad, all I can say is, maybe, but somebody has to have *time* and *volition* to implement something new. Something still operating as a GUI installer to install a Cygwin distro from the ground up. And also something on the server side to support the new layout. And the packager support. As long as my reqeusts for volunteers goes unheard, I don't see how we could change that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_jl459tzKY.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
2014-12-10 19:01 GMT+03:00 Corinna Vinschen: On Dec 10 08:36, Alexey Pavlov wrote: [...] Our changes to Cygwin runtime as we talk in the past are not acceptable to Cygwin upstream because have a different philosophy and have break some posix features. About half a year ago we talk about how integrate MSYS functionality into Cygwin upstream. As a result of this discussion was added this code: https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212 To try make MSYS functionality separate from original Cygwin DLL. But as our team is small and we have our real work too, we don't have time and in some parts necessary knowledges to finish this work. As you may have noticed, our team is pretty small as well. It looks a lot like it's smaller than yours. Yeah, but you is paid to work full time on Cygwin. While for us this is just free-time project. Sometimes we don't do anything for couple of weeks just because of lack of time. Only 2 persons work on MSYS2 itself and both are have many other work then MSYS2. For you Cygwin is target of work but for us MSYS2 is just a tool to do other work. So we need time-share between different works. Also I think some changes can't be easily separated into external dll. So we open minded to incorporate with Cygwin if anyone will help with finishing this work. The problem is not that your changes can or can't be implemented using cgf's suggested change, the problem is that you simply never discussed it. Cgf started a discussion of what changes might be required on 2013-07-30: https://cygwin.com/ml/cygwin-developers/2013-07/msg00075.html As you may have noticed, the mail explicitely mention that this was supposed to be a discussion. He then checked in a preliminary patch to a branch: https://cygwin.com/ml/cygwin-developers/2013-07/msg00076.html The result: Nothing. You could have heard the crickets chirping in the thread. No. Reply. At. All. Until 2013-10-21, almost three months later, cgf asked if nobody is interested to pick up: https://cygwin.com/ml/cygwin-developers/2013-10/msg7.html Reply: We're just busy. Then... nothing. Crickets again, the thread collecting dust and cobwebs. Another four months later, cgf pinged you guys and the result: https://cygwin.com/ml/cygwin-developers/2014-02/msg1.html Then... nothing. How do you expect any progress if you don't at least **discuss what's necessary, and eventually code up and test changes? So here we have lost time... But there are good too - we drop old MSYS code in this months. Both of us definitely lost interest after Feb-2014, because, apparently you weren't able to come up with anything. You have your solution, which is a bunch of patches, and that's apparently enough for you. There's no interest to follow up on a better solution, from what I see. In contrast with Cygwin developers, we don't have any problems with Arch Linux developers You don't have interoperability issues with Arch Linux. I explained what we were thinking of pretty detailed on the mingw-w64-public mailing list. Without going into much detail now, the idea would have been basically to keep the MSYS2 distro based on the latest Cygwin packages, and have the behavioral change hidden behind the MSYS2 hook. You could have a seamless integration between all of the Cygwin distro and the few parts of the MSYS2 distro which really needed a patch. Basically MSYS2 could have been a subset or even an integral part of a Cygwin distro, which would have (probably) benefitted all of us. We have very different structure than Cygwin. So in any case we will need create our own distro as we don't want to use Cygwin build packages system and installer. Pacman solve a lot of problems for maintaining packages. Also we switch to use real /usr folder and just create virtual mount for /bin folder that needed for some programs. So if you want to grab or rip-off (as you wish) our pacman, feel free to get it and use under Cygwin. We don't have any problems with it. It's not really feasible because it requires to rebuild all packages. We're also relying on an infrastructure which is kind of bound to the setup and upset tools so far. Also, does pacman work without a basic MSYS2 installed already, or do you have to have an MSYS2 install to be able to run pacman? Pacman is MSYS-like program not Windows native so it can be run only from install. Our installer give user minimal system from what he can use pacman to install packages that user need. Minimal system also created with pacman using chroot and then archived for installer. MSYS2 is rolling-release system so we really don't have versions - just create installer for current snapshot to give new users more recent system without installing tons of updates. But users also can upgrade system to recent from older installers too. If we could make pacman work with setup.ini, I wouldn't be unhappy to
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 8 15:14, Warren Young wrote: On Dec 6, 2014, at 12:49 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: - Cygwin can now generate passwd/group entries directly from Windows This is huge, Corinna! It must have been a lot of work, and while I personally will not benefit much from this — don’t use AD here, and /etc/passwd suffices for my purposes You can still benefit, I hope. Even when using only the local SAM, the process startups should be a tad bit faster than when every exec'ed process has to read /etc/passwd and /etc/group files: $ cat /etc/nsswitch.conf EOF passwd: db group: db EOF $ exit restart your terminal Give it a try! — it’s one of those things that should obviously be done. Congratulations on getting this into a shippable state. I realize it isn’t formally released yet, but you’ve gotten it over the hump where it must be compiled out of release binaries. I assume this is one of those situations where the last 10% of the work takes 90% of the time. Congratulations! Thank you very much! I started to implement this stuff in January 2014 and the formal release will hopefully be in January 2015, so, yes, all in all, it was a lot of work. Especially the documentation :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpLzVyhVFaaX.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
Greetings, Warren Young! - Cygwin can now generate passwd/group entries directly from Windows This is huge, Corinna! It must have been a lot of work, and while I personally will not benefit much from this — don’t use AD here, and /etc/passwd suffices for my purposes — it’s one of those things that should obviously be done. You'd be surprised to know, how much faster it works when you delete the passwd. Especially if you start alot of Cygwin tools from native app, so they don't benefit from parent caching. Congratulations on getting this into a shippable state. I realize it isn’t formally released yet, but you’ve gotten it over the hump where it must be compiled out of release binaries. I assume this is one of those situations where the last 10% of the work takes 90% of the time. On this, I agree. -- WBR, Andrey Repin (anrdae...@yandex.ru) 09.12.2014, 14:36 Sorry for my terrible english...
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 9, 2014, at 3:56 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Dec 8 15:14, Warren Young wrote: On Dec 6, 2014, at 12:49 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: - Cygwin can now generate passwd/group entries directly from Windows don’t use AD here, and /etc/passwd suffices for my purposes You can still benefit, I hope. Even when using only the local SAM, the process startups should be a tad bit faster than when every exec'ed process has to read /etc/passwd and /etc/group files: Challenge…accepted. I decided to do the nastiest thing I could think of to Cygwin: run a configure script. ;) In my Windows 10 Technical Preview test VM, Cygwin 64 1.7.33 runs the iperf3 configure script in 20 seconds. On upgrading to 1.7.34-002, without doing anything to nsswitch.conf, the time remained the same. On making the suggested change to nsswitch.conf, configure time went *up* to 21 seconds. So, I moved the new nsswitch.conf back out of the way, relaunched MinTTY, and configure time dropped its extra second. Hmm. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
Corinna Vinschen wrote: How nice. We have all the work and they simple grab it and don't give anything back to their upstream project. ...the *Dark* side of free (GPL?) software... I guess.. In any case, you could always *grab* their pacman manager.. Besides being very appealing, it would avoid the long thread [*] on cygwin-apps list.. Why what aims to be a ..Linux feeling - on Windows should have a package manager (setup.exe :( ) which install deps more o less silently... apt-get, yum, pacman, port (on OSX) (and, I sure, others) always warn the user about which packages are to be installed.. Unless you adopt a 'true' package manager, I would not change the current behavior of setup.exe.. Ciao, Angelo. --- [*] https://cygwin.com/ml/cygwin-apps/2014-12/msg00017.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
2014-12-10 2:28 GMT+03:00 Angelo Graziosi : Corinna Vinschen wrote: How nice. We have all the work and they simple grab it and don't give anything back to their upstream project. ...the *Dark* side of free (GPL?) software... I guess.. In any case, you could always *grab* their pacman manager.. Besides being very appealing, it would avoid the long thread [*] on cygwin-apps list.. Why what aims to be a ..Linux feeling - on Windows should have a package manager (setup.exe :( ) which install deps more o less silently... apt-get, yum, pacman, port (on OSX) (and, I sure, others) always warn the user about which packages are to be installed.. Unless you adopt a 'true' package manager, I would not change the current behavior of setup.exe.. Hi! I'm MSYS2 maintainer. I do not understand why some of you constantly want to throw stones in the garden of MSYS2. We are solve problems other than Cygwin. And MSYS2 don't replace Cygwin as project. We have small subset of Cygwin-like programs that only needed to develop applications under Windows using mingw-w64 native toolchains. We don't have X11 apps, daemons and many others as Cygwin have as it not need to our work. If you compare number of MSYS packages: https://github.com/Alexpux/MSYS2-packages with Cygwin package list than you can see the difference. Our primary goal is native Windows applications building with mingw-w64 toolchains. We have create lot of mingw-w64 packages: https://github.com/Alexpux/MINGW-packages Some patches from our project are go upstream - many not as not all projects are open-minded. For example Python where developers always block changes that add Mingw as build target. Latest MSYS2 runtime sources are always present here: https://github.com/Alexpux/Cygwin/tree/develop Yeah I'm forgetting push latest t osf.net because I don't use it and I don't like sf.net web-interface to repositories. Maybe need just delete repo on sf.net and redirect page to github. Yeah I try to stay up-to-date with current Cygwin sources to not create by anyone other fork of Cygwin for something like MSYS3 because of MSYS2 outdate and not supportable. Also often syncing with cygwin sources helps with merging our changes more easily. Merging 10 commits instead of 100 is more easily. Our changes to Cygwin runtime as we talk in the past are not acceptable to Cygwin upstream because have a different philosophy and have break some posix features. About half a year ago we talk about how integrate MSYS functionality into Cygwin upstream. As a result of this discussion was added this code: https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212 To try make MSYS functionality separate from original Cygwin DLL. But as our team is small and we have our real work too, we don't have time and in some parts necessary knowledges to finish this work. Also I think some changes can't be easily separated into external dll. So we open minded to incorporate with Cygwin if anyone will help with finishing this work. In contrast with Cygwin developers, we don't have any problems with Arch Linux developers as we use it's latest pacman from git which is not released yet and also have our own fork of it: https://github.com/Alexpux/MSYS2-pacman/tree/master So if you want to grab or rip-off (as you wish) our pacman, feel free to get it and use under Cygwin. We don't have any problems with it. Regards, Alexey. Ciao, Angelo. --- [*] https://cygwin.com/ml/cygwin-apps/2014-12/msg00017.html -- 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 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 7 12:21, Angelo Graziosi wrote: Ciao Corinna, Corinna Vinschen wrote: The new nsswitch.conf settings maybe I am wrong.. but shouldn't these new test release come with a default /etc/nsswitch.conf file? a file which is installed/updated if it does not exist/unchanged.. This would be the job of the base-cygwin package, which I'll update as soon as I release Cygwin 1.7.34. I have seen that MSYS2 *has* it... The Cygwin rip-off which, again, violates the GPL? They are already releasing the code which isn't even officially release for Cygwin? How nice. We have all the work and they simple grab it and don't give anything back to their upstream project. How very nice. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp8wbOEC5FAM.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 7 15:59, Henry S. Thompson wrote: Corinna Vinschen writes: I finally released another TEST version of the next upcoming Cygwin release. The version number is 1.7.34-002. I just installed both 32- and 64-bit version on top of my existing (normal) release. The 64-bit one has a two-line (passwd=group=db) nsswitch.conf left over from May, when I last tried a test release, the 32-bit one has no nsswitch.conf. Nothing to report. ssh, sshd and kinit all work on 64-bit, ssh and kinit on 32-bit. Thought this was just barely worth a mention. Heh. I'm glad for your report nevertheless. I'd be just happy if people would experiment with the new nsswitch.conf options a bit. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3iMIAEGHex.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
On Dec 6, 2014, at 12:49 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: - Cygwin can now generate passwd/group entries directly from Windows This is huge, Corinna! It must have been a lot of work, and while I personally will not benefit much from this — don’t use AD here, and /etc/passwd suffices for my purposes — it’s one of those things that should obviously be done. Congratulations on getting this into a shippable state. I realize it isn’t formally released yet, but you’ve gotten it over the hump where it must be compiled out of release binaries. I assume this is one of those situations where the last 10% of the work takes 90% of the time. Congratulations! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
Ciao Corinna, Corinna Vinschen wrote: The new nsswitch.conf settings maybe I am wrong.. but shouldn't these new test release come with a default /etc/nsswitch.conf file? a file which is installed/updated if it does not exist/unchanged.. I have seen that MSYS2 *has* it... Ciao, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
Corinna Vinschen writes: I finally released another TEST version of the next upcoming Cygwin release. The version number is 1.7.34-002. I just installed both 32- and 64-bit version on top of my existing (normal) release. The 64-bit one has a two-line (passwd=group=db) nsswitch.conf left over from May, when I last tried a test release, the 32-bit one has no nsswitch.conf. Nothing to report. ssh, sshd and kinit all work on 64-bit, ssh and kinit on 32-bit. Thought this was just barely worth a mention. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
Hi Cygwin friends and users,
I finally released another TEST version of the next upcoming Cygwin
release. The version number is 1.7.34-002.
The big changes compared to 1.7.34-001, apart from bugfixes and a new
API (qsort_r), are the following:
- The new nsswitch.conf settings db_home, db_shell, and db_gecos
to define where and how to fetch home directory, login shell, and
gecos content.
Most importantly, this is also documented now. See the preliminary
documentation URL below.
- When spawning a process under another user account (sshd, cron, etc),
the user's default Windows environment is now merged into the new
processes environment.
If you want to help testing this new release (which I seriously hope
for), you can find it in your setup-x86.exe or setup-x86_64.exe as
test release.
The major change in this new release will be the new method to read
account (passwd and group) information from the Windows user databases
directly, without the requirement to generate /etc/passwd and /etc/group
files to generate Unix-like uid and gid.
For your convenience I wrote new documentation. Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at
https://cygwin.com/preliminary-ntsec.html
If you read it (which I seriously hope for) and it's all just
incomprehensible gobbledygook to you, please say so on the mailing list
cygwin AT cygwin DOT com
so we have a chance to improve the documentation.
Please give this TEST release a try.
If you find problems in the new features or regressions compared to the
current stable release 1.7.33, please report them to the public mailing
list
cygwin AT cygwin DOT com
Following is a list of changes in this new release:
What's new:
---
- Cygwin can now generate passwd/group entries directly from Windows
user databases (local SAM or Active Directory), thus allowing to run
Cygwin without having to create /etc/passwd and /etc/group files.
Introduce /etc/nsswitch.conf file to configure passwd/group handling.
For bordercase which require to use /etc/passwd and /etc/group files,
change mkpasswd/mkgroup to generate passwd/group entries compatible
with the entries read from SAM/AD.
- Add -b/--remove-all option to setfacl to reduce the ACL to only the
entries representing POSIX permission bits.
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
What changed:
-
- Revamp Solaris ACL implementation to more closely work like POSIX ACLs
are supposed to work. Finally implement a CLASS_OBJ emulation. Update
getfacl(1)/setfacl(1) accordingly.
- The xdr functions are no longer exported for newly built executables.
Use libtirpc-devel instead.
- 32 bit only: Change default values for socket buffer size to raise
performance on 10Gb networks.
- When spawning a process under another user account, merge the user's
default Windows environment into the new process' environment.
Bug Fixes
-
- Fix the problem that ptys master side always writes single byte packages
to the slave side, and pty slaves always read VMIN byte packages from
the master side if VMIN is 0.
Fixes: https://cygwin.com/ml/cygwin-developers/2014-11/msg0.html
- Fix a synchronization problem in signal handling when using pthreads.
Addresses: https://cygwin.com/ml/cygwin/2014-11/msg00472.html
- Fix an invalid handle problem when using flock(2) with a parent process
holding the lock.
Addresses: https://cygwin.com/ml/cygwin/2014-12/msg00012.html
To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe
If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so. If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet available in
the 64 bit release.
Have fun,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
