Re: slow startup after upgrade
On Feb 18 22:01, Roger Orr wrote: and also it no longer opens 14 TCP/IP sessions to various ldap servers around the planet (!) Uh, that might be the result of the other changes which don't open an LDAP connection to fetch group info. 14 connections probably means, you're in 14 groups in other domains than your login domain. There weren't any other LDAP requests logged (I was testing with the first patch 1.7.35-0.1 that reduced the time for running echo.exe from 120s to 4.5s) so I don't think it was related to another query. When you start a Cygwin process from a non-Cygwin process, Cygwin will try to generate passwd entries for your account, as well as group entries for all groups in your token. For the group entries it only needs LDAP calls if a group is in another domain than your login domain, and the request only goes to your own DC. This entire set of LDAP calls are supposed to share the same LDAP connection. I don't know what Windows is doing under the hood, but in theory there should only be a single socket open for this. I may be able to test this out again tomorrow and get the call stacks of the connect calss. Incidentally how can you tell the patch level of cygwin1.dll -- the DLL versions all seem to be 1007.35.0.0 ? The versioning system isn't able to handle subversions. As marco wrote, uname -a (the build date or uname -v) can be used to distinguish the versions. I'm planning to change that at one point. It shouldn't be too hard to add the subversion to the DLL properties. uname -r is a problem, though, since the info already takes 18 of 19 allowed characters... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSPVzOUvTtX.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: make-4.1-1
BLUF: either the new make package needs cygltdl-7 as one of its dependencies, or Guile does, so that setup.exe can Do The Right Thing. I updated to make-4.1-1 and the executable immediately broke: $ make --version /usr/bin/make.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory Poked the current cygcheck at it: $ cygcheck /usr/bin/make.exe C:\cygwin\bin\make.exe C:\cygwin\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\cygwin\bin\cygguile-17.dll C:\cygwin\bin\cygcrypt-0.dll C:\cygwin\bin\cyggmp-3.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cygintl-8.dll C:\cygwin\bin\cygiconv-2.dll cygcheck: track_down: could not find cygltdl-7.dll I brought up setup.exe, found cygltdl-7 (which was not previously installed), installed 2.4.6-1, and now all is well: $ make --version GNU Make 4.1 Built for i686-pc-cygwin Copyright (C) 1988-2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ cygcheck /usr/bin/make.exe C:\cygwin\bin\make.exe C:\cygwin\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\cygwin\bin\cygguile-17.dll C:\cygwin\bin\cygcrypt-0.dll C:\cygwin\bin\cyggmp-3.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cygintl-8.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygltdl-7.dll The indentation would seem to indicate that cygltdl-7 is needed by cygguile-17 and not by make.exe directly. This fits with what little I know about Guile, however I did not have time to pursue the problem any further, as I needed to go back to my original task (the one for which I was running make). So if/when the cygguile package is rebuilt next time, this may all solve itself; for now this message is just an FYI for future google users wondering why setup.exe isn't magically doing a transitive closure. :-) Thanks to everyone involved! -Ti -- Problem reports:
Re: ffcall
On 02/19/2015 06:19 PM, Ken Brown wrote: On 2/19/2015 11:46 AM, Ken Brown wrote: On 2/19/2015 10:43 AM, Reini Urban wrote: On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. Yes, it seems to be. So far I've built and am testing a version with no non-default modules, and with the default regexp module disabled. I had to do the latter because of the gcc problem I encountered while trying to compile regexi.c: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. Huh, that's a good one! Something for Kai. I tried to test my build by using it to build xindy. It appeared to work, as far as it went, but it didn't go too far because xindy requires the regexp module. So I think I'm stuck until the gcc problem is resolved. I don't whether it's worth uploading my crippled clisp at this point to let it get some testing. Reini, is clisp without regexp at all useful? Usually clisp users don't need the regexp module, they usually have better matchers. But xindy needs it, so... :) And the deal with the latest clisp 2.49 was that modules can be dynaloaded. If the gnulib steps would work. I never did for me. And I fixed most of the other module compilation problems before.
Re: Is db_home: windows exactly equivalent to db_home: /%H?
Greetings, Warren Young! I was just scanning through the ntsec page, and saw that the “windows” scheme does the same thing as /%H. I tried it, and it seems to be true. Is there some minor difference? Yes. You can't use windows/someotherdir. -- WBR, Andrey Repin (anrdae...@yandex.ru) 19.02.2015, 12:24 Sorry for my terrible english...
RE: Very slow Cygwin startup on Windows 7
Hi Corinna, Can you please try this test version without cygserver, and with the passwd and group settings in /etc/nsswitch.conf set to passwd: db group: db It would be very interesting to know if this improves the situation for you. Just did it for 1.7.35-0.2 - I haven't seen 0.3 turn up at a mirror site yet. It's only just uploaded so it might take another while, depending on your mirrors. According to Roger's results in https://cygwin.com/ml/cygwin/2015-02/msg00511.html and https://cygwin.com/ml/cygwin/2015-02/msg00543.html, the real problem hadn't been fixed in the 0.2 test release, so you might give 0.3 another chance. BTW - I did try ADInsight, but it didn't show me anything (maybe because this is a 64 bit windows?) Anyway, I ran it with 0.3 and nsswitch = db and the result is??? 1.68-1.72 seconds With nsswitch = files db it was 1.43-1.45 seconds. With nsswitch = files it was 0.13-0.14 seconds (It seems basically the same as 0.2) Regards Dennis
RE: slow startup after upgrade
I've tested again with the first patched cygwin1.dll: CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35(0.286/5/3) 2015-02-16 13:18 i686 Cygwin I can confirm the connections are occurring within the ldap_search_s call - here is one of the call stacks: 00ebc31c 76e5c451 0278 0045dd28 0010 WS2_32!connect (FPO: [Non-Fpo]) 00ebc87c 76e5cad5 00462758 00ebc8a4 0185 wldap32!LdapParallelConnect+0x2e3 (FPO: [Non-Fpo]) 00ebca70 76e597a2 00462758 004568a0 wldap32!ConnectToSRVrecs+0x21b (FPO: [Non-Fpo]) 00ebcac8 76e59688 00462758 wldap32!OpenLdapServer+0x612 (FPO: [Non-Fpo]) 00ebcae8 76e62ca9 00462758 wldap32!LdapConnect+0x2cf (FPO: [Non-Fpo]) 00ebcb58 76e63021 00432670 76e8e158 wldap32!LdapChaseReferral+0xb27 (FPO: [Non-Fpo]) 00ebcb98 76e62e1d 0042ca00 004328b0 00432670 wldap32!HandleReferral+0x7ac (FPO: [Non-Fpo]) 00ebcbd4 76e553e2 0042cab8 00ebcc04 wldap32!HandleReferrals+0x151 (FPO: [Non-Fpo]) 00ebcc08 76e5b0f8 0042cab8 0005 0001 wldap32!ldap_result_with_error+0x30e (FPO: [Non-Fpo]) 00ebcc3c 76e5e584 0042cce4 80039620 0002 wldap32!ldap_search_ext_sW+0x87 (FPO: [Non-Fpo]) 00ebcc80 76e5e783 0042cce4 80039620 0002 wldap32!ldap_search_stW+0x45 (FPO: [Non-Fpo]) 00ebcca8 610818e2 0042cce4 80039620 0002 wldap32!ldap_search_sW+0x21 (FPO: [Non-Fpo]) I can see this occurring with ldp.exe (from Windows Server 2003 support tools; also works on newer version of windows) and netstat.exe Connection-Connect (default server, default port 389) (1 TCP/IP session to DC1:389) Connection-Bind (enter username and password) (no new sessions) Browse-Search Base Dn - first naming context Filter: ((objectClass=trustedDomain)(name=wibble)) Gets 0 entries, quickly, no extra sessions visible Click 'Options' Select 'Chase Referrals' Click Ok Search again. Gets 0 entries, takes some seconds, and establishes nuermous TCP/IP connections. (1) LDAP_OPT_REFERRALS is on by default (2) The fix added CN=System to the Base Dn - this seems to turn off referrals -- *aside* Sysinternals ADInsight is a 32bit only tool and, in order to work on a 64bit Windows you seem to have to manually inject the DLL ADInsightDll.dll (which is extracted into %TEMP%) into the target (32-bit!) process. Regards, Roger. From: Roger Orr Sent: 18 February 2015 11:26 To: Corinna Vinschen Cc: cygwin@cygwin.com Subject: RE: slow startup after upgrade Hello Corinna, I've just been trying out both the 2015-02-18 10:30:19/44 UTC and 2015-02-17 21:27:23/48 UTC patches. Both are now down to the same timings as with a 'files' entry in /etc/nsswitch.cfg, (and there's no detectable speed difference between them.) The scope restriction in the second query to \System reduces the query time to 1.1 - 1.3 ms (was 4 seconds) and also it no longer opens 14 TCP/IP sessions to various ldap servers around the planet (!) I note that mkpasswd and mkgroup do still open many sessions to the ldap servers, but that may be inevitable. It's not an issue directly, of course, since I'll no longer need to make use of these, but it perhaps might indicate another place where the ldap queries are sub-optimal. Thanks for your rapid response on this issue! Regards, Roger. From: Corinna Vinschen [corinna-cyg...@cygwin.com] Sent: 18 February 2015 11:18 To: cygwin@cygwin.com Cc: Roger Orr Subject: Re: slow startup after upgrade Hi Roger, On Feb 17 22:32, Corinna Vinschen wrote: On Feb 17 19:13, Roger Orr wrote: According to nltest /dclist: Our environment has 6 London based DCs According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP. 6 leaf nodes at the top matching ther 6 DCs 4 leaf nodes under an AUS (Australia) node 3 leaf nodes under a CHI (Chicago) node and a few more similar to this in other regions. When running mkpasswd I see active sessions to all the nodes in the tree on port 389 (ldap) I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what requests are made with 'echo.exe' There are two searches shown: A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*) (1.113ms) B) London DNS:LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND (name=Australian DNS)) (4.426s) I don't know why the second query is being made with the Australian DNS name but I suspect this is the problem. Thanks for doing that! It's really cool to get this info since it seems to point to the culprit. It's not the problem that the Australian DNS is mentioned here. This is perfectly valid. The LDAP query is going to the London DNS DC (apparently, I hope that's right in your case) and the query is for information on a trusted domain. It looks like you have a group from the australian domain in your user token. To compute the gid of the group, cygwin asks *your* DC for a value called posixOffset for *that* trusted domain. The bottom line is,
Re: ffcall
On Feb 18 17:41, Ken Brown wrote: On 2/18/2015 3:08 PM, Corinna Vinschen wrote: On Feb 18 13:28, Yaakov Selkowitz wrote: On Wed, 2015-02-18 at 13:49 -0500, Ken Brown wrote: I've been trying to adopt Reini's packages that have not yet been ported to 64-bit Cygwin and that have some connection to packages I already maintain. The next one on my list is ffcall. I'm guessing this is for clisp? (In Fedora, clisp is the only package which BR: ffcall). Unfortunately, the source has a lot of assembler code in it, so I will almost certainly need help from someone well versed in x86_64 assembly language. And the libffcall project appears to be dead upstream, so I'm not going to get help there. Unless you can find a patch somewhere for Win64 support. I have no idea how hard this will be. The code has been ported to x86_64 Linux, so there's at least a starting point. What is ffcall doing? What functions does it call? I don't know much about it yet. Here's an overview: ffcall - foreign function call libraries This is a collection of four libraries which can be used to build foreign function call interfaces in embedded interpreters. The four packages are: avcall - calling C functions with variable arguments vacall - C functions accepting variable argument prototypes trampoline - closures as first-class C functions callback - closures with variable arguments as first-class C functions (a reentrant combination of vacall and trampoline) All except callback are written in assembler. Dunno about trampoline, but avcall and vacall shouldn't be too hard. It's just juggling around register and stack usage a bit, probably. Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4qa7cqtYU7.pgp Description: PGP signature
Re: [SECURITY] arc 5.21p-1 (UPLOADED)
2015-02-18 04:06 Yaakov Selkowitz yselkow...@cygwin.com: | Jari, | | A directory traversal vulnerability has been found in arc. Please add | the following patches to the arc package ASAP: Uploaded both 5.21p-2 and 5.21q-1 with patches included. Jari
Re: HEADSUP: Packages with obsolete dependencies (pal UPLOADED)
On Feb 19 12:51, jari wrote: On 2015-02-11 03:27, Yaakov Selkowitz wrote: | On Tue, 2015-02-10 at 22:14 -0600, Yaakov Selkowitz wrote: | | I just cleared out a huge number of obsolete and stale packages | | pal ORPHANED (Jari Aalto) Took care of this, Jari I removed the orphaned status from the package. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTaZIRtAv8w.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: pal 0.3.5-2 -- A cal-like calendar with day highlight and support for events
PACKAGE DESCRIPTION === Homepage: http://sourceforge.net/projects/palcal License : GPL Some of pal's main features are: Assign different colors to different types of events; Search events with regular expressions; Includes calendars for holiday (US, Christian, etc) and historical events; One-time events and a variety of recurring events are supported; Easy-to-use interface for interactively adding events to calendars; Automated deletion of old events; Generation of HTML calendars; Generation of LaTeX calendar suitable for printing. CHANGES SINCE LAST RELEASE == See /usr/share/doc/pal-*/ChangeLog http://palcal.cvs.sourceforge.net/palcal/pal/ChangeLog?revision=HEADview=markup INSTALL OR UPGRADE NOTES Cygwin: compiled with libreadline7 Standard install. CYGWIN INSTALLATION INFORMATION === To install this package, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. You'll find the package listed in the All category. After installation, read the documentation at directories: /usr/share/doc/package-version/* /usr/share/doc/Cygwin/package-version.README If you have questions or comments, please send them to the Cygwin mailing list at cygwin@cygwin.com. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO This message has been sent to cygwin-announce list. If you want to unsubscribe from the 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 More information on unsubscribing can be found: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above 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
Re: Clearing O_NONBLOCK from a pipe may lose data
On Feb 18 22:08, Lasse Collin wrote: (Please Cc me when replying, I'm not subscribed to the list.) Hi! I suspect that there is a bug in Cygwin: 1. Create a pipe with both ends in blocking mode (O_NONBLOCK is not set). 2. The writer sets its end to non-blocking mode. 3. The writer writes to the pipe. 4. The writer restores its end of the pipe to blocking mode before the reader has read anything from the pipe. 5. The writer closes its end of the pipe. 6. The reader reads from the pipe in blocking mode. The last bytes written by the writer never appear at the reader, thus data is silently lost. Omitting the step 4 above makes the problem go away. I can imagine. A few years back, when changing the pipe code to using overlapped IO, we stumbled over a problem in Windows. When closing an overlapped pipe while I/O is still ongoing, Windows simply destroys the pipe buffers without flushing the data to the reader. This is not much of a problem for blocking IO, but it obviously is for non-blocking. The workaround for this behaviour is this: If the pipe is closed, and this is the writing side of a nonblocking pipe, a background thread gets started which keeps the overlapped structure open and continues to wait for IO completion (i.e. the data has been sent to the reader). However, if you switch back to blocking before closing the pipe, the aforementioned mechanism does not kick in. I can look into improving that at one point, but not soon. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2H1gOlZJ_h.pgp Description: PGP signature
Updated: arc 5.21p-2 -- The ARC archive utility
PACKAGE DESCRIPTION === Homepage: http://www.sourceforge.net/projects/arc License : GPL This program is based on the MSDOS ARC program, version 5.21, plus a few enhancements. ARC performs Huffman Squeezing on data. The Huffman Squeeze algorithm was removed from MSDOS ARC after version 5.12. It turns out to be more efficient than Lempel-Ziv style compression when compressing graphic images. Squeeze analysis is always done now, and the best of packing, squeezing, or crunching is used. CHANGES SINCE LAST RELEASE == http://arc.cvs.sourceforge.net/arc/arc/Changelog?revision=HEADview=markup INSTALL OR UPGRADE NOTES Standard install. Cygwin: compiled with security patches from http://pkgs.fedoraproject.org/cgit/arc.git - arc-5.21p-directory-traversel.patch - arc-5.21p-fix-arcdie.patch - arc-5.21p-hdrv1-read-fix.patch CYGWIN INSTALLATION INFORMATION === To install this package, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. You'll find the package listed in the All category. After installation, read the documentation at directories: /usr/share/doc/package-version/* /usr/share/doc/Cygwin/package-version.README If you have questions or comments, please send them to the Cygwin mailing list at cygwin(at)cygwin.com. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO This message has been sent to cygwin-announce list. If you want to unsubscribe from the 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.com(at)cygwin.com More information on unsubscribing can be found: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL.
Re: HEADSUP: Packages with obsolete dependencies
On 02/11/2015 07:56 AM, Achim Gratz wrote: Of the orphaned packages, as said in another thread, I'd make rakudo and parrot obsolete. I can maybe resurrect them after the Perl update if there's still interest in those or maybe a new maintainer shows up. yes, please. parrot is now dead upstream, and rakudo needs now moarvm and jvm dependencies. The planned stable rakudo release is Dec 2015, so there's enough time to get a maintainer. They work mostly on windows.
[ANNOUNCEMENT] Updated: arc 5.21p-2 -- The ARC archive utility
PACKAGE DESCRIPTION === Homepage: http://www.sourceforge.net/projects/arc License : GPL This program is based on the MSDOS ARC program, version 5.21, plus a few enhancements. ARC performs Huffman Squeezing on data. The Huffman Squeeze algorithm was removed from MSDOS ARC after version 5.12. It turns out to be more efficient than Lempel-Ziv style compression when compressing graphic images. Squeeze analysis is always done now, and the best of packing, squeezing, or crunching is used. CHANGES SINCE LAST RELEASE == http://arc.cvs.sourceforge.net/arc/arc/Changelog?revision=HEADview=markup INSTALL OR UPGRADE NOTES Standard install. Cygwin: compiled with security patches from http://pkgs.fedoraproject.org/cgit/arc.git - arc-5.21p-directory-traversel.patch - arc-5.21p-fix-arcdie.patch - arc-5.21p-hdrv1-read-fix.patch CYGWIN INSTALLATION INFORMATION === To install this package, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. You'll find the package listed in the All category. After installation, read the documentation at directories: /usr/share/doc/package-version/* /usr/share/doc/Cygwin/package-version.README If you have questions or comments, please send them to the Cygwin mailing list at cygwin(at)cygwin.com. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO This message has been sent to cygwin-announce list. If you want to unsubscribe from the 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.com(at)cygwin.com More information on unsubscribing can be found: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above 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
Re: Very slow Cygwin startup on Windows 7
On Feb 19 09:49, Dennis Hagarty (dehagart) wrote: Hi Corinna, Can you please try this test version without cygserver, and with the passwd and group settings in /etc/nsswitch.conf set to passwd: db group: db It would be very interesting to know if this improves the situation for you. Just did it for 1.7.35-0.2 - I haven't seen 0.3 turn up at a mirror site yet. It's only just uploaded so it might take another while, depending on your mirrors. According to Roger's results in https://cygwin.com/ml/cygwin/2015-02/msg00511.html and https://cygwin.com/ml/cygwin/2015-02/msg00543.html, the real problem hadn't been fixed in the 0.2 test release, so you might give 0.3 another chance. BTW - I did try ADInsight, but it didn't show me anything (maybe because this is a 64 bit windows?) Anyway, I ran it with 0.3 and nsswitch = db and the result is??? 1.68-1.72 seconds Hmm. No offense, but are you sure you ran this with 0.3? With nsswitch = files db it was 1.43-1.45 seconds. With nsswitch = files it was 0.13-0.14 seconds (It seems basically the same as 0.2) It would be pretty helpful to get an idea what's so slow in your case. Either you get ADInsight working, or... is it ok if I send you a link to a debug-augmented DLL via PM? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprSiIWcW6Cg.pgp Description: PGP signature
plain Text
Hi All, I am just confirming that this email goes through. Stephen Grant Brown -- 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: HEADSUP: Packages with obsolete dependencies (pal UPLOADED)
On 2015-02-11 03:27, Yaakov Selkowitz wrote: | On Tue, 2015-02-10 at 22:14 -0600, Yaakov Selkowitz wrote: | | I just cleared out a huge number of obsolete and stale packages | | pal ORPHANED (Jari Aalto) Took care of this, Jari
Updated: pal 0.3.5-2 -- A cal-like calendar with day highlight and support for events
PACKAGE DESCRIPTION === Homepage: http://sourceforge.net/projects/palcal License : GPL Some of pal's main features are: Assign different colors to different types of events; Search events with regular expressions; Includes calendars for holiday (US, Christian, etc) and historical events; One-time events and a variety of recurring events are supported; Easy-to-use interface for interactively adding events to calendars; Automated deletion of old events; Generation of HTML calendars; Generation of LaTeX calendar suitable for printing. CHANGES SINCE LAST RELEASE == See /usr/share/doc/pal-*/ChangeLog http://palcal.cvs.sourceforge.net/palcal/pal/ChangeLog?revision=HEADview=markup INSTALL OR UPGRADE NOTES Cygwin: compiled with libreadline7 Standard install. CYGWIN INSTALLATION INFORMATION === To install this package, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. You'll find the package listed in the All category. After installation, read the documentation at directories: /usr/share/doc/package-version/* /usr/share/doc/Cygwin/package-version.README If you have questions or comments, please send them to the Cygwin mailing list at cyg...@cygwin.com. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO This message has been sent to cygwin-announce list. If you want to unsubscribe from the 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 More information on unsubscribing can be found: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL.
[ANNOUNCEMENT] New package: picard-1.3.2 - MusicBrainz audio tagger
Hi The package picard is now available with the Cygwin distribution: o http://picard.musicbrainz.org/ (Homepage) DESCRIPTION: MusicBrainz Picard is the official MusicBrainz tagger. Picard supports the majority of audio file formats, is capable of using audio fingerprints (PUIDs, AcoustIDs), performing CD lookups and disc ID submissions, and has excellent Unicode support. Enjoy Volker -- To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Once you've downloaded setup.exe, run it and select Audio and then click on the appropriate fields until the above announced version numbers appear if they are not displayed already. If your mirror doesn't yet have the latest version of this package after 24 hours, you can either continue to wait for that site to be updated or you can try to find another mirror. Please send questions or comments to the Cygwin mailing list at: cyg...@cygwin.com If you want to subscribe go to: http://cygwin.com/ml/cygwin/ I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: slow startup after upgrade
On Feb 19 11:53, Roger Orr wrote: I've tested again with the first patched cygwin1.dll: CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35(0.286/5/3) 2015-02-16 13:18 i686 Cygwin I can confirm the connections are occurring within the ldap_search_s call - here is one of the call stacks: [...] AFAICS that's expected when enumerating accounts. Connection-Bind (enter username and password) (no new sessions) Browse-Search Base Dn - first naming context Filter: ((objectClass=trustedDomain)(name=wibble)) Gets 0 entries, quickly, no extra sessions visible Click 'Options' Select 'Chase Referrals' Click Ok Search again. Gets 0 entries, takes some seconds, and establishes nuermous TCP/IP connections. Hunting down the other DCs I assume. (1) LDAP_OPT_REFERRALS is on by default (2) The fix added CN=System to the Base Dn - this seems to turn off referrals I don't think it does. The domain info is available on the DC you're contacting so it doesn't have to ask others. I assume here that wibble is no valid domain name ;) -- *aside* Sysinternals ADInsight is a 32bit only tool and, in order to work on a 64bit Windows you seem to have to manually inject the DLL ADInsightDll.dll (which is extracted into %TEMP%) into the target (32-bit!) process. Uh, too bad. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNDdUmjJIbX.pgp Description: PGP signature
Re: HEADSUP: Packages with obsolete dependencies (pal UPLOADED)
On 2015-02-19 11:57, Corinna Vinschen wrote: | On Feb 19 12:51, jari wrote: | On 2015-02-11 03:27, Yaakov Selkowitz wrote: | | On Tue, 2015-02-10 at 22:14 -0600, Yaakov Selkowitz wrote: | | | | I just cleared out a huge number of obsolete and stale packages | | | | pal ORPHANED (Jari Aalto) | | Took care of this, | Jari | | I removed the orphaned status from the package. You can leave it orphaned. I just rebuilt it using the latest libraries to help Yaakow clean up old libs. If someone wants to take over, please go ahead. Jari signature.asc Description: Digital signature
[PATCH] Compile sigfe.s with CFLAGS
CFLAGS isn't used when compiling the generated file sigfe.s, so if that
contains -g, it lacks source debugging information.
2015-02-19 Jon TURNEY jon.tur...@dronecode.org.uk
* Makefile.in (sigfe.o): Use CFLAGS.
Index: cygwin/Makefile.in
===
RCS file: /cvs/src/src/winsup/cygwin/Makefile.in,v
retrieving revision 1.278
diff -u -u -p -r1.278 Makefile.in
--- cygwin/Makefile.in 28 Jan 2015 11:43:06 - 1.278
+++ cygwin/Makefile.in 19 Feb 2015 13:12:11 -
@@ -710,7 +710,7 @@ sigfe.s: $(DEF_FILE)
[ -s $@ ] touch $@
sigfe.o: sigfe.s
- $(CC) -c -o $@ $
+ $(CC) ${CFLAGS} -c -o $@ $
ctags: CTAGS
tags: CTAGS
Re: [PATCH] Compile sigfe.s with CFLAGS
On Feb 19 13:21, Jon TURNEY wrote: * Makefile.in (sigfe.o): Use CFLAGS. Please apply. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpmlZMUyVfqp.pgp Description: PGP signature
[ANNOUNCEMENT] New packages: libpakchois0/libpakchois-devel/libpakchois-doc-0.4 - A PKCS #11 wrapper library
Hi The packages libpakchois0/libpakchois-devel/libpakchois-doc are now available with the Cygwin distribution: o http://www.manyfish.co.uk/pakchois (Homepage) DESCRIPTION: PaKChoiS is just another PKCS #11 wrapper library. PaKChoiS aims to provide a thin wrapper over the PKCS#11 interface. Enjoy Volker -- To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Once you've downloaded setup.exe, run it and select Libs and then click on the appropriate fields until the above announced version numbers appear if they are not displayed already. If your mirror doesn't yet have the latest version of this package after 24 hours, you can either continue to wait for that site to be updated or you can try to find another mirror. Please send questions or comments to the Cygwin mailing list at: cygwin@cygwin.com If you want to subscribe go to: http://cygwin.com/ml/cygwin/ I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- 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
New packages: libpakchois0/libpakchois-devel/libpakchois-doc-0.4 - A PKCS #11 wrapper library
Hi The packages libpakchois0/libpakchois-devel/libpakchois-doc are now available with the Cygwin distribution: o http://www.manyfish.co.uk/pakchois (Homepage) DESCRIPTION: PaKChoiS is just another PKCS #11 wrapper library. PaKChoiS aims to provide a thin wrapper over the PKCS#11 interface. Enjoy Volker -- To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Once you've downloaded setup.exe, run it and select Libs and then click on the appropriate fields until the above announced version numbers appear if they are not displayed already. If your mirror doesn't yet have the latest version of this package after 24 hours, you can either continue to wait for that site to be updated or you can try to find another mirror. Please send questions or comments to the Cygwin mailing list at: cyg...@cygwin.com If you want to subscribe go to: http://cygwin.com/ml/cygwin/ I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place.
Re: Is db_home: windows exactly equivalent to db_home: /%H?
On Feb 18 21:46, Warren Young wrote: I was just scanning through the ntsec page, and saw that the “windows” scheme does the same thing as /%H. I tried it, and it seems to be true. Is there some minor difference? Yes. The windows scheme is always just /%H, while %H allows something like /%H/cygwin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpXraluOSl4H.pgp Description: PGP signature
src/winsup/cygwin ChangeLog sec_acl.cc release ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2015-02-19 14:15:44 Modified files: winsup/cygwin : ChangeLog sec_acl.cc winsup/cygwin/release: 1.7.35 Log message: * sec_acl.cc (setacl): Always grant owner FILE_WRITE_ATTRIBUTES access. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6636r2=1.6637 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sec_acl.cc.diff?cvsroot=srcr1=1.82r2=1.83 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/release/1.7.35.diff?cvsroot=srcr1=1.5r2=1.6
Re: setfacl: root of all evil?
On Feb 16 17:40, Houder wrote: On Feb 16 14:53, Houder wrote: Hi Corinna, Yes, sorry, setfacl again ... [snip] RFC :-) Dumb bug in Cygwin. I found it and fixed it locally. Indeed? Did expect a deliberate different school of thoughts ... Apparently, not. [snip] Actually, I don't think I'm going to apply the fix anyway. Never mind. I applied this patch to CVS since the new ACL code will take some more time. The speedups to the LDAP calls probably qualify for a quicker release of 1.7.35. Just FYI, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBGEqi1fnwK.pgp Description: PGP signature
Re: ffcall
On 2/19/2015 12:44 PM, Corinna Vinschen wrote: On Feb 19 12:19, Ken Brown wrote: On 2/19/2015 11:46 AM, Ken Brown wrote: On 2/19/2015 10:43 AM, Reini Urban wrote: On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. Yes, it seems to be. So far I've built and am testing a version with no non-default modules, and with the default regexp module disabled. I had to do the latter because of the gcc problem I encountered while trying to compile regexi.c: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. I tried to test my build by using it to build xindy. It appeared to work, as far as it went, but it didn't go too far because xindy requires the regexp module. So I think I'm stuck until the gcc problem is resolved. Does it build with the former gcc 4.8.3, by any chance? No, same error. Ken
RE: Very slow Cygwin startup on Windows 7
Hi Corinna, Can you please try this test version without cygserver, and with the passwd and group settings in /etc/nsswitch.conf set to passwd: db group: db It would be very interesting to know if this improves the situation for you. Just did it for 1.7.35-0.2 - I haven't seen 0.3 turn up at a mirror site yet. It's only just uploaded so it might take another while, depending on your mirrors. According to Roger's results in https://cygwin.com/ml/cygwin/2015-02/msg00511.html and https://cygwin.com/ml/cygwin/2015-02/msg00543.html, the real problem hadn't been fixed in the 0.2 test release, so you might give 0.3 another chance. BTW - I did try ADInsight, but it didn't show me anything (maybe because this is a 64 bit windows?) Anyway, I ran it with 0.3 and nsswitch = db and the result is??? 1.68-1.72 seconds Hmm. No offense, but are you sure you ran this with 0.3? I knew you'd doubt me :-) CYGWIN_NT-6.1 DEHAGART-WS02 1.7.35(0.286/5/3) 2015-02-18 11:32 x86_64 Cygwin With nsswitch = files db it was 1.43-1.45 seconds. With nsswitch = files it was 0.13-0.14 seconds (It seems basically the same as 0.2) It would be pretty helpful to get an idea what's so slow in your case. Either you get ADInsight working, or... is it ok if I send you a link to a debug-augmented DLL via PM? Sure. Sysinternals ADInsight is a 32bit only tool and, in order to work on a 64bit Windows you seem to have to manually inject the DLL ADInsightDll.dll (which is extracted into %TEMP%) into the target (32-bit!) process. So, it seems ADInsight seems a non-starter - for my skill level anyway.
Re: Clearing O_NONBLOCK from a pipe may lose data
Am 19.02.2015 um 10:51 schrieb Corinna Vinschen: On Feb 18 22:08, Lasse Collin wrote: (Please Cc me when replying, I'm not subscribed to the list.) Hi! I suspect that there is a bug in Cygwin: 1. Create a pipe with both ends in blocking mode (O_NONBLOCK is not set). 2. The writer sets its end to non-blocking mode. 3. The writer writes to the pipe. 4. The writer restores its end of the pipe to blocking mode before the reader has read anything from the pipe. 5. The writer closes its end of the pipe. 6. The reader reads from the pipe in blocking mode. The last bytes written by the writer never appear at the reader, thus data is silently lost. Omitting the step 4 above makes the problem go away. I can imagine. A few years back, when changing the pipe code to using overlapped IO, we stumbled over a problem in Windows. When closing an overlapped pipe while I/O is still ongoing, Windows simply destroys the pipe buffers without flushing the data to the reader. This is not much of a problem for blocking IO, but it obviously is for non-blocking. The workaround for this behaviour is this: If the pipe is closed, and this is the writing side of a nonblocking pipe, a background thread gets started which keeps the overlapped structure open and continues to wait for IO completion (i.e. the data has been sent to the reader). However, if you switch back to blocking before closing the pipe, the aforementioned mechanism does not kick in. Could not switching back to blocking simply be handled like closing as far as the waiting is concerned, thus effectively flushing the pipe buffer? -- 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: ffcall
On 2/19/2015 2:46 PM, Reini Urban wrote: On 02/19/2015 06:19 PM, Ken Brown wrote: On 2/19/2015 11:46 AM, Ken Brown wrote: On 2/19/2015 10:43 AM, Reini Urban wrote: On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. Yes, it seems to be. So far I've built and am testing a version with no non-default modules, and with the default regexp module disabled. I had to do the latter because of the gcc problem I encountered while trying to compile regexi.c: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. Huh, that's a good one! Something for Kai. I tried to test my build by using it to build xindy. It appeared to work, as far as it went, but it didn't go too far because xindy requires the regexp module. So I think I'm stuck until the gcc problem is resolved. I don't whether it's worth uploading my crippled clisp at this point to let it get some testing. Reini, is clisp without regexp at all useful? Usually clisp users don't need the regexp module, they usually have better matchers. In that case, I think I'll go ahead and release what I have and see if it's of use to anyone. Ken
Re: [SECURITY] vorbis-tools
On Tue, 2015-02-17 at 22:42 -0600, Yaakov Selkowitz wrote: David, vorbis-tools requires a patch for CVE-2014-9640: http://pkgs.fedoraproject.org/cgit/vorbis-tools.git/plain/vorbis-tools-1.4.0-bz1185558.patch And now another one for CVE-2014-9638 and CVE-2014-9639: http://pkgs.fedoraproject.org/cgit/vorbis-tools.git/plain/vorbis-tools-1.4.0-CVE-2014-9638-CVE-2014-9639.patch There are other patches in that repo that you may wish to consider adding; at a minimum, I would recommend the patch for vcut: http://pkgs.fedoraproject.org/cgit/vorbis-tools.git/plain/vorbis-tools-1.4.0-bz1003607.patch -- Yaakov
Re: Clearing O_NONBLOCK from a pipe may lose data
Am 20.02.2015 um 00:47 schrieb Andrey Repin: Greetings, Thomas Wolff! Am 19.02.2015 um 10:51 schrieb Corinna Vinschen: On Feb 18 22:08, Lasse Collin wrote: (Please Cc me when replying, I'm not subscribed to the list.) Hi! I suspect that there is a bug in Cygwin: 1. Create a pipe with both ends in blocking mode (O_NONBLOCK is not set). 2. The writer sets its end to non-blocking mode. 3. The writer writes to the pipe. 4. The writer restores its end of the pipe to blocking mode before the reader has read anything from the pipe. 5. The writer closes its end of the pipe. 6. The reader reads from the pipe in blocking mode. The last bytes written by the writer never appear at the reader, thus data is silently lost. Omitting the step 4 above makes the problem go away. I can imagine. A few years back, when changing the pipe code to using overlapped IO, we stumbled over a problem in Windows. When closing an overlapped pipe while I/O is still ongoing, Windows simply destroys the pipe buffers without flushing the data to the reader. This is not much of a problem for blocking IO, but it obviously is for non-blocking. The workaround for this behaviour is this: If the pipe is closed, and this is the writing side of a nonblocking pipe, a background thread gets started which keeps the overlapped structure open and continues to wait for IO completion (i.e. the data has been sent to the reader). However, if you switch back to blocking before closing the pipe, the aforementioned mechanism does not kick in. Could not switching back to blocking simply be handled like closing as far as the waiting is concerned, thus effectively flushing the pipe buffer? You can't just flush it, if the receiving end isn't reading from it. By flushing I meant actually waiting until it's been consumed at the other end in this case, if that's technically feasible. I see no strict requirement that the fcntl call removing O_NONBLOCK from a file descriptor should itself still be handled as nonblocking (it can well be argued that the flag is changed first and then the call is allowed to block) - and even if this were not proper it is certainly more acceptable than losing data. -- Thomas --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. http://www.avast.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: Clearing O_NONBLOCK from a pipe may lose data
Greetings, Thomas Wolff! Am 19.02.2015 um 10:51 schrieb Corinna Vinschen: On Feb 18 22:08, Lasse Collin wrote: (Please Cc me when replying, I'm not subscribed to the list.) Hi! I suspect that there is a bug in Cygwin: 1. Create a pipe with both ends in blocking mode (O_NONBLOCK is not set). 2. The writer sets its end to non-blocking mode. 3. The writer writes to the pipe. 4. The writer restores its end of the pipe to blocking mode before the reader has read anything from the pipe. 5. The writer closes its end of the pipe. 6. The reader reads from the pipe in blocking mode. The last bytes written by the writer never appear at the reader, thus data is silently lost. Omitting the step 4 above makes the problem go away. I can imagine. A few years back, when changing the pipe code to using overlapped IO, we stumbled over a problem in Windows. When closing an overlapped pipe while I/O is still ongoing, Windows simply destroys the pipe buffers without flushing the data to the reader. This is not much of a problem for blocking IO, but it obviously is for non-blocking. The workaround for this behaviour is this: If the pipe is closed, and this is the writing side of a nonblocking pipe, a background thread gets started which keeps the overlapped structure open and continues to wait for IO completion (i.e. the data has been sent to the reader). However, if you switch back to blocking before closing the pipe, the aforementioned mechanism does not kick in. Could not switching back to blocking simply be handled like closing as far as the waiting is concerned, thus effectively flushing the pipe buffer? You can't just flush it, if the receiving end isn't reading from it. -- WBR, Andrey Repin (anrdae...@yandex.ru) 20.02.2015, 02:46 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: TEST RELEASE: Cygwin 1.7.35-0.3
Corinna Vinschen wrote at 11:59 +0100 on Feb 18, 2015: Hi Cygwin friends and users, I released another very early TEST version of the next upcoming Cygwin release. The version number is 1.7.35-0.3. This release introduces a revision of the LDAP calls done to fetch information from the DC. By limiting the search scope, the calls should now be faster even in bigger environments. Please give it a try with activated db settings for passwd and group entries in /etc/nsswitch.conf passwd: db group: db Please report back your experience, especially if you're suffering from slow startup problems. Without 'files' in /etc/nsswitch.conf or 'cygserver' running, the testing cycle here is slow. So I've been a bit delayed at reporting back. I know some people have alleged wonderful speedups with 1.7.35-0.3, but I can't report the same. Here I'm in an AD environment with ~8000 entries in AD (as determined by 'mkpasswd -d | wc') and I'm in 200+ groups. I guess I'd call it somewhat large, and the network is geographically spread out and connected by links that vary in speed (the slowest is probably 10s of Mbps), although there is a local AD slave on the local LAN. It's particularly slow if I force using my shell of choice (tcsh) rather than forcing '/bin/dash' as the 'db_shell' entry in nsswitch.conf. This is likely because of all the various things that get executed at shell startup (csh.cshrc, profile.d/*.csh). Just to avoid any possible cruft from my old cygwin install, I installed a minimal fresh cygwin. The only change was to nsswitch.conf: passwd: db group: db db_shell: /bin/dash Starting mintty with db_shell set to /bin/tcsh has taken up to a half hour before the prompt appears. I don't have a complicated .cshrc (just a few alias definitions 'set' commands). Also mkpasswd -d seems to be taking a long time (haven't had it complete in hours now). That didn't happen with 1.7.34 - maybe there's a local issue here on our network. What's a good way to debug what's happening with mkpasswd? Seems like its not doing anything. -- 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 has no LISP package
On 12/27/2014 11:38 PM, Phil _ wrote: cygwin64 has no package with any version of LISP. This has just changed: https://cygwin.com/ml/cygwin-announce/2015-02/msg00144.html Please give it a try. 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
Re: ffcall
On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. In the meantime I started here: https://github.com/rurban/ffcall/tree/win64 with a win64 port, time permits. win64 also needs 32byte shadow stack space to spill rcx, rdx, r8 and r9. libffi added win64 and cygwin64 support recently, but ffcall is easier to understand, and faster.
Re: ffcall
On 2/19/2015 10:43 AM, Reini Urban wrote: On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. Yes, it seems to be. So far I've built and am testing a version with no non-default modules, and with the default regexp module disabled. I had to do the latter because of the gcc problem I encountered while trying to compile regexi.c: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. In the meantime I started here: https://github.com/rurban/ffcall/tree/win64 with a win64 port, time permits. Thanks!! win64 also needs 32byte shadow stack space to spill rcx, rdx, r8 and r9. libffi added win64 and cygwin64 support recently, but ffcall is easier to understand, and faster. Ken
Re: ffcall
On 2/19/2015 11:46 AM, Ken Brown wrote: On 2/19/2015 10:43 AM, Reini Urban wrote: On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. Yes, it seems to be. So far I've built and am testing a version with no non-default modules, and with the default regexp module disabled. I had to do the latter because of the gcc problem I encountered while trying to compile regexi.c: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. I tried to test my build by using it to build xindy. It appeared to work, as far as it went, but it didn't go too far because xindy requires the regexp module. So I think I'm stuck until the gcc problem is resolved. I don't whether it's worth uploading my crippled clisp at this point to let it get some testing. Reini, is clisp without regexp at all useful? Ken
[ANNOUNCEMENT] Updated: arc 5.21q-1 -- The ARC archive utility
PACKAGE DESCRIPTION === Homepage: http://www.sourceforge.net/projects/arc License : GPL This program is based on the MSDOS ARC program, version 5.21, plus a few enhancements. ARC performs Huffman Squeezing on data. The Huffman Squeeze algorithm was removed from MSDOS ARC after version 5.12. It turns out to be more efficient than Lempel-Ziv style compression when compressing graphic images. Squeeze analysis is always done now, and the best of packing, squeezing, or crunching is used. CHANGES SINCE LAST RELEASE == http://arc.cvs.sourceforge.net/arc/arc/Changelog?revision=HEADview=markup INSTALL OR UPGRADE NOTES Standard install. Cygwin: compiled with Fedora security patches CYGWIN INSTALLATION INFORMATION === To install this package, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. You'll find the package listed in the All category. After installation, read the documentation at directories: /usr/share/doc/package-version/* /usr/share/doc/Cygwin/package-version.README If you have questions or comments, please send them to the Cygwin mailing list at cygwin(at)cygwin.com. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO This message has been sent to cygwin-announce list. If you want to unsubscribe from the 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.com(at)cygwin.com More information on unsubscribing can be found: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above 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
Re: [SECURITY] arc 5.21p-1 (UPLOADED)
On Thu, 2015-02-19 at 12:19 +0200, Jari Aalto wrote: 2015-02-18 04:06 Yaakov Selkowitz: | A directory traversal vulnerability has been found in arc. Please add | the following patches to the arc package ASAP: Uploaded both 5.21p-2 and 5.21q-1 with patches included. Thanks, Yaakov
Re: ffcall
On Feb 19 12:19, Ken Brown wrote: On 2/19/2015 11:46 AM, Ken Brown wrote: On 2/19/2015 10:43 AM, Reini Urban wrote: On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. Yes, it seems to be. So far I've built and am testing a version with no non-default modules, and with the default regexp module disabled. I had to do the latter because of the gcc problem I encountered while trying to compile regexi.c: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. I tried to test my build by using it to build xindy. It appeared to work, as far as it went, but it didn't go too far because xindy requires the regexp module. So I think I'm stuck until the gcc problem is resolved. Does it build with the former gcc 4.8.3, by any chance? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpdVZVtyjWKk.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: clamav-0.98.6-2
The following packages have been updated in the Cygwin distribution: * clamav-0.98.6-2 * clamav-db-0.98.6-2 * libclamav6-0.98.6-2 * libclamav-devel-0.98.6-2 Clam AntiVirus is a GPL anti-virus toolkit for *NIX systems, featuring a command-line scanner, advanced database updater, and built-in support for all standard mail file formats, various archive formats, ELF executables and Portable Executable files packed or obfuscated in various ways, and popular document formats. This is an update to the latest upstream release, which includes a fix for multiple vulnerabilities: http://blog.clamav.net/2015/01/clamav-0986-has-been-released.html There are also several packaging changes in this release: - Scanning of RAR archive contents has been disabled due to non-free licensing of the related code; - The default DatabaseDirectory has been moved to /var/lib/clamav for FHS compliance. - The system json-c, llvm, and libmspack libraries are used in place of bundled versions. -- 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
Updated: clamav-0.98.6-2
The following packages have been updated in the Cygwin distribution: * clamav-0.98.6-2 * clamav-db-0.98.6-2 * libclamav6-0.98.6-2 * libclamav-devel-0.98.6-2 Clam AntiVirus is a GPL anti-virus toolkit for *NIX systems, featuring a command-line scanner, advanced database updater, and built-in support for all standard mail file formats, various archive formats, ELF executables and Portable Executable files packed or obfuscated in various ways, and popular document formats. This is an update to the latest upstream release, which includes a fix for multiple vulnerabilities: http://blog.clamav.net/2015/01/clamav-0986-has-been-released.html There are also several packaging changes in this release: - Scanning of RAR archive contents has been disabled due to non-free licensing of the related code; - The default DatabaseDirectory has been moved to /var/lib/clamav for FHS compliance. - The system json-c, llvm, and libmspack libraries are used in place of bundled versions. -- Yaakov
Re: HEADSUP: Packages with obsolete dependencies
On Thu, 2015-02-19 at 12:50 +0100, Reini Urban wrote: On 02/11/2015 07:56 AM, Achim Gratz wrote: Of the orphaned packages, as said in another thread, I'd make rakudo and parrot obsolete. I can maybe resurrect them after the Perl update if there's still interest in those or maybe a new maintainer shows up. yes, please. parrot is now dead upstream, and rakudo needs now moarvm and jvm dependencies. The planned stable rakudo release is Dec 2015, so there's enough time to get a maintainer. They work mostly on windows. I have removed parrot, rakudo, and rakudo-star from the distribution. -- Yaakov
Re: TEST RELEASE: Cygwin 1.7.35-0.3
Greetings, John Hein! Without 'files' in /etc/nsswitch.conf or 'cygserver' running, the testing cycle here is slow. So I've been a bit delayed at reporting back. I know some people have alleged wonderful speedups with 1.7.35-0.3, but I can't report the same. Here I'm in an AD environment with ~8000 entries in AD (as determined by 'mkpasswd -d | wc') and I'm in 200+ groups. I guess I'd call it somewhat large, and the network is geographically spread out and connected by links that vary in speed (the slowest is probably 10s of Mbps), although there is a local AD slave on the local LAN. It's particularly slow if I force using my shell of choice (tcsh) rather than forcing '/bin/dash' as the 'db_shell' entry in nsswitch.conf. This is likely because of all the various things that get executed at shell startup (csh.cshrc, profile.d/*.csh). I can't comment on this matter, but this seems RATHER suspicious. Just to avoid any possible cruft from my old cygwin install, I installed a minimal fresh cygwin. The only change was to nsswitch.conf: passwd: db group: db db_shell: /bin/dash Starting mintty with db_shell set to /bin/tcsh has taken up to a half hour before the prompt appears. I don't have a complicated .cshrc (just a few alias definitions 'set' commands). You can get a more reliable test of the changes to Cygwin specifically, if you just run `id` directly (let's say, from native console, or a batch file). Also mkpasswd -d seems to be taking a long time (haven't had it complete in hours now). That didn't happen with 1.7.34 - maybe there's a local issue here on our network. mkpasswd is trying to pull up ALL records for ALL users in the domain. Even with recent changes, I can imagine it taking a lot of time in a spread out network. What's a good way to debug what's happening with mkpasswd? Seems like its not doing anything. Sysinternals ADInsight, as has been mentioned before. https://technet.microsoft.com/en-us/sysinternals/bb897539 -- WBR, Andrey Repin (anrdae...@yandex.ru) 20.02.2015, 05:50 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
New: clisp-2.48-4 for 64-bit Cygwin
The following package has been added to the 64-bit Cygwin distribution: * clisp-2.48-4 ANSI Common Lisp is a high-level, general-purpose programming language. GNU CLISP is a Common Lisp implementation by Bruno Haible of Karlsruhe University and Michael Stoll of Munich University, both in Germany. It mostly supports the Lisp described in the ANSI Common Lisp standard. GNU CLISP includes an interpreter, a compiler, a debugger, CLOS, MOP, a foreign language interface, sockets, i18n, fast bignums, and more. GNU CLISP runs Maxima, ACL2, and many other Common Lisp packages. This is the first release of clisp for 64-bit Cygwin. It is built with no non-default modules, and with the default regexp module disabled. I had to do the latter because of a gcc problem I encountered while trying to compile regexp: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. I hope to be able to release a more complete clisp once this problem is solved. As I said in my recent announcement of 32-bit clisp-2.48-4, I am not a clisp user, so I can't properly support it. But I did run the clisp testsuite on the 64-bit build, and it passed all but 3 of about 11,000 tests. So I hope it will be usable. Feedback is welcome. Ken Brown Cygwin's clisp maintainer
[ANNOUNCEMENT] New: clisp-2.48-4 for 64-bit Cygwin
The following package has been added to the 64-bit Cygwin distribution: * clisp-2.48-4 ANSI Common Lisp is a high-level, general-purpose programming language. GNU CLISP is a Common Lisp implementation by Bruno Haible of Karlsruhe University and Michael Stoll of Munich University, both in Germany. It mostly supports the Lisp described in the ANSI Common Lisp standard. GNU CLISP includes an interpreter, a compiler, a debugger, CLOS, MOP, a foreign language interface, sockets, i18n, fast bignums, and more. GNU CLISP runs Maxima, ACL2, and many other Common Lisp packages. This is the first release of clisp for 64-bit Cygwin. It is built with no non-default modules, and with the default regexp module disabled. I had to do the latter because of a gcc problem I encountered while trying to compile regexp: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. I hope to be able to release a more complete clisp once this problem is solved. As I said in my recent announcement of 32-bit clisp-2.48-4, I am not a clisp user, so I can't properly support it. But I did run the clisp testsuite on the 64-bit build, and it passed all but 3 of about 11,000 tests. So I hope it will be usable. Feedback is welcome. Ken Brown Cygwin's clisp maintainer -- 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 package: pdftk-2.02-1
On Wed, 2015-02-18 at 20:00 +, Buchbinder, Barry (NIH/NIAID) [E] wrote: There is no 64 bit pdftk package. Is that an oversight? No, gcc-java/libgcj have not yet been ported to 64-bit Cygwin. -- 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
