Re: Cannot change console mode during usage of expect
On Apr 15 17:57, Keith Proctor wrote: > Corinna Vinschen cygwin.com> writes: > > On Apr 15 01:17, Keith Proctor wrote: > > > Hello, my name is Keith Proctor. I test FileMaker Server and I have > > > written a test suite on Macintosh. > > > [...] > > > The issue is that the following phrases appear and won’t allow > > > my interactive expect command to continue. > > > > > > GetConsoleMode// prints once > > > SetConsoleMode// prints once > > > ReadConsoleInput // spews while collecting input from the command line. > > > > I don't understand this. What does Cygwin expect have to do > > with these underlying OS calls?!? They only work in a console > > window and they are not to be suppsoed to be used by Cygwin > > executables since all the underlying OS details are (more or less) > > hidden behind the TTY code. Also, how are they supposed to work > > in a PTY which is constituted by Named Pipes, not a console? > > And expect certainly uses PTYs to perform its pseudo-interactive stuff. > > > Corinna, Let me make this a little clearer fmsadmin application is making > the 3 calls. In this case fmsadmin is being called from expect and expect > is the cause of the issue. Well, not really. The cause of the issue is that fmsadmin uses these calls. Fmsadmin apparently expects to run in a normal Windows console. Expect on the other hand is a Cygwin POSIX application, so it's using Cygwin PTYs and offers those as stdio descriptors to the inferior application. The problem here seems to be that you're expecting Cygwin to do something it doesn't, and fmsadmin not being a Cygwin application not being able to work seamlessly with a Cygwin POSIX appication in this regard. > On a very related note I see this same question being asked for years > and the Cygwin answer has been change your code to work with > Cygwin. Unfortunately, I don't have that luxury. fmsadmin is a > DOS application. I may never be able to get a fix for this issue in > fmsadmin as our target is NOT Cygwin. Which makes me wonder if using Cygwin is the right thing to do here. > BTW, I expect GetConsoleMode and SetConsoleMode is standard > usage by any console application. These calls work on Macintosh, > Windows and Cygwin window without expect. I have no idea what Mac you're talking about. IIUC OS X is a BSD-based system and it does not provide Windows-only calls. And GetConsoleMode, SetConsoleMode, and ReadConsoleInput are Windows calls. I have a hard time to believe that an OS X console uses the weird Windows console API. Unless, of course, you're running a Windows fmsadmin tool under some OS X Windows emulator. Does wine for OS X exist? As for Cygwin I'd like to stress that Cygwin tries to emulate POSIX in the first place. An application like expect will be compiled under Cygwin as a POSIX application. It will quite certainly not use or understand Windows calls. As a POSIX application, it will have no notion of Windows consoles and it will use PTYs as communication channels to the inferior process. PTYs are Cygwin-specific, implemented using named pipes under the hood. Named Pipes very certainly don't support the console API. The bottom line is, the fmsadmin tool, as a native Windows application, expects to perform I/O via the Windows Console. Thus it uses the Windows console API. Cygwin's expect on the other hand, is implemented as POSIX application and as such, uses POSIX means, PTYs. I don't see how the two of them can come together. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2r6JepmZtn.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi, On Apr 16 09:26, Takashi Yano wrote: > Hi Corinna, > > On Tue, 14 Apr 2015 09:34:56 +0200 > Corinna Vinschen wrote: > > > And the native client, not knowing what he's talking to, recognizes the > > output stream as a normal named pipe, if it's looking for that info at > > all. Being native, it will use native Windows MSVCRT stdio calls. > > Worse, as you can see in the behaviour of some native applications, the > > MSVCRT isatty() call returns 0 for named pipes. > > > > If we have a Cygwin client, we can do all kinds of stuff on the slave > > side, but as soon as we have a native client, only the master side of > > the pty has any chance to do the right thing. That's why I wrote that > > we don't have the slave side under control. > > > > Therefore we should really move the OPOST code back to the master side. > > I'm reluctant to just revert your patch, though, because I think you > > know better how to fix the OPOST code to make it work correctly on the > > master side. > > So OPOST processing should be in master side for native windows program. > However, to solve the second problem I had pointed out in > http://cygwin.com/ml/cygwin/2015-02/msg00929.html , > OPOST processing should be done on a timing when slave calls write(). > > To solve this antinomy, I have made a patch attached. > > With this patch, new pipe is introduced to handle OPSOT-process separately > between native windows program and cygwin program. > > Data from cygwin program is passed through the pipe newly introduced. > In this case, process_opost_output() is called in fhandler_pty_slave::write(). > Master reads data, which is already applied OPOST process, from the > new pipe. > > On the other hands, for native windows program, data is written into > conventional pipe. Master forwarding thread, which is also newly > introduced, reads conventional pipe and forward the data to the pipe > newly introduced by calling process_opost_output(). This makes OPOST > processing be done in master side. > > I have confirmed that the both problem is fixed with this patch. Ok, but... this is a really big patch and it complicates the pty code even more. Is there really no other option as far as the TCSADRAIN problem is concerned? What strikes me as weird is that neither fhandler_pty_slave::tcsetattr nor fhandler_pty_master::tcsetattr give a damn for the optional_actions parameter. They simply overwrite the tc settings. So I'm wondering, wouldn't it be possible to add code to the tcsetattr implementation instead, so that TCSADRAIN/TCSAFLUSH are honored and than only have one place for OPOST handling? > By the way, > I know that the names for the new pipe such as io_handle2, to_master2 > and output_handle2 are ugly enough. Are there more appropriate names? What about renaming io_handle to io_handle_nat and io_handle2 to io_handle or io_handle_cyg? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgppfkijLvlXr.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Apr 16 11:05, Corinna Vinschen wrote: > Hi Takashi, > > On Apr 16 09:26, Takashi Yano wrote: > > So OPOST processing should be in master side for native windows program. > > However, to solve the second problem I had pointed out in > > http://cygwin.com/ml/cygwin/2015-02/msg00929.html , > > OPOST processing should be done on a timing when slave calls write(). > > > > To solve this antinomy, I have made a patch attached. > > > > With this patch, new pipe is introduced to handle OPSOT-process separately > > between native windows program and cygwin program. > > > > Data from cygwin program is passed through the pipe newly introduced. > > In this case, process_opost_output() is called in > > fhandler_pty_slave::write(). > > Master reads data, which is already applied OPOST process, from the > > new pipe. > > > > On the other hands, for native windows program, data is written into > > conventional pipe. Master forwarding thread, which is also newly > > introduced, reads conventional pipe and forward the data to the pipe > > newly introduced by calling process_opost_output(). This makes OPOST > > processing be done in master side. > > > > I have confirmed that the both problem is fixed with this patch. > > Ok, but... this is a really big patch and it complicates the pty code > even more. Is there really no other option as far as the TCSADRAIN > problem is concerned? > > What strikes me as weird is that neither fhandler_pty_slave::tcsetattr > nor fhandler_pty_master::tcsetattr give a damn for the optional_actions > parameter. They simply overwrite the tc settings. So I'm wondering, > wouldn't it be possible to add code to the tcsetattr implementation > instead, so that TCSADRAIN/TCSAFLUSH are honored and than only have one > place for OPOST handling? ...and additionally don't have to maintain yet another handle. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp59Iw96jJ4_.pgp Description: PGP signature
Re: [TESTERS needed] New POSIX permission handling
Hi, Corinna Vinschen-2 wrote > Hi Ismail, > > On Apr 12 16:25, Corinna Vinschen wrote: >> On Apr 12 06:21, İsmail Dönmez wrote: >> > Corinna Vinschen-2 wrote >> > > On Apr 11 10:11, donmez wrote: >> > >> Corinna Vinschen-2 wrote >> > >> > I just applied a patch I'm working on for quite some time now. As >> I >> > >> > outlined before on this list, the POSIX permission handling has >> aged >> > >> > considerably and, for historical reasons, did things differently >> > >> > dependent on the calling function. I took the time to reimplement >> the >> > >> > core functionality to handle all ACLs as strictly following POSIX >> ACL >> > >> > rules as possible. >> > >> >> > >> I tested the updated package and at least quilt and mutt seems to >> broken >> > >> by >> > >> the permission changes: >> > >> [...] >> > > No offense, but this is not overly helpful. The problem is to learn >> > > *why* this happens and how to fix it. For that I'd need to know what >> > > your permissions on /tmp look like (ls -l, getfacl, icacls). >> Creating >> > > files in my /tmp (having an old-style ACL) with the following >> > > permissions works as desired for me: >> > >> > Hopefully this will shed some more light: >> >> It does, thank you. The problem is the dreaded "owner == group" problem >> introduced with these weird Microsoft accounts. I completely forgot >> about this while implementing the new code. It's pretty tricky to get >> the Windows ACL right for this. Additionally the ACLs already created >> by setup are... borderline correct only. Back to the drawing board... > > I just applied a patch which is supposed to handle this owner==group > scenario better. > > In short, Cygwin will try to handle POSIX user and group permissions > separately, even if owner == group. This is basically a fake as far > as the actual permissions of the account are concerned, but it allows > applications still to chmod to different user and group perms. It > just *looks* different in the end. > > The only restriction of this is that the POSIX user permissions are > always changed so that the user perms are >= the group perms in this > situation. So this: > > chmod 460 foo > > will be internally twisted into > > chmod 660 foo > > > I uploaded new developer snapshots to https://cygwin.com/snapshots/ > and I'm just uploading a 2.0.0-0.5 test release with this change. I tested the new test release (rm -rfd the cygwin installation and re-installed from scratch just to be sure), my original testcase with quilt and mutt works, BUT now when I run make install inside mutt source it complains that /usr/bin/install cannot change permissions on the destination executables. Now this is a pretty vague error report but it might take some time before I can post an easily reproducable error. Because running the same command myself gives no error whatsoever. I'll try to come up with a better report. Thanks a lot! -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117615.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: vim-7.4.692-1
2015-04-13 17:19 GMT+02:00 Yaakov Selkowitz: > The following packages have been updated in the Cygwin distribution: > > * vim-7.4.692-1 > * vim-common-7.4.692-1 > * vim-minimal-7.4.692-1 > * xxd-7.4.692-1 > * gvim-7.4.692-1 > > Vim is an advanced text editor that seeks to provide the power of the > de-facto Unix editor 'Vi', with a more complete feature set and a choice > of terminal and GTK+ interfaces. > > This is an update to the latest upstream patchset. Is it by design that vim now requires tcsh? tcsh(6.18.01-6) An enhanced version of csh, the C shell Required by: vim-common 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 POSIX permission handling
On Apr 16 03:20, Ismail Donmez wrote: > Corinna Vinschen-2 wrote > > I just applied a patch which is supposed to handle this owner==group > > scenario better. > > > > In short, Cygwin will try to handle POSIX user and group permissions > > separately, even if owner == group. This is basically a fake as far > > as the actual permissions of the account are concerned, but it allows > > applications still to chmod to different user and group perms. It > > just *looks* different in the end. > > > > The only restriction of this is that the POSIX user permissions are > > always changed so that the user perms are >= the group perms in this > > situation. So this: > > > > chmod 460 foo > > > > will be internally twisted into > > > > chmod 660 foo > > > > > > I uploaded new developer snapshots to https://cygwin.com/snapshots/ > > and I'm just uploading a 2.0.0-0.5 test release with this change. > > I tested the new test release (rm -rfd the cygwin installation and > re-installed from scratch just to be sure), my original testcase with quilt > and mutt works, BUT now when I run make install inside mutt source it > complains that /usr/bin/install cannot change permissions on the destination > executables. Hmm, ok. Off the top of my head I don't understand this. > can post an easily reproducable error. Because running the same command > myself gives no error whatsoever. I'll try to come up with a better report. That would be nice. A good start would be to know what permission mask install is trying to set the destination to. Maybe that sheds some light. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpo5ttAptYY5.pgp Description: PGP signature
"R" help leaves out lines of text
I am ramping up on the R statistical analysis environment. I find that the help leaves out entire lines of text. The pager is /usr/lib/R/bin/pager. I changed it to /bin/less, but I see the same symptom. The problem shows up both in xterm and mintty. The computer is in a locked down environment, so a straight update of cygwin packages is not an option. From the R forum, the problem might be due to improper handling of line endings by the R port to cygwin. Is there anything further I can try to circumvent the problem? My version info is: 64-bit Cygwin DLL version 1.7.28 R version 3.0.1-1 -- 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 2.0.0-5
I am unable to start Cywin/X X-server 1.17.1 with this version. Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for the time being. Other than updating to 2.0.0.5, I also installed the April 2015 "Patch Tuesday" updates from Microsoft. I don't know if the two are related. Windows 7 Home Premium, 64-bit Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= edi=0028C790 ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0028C608 77C50F8A (, 612D2648, , 612D67B0) 0028C738 610CDA1F (43FF, , , 80012428) 0028C7B8 61047198 (, 72483F24, 75604227, 0254) 0028C7F8 610F629D (0001, , , 75623912) -- Jim Reisert AD1C, , http://www.ad1c.us cygcheck.out Description: Binary data -- 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] Updated: vim-7.4.692-1
On Thu, 2015-04-16 at 12:22 +0200, Frank Fesevur wrote: > Is it by design that vim now requires tcsh? > > tcsh(6.18.01-6) > An enhanced version of csh, the C shell > Required by: vim-common I hadn't noticed this, but now that you mention it, this dependency is for the $VIMRUNTIME/tools/vim132 script. -- 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: [TESTERS needed] New POSIX permission handling
Hi, Corinna Vinschen-2 wrote > On Apr 16 03:20, Ismail Donmez wrote: >> Corinna Vinschen-2 wrote >> > I just applied a patch which is supposed to handle this owner==group >> > scenario better. >> > >> > In short, Cygwin will try to handle POSIX user and group permissions >> > separately, even if owner == group. This is basically a fake as far >> > as the actual permissions of the account are concerned, but it allows >> > applications still to chmod to different user and group perms. It >> > just *looks* different in the end. >> > >> > The only restriction of this is that the POSIX user permissions are >> > always changed so that the user perms are >= the group perms in this >> > situation. So this: >> > >> > chmod 460 foo >> > >> > will be internally twisted into >> > >> > chmod 660 foo >> > >> > >> > I uploaded new developer snapshots to https://cygwin.com/snapshots/ >> > and I'm just uploading a 2.0.0-0.5 test release with this change. >> >> I tested the new test release (rm -rfd the cygwin installation and >> re-installed from scratch just to be sure), my original testcase with >> quilt >> and mutt works, BUT now when I run make install inside mutt source it >> complains that /usr/bin/install cannot change permissions on the >> destination >> executables. > > Hmm, ok. Off the top of my head I don't understand this. > >> can post an easily reproducable error. Because running the same command >> myself gives no error whatsoever. I'll try to come up with a better >> report. > > That would be nice. A good start would be to know what permission mask > install is trying to set the destination to. Maybe that sheds some light. So I am trying to configure and install mutt, and the first error I see is at the end of configure: configure: creating ./config.status chmod: changing permissions of './config.status': Permission denied configure: error: write failure creating ./config.status Well, looks like its right: [~/src/mutt]> chmod +x config.status chmod: changing permissions of ‘config.status’: Permission denied [~/src/mutt]> uname -a CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin [~/src/mutt]> getfacl . # file: . # owner: ismail # group: ismail user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:r-x other:r-x default:user::rwx default:group::r-x default:group:SYSTEM:rwx default:group:Administrators:rwx default:mask:r-x default:other:r-x [~/src/mutt]> getfacl config.status # file: config.status # owner: ismail # group: ismail user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:r-x other:r-x Any ideas? :) Thank you. -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117621.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-5
On Apr 16 08:17, Jim Reisert AD1C wrote: > I am unable to start Cywin/X X-server 1.17.1 with this version. > Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for > the time being. > > Other than updating to 2.0.0.5, I also installed the April 2015 "Patch > Tuesday" updates from Microsoft. I don't know if the two are related. > Windows 7 Home Premium, 64-bit > > Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A > eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= edi=0028C790 > ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, thread > main > cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B > Stack trace: > Frame Function Args > 0028C608 77C50F8A (, 612D2648, , 612D67B0) > 0028C738 610CDA1F (43FF, , , 80012428) > 0028C7B8 61047198 (, 72483F24, 75604227, 0254) > 0028C7F8 610F629D (0001, , , 75623912) Ohhh...kay. This looks like a check for equality of two SIDs, the owner SID and the group SID of a file, crashing while being called from fchown. This test didn't exist up to 2.0.0-0.4 because it was addded to handle the owner == group case. But then again, this would mean that with older versions the group SID of a file is not set. Or changed, fwiw. This might happen if either one of these SIDs is invalid or NULL, which in turn may occur if the owner or group SID can't be found in the account DB. The question is then, is your /etc/passwd or /etc/group file broken, and/or are you using the "files" only method in /etc/nsswitch.conf? I could add an extra check which refuses to change permissions if the account's SID can't be found, but since this occurs very deep in the call stack, the error message might be pretty vapid. Alternatively I just let this slip through and you might wonder why the group hasn't changed in this case. Btw., it would be nice to know why XWin tries to chown a file. Jon? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpXM95L_gqC6.pgp Description: PGP signature
Re: [TESTERS needed] New POSIX permission handling
On Apr 16 09:09, Ismail Donmez wrote: > Hi, > > [...] > So I am trying to configure and install mutt, and the first error I see is > at the end of configure: > > configure: creating ./config.status > chmod: changing permissions of './config.status': Permission denied > configure: error: write failure creating ./config.status > > Well, looks like its right: > > [~/src/mutt]> chmod +x config.status > chmod: changing permissions of ‘config.status’: Permission denied > > [~/src/mutt]> uname -a > CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin > > [~/src/mutt]> getfacl . > # file: . > # owner: ismail > # group: ismail > user::rwx > group::r-x > group:SYSTEM:rwx > group:Administrators:rwx > mask:r-x > other:r-x > default:user::rwx > default:group::r-x > default:group:SYSTEM:rwx > default:group:Administrators:rwx > default:mask:r-x > default:other:r-x > > [~/src/mutt]> getfacl config.status > # file: config.status > # owner: ismail > # group: ismail > user::rwx > group::r-x > group:SYSTEM:rwx > group:Administrators:rwx > mask:r-x > other:r-x > > Any ideas? :) Not yet. Can you add the output of icacls for both? For easier copy/pasting, just pipe the icacls output through `cat' for the time being. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpLmkhsCiOGf.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-5
> This might happen if either one of these SIDs is invalid or NULL, which > in turn may occur if the owner or group SID can't be found in the > account DB. > > The question is then, is your /etc/passwd or /etc/groups file broken, > and/or are you using the "files" only method in /etc/nsswitch.conf? I don't know how to tell if those files are broken. /etc/nsswitch.conf has only comments. Interestingly, this problem did not occur at work, Windows 7 Enterprise, 64-bit. Perhaps one of passwd/group is broken at home, but not at work? Is there a way to re-create either /etc/passwd and/or /etc/groups as if I were installing Cygwin from scratch (but not actually doing that)? The install was done before the ACL changes, so I don't know if either file was (or needs to be) "transformed". - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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 2.0.0-5
On Apr 16 10:28, Jim Reisert AD1C wrote: > > This might happen if either one of these SIDs is invalid or NULL, which > > in turn may occur if the owner or group SID can't be found in the > > account DB. > > > > The question is then, is your /etc/passwd or /etc/groups file broken, > > and/or are you using the "files" only method in /etc/nsswitch.conf? > > I don't know how to tell if those files are broken. > /etc/nsswitch.conf has only comments. > > Interestingly, this problem did not occur at work, Windows 7 > Enterprise, 64-bit. Perhaps one of passwd/group is broken at home, > but not at work? Possibly. It might be interesting to check the files. Don't delete them, they may come in handy for forensics. If you don't mind and they don;t contain anything too private, you might even just copy them here. > Is there a way to re-create either /etc/passwd and/or /etc/groups as > if I were installing Cygwin from scratch (but not actually doing > that)? I would suggest not to use passwd and group files anymore, unless you're in a situation with no connection to the account DB (e.g. AD member machine without connection to the DC). Otherwise, if you're feeling more comfortable with passwd and group files, you can easily recreate them with mkpasswd/mkgroup. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKf_GTLIIoD.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-5
On Apr 16 18:21, Corinna Vinschen wrote: > On Apr 16 08:17, Jim Reisert AD1C wrote: > > I am unable to start Cywin/X X-server 1.17.1 with this version. > > Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for > > the time being. > > > > Other than updating to 2.0.0.5, I also installed the April 2015 "Patch > > Tuesday" updates from Microsoft. I don't know if the two are related. > > Windows 7 Home Premium, 64-bit > > > > Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A > > eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= > > edi=0028C790 > > ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, thread > > main > > cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B > > Stack trace: > > Frame Function Args > > 0028C608 77C50F8A (, 612D2648, , 612D67B0) > > 0028C738 610CDA1F (43FF, , , 80012428) On second thought, if I can trust the args output, that would be an fchmod(0,0). If there's no uid or gid 0, which there isn't unless you explicitely created them in the passwd/group files, the uid and gid have no SID connected to. This may be the culprit here. > I could add an extra check which refuses to change permissions if > the account's SID can't be found, but since this occurs very deep > in the call stack, the error message might be pretty vapid. > > Alternatively I just let this slip through and you might wonder > why the group hasn't changed in this case. I added a change to this effect, but it occuurs to me that this may be really just a missing test if the uid and gid values are backed by a real Windows account. It seems better to return EPERM here. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqH0qnjR5gk.pgp Description: PGP signature
Re: [TESTERS needed] New POSIX permission handling
Corinna Vinschen-2 wrote > On Apr 16 09:09, Ismail Donmez wrote: >> Hi, >> >> [...] >> So I am trying to configure and install mutt, and the first error I see >> is >> at the end of configure: >> >> configure: creating ./config.status >> chmod: changing permissions of './config.status': Permission denied >> configure: error: write failure creating ./config.status >> >> Well, looks like its right: >> >> [~/src/mutt]> chmod +x config.status >> chmod: changing permissions of ‘config.status’: Permission denied >> >> [~/src/mutt]> uname -a >> CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin >> >> [~/src/mutt]> getfacl . >> # file: . >> # owner: ismail >> # group: ismail >> user::rwx >> group::r-x >> group:SYSTEM:rwx >> group:Administrators:rwx >> mask:r-x >> other:r-x >> default:user::rwx >> default:group::r-x >> default:group:SYSTEM:rwx >> default:group:Administrators:rwx >> default:mask:r-x >> default:other:r-x >> >> [~/src/mutt]> getfacl config.status >> # file: config.status >> # owner: ismail >> # group: ismail >> user::rwx >> group::r-x >> group:SYSTEM:rwx >> group:Administrators:rwx >> mask:r-x >> other:r-x >> >> Any ideas? :) > > Not yet. Can you add the output of icacls for both? For easier > copy/pasting, just pipe the icacls output through `cat' for the time > being. [~/src/mutt]> icacls config.status config.status NULL SID:(DENY)(Rc,S,REA,X,DC) UX31A\ismail:(F) UX31A\ismail:(RX) NT AUTHORITY\SYSTEM:(RX,W,DC) BUILTIN\Administrators:(RX,W,DC) Everyone:(RX) Successfully processed 1 files; Failed processing 0 files [~/src/mutt]> icacls . . NULL SID:(DENY)(Rc,S,REA,X,DC) UX31A\ismail:(F) UX31A\ismail:(RX) NT AUTHORITY\SYSTEM:(RX,W,DC) BUILTIN\Administrators:(RX,W,DC) Everyone:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC) BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117627.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-5
On Thu, Apr 16, 2015 at 10:17 AM, Jim Reisert AD1C wrote: > I am unable to start Cywin/X X-server 1.17.1 with this version. > Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for > the time being. > > Other than updating to 2.0.0.5, I also installed the April 2015 "Patch > Tuesday" updates from Microsoft. I don't know if the two are related. > Windows 7 Home Premium, 64-bit > > Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A > eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= edi=0028C790 > ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, thread > main > cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B > Stack trace: > Frame Function Args > 0028C608 77C50F8A (, 612D2648, , 612D67B0) > 0028C738 610CDA1F (43FF, , , 80012428) > 0028C7B8 61047198 (, 72483F24, 75604227, 0254) > 0028C7F8 610F629D (0001, , , 75623912) > > -- > Jim Reisert AD1C, , http://www.ad1c.us I've actually had problem building Cygwin (1.7.35 or 2.x source) on Cygwin 2.x using Windows. The make errors out with a "permissions denied" when setting permissions (chmod +x) on config.status in /etc. I was able to produce it on three different, freshly built copies of Windows (no BLODA at all). Only had Cygwin plus the build essentials (gcc, ming, xmlto, diffutils, textinfo, cocom) installed. Only tried with 32-bit. The super wacky thing is that if I rearrange the unrelated contents of the make file that fuels the whole process, the problem goes away. If I "downgrade" the core back to 1.7.35, the problem goes away. It almost seems like there might an uninitialized memory issue in the code path executed in chmod(). I apologize for the lack of debugging on my part, but I just wanted to throw this out there in case a) it could be related to this issue or b) anyone else has seen this. That said, I'm making progress in debugging my "Unknown Group" issue described in another chain; hope to report out on that this weekend when I have a little more time to play. -- 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: "R" help leaves out lines of text
On 4/16/2015 4:22 PM, paul wrote: I am ramping up on the R statistical analysis environment. I find that the help leaves out entire lines of text. The pager is /usr/lib/R/bin/pager. I changed it to /bin/less, but I see the same symptom. The problem shows up both in xterm and mintty. The computer is in a locked down environment, so a straight update of cygwin packages is not an option. From the R forum, the problem might be due to improper handling of line endings by the R port to cygwin. Is there anything further I can try to circumvent the problem? My version info is: 64-bit Cygwin DLL version 1.7.28 R version 3.0.1-1 Are the input files Unix style or DOS style ? Can you give an example to replicate your finding ? I can that test than if the last R-3.1.3-1 package behaves correctly or not. R-3.0.1-1 package is almost 2 years old. 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: Cannot change console mode during usage of expect
On 4/16/2015 8:20 AM, Keith Proctor wrote: Marco Atzeri gmail.com> writes: Thanks Marco but I'm not sure which direction your asking me to go. Should I: No directions. I was giving just a link on similar discussed ones that could give you an hint and explanation why your trial does not work. 1) Install Console2 ( I didn't find it in the Cygwin installer) It is not a cygwin program. 2) Build the tool mentioned in the link and prepend build/console.exe to all my DOS commands. It is a possibility if you want to try the interaction between your not-cygwin aware program and the cygwin version of expect. I never used it. The second seams like a bit of a hack and I would have to do the equivalent of #define for Windows versus Mac in my code. It is also a hack to use cygwin expect with a not cygwin program. Maybe I missed missed another option? Inquiring minds Inquire, :) Keith 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-5
On 2015-04-16 à 18:43, Corinna Vinschen wrote: > On Apr 16 18:21, Corinna Vinschen wrote: >> On Apr 16 08:17, Jim Reisert AD1C wrote: >>> I am unable to start Cywin/X X-server 1.17.1 with this version. >>> Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for >>> the time being. >>> >>> Other than updating to 2.0.0.5, I also installed the April 2015 "Patch >>> Tuesday" updates from Microsoft. I don't know if the two are related. >>> Windows 7 Home Premium, 64-bit >>> >>> Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A >>> eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= >>> edi=0028C790 >>> ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, thread >>> main >>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B >>> Stack trace: >>> Frame Function Args >>> 0028C608 77C50F8A (, 612D2648, , 612D67B0) >>> 0028C738 610CDA1F (43FF, , , 80012428) > > On second thought, if I can trust the args output, that would be an > fchmod(0,0). If there's no uid or gid 0, which there isn't unless you > explicitely created them in the passwd/group files, the uid and gid have > no SID connected to. This may be the culprit here. > >> I could add an extra check which refuses to change permissions if >> the account's SID can't be found, but since this occurs very deep >> in the call stack, the error message might be pretty vapid. >> >> Alternatively I just let this slip through and you might wonder >> why the group hasn't changed in this case. > > I added a change to this effect, but it occuurs to me that this may > be really just a missing test if the uid and gid values are backed by > a real Windows account. It seems better to return EPERM here. > I applied the patch indicated (see in https://cygwin.com/ml/cygwin-cvs/2015-q2/msg00033.html) and X11 now works back again. Thank you 1000 times. Regards, Denis Excoffier. -- 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 2.0.0-5
> It might be interesting to check the files. Don't delete > them, they may come in handy for forensics. If you don't mind and they > don;t contain anything too private, you might even just copy them here. I can post the good and "bad" ones tomorrow. -- Jim Reisert AD1C, , http://www.ad1c.us -- 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 2.0.0-5
> It might be interesting to check the files. Don't delete > them, they may come in handy for forensics. If you don't mind and they > don;t contain anything too private, you might even just copy them here. I can post the good and "bad" ones tomorrow. Similar problem today. Previous 2.0.0-0.x worked OK, and going back to 1.7.35-1 works OK. No admin rights. No passwd or group files. nsswitch.conf all commented out. Some excerpts follow. $ startxwin & [1] 2084 $ Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.17.1.0 OS: CYGWIN_NT-6.1 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.17.1-2 built 2015-02-23 XWin was started with the following command line: /usr/bin/XWin :2 -multiwindow -auth /home//.serverauth.2084 xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error [1]+ Exit 1 startxwin In /var/log/setup.log.full: Updating package information in /var/cache/rebase/rebase_pkg. from /etc/setup/cygwin.lst.gz... /bin/rebaselst: 173: /bin/rebaselst: cannot create /var/cache/rebase/rebase_pkg: Permission denied /bin/rebaselst: 178: /bin/rebaselst: cannot create /var/cache/rebase/rebase_pkg: Permission denied Updating rebase information for installed dynamic objects in /var/cache/rebase/rebase_lst. /bin/rebaselst: 211: /bin/rebaselst: cannot create /var/cache/rebase/rebase_lst: Permission denied Updating rebase information for installed executables in /var/cache/rebase/rebase_exe. /bin/rebaselst: 197: /bin/rebaselst: cannot create /var/cache/rebase/rebase_exe: Permission denied removing /var/cache/rebase/rebase_dyn creating empty /var/cache/rebase/rebase_dyn Looking for dynamic language modules/libraries in: /usr/lib/R/site-library /usr/lib/perl5/site_perl Updating rebase information for dynamic language modules/libraries /var/cache/rebase/rebase_dyn. Updating rebase information for user-defined dynamic objects /var/cache/rebase/rebase_user. Updating rebase information for user-defined executables /var/cache/rebase/rebase_user_exe. Rebasing with list /var/cache/rebase/rebase_all, built from /var/cache/rebase/rebase_lst /var/cache/rebase/rebase_dyn /var/cache/rebase/rebase_user. /usr/i686-pc-cygwin/sys-root/usr/bin/cygatomic-1.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygformw-10.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cyggcc_s-1.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cyggfortran-3.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cyggomp-1.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cyghistory7.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygmenuw-10.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygncurses++w-10.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygncursesw-10.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygpanelw-10.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygquadmath-0.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygreadline7.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygssp-0.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygstdc++-6.dll: skipped because wrong machine type. /usr/i686-pc-cygwin/sys-root/usr/bin/cygticw-10.dll: skipped because wrong machine type. In /var/log/setup.log: 2015/04/16 16:26:14 Could not open Service control manager 2015/04/16 16:26:16 source: network install 2015/04/16 16:26:17 root: C:\cygwin64 user 2015/04/16 16:26:18 Selected local directory: C:\Users\\Downloads\cygwin 2015/04/16 16:26:18 net: Proxy 2015/04/16 16:26:19 site: ftp://ftp.gtlib.gatech.edu/pub/cygwin/ 2015/04/16 16:27:06 Running preremove script for cygwin 2015/04/16 16:27:06 Uninstalling cygwin 2015/04/16 16:27:06 Extracting from file://C:\Users\\Downloads\cygwin/ftp%3a%2f%2fftp.gtlib.gatech.edu%2fpub%2fcygwin %2f/x86_64/release/cygwin/cygwin-2.0.0-0.5.tar.xz 2015/04/16 16:27:06 io_stream_cygfile: fopen(/usr/bin/cygwin1.dll) failed 13 Permission denied In /var/log/xwin/XWin.3.log: [ 3570.628] winMultiWindowXMsgProcErrorHandler - ERROR: BadMatch (invalid parameter attributes) [ 4232.478] winWindowProc - WM_DISPLAYCHANGE - new width: 1680 new height: 1050 new bpp: 32 [ 4232.509] winAllocateFBShadowGDI - Creating DIB with width: 2730 height: 1680 depth: 32 [ 9578.586] winDeinitMultiWindowWM - Noting shutdown in progress [ 9578.586] winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. [ 9578.586] winClipboardProc - XDestroyWindow succeeded. [ 9578.586] winClipboardIOErrorHandler! [ 9578.601]
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-5
> I would suggest not to use passwd and group files anymore, unless you're > in a situation with no connection to the account DB (e.g. AD member > machine without connection to the DC). If you mean remove the /etc/passwd and /etc/group files, that didn't work for me. Xwin crashed the same way. "mkpasswd" isn't an option for me, everyone in the company will be added to the password file (I tried it). Non-starter! - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: Cannot change console mode during usage of expect
Marco Atzeri gmail.com> writes: OK, I've done both this morning and neither work. I've figured out a bit more, In general, expect is working with non password tests. So I have turned off anything that would test a password and I'm running my automation now. Again to be clear... fmsadmin works in the Cygwin window when typing in commands by hand. It is the interaction with expect that is the issue. Now we know it's specifically password handling. Keith P.S. Last comment is just in passing and for my understanding. Why install Cygwin on Windows if you can't interact with the local Windows executables. If your not suppose to run any of the local Windows applications then why not just install Linux or some other flavor of unix. I believe the ONLY interesting part of Cygwin is allowing the interaction between Windows and Unix and the effort fails if integration is not allowed and extended. It's one thing to be a purest but I believe the over 2000 people who downloaded winpty would agree with me. BTW it's OK that you disagree. This is just my opinion and I'm trying to use Cygwin to save a lot of effort and help your effort along the way. So far, except for this one thing it has helped 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
Cygwin emacs -- apparent version config issue with 24.4 to 24.5
I just did a new install of Cygwin and its emacs using the windows 64 intaller, and when I ran emacs from the Cygwin command line I got these errors: $ emacs Warning: arch-dependent data dir `/usr/libexec/emacs/24.5/x86_64-unknown-cygwin/': No such file or directory Warning: arch-independent data dir `/usr/share/emacs/24.5/etc/': No such file or directory Warning: Lisp directory `/usr/share/emacs/24.5/lisp': No such file or directory Error: charsets directory not found: /usr/share/emacs/24.5/etc/charsets Emacs will not function correctly without the character map files. Please check your installation! After I did $ mv /usr/share/emacs/24.4/ /usr/share/emacs/24.5/ then emacs worked ok. Seems like perhaps the path didn't get updated somewhere from 24.4 to 24.5? This is on Windows 7 64 bit, 'uname -a' prints "CYGWIN_NT-6.1 Tregastel 1.7.35(0.287/5/3) 2015-03-04 12:09 x86_64 Cygwin" -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin emacs -- apparent version config issue with 24.4 to 24.5
On 4/16/2015 7:04 PM, Joe Morris wrote: I just did a new install of Cygwin and its emacs using the windows 64 intaller, and when I ran emacs from the Cygwin command line I got these errors: $ emacs Warning: arch-dependent data dir `/usr/libexec/emacs/24.5/x86_64-unknown-cygwin/': No such file or directory Warning: arch-independent data dir `/usr/share/emacs/24.5/etc/': No such file or directory Warning: Lisp directory `/usr/share/emacs/24.5/lisp': No such file or directory Error: charsets directory not found: /usr/share/emacs/24.5/etc/charsets Emacs will not function correctly without the character map files. Please check your installation! After I did $ mv /usr/share/emacs/24.4/ /usr/share/emacs/24.5/ then emacs worked ok. Seems like perhaps the path didn't get updated somewhere from 24.4 to 24.5? I think something must have gone wrong with your installation. The paths are correct in the tarball, as you can see at https://cygwin.com/packages/x86_64/emacs/emacs-24.5-1 I suggest you reinstall emacs. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: php-5.6.8-1
The following packages have been updated in the Cygwin distribution: * php-5.6.8-1 * apache2-mod_php5-5.6.8-1 * php-bcmath-5.6.8-1 * php-bz2-5.6.8-1 * php-calendar-5.6.8-1 * php-ctype-5.6.8-1 * php-curl-5.6.8-1 * php-dba-5.6.8-1 * php-devel-5.6.8-1 * php-enchant-5.6.8-1 * php-exif-5.6.8-1 * php-fileinfo-5.6.8-1 * php-ftp-5.6.8-1 * php-gd-5.6.8-1 * php-gettext-5.6.8-1 * php-gmp-5.6.8-1 * php-iconv-5.6.8-1 * php-imap-5.6.8-1 * php-intl-5.6.8-1 * php-ldap-5.6.8-1 * php-mbstring-5.6.8-1 * php-mcrypt-5.6.8-1 * php-mssql-5.6.8-1 * php-mysql-5.6.8-1 * php-mysqli-5.6.8-1 * php-odbc-5.6.8-1 * php-opcache-5.6.8-1 * php-pdo_dblib-5.6.8-1 * php-pdo_mysql-5.6.8-1 * php-pdo_odbc-5.6.8-1 * php-pdo_sqlite-5.6.8-1 * php-pgsql-5.6.8-1 * php-phar-5.6.8-1 * php-posix-5.6.8-1 * php-pspell-5.6.8-1 * php-recode-5.6.8-1 * php-shmop-5.6.8-1 * php-simplexml-5.6.8-1 * php-soap-5.6.8-1 * php-sockets-5.6.8-1 * php-sqlite3-5.6.8-1 * php-sybase_ct-5.6.8-1 * php-sysvmsg-5.6.8-1 * php-sysvsem-5.6.8-1 * php-sysvshm-5.6.8-1 * php-tidy-5.6.8-1 * php-tokenizer-5.6.8-1 * php-wddx-5.6.8-1 * php-xmlreader-5.6.8-1 * php-xmlrpc-5.6.8-1 * php-xmlwriter-5.6.8-1 * php-xsl-5.6.8-1 * php-zip-5.6.8-1 * php-zlib-5.6.8-1 PHP (recursive acronym for 'PHP: Hypertext Preprocessor') is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. This is an update to the latest upstream stable release, which includes fixes for CVE-2015-1351, CVE-2015-1352 and CVE-2015-2783: http://php.net/ChangeLog-5.php#5.6.8 -- 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
[ANNOUNCEMENT] Updated: lilypond-2.19.18-2
Versions 2.19.18-2 of lilypond lilypond-doc for cygwin are now available: CYGWIN CHANGES Both architecture are now available using latest development (but more cygwin 32bit robust) release The HTML documentions was replaced with PDF one. The HTML version is available online at: http://www.lilypond.org/manuals.html CHANGES Last upstream release http://www.lilypond.org/old-news.html DESCRIPTION LilyPond is a music engraving program, devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. LilyPond is free software and part of the GNU Project. HOMEPAGE http://www.lilypond.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
