Re: RFU: mscgen-0.19-1
On Jan 4 19:08, Michael McTernan wrote: Hi, Please upload mscgen-0.19-1 which follows a new upstream release: wget -nd -P mscgen \ http://www.mcternan.me.uk/mscgen/cygport/mscgen-0.19-1.tar.bz2 \ http://www.mcternan.me.uk/mscgen/cygport/mscgen-0.19-1-src.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files
On Jan 6 17:04, Andrew Schulman wrote: New package available at: http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2 http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2.sig http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig I was trying to download the files, but I get a permanent error: wget http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 --2011-01-10 18:06:26-- http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 Resolving www.eco-lution.tv... 87.217.144.54 Connecting to www.eco-lution.tv|87.217.144.54|:80... connected. HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying. [...] Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Jan 9 12:58, David Sastre wrote: On Sun, Jan 09, 2011 at 04:54:26AM +0100, Jorge Díaz wrote: Can you try installing recent Cygwin snapshot Can you try launching only failed test r00326.vtc?? Can you send me your IPv6 error log? CYGWIN_NT-6.1 win7 1.7.8s(0.234/5/3) 20101229 01:34:45 i686 Cygwin I have used a modified version of c5.vtc to test IPv6 in 2.1.4-4 and 2.1.2-4. All tests have run successfully. David, is that a GTG? If so, I'd upload the files... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files
On Mon, Jan 10, 2011 at 06:08:06PM +0100, Corinna Vinschen wrote: On Jan 6 17:04, Andrew Schulman wrote: New package available at: http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig I was trying to download the files, but I get a permanent error: Yep...the box has been down all day long. Files are available again. Sorry for the inconvenience. Also, I'd appreciate opinions regarding the guard-like tests in some config files, namely /etc/profile, /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc. I'm not very convinced about including them. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 06:12:02PM +0100, Corinna Vinschen wrote:
On Jan 9 12:58, David Sastre wrote:
On Sun, Jan 09, 2011 at 04:54:26AM +0100, Jorge Díaz wrote:
Can you try installing recent Cygwin snapshot
Can you try launching only failed test r00326.vtc??
Can you send me your IPv6 error log?
CYGWIN_NT-6.1 win7 1.7.8s(0.234/5/3) 20101229 01:34:45 i686 Cygwin
I have used a modified version of c5.vtc to test IPv6 in
2.1.4-4 and 2.1.2-4.
All tests have run successfully.
David, is that a GTG? If so, I'd upload the files...
I'm waiting for Jorge to pack a version correcting the absence of
setup.hint and a README in varnish-${version}.cygwin.patch.
My apologies to both. I wasn't clear about that.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
I am working on it.
I have added setup.hint and README files and also made two minor changes.
I think it will be finished today.
2011/1/10 David Sastre d.sastre.med...@gmail.com:
On Mon, Jan 10, 2011 at 06:12:02PM +0100, Corinna Vinschen wrote:
On Jan 9 12:58, David Sastre wrote:
On Sun, Jan 09, 2011 at 04:54:26AM +0100, Jorge Díaz wrote:
Can you try installing recent Cygwin snapshot
Can you try launching only failed test r00326.vtc??
Can you send me your IPv6 error log?
CYGWIN_NT-6.1 win7 1.7.8s(0.234/5/3) 20101229 01:34:45 i686 Cygwin
I have used a modified version of c5.vtc to test IPv6 in
2.1.4-4 and 2.1.2-4.
All tests have run successfully.
David, is that a GTG? If so, I'd upload the files...
I'm waiting for Jorge to pack a version correcting the absence of
setup.hint and a README in varnish-${version}.cygwin.patch.
My apologies to both. I wasn't clear about that.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk0rV5kACgkQYX05bESLMevAEgCdFPqAj5r5W2okEAltVM6RDwST
3bIAoMONJ89AJ8X+EIYZWkNvNbn8cJPL
=sqP8
-END PGP SIGNATURE-
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 08:07:13PM +0100, Jorge Díaz wrote:
2011/1/10 David Sastre !!: ===!!¹
On Mon, Jan 10, 2011 at 06:12:02PM +0100, Corinna Vinschen wrote:
On Jan 9 12:58, David Sastre wrote:
On Sun, Jan 09, 2011 at 04:54:26AM +0100, Jorge Díaz wrote:
Can you try installing recent Cygwin snapshot
Can you try launching only failed test r00326.vtc??
Can you send me your IPv6 error log?
CYGWIN_NT-6.1 win7 1.7.8s(0.234/5/3) 20101229 01:34:45 i686 Cygwin
I have used a modified version of c5.vtc to test IPv6 in
2.1.4-4 and 2.1.2-4.
All tests have run successfully.
David, is that a GTG? If so, I'd upload the files...
I'm waiting for Jorge to pack a version correcting the absence of
setup.hint and a README in varnish-${version}.cygwin.patch.
My apologies to both. I wasn't clear about that.
I am working on it.
I have added setup.hint and README files and also made two minor changes.
I think it will be finished today.
Please http://cygwin.com/acronyms/#TOFU
and ¹http://cygwin.com/acronyms/#PCYMTNQREAIYR
OK. Please bump the cygwin package release number when you do that.
Thanks for the quick response!
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
I have prepared last set of packages. - added setup.hint and README to packages - cygport deleted /var/varnish empty dir when packing, fixed with keepdir instruction in cygport - IPv6 test is enabled (c5.vtc) is passed ok (windows xp problems was caused by a machine configuration error) - removed AC_DEFINE([RTLD_LOCAL], [0] from configure.ac (in cygwin 1.7.7 is not necesary) - removed a very ugly fix only for r5665 package for drand48 function (in future cygwin 1.7.8 is fixed: http://www.cygwin.com/ml/cygwin/2010-12/msg00460.html) The new packages can be downloaded from: wget http://downloads.sourceforge.net/project/cygvarnish/cygwin-varnish%20package/varnish-2.1.2-5-src.tar.bz2 wget http://downloads.sourceforge.net/project/cygvarnish/cygwin-varnish%20package/varnish-2.1.2-5.tar.bz2 wget http://downloads.sourceforge.net/project/cygvarnish/cygwin-varnish%20package/varnish-2.1.4-5-src.tar.bz2 wget http://downloads.sourceforge.net/project/cygvarnish/cygwin-varnish%20package/varnish-2.1.4-5.tar.bz2 wget http://downloads.sourceforge.net/project/cygvarnish/cygwin-varnish%20package/varnish-r5665-5-src.tar.bz2 wget http://downloads.sourceforge.net/project/cygvarnish/cygwin-varnish%20package/varnish-r5665-5.tar.bz2 wget http://downloads.sourceforge.net/project/cygvarnish/cygwin-varnish%20package/setup.hint
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 09:43:31PM +0100, Jorge Díaz wrote: I have prepared last set of packages. - added setup.hint and README to packages Thanks. - cygport deleted /var/varnish empty dir when packing, fixed with keepdir instruction in cygport I overlooked that... - IPv6 test is enabled (c5.vtc) is passed ok (windows xp problems was caused by a machine configuration error) I see, 2.1.2-5 and 2.1.4-5 now have :: / 0 uncommented in c5.vtc test. - removed AC_DEFINE([RTLD_LOCAL], [0] from configure.ac (in cygwin 1.7.7 is not necesary) I get this to mean starting from 1.7.7 - removed a very ugly fix only for r5665 package for drand48 function (in future cygwin 1.7.8 is fixed: http://www.cygwin.com/ml/cygwin/2010-12/msg00460.html) One -really- minor annoyance (at least in win7) regarding how the test suite is executed in r5665. It looks like it runs too fast to clean /tmp properly. But issuing a quick-and-dirty: $ for a in /usr/src/varnish/varnish-r5665-5-src/varnish-r5665-5/src/varnish-cache/bin/varnishtest/tests/*vtc; do ./varnishtest $a; sleep 2; rm -rf /tmp/vtc*; done gets all of the test run successfully. GTG. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 08:34:03PM +0100, David Sastre wrote:
On Mon, Jan 10, 2011 at 08:07:13PM +0100, Jorge D?az wrote:
2011/1/10 David Sastre !!: ===!!?
On Mon, Jan 10, 2011 at 06:12:02PM +0100, Corinna Vinschen wrote:
On Jan ?9 12:58, David Sastre wrote:
On Sun, Jan 09, 2011 at 04:54:26AM +0100, Jorge D?az wrote:
Can you try installing recent Cygwin snapshot
Can you try launching only failed test r00326.vtc??
Can you send me your IPv6 error log?
CYGWIN_NT-6.1 win7 1.7.8s(0.234/5/3) 20101229 01:34:45 i686 Cygwin
I have used a modified version of c5.vtc to test IPv6 in
2.1.4-4 and 2.1.2-4.
All tests have run successfully.
David, is that a GTG? ?If so, I'd upload the files...
I'm waiting for Jorge to pack a version correcting the absence of
setup.hint and a README in varnish-${version}.cygwin.patch.
My apologies to both. I wasn't clear about that.
I am working on it.
I have added setup.hint and README files and also made two minor changes.
I think it will be finished today.
Please http://cygwin.com/acronyms/#TOFU
and ?http://cygwin.com/acronyms/#PCYMTNQREAIYR
OK. Please bump the cygwin package release number when you do that.
Thanks for the quick response!
Why bump the package release on something that has never been released?
I think it makes sense that the first release should be -1.
cgf
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 07:57:23PM -0500, Christopher Faylor wrote: On Mon, Jan 10, 2011 at 08:34:03PM +0100, David Sastre wrote: OK. Please bump the cygwin package release number when you do that. Why bump the package release on something that has never been released? I think it makes sense that the first release should be -1. That's what I understand from: 2. Do increase the version number no matter what (if upstream version didn't change, bump the Cygwin release number): even if the package was bad, even if it was removed from the server for a security issue, even if has only been discussed in mailing list and never uploaded: it costs nothing and avoids confusion in both setup.exe and people mind. in http://cygwin.com/setup.html It makes sense to me regardless it is a first release or an update. Is it a wrong assumption? -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Tue, Jan 11, 2011 at 07:23:45AM +0100, David Sastre wrote: On Mon, Jan 10, 2011 at 07:57:23PM -0500, Christopher Faylor wrote: On Mon, Jan 10, 2011 at 08:34:03PM +0100, David Sastre wrote: OK. Please bump the cygwin package release number when you do that. Why bump the package release on something that has never been released? I think it makes sense that the first release should be -1. That's what I understand from: 2.?Do increase the version number no matter what (if upstream version didn't change, bump the Cygwin release number): even if the package was bad, even if it was removed from the server for a security issue, even if has only been discussed in mailing list and never uploaded: it costs nothing and avoids confusion in both setup.exe and people mind. The package was never on the server, i.e., it was never released. If a package ever touches cygwin.com then, yes, you have to bump the version any time you make any change no matter how tiny. I don't care if the package is released with -57 release number but I don't want it to get into the common knowledge pool that it is a requirement because it isn't. cgf
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
2011/1/11, Christopher Faylor wrote: On Tue, Jan 11, 2011 at 07:23:45AM +0100, David Sastre wrote: On Mon, Jan 10, 2011 at 07:57:23PM -0500, Christopher Faylor wrote: On Mon, Jan 10, 2011 at 08:34:03PM +0100, David Sastre wrote: OK. Please bump the cygwin package release number when you do that. Why bump the package release on something that has never been released? I think it makes sense that the first release should be -1. That's what I understand from: 2.?Do increase the version number no matter what (if upstream version didn't change, bump the Cygwin release number): even if the package was bad, even if it was removed from the server for a security issue, even if has only been discussed in mailing list and never uploaded: it costs nothing and avoids confusion in both setup.exe and people mind. The package was never on the server, i.e., it was never released. If a package ever touches cygwin.com then, yes, you have to bump the version any time you make any change no matter how tiny. I don't care if the package is released with -57 release number but I don't want it to get into the common knowledge pool that it is a requirement because it isn't. Duly noted. Thanks for the clarification.
Re: [PATCH] cygcheck -s should not imply -d
On Jan 5 19:50, Jon TURNEY wrote: Currently, for cygcheck -s implies -d. This seems rather unhelpful. I'm afraid I've lost the thread which inspired this, but in it the reporter provided cygcheck -svr output as requested, but this did not help diagnose what ultimately turned out to be the problem, that a DLL was actually an older version (presumably due to replace-in-use problems) Attached a patch to modify cygcheck so -s no longer implies -d (although -d can still be used). 2011-01-05 Jon TURNEY * cygcheck.cc (main): don't imply -d from -s option to cygcheck Looks good to me. Applied. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] cygcheck -s should not imply -d
On Mon, Jan 10, 2011 at 01:51:02PM +0100, Corinna Vinschen wrote: On Jan 5 19:50, Jon TURNEY wrote: Currently, for cygcheck -s implies -d. This seems rather unhelpful. I'm afraid I've lost the thread which inspired this, but in it the reporter provided cygcheck -svr output as requested, but this did not help diagnose what ultimately turned out to be the problem, that a DLL was actually an older version (presumably due to replace-in-use problems) Attached a patch to modify cygcheck so -s no longer implies -d (although -d can still be used). 2011-01-05 Jon TURNEY * cygcheck.cc (main): don't imply -d from -s option to cygcheck Looks good to me. Applied. Sorry that I didn't reply to this. I wasn't 100% convinced that this was a good idea since some of the packages show up as having problems when they are ok. I was wondering if that would end up generating more (understandably) confused mailing list traffic but I guess, in the end, it probably is better to check the validity of the packages for the prescribed error reporting technique. cgf
1.7.7 on Windows 7: can't write to removable disk
Hello. I'm trying to write a disk image to a compact flash card with dd, but I get the error: dd: writing to /dev/sdj: Permission denied Apart from the CF-card, I also tried a USB-stick with the same results. I'm logged in as administrator. Attaching output from cygcheck if needed. Tomas Cygwin Configuration Diagnostics Current System Time: Mon Jan 10 09:48:51 2011 Windows 7 Professional N Ver 6.1 Build 7600 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Program Files\ThinkPad\Bluetooth Software\ C:\Program Files\Intel\WiFi\bin\ C:\Program Files\Common Files\Intel\WirelessCommon\ C:\Program Files\Common Files\Lenovo C:\Program Files\Lenovo\Access Connections\ Output from C:\cygwin\bin\id.exe UID: 500(Administrator) GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'Administrator' PWD = '/home/Administrator' HOME = '/home/Administrator' HOMEPATH = '\Users\Administrator' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Users\Administrator\AppData\Roaming' HOSTNAME = 'micke-x' RR = 'C:\Program Files\Lenovo\Rescue and Recovery' TVTCOMMON = 'C:\Program Files\Common Files\Lenovo' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 23 Stepping 10, GenuineIntel' WINDIR = 'C:\Windows' TVTPYDIR = 'C:\Program Files\Common Files\Lenovo\Python24' TVT = 'C:\Program Files\Lenovo' PUBLIC = 'C:\Users\Public' OLDPWD = '/etc/skel' USERDOMAIN = 'MICKE-X' ACPath = 'C:\Program Files\Lenovo\Access Connections\' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' !:: = '::\' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' configsetroot = 'C:\Windows\ConfigSetRoot' USERNAME = 'Administrator' PROCESSOR_LEVEL = '6' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'C.UTF-8' USERPROFILE = 'C:\Users\Administrator' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\MICKE-X' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\Administrator\AppData\Local' !C: = 'C:\cygwin\bin' SWSHARE = 'C:\SWSHARE' ProgramData = 'C:\ProgramData' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PRINTER = 'iR C3220' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '170a' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' COMPUTERNAME = 'MICKE-X' _ = '/usr/bin/cygcheck.exe' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin c: hd NTFS225272Mb 13% CP CS UN PA FC Windows7_OS d: cd N/AN/A e: fd N/AN/A f: fd N/AN/A g: fd N/AN/A h: fd N/AN/A i: fd N/AN/A j: fd N/AN/A k: fd N/AN/A l: fd FAT32 3822Mb 57% CPUN TRANSCEND q: hd NTFS 11999Mb 67% CP CS UN PA FC Lenovo_Recovery C:\cygwin/ system binary,auto C:\cygwin\bin/usr/bin system binary,auto C:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,auto Found: C:\cygwin\bin\awk Found: C:\cygwin\bin\awk - C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cp.exe Not Found: cpp (good!) Not Found: crontab Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\find.exe Found: C:\Windows\system32\find.exe Warning: C:\cygwin\bin\find.exe hides C:\Windows\system32\find.exe Not Found: gcc Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Found: C:\cygwin\bin\kill.exe Not Found: ld Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\ls.exe Not Found: make Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\mv.exe Not Found: patch Not Found: perl Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\sed.exe Not Found: ssh Found:
Brand new setup ends up not where intended (?but at default)
I know you're probably not much interested in legacy difficulties (or maybe you are) but as setup.exe = setup-legacy.exe I thought I'd mention it. The following glitch has occurred several times, and I'm reminded of other posts written post-installation of the cannot find /home cannot find /bin/bash variety. I have always assumed that I must have suffered some kind of lapsed-concentration self-induced keypress malfunction. This time (like most times actually) I took good care. Intention: to install legacy version 1.5 on drive I: (ie not default) from sources stored under F:\Cyg0\release-legacy (ie not web). Command: F:\Cyg0\setup-legacy.exe Prompts (3 of them): 1. choose location I:\ for installation; 2. say YES I do mean that in response to warning; and 3. state F:\Cyg0 for source. The installation process appeared to run satisfactorily to completion (but surprisingly rapidly - I:\ is a usb stick and writes are pretty slow) but in the end all that's on I:\ is /i/: \─bin/: \─etc/: │ \─setup/: │ \─timestamp \─home/: \─lib/: \─tmp/: \─usr/: │ \─bin/: │ \─lib/: │ \─local/: │ │ \─bin/: │ │ \─etc/: │ │ \─lib/: │ \─src/: │ \─tmp/: \─var/: \─log/: │ \─setup.log │ \─setup.log.full \─run/: │ \─utmp \─tmp/: and what has actually happened is that the installation has been placed under C:\cygwin\. Not really what I wanted. The 4 files mentioned above (timestamp, setup.log.*, utmp) do NOT occur anywhere under c:\cygwin. I'll do a transfer or something and attend to mounts; but this has definitely happened more than once. Something I'm doing, or failing to do? Something your end that under certain circumstances causes the default architecture to override user-stated preferences? I did NOT clean the registry. Things were properly uninstalled (ie I had umount'ed everything) but without doubt the registry will have had trailing vestigial references to Cygwin and Cygnus Solutions, though essentially empty. Could this be the problem? Fergus -- 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: Bad rebaseall interaction with new mingw
Daniel, On Fri, Jan 07, 2011 at 06:10:19PM -0800, Daniel Colascione wrote: On Fri, Jan 7, 2011 at 4:25 PM, JonY wrote: IMHO rebaseall shouldn't be interacting with mingw dlls at all. Maybe it can check for dependencies on cygwin1.dll before rebasing? That's the point. The mingw DLLs need to be added to rebaseall's filter pattern. The above is on my to do list. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: skipping file `...', as it was replaced while being copied
From: Eric Blake On 01/07/2011 01:06 PM, Nellis, Kenneth wrote: Using Cygwin 1.7.7, the following behavior started recently, but I can't think of any change that may be the culprit: I can. Most likely, you recently ran setup.exe and upgraded tar. Indeed. :-) Upstream tar includes a patch to make it more picky about stat() structures changing behind the scenes, that older tar was ignoring. Which in turn is exposing (yet another) buggy file system that cygwin needs to be taught how to work around. I'm guessing that the tar patch patched more than just tar because: 1) I wasn't invoking tar, just cp; and 2) after downgrading tar to 1.23-1, the behavior persists. How should I downgrade to previous (working) behavior? --Ken Nellis
Re: Brand new setup ends up not where intended (?but at default)
On 2011-01-10 10:58Z, Fergus wrote: Intention: to install legacy version 1.5 on drive I: (ie not default) [...some directories are created on I:, but...] and what has actually happened is that the installation has been placed under C:\cygwin\. I installed it on XP (where it's unsupported) with similar symptoms. I specified C:/cygwin-1_5 as root; but a C:/Cygwin directory was created too, and most of the files wound up there. Two iterations of - remove unwanted default C:/Cygwin - run setup-legacy again gave a working installation in C:/cygwin-1_5 , and no C:/Cygwin . I did NOT clean the registry. Things were properly uninstalled (ie I had umount'ed everything) but without doubt the registry will have had trailing vestigial references to Cygwin and Cygnus Solutions, though essentially empty. Could this be the problem? Probably not: I've seen these symptoms right after reinstalling the OS. -- 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: zsh-4.3.11-1
An updated version of zsh (zsh-4.3.11-1) has been released and
should be at a mirror near you real soon. This is an upstream release.
NOTICE:
===
Version 4.3.11 has just been released. It contains many fixes and some
new features, but, like the previous version (4.3.10 and 4.3.10-dev-2)
this version still exhibits some strange issues on Cygwin.
I have noticed some strange cases where hangs sometimes happen with
subshells and file re-direction. If you encounter these, please report
them with a test case.
As with the 4.3.10 release, this release of Zsh is built with FIFO and
Multi-byte/Unicode support enabled. See Announcement for 4.3.10 for
additional details.
NEWS:
=
(From the release notes:)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
CHANGES FROM PREVIOUS VERSIONS OF ZSH
-
Note also the list of incompatibilities in the README file.
Changes between versions 4.3.10 and 4.3.11
--
When the shell is invoked with the base name of a script, for example as
`zsh scriptname', previous versions of zsh have used the name directly,
whereas other shells use the value of $PATH to find the script. The
option PATH_SCRIPT has been added to provide the alternative behaviour.
This is turned on where appropriate in compatibility modes.
Parameters, globbing, etc.
-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter expansion has been enhanced to provide the ${NAME:OFFSET} and
${NAME:OFFSET:LENGTH} syntax for substrings and subarrays present in
several other shells. OFFSET always uses zero-based indexing. The only
clash with existing zsh syntax occurs if OFFSET begins with an
alphabetic character or `', which is not likely.
The (D) flag in parameter expansion abbreviates directories in the
substituted value. The (q-) flag does minimal shell quotation of arguments
for maximum human readability of the result.
The (Z) flag in parameter expansion is an enhanced version of the (z)
flag that takes an argument indicating how the string to be split
is treated. (Z:c:) parses comments as strings; (Z:C:) parses comments
and strips them; (Z:n:) treats newlines as ordinary whitespace: (z)
has always treated unquoted newlines as shell delimiters and turned them
into semicolons, though this was not previously documented.
Numeric expansion with braces has been extended so that a step may be
given, as in {3..9..2}. The step may be negative as may the start and
end of the range (this is also new).
The glob qualifier P can be used to add a separate word before each
match. For example, *(P:-f:) produces the command line
`-f file1 -f file2 ...'.
Regular expression matches now use the same variables for storing matched
components as shell pattern matching. The function system now provides the
function regexp-replace for replacing text using regular expressions. The
zle widget functions replace-string, replace-string-again, if defined with
regex in the name (e.g. zle -N replace-regexp replace-string), perform
regular expression matches. In replacement text \ and \1 have the
standard meaning.
Line editor and completion
-+-+-+-+-+-+-+-+-+-+-+-+-+
The completion system now has a style path-completion. Setting this to
false inhibits completion of paths before the current path component,
e.g. /u/b/z no longer completes to /usr/bin/zsh. This is useful on systems
where this form of completion is pathologically slow due to network
performance.
With the MULTIBYTE option, the line editor now highlights bytes in the
input that are not part of a valid character in the current locale in hex
as XX for hex digits X; highlighting is controlled by the special
keyword in the zle_highlight array. These can be distinguished from
unprintable Unicode characters which also use special highlighting as the
latter are always two or four bytes long, e.g. , .
zle_highlight also controls highlighting of a removable completion
suffix, e.g. the / automatically appended to directories. This uses
the keyword suffix.
The line editor now sets the variable ZLE_LINE_ABORTED if there is
an error when editing the line. The following code can be used
to create a bindable editor widget to restore the aborted line:
recover-line() { LBUFFER=$ZLE_LINE_ABORTED RBUFFER=; }
zle -N recover-line
and then either bind recover-line to a key sequence or use
`M-x recover-line RET'.
The parameter ZLE_STATE, available in user-defined line editor widgets,
gives information on the state of the line editor. Currently this is
whether the line editor is in insert or overwrite mode.
Miscellaneous options
-+-+-+-+-+-+-+-+-+-+-
The new shell option HIST_LEX_WORDS causes history lines read in from
a file to be split in the same way as normal shell lines, instead of
simply on whitespace. It's an option as although the result is more
accurate it can take a long time when the history size is large.
The shell option
Re: skipping file `...', as it was replaced while being copied
On 1/10/2011 8:55 AM, Nellis, Kenneth wrote: From: Eric Blake On 01/07/2011 01:06 PM, Nellis, Kenneth wrote: Using Cygwin 1.7.7, the following behavior started recently, but I can't think of any change that may be the culprit: I can. Most likely, you recently ran setup.exe and upgraded tar. Indeed. :-) Upstream tar includes a patch to make it more picky about stat() structures changing behind the scenes, that older tar was ignoring. Which in turn is exposing (yet another) buggy file system that cygwin needs to be taught how to work around. I'm guessing that the tar patch patched more than just tar because: 1) I wasn't invoking tar, just cp; and 2) after downgrading tar to 1.23-1, the behavior persists. How should I downgrade to previous (working) behavior? Rerun 'setup.exe' and click on the version next to the tar package until you see the previous one display. Continue from there. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
ssh and sshd hanging
Hello all, WinXP SP 3, Cygwin1.dll 1.7.7 (latest stable download), sshd and ssh latest stable. I created a root user (!), empty /var/empty that belongs to root, but deviate (by ssh-host-config) from the standard by Port 22 StrictModes no UsePrivilegeSeparation no Compression no Subsystem sftp/usr/sbin/sftp-server I did my mkpasswd -l /etc/passwd mkgroup -l /etc/group Connection establishes but I cannot continue to work (note the line debug1: Connection established): mar...@martin004 ~ $ cygrunsrv --start sshd mar...@martin004 ~ $ strace -f -o /tmp/strace.out ssh -vvv mar...@192.168.178.2 OpenSSH_5.6p1, OpenSSL 0.9.8q 2 Dec 2010 debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.178.2 [192.168.178.2] port 22. debug1: Connection established. debug1: identity file /home/martin/.ssh/id_rsa type -1 debug1: identity file /home/martin/.ssh/id_rsa-cert type -1 debug3: Not a RSA1 key file /home/martin/.ssh/id_dsa. debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug1: identity file /home/martin/.ssh/id_dsa type 2 debug1: ssh_dss_verify: signature correct debug1: identity file /home/martin/.ssh/id_dsa-cert type 4 Funnily enough, /tmp/strace.out shows (less with line numbers) 102490 285650 [main] ssh 928 fhandler_base::set_flags: flags 0x10, supplied_bin 0x1 102536 285686 [main] ssh 928 fhandler_base::set_flags: filemode set to text 102638 285724 [main] ssh 928 fhandler_base::open: 0 = NtCreateFile (0x5D0, 8010, \??\C:\cygwin\home\martin\.ssh\id_dsa-c o, NULL, 0, 7, 1, 4020, NULL, 0) 1027 338 286062 [main] ssh 928 fhandler_base::open: 1 = fhandler_base::open (\??\C:\cygwin\home\martin\.ssh\id_dsa-cert.pub, 0 102849 286111 [main] ssh 928 fhandler_base::open_fs: 1 = fhandler_disk_file::open (\??\C:\cygwin\home\martin\.ssh\id_dsa-cer ) 102940 286151 [main] ssh 928 open: 4 = open (/home/martin/.ssh/id_dsa-cert.pub, 0x0) 1030 177 286328 [main] ssh 928 _cygwin_istext_for_stdio: fd 4: defaulting to text 1031 235 286563 [main] ssh 928 cygpsid::debug_print: get_sids_info: owner SID = S-1-5-21-484763869-823518204-682003330-1005 103248 286611 [main] ssh 928 cygpsid::debug_print: get_sids_info: group SID = S-1-5-21-484763869-823518204-682003330-513 103342 286653 [main] ssh 928 get_info_from_sd: ACL 1A4, uid 1005, gid 513 103445 286698 [main] ssh 928 fhandler_base::fstat_helper: 0 = fstat (\??\C:\cygwin\home\martin\.ssh\id_dsa-cert.pub, 0x23831 e=4D2B76EC st_size=1605, st_mode=0x81A4, st_ino=125256364636259231, sizeof=96 103564 286762 [main] ssh 928 fstat64: 0 = fstat (4, 0x238318) 103661 286823 [main] ssh 928 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 103734 286857 [main] ssh 928 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x1 103841 286898 [main] ssh 928 fhandler_base::set_flags: filemode set to binary 103941 286939 [main] ssh 928 setmode: (4\??\C:\cygwin\home\martin\.ssh\id_dsa-cert.pub, 0x1) returning text 104037 286976 [main] ssh 928 readv: readv (4, 0x238334, 1) blocking, sigcatchers 0 104194 287070 [main] ssh 928 fhandler_base::read: returning 1605, binary mode 104231 287101 [main] ssh 928 readv: 1605 = readv (4, 0x238334, 1), errno 2 104338 287139 [main] ssh 928 fhandler_base::set_flags: flags 0x12, supplied_bin 0x0 104441 287180 [main] ssh 928 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x2 104538 287218 [main] ssh 928 fhandler_base::set_flags: filemode set to text 104632 287250 [main] ssh 928 setmode: (4\??\C:\cygwin\home\martin\.ssh\id_dsa-cert.pub, 0x2) returning binary 1047 10227 297477 [main] ssh 928 fhandler_console::write: 237E88, 43 104858 297535 [main] ssh 928 fhandler_console::write: at 100(d) state is 0 1049 180 297715 [main] ssh 928 fhandler_console::write: at 10(0x20) state is 0 105073 297788 [main] ssh 928 fhandler_console::write: 43 = fhandler_console::write (,..43) 1051 934 298722 [main] ssh 928 close: close (4) 105241 298763 [main] ssh 928 fhandler_base::close: closing '/home/martin/.ssh/id_dsa-cert.pub' handle 0x5D0 1053 520 299283 [main] ssh 928 close: 0 = close (4) 1054 320 299603 [main] ssh 928 fhandler_console::write: 23B088, 60 105537 299640 [main] ssh 928 fhandler_console::write: at 100(d) state is 0 1056 142 299782 [main] ssh 928 fhandler_console::write: at 10(0x20) state is 0 105774 299856 [main] ssh
Fwd: [ctypes-users] pyusb under Cygwin and stdcall libusb-1.0
Just wondering if I can have the answer here. Thanks. Please CC me as I am not subscribed. Thanks. -- Xiaofan -- Forwarded message -- From: Andrew MacIntyre andrew.macint...@acma.gov.au Date: Tue, Jan 11, 2011 at 1:24 PM Subject: RE: [ctypes-users] pyusb under Cygwin and stdcall libusb-1.0 [SEC=UNCLASSIFIED] To: Xiaofan Chen xiaof...@gmail.com, ctypes-us...@lists.sourceforge.net On Tue, Jan 11, 2011 at 10:40 AM, Xiaofan Chen xiaof...@gmail.com wrote: http://sourceforge.net/mailarchive/message.php?msg_id=26873757 There seems to be problems to get pyusb to work under Cygwin. The author asks if Cygwin libusb-1.0 should use stdcall or not? http://sourceforge.net/mailarchive/message.php?msg_id=26873777 Normal Python under Windows can support either cdecl (CDLL) or stdcall (WinDLL). The problem is that Cygwin Ctypes only supports cdecl. Therefore it is not possible to load cygusb-1.0.dll and pyusb's libusb-1.0 backend will not work under Cygwin as a result. Just wondering why Ctypes under Cygwin does not support WinDLL? Take note os.name == 'posix' under Cygwin Python. I have updated Cygwin installation to the latest version. Just wondering why Ctypes under Cygwin does not support WinDLL? Take note os.name == 'posix' under Cygwin Python. That really is a question for the maintainer of Python on Cygwin. It may be because the necessary libffi plumbing isn't in yet place on that platform. -- 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: zsh-4.3.11-1
An updated version of zsh (zsh-4.3.11-1) has been released and
should be at a mirror near you real soon. This is an upstream release.
NOTICE:
===
Version 4.3.11 has just been released. It contains many fixes and some
new features, but, like the previous version (4.3.10 and 4.3.10-dev-2)
this version still exhibits some strange issues on Cygwin.
I have noticed some strange cases where hangs sometimes happen with
subshells and file re-direction. If you encounter these, please report
them with a test case.
As with the 4.3.10 release, this release of Zsh is built with FIFO and
Multi-byte/Unicode support enabled. See Announcement for 4.3.10 for
additional details.
NEWS:
=
(From the release notes:)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
CHANGES FROM PREVIOUS VERSIONS OF ZSH
-
Note also the list of incompatibilities in the README file.
Changes between versions 4.3.10 and 4.3.11
--
When the shell is invoked with the base name of a script, for example as
`zsh scriptname', previous versions of zsh have used the name directly,
whereas other shells use the value of $PATH to find the script. The
option PATH_SCRIPT has been added to provide the alternative behaviour.
This is turned on where appropriate in compatibility modes.
Parameters, globbing, etc.
-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter expansion has been enhanced to provide the ${NAME:OFFSET} and
${NAME:OFFSET:LENGTH} syntax for substrings and subarrays present in
several other shells. OFFSET always uses zero-based indexing. The only
clash with existing zsh syntax occurs if OFFSET begins with an
alphabetic character or `', which is not likely.
The (D) flag in parameter expansion abbreviates directories in the
substituted value. The (q-) flag does minimal shell quotation of arguments
for maximum human readability of the result.
The (Z) flag in parameter expansion is an enhanced version of the (z)
flag that takes an argument indicating how the string to be split
is treated. (Z:c:) parses comments as strings; (Z:C:) parses comments
and strips them; (Z:n:) treats newlines as ordinary whitespace: (z)
has always treated unquoted newlines as shell delimiters and turned them
into semicolons, though this was not previously documented.
Numeric expansion with braces has been extended so that a step may be
given, as in {3..9..2}. The step may be negative as may the start and
end of the range (this is also new).
The glob qualifier P can be used to add a separate word before each
match. For example, *(P:-f:) produces the command line
`-f file1 -f file2 ...'.
Regular expression matches now use the same variables for storing matched
components as shell pattern matching. The function system now provides the
function regexp-replace for replacing text using regular expressions. The
zle widget functions replace-string, replace-string-again, if defined with
regex in the name (e.g. zle -N replace-regexp replace-string), perform
regular expression matches. In replacement text \ and \1 have the
standard meaning.
Line editor and completion
-+-+-+-+-+-+-+-+-+-+-+-+-+
The completion system now has a style path-completion. Setting this to
false inhibits completion of paths before the current path component,
e.g. /u/b/z no longer completes to /usr/bin/zsh. This is useful on systems
where this form of completion is pathologically slow due to network
performance.
With the MULTIBYTE option, the line editor now highlights bytes in the
input that are not part of a valid character in the current locale in hex
as XX for hex digits X; highlighting is controlled by the special
keyword in the zle_highlight array. These can be distinguished from
unprintable Unicode characters which also use special highlighting as the
latter are always two or four bytes long, e.g. , .
zle_highlight also controls highlighting of a removable completion
suffix, e.g. the / automatically appended to directories. This uses
the keyword suffix.
The line editor now sets the variable ZLE_LINE_ABORTED if there is
an error when editing the line. The following code can be used
to create a bindable editor widget to restore the aborted line:
recover-line() { LBUFFER=$ZLE_LINE_ABORTED RBUFFER=; }
zle -N recover-line
and then either bind recover-line to a key sequence or use
`M-x recover-line RET'.
The parameter ZLE_STATE, available in user-defined line editor widgets,
gives information on the state of the line editor. Currently this is
whether the line editor is in insert or overwrite mode.
Miscellaneous options
-+-+-+-+-+-+-+-+-+-+-
The new shell option HIST_LEX_WORDS causes history lines read in from
a file to be split in the same way as normal shell lines, instead of
simply on whitespace. It's an option as although the result is more
accurate it can take a long time when the history size is large.
The shell option
