Re: RFU: cppcheck-1.47-1

[Andy Koppe]

On 9 February 2011 02:46, Chris Sutcliffe wrote:
 Please upload:

 ---

 wget -x -nH --cut-dirs=1 \
 http://emergedesktop.org/cygwin/cppcheck/setup.hint  \
 http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.47-1.tar.bz2  \
 http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.47-1-src.tar.bz2

 ---

 I've updated setup.hint for this release to require libgcc1 and libstdc++6.

 Please leave 1.46.1 as previous and feel free to remove older releases.

Done and done.

Thanks,
Andy

Re: [RFU] zsh-4.3.11-2

[Christopher Faylor]

On Tue, Jan 25, 2011 at 09:15:53PM -0800, Peter A. Castro wrote:
Hmm... I was sure I'd waited until they appeared in the mirrors.

You don't have to wait until they appeared in mirrors since that's a
very variable thing.  It is best to wait until someone has acked your
RFU request, though (as I'm sure you know).

cgf

Re: [ITA] - base-files

[Charles Wilson]

On 2/6/2011 4:40 PM, David Sastre wrote:
 I have a question yet: is there a consistent way of knowing
 the GID of users with administrative privileges (from a windows
 perspective) so that could be used to add /usr/sbin to their paths? 

AFAIK, this requires Win32 C code.  Take a look at the code in winsec.c
that is part of cygwin's login package -- and how it is used in login.c
to determine Administrator membership (see isROOT_UID() in login,.c).

It's possible some part of this functionality could be added to an
executable utility in cygutils or csih, but...should base-files really
depend on either of those packages?  Maybe instead, base-files should
also ship some new utility .exe for this purpose in /usr/bin/?

 Would that be useful?

Maybe, but admin user accounts can always add /usr/sbin themselves, in
~/.bash_profile or ~/.bashrc.  (I usually don't bother, and just invoke
sbin progs by full path).  Dunno if it's worth the effort.

--
Chuck

Re: [ITA] - base-files

[Corinna Vinschen]

On Feb  9 10:42, Charles Wilson wrote:
 On 2/6/2011 4:40 PM, David Sastre wrote:
  I have a question yet: is there a consistent way of knowing
  the GID of users with administrative privileges (from a windows
  perspective) so that could be used to add /usr/sbin to their paths? 
 
 AFAIK, this requires Win32 C code.  Take a look at the code in winsec.c
 that is part of cygwin's login package -- and how it is used in login.c
 to determine Administrator membership (see isROOT_UID() in login,.c).
 
 It's possible some part of this functionality could be added to an
 executable utility in cygutils or csih, but...should base-files really
 depend on either of those packages?  Maybe instead, base-files should
 also ship some new utility .exe for this purpose in /usr/bin/?

When you call mkgroup, you have the admins group with gid 544.  It will
be in the user token and id(1) will contain it in its output.  We
should really start to rely on that.  Here's the test I'm doing:

admin=$(/usr/bin/id -G | /usr/bin/grep -Eq '\544\'  echo yes || echo no)

  Would that be useful?
 
 Maybe, but admin user accounts can always add /usr/sbin themselves, in
 ~/.bash_profile or ~/.bashrc.  (I usually don't bother, and just invoke
 sbin progs by full path).  Dunno if it's worth the effort.

I agree.  It's an interesting idea but it costs an extra call to one or
more external applications in the profile which most users won't need.
I guess we should avoid that.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

AW: AW: clipboard integration doesn't work

[Paul Maier]

 As a workaround, you could perhaps set your locale to 
 de_DE.ISO8859-1 (which
 is a subset of CP1252), if you actually need to work with 
 CP1252 encoded data,


Hi Jon, that WORKS!!  8-)))

Thanks for the help. It's fine for me now.
Paul


--
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: Can't use XDMCP, winProcEstablishConnection - ProcEstablishConnection failed, bailing shows in log

[Alexander Pokluda]

Here is an excerpt from /var/log/messages on the VM that I'm trying to
connect to with XWin.

This is what appears in the log after running

XWin -from 10.3.20.159 -query 10.3.147.100

Feb  8 11:22:08 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
QUERY from client 10.3.20.159
Feb  8 11:22:08 dev01 gdm[4097]: gdm_xdmcp_handle_query: Opcode 2 from
10.3.20.159
Feb  8 11:22:08 dev01 gdm[4097]: gdm_xdmcp_host_allow:
client-hostname is ci001138531.xxx.net
Feb  8 11:22:08 dev01 gdm[4097]: gdm_xdmcp_send_willing: Sending
WILLING to 10.3.20.159
Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
QUERY from client 10.3.20.159
Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_handle_query: Opcode 2 from
10.3.20.159
Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_host_allow:
client-hostname is ci001138531.xxx.net
Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_send_willing: Sending
WILLING to 10.3.20.159
Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
QUERY from client 10.3.20.159
Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_handle_query: Opcode 2 from
10.3.20.159
Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_host_allow:
client-hostname is ci001138531.xxx.net
Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_send_willing: Sending
WILLING to 10.3.20.159
Feb  8 11:27:45 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
QUERY from client 10.3.20.159
Feb  8 11:27:45 dev01 gdm[4097]: gdm_xdmcp_handle_query: Opcode 2 from
10.3.20.159
Feb  8 11:27:45 dev01 gdm[4097]: gdm_xdmcp_host_allow:
client-hostname is ci001138531.xxx.net
Feb  8 11:27:45 dev01 gdm[4097]: gdm_xdmcp_send_willing: Sending
WILLING to 10.3.20.159
[...]

It seems that the REQUEST message sent by XWin somehow gets lost.
Although it shows up in the Wireshark trace, it never shows up in the
log on the VM. By contrast, this is what appears in the log when
making a successful connection with XLaunch/Xming:

Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
QUERY from client 10.3.20.159
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_handle_query: Opcode 2 from
10.3.20.159
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_host_allow:
client-hostname is ci001138531.xxx.net
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_send_willing: Sending
WILLING to 10.3.20.159
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
REQUEST from client 10.3.20.159
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_handle_request: Got REQUEST
from 10.3.20.159
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_host_allow:
client-hostname is ci001138531.xxx.net
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_displays_check: Disposing
session id 971069010
Feb  8 11:28:39 dev01 gdm[4097]: gdm_display_dispose: Disposing dev01.xxx.net:2
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_handle_request:
xdmcp_pending=0, MaxPending=4, xdmcp_sessions=0, MaxSessions=16,
ManufacturerID=
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_display_dispose_check
(ci001138531.xxx.net:0)
Feb  8 11:28:39 dev01 gdm[4097]: gdm_auth_secure_display: Setting up
access for ci001138531.xxx.net:0
Feb  8 11:28:39 dev01 gdm[4097]: gdm_auth_secure_display: Setting up access
Feb  8 11:28:39 dev01 gdm[4097]: gdm_auth_secure_display: Setting up
access for ci001138531.xxx.net:0 - 1 entries
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_display_alloc:
display=ci001138531.xxx.net:0, session id=971069011,
xdmcp_pending=1
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_send_accept: Sending ACCEPT
to 10.3.20.159 with SessionID=971069011
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
MANAGE from client 10.3.20.159
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_handle_manage: Got MANAGE
from 10.3.20.159
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_host_allow:
client-hostname is ci001138531.xxx.net
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_handle_manage: Got
Display=0, SessionID=971069011 Class=MIT-unspecified from 10.3.20.159
Feb  8 11:28:39 dev01 gdm[4097]: gdm_xdmcp_handle_manage: Looked up
ci001138531.xxx.net:0
Feb  8 11:28:39 dev01 gdm[4097]: gdm_choose_indirect_lookup: Host
10.3.20.159 not found
Feb  8 11:28:39 dev01 gdm[4097]: gdm_forward_query_lookup: Host
10.3.20.159 not found
Feb  8 11:28:39 dev01 gdm[4097]: gdm_display_manage: Managing
ci001138531.xxx.net:0
Feb  8 11:28:39 dev01 gdm[4097]: loop check: last_start 0, last_loop
0, now: 1297182519, retry_count: 0
Feb  8 11:28:39 dev01 gdm[4097]: Resetting counts for loop of death detection
Feb  8 11:28:39 dev01 gdm[4097]: gdm_display_manage: Forked slave: 12208
Feb  8 11:28:39 dev01 gdm[12208]: gdm_slave_start: Starting slave
process for ci001138531.xxx.net:0
Feb  8 11:28:39 dev01 gdm[12208]: gdm_slave_start: Loop Thingie
Feb  8 11:28:40 dev01 gdm[12208]: gdm_slave_run: Opening display
ci001138531.xxx.net:0
Feb  8 11:28:40 dev01 gdm[12208]: gdm_slave_greeter: Running greeter
on ci001138531.xxx.net:0
Feb  8 11:28:40 dev01 gdm[12208]: gdm_slave_greeter: Greeter on pid 12218
[...]


On Tue, Feb 8, 2011 at 5:00 

Re: Can't use XDMCP, winProcEstablishConnection - ProcEstablishConnection failed, bailing shows in log

[Jon TURNEY]

Firstly, thanks very much for taking the time to collect so much detailed
information about this problem.

On 09/02/2011 15:36, Alexander Pokluda wrote:
 Here is an excerpt from /var/log/messages on the VM that I'm trying to
 connect to with XWin.
 
 This is what appears in the log after running
 
 XWin -from 10.3.20.159 -query 10.3.147.100
 
 Feb  8 11:22:08 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
 QUERY from client 10.3.20.159
 Feb  8 11:22:08 dev01 gdm[4097]: gdm_xdmcp_handle_query: Opcode 2 from
 10.3.20.159
 Feb  8 11:22:08 dev01 gdm[4097]: gdm_xdmcp_host_allow:
 client-hostname is ci001138531.xxx.net
 Feb  8 11:22:08 dev01 gdm[4097]: gdm_xdmcp_send_willing: Sending
 WILLING to 10.3.20.159
 Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_decode: Received opcode
 QUERY from client 10.3.20.159
 Feb  8 11:24:16 dev01 gdm[4097]: gdm_xdmcp_handle_query: Opcode 2 from
 10.3.20.159
[snip]

 It seems that the REQUEST message sent by XWin somehow gets lost.
 Although it shows up in the Wireshark trace, it never shows up in the
 log on the VM.

The other alternative is that the REQUEST arrives at the VM, but gdm doesn't
like the contents for some reason.  Possibly you could check that by
wiresharking at that end.

 On Tue, Feb 8, 2011 at 5:00 PM, Alexander Pokluda apokl...@gmail.com wrote:
 Sorry for the delay in my response.

 No, I am not runnig the VMs locally. These VMs are being run and
 managed in a lab that I don't have access to, but I am expected to use
 VMs in the lab for development and testing on a new project.

 I have one physical network adapter in my computer and several virtual
 adapters since I do have VMware Workstation and Virtual Box installed.
 The IP address of the physical adapter is a static IP address set to
 10.3.20.159 with /24 subnet mask. The VM that I've been trying to
 connect to has IP address 10.3.147.100 and /24 subnet mask. Running

 XWin -from 10.3.20.159 -query 10.3.147.100

 doesn't work. A blank window opens and eventually closes and re-opens.
 This goes on indefinitely. In the attached Wireshark trace, you can
 see a cycle of query-willing-request-request...-query-willing-request-request
 after running this command in Cygwin:

 No. TimeSourceDestination   Protocol Info
   3219 253.037685  10.3.20.159   10.3.147.100  XDMCPQuery

 No. TimeSourceDestination   Protocol Info
   3220 253.043332  10.3.147.100  10.3.20.159   XDMCP
 Willing

 No. TimeSourceDestination   Protocol Info
   3331 254.061501  10.3.20.159   10.3.147.100  XDMCP
 Request

 No. TimeSourceDestination   Protocol Info
   3361 257.044353  10.3.20.159   10.3.147.100  XDMCP
 Request

 [...]

 I've also attached a Wireshark trace capturing when using XLaunch to
 start an XDMCP session using Xming. In this trace, you can see the
 expected query-willing-request-accept sequence:

 No. TimeSourceDestination   Protocol Info
129 14.553230   10.3.20.159   10.3.147.100  XDMCPQuery

 No. TimeSourceDestination   Protocol Info
130 14.554923   10.3.147.100  10.3.20.159   XDMCP
 Willing

 No. TimeSourceDestination   Protocol Info
135 15.226412   10.3.20.159   10.3.147.100  XDMCP
 Request

 No. TimeSourceDestination   Protocol Info
136 15.231235   10.3.147.100  10.3.20.159   XDMCP
 Accept

I wonder if you could send me privately the Wireshark .pcap files for these
traces, I'd like to examine them further.

A significant difference is in the Connections data sent in the REQUEST packet
(which is a list of network addresses the requestor knows for itself)

Xming 6.9:

X Display Manager Control Protocol
Version: 1
Opcode: Request (0x0007)
Message length: 81
Display number: 0
Connections (1)
Authentication name:
Authentication data (0 bytes)
Authorization names (3)
Manufacturer display ID:

vs.

XWin

X Display Manager Control Protocol
Version: 1
Opcode: Request (0x0007)
Message length: 220
Display number: 0
Connections (9)
Authentication name:
Authentication data (0 bytes)
Authorization names (2)
Manufacturer display ID:

I could understand 8 (the total number of IPv4 and IPv6 interfaces your host
has), if you weren't using -from, but 9 is a bit confusing.

I would expect Xming 6.9 to report fewer interfaces, since it was built
without IPv6 support, but I'm not sure why it's only reporting 1, if you
aren't using -from.

It seems likely that IPv6 support in XWin is the difference which prevents
things from working correctly.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe 

winsup/cygwin exception.h ChangeLog

[cgf]

CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: c...@sourceware.org 2011-02-09 15:40:39

Modified files:
cygwin : exception.h ChangeLog 

Log message:
* exception.h: Remove DEBUG_EXCEPTION left over debugging ifdef.
* dll_init.cc: Fix typo in comment.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/exception.h.diff?cvsroot=uberbaumr1=1.3r2=1.4
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5147r2=1.5148

winsup/cygwin ChangeLog hookapi.cc

[cgf]

CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: c...@sourceware.org 2011-02-09 15:46:00

Modified files:
cygwin : ChangeLog hookapi.cc 

Log message:
* hookapi.cc (hook_or_detect_cygwin): Prevent i from being considered
uninitialized by gcc.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5148r2=1.5149
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/hookapi.cc.diff?cvsroot=uberbaumr1=1.19r2=1.20

winsup/cygwin cygheap.cc ChangeLog lib/cygwin_ ...

[cgf]

CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: c...@sourceware.org 2011-02-10 02:22:36

Modified files:
cygwin : cygheap.cc ChangeLog 
cygwin/lib : cygwin_crt0.c 

Log message:
* cygheap.cc: Add some __stdcall decoration where appropriate.
* lib/cygwin_crt0.c: __attribute - __attribute__.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/cygheap.cc.diff?cvsroot=uberbaumr1=1.155r2=1.156
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5149r2=1.5150
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/lib/cygwin_crt0.c.diff?cvsroot=uberbaumr1=1.11r2=1.12

Re: provide __xpg_strerror_r

[Christopher Faylor]

On Wed, Feb 09, 2011 at 05:20:59PM -0700, Eric Blake wrote:
On 02/06/2011 02:54 AM, Corinna Vinschen wrote:
 We already provide our own strerror() (it provides a better experience
 for out-of-range values that the newlib interface), but we're currently
 using the newlib strerror_r() (in spite of its truncation flaw).

 How should I rework this patch?
 
 It would be better if we implement strerror_r locally, in two versions,
 just as on Linux.  I think the best approach is to implement this in
 newlib first (I replied to your mail there) and then, given that we use
 the newlib string.h, copy the method over to Cygwin to match our current
 strerror more closely.

Here's the cygwin side of things, to match newlib's string.h changes.
 Surprisingly, strerror_r turned out to be identical even when based on
different root strerror(), so I left that inside #if 0, but it's easy
enough to kill the #if 0 if you don't want cygwin to use any of newlib's
strerror*.

---
 winsup/cygwin/ChangeLog|9 +++
 winsup/cygwin/cygwin.din   |1 +
 winsup/cygwin/errno.cc |   84
+---
 winsup/cygwin/include/cygwin/version.h |3 +-
 4 files changed, 68 insertions(+), 29 deletions(-)

2011-02-09  Eric Blake  ebl...@redhat.com

   * errno.cc (__xpg_strerror_r): New function.
   (strerror_r): Update comments to match newlib's fixes.
   (strerror): Set errno on failure.
   (_sys_errlist): Cause EINVAL failure for reserved values.
   * cygwin.din: Export new function.
   * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

diff --git a/winsup/cygwin/cygwin.din b/winsup/cygwin/cygwin.din
index 2e7e647..780179a 100644
--- a/winsup/cygwin/cygwin.din
+++ b/winsup/cygwin/cygwin.din
@@ -1933,6 +1933,7 @@ xdrrec_skiprecord SIGFE
 __xdrrec_getrec SIGFE
 __xdrrec_setnonblock SIGFE
 xdrstdio_create SIGFE
+__xpg_strerror_r SIGFE
 y0 NOSIGFE
 y0f NOSIGFE
 y1 NOSIGFE
diff --git a/winsup/cygwin/errno.cc b/winsup/cygwin/errno.cc
index a9860f4..0e9c863 100644
--- a/winsup/cygwin/errno.cc
+++ b/winsup/cygwin/errno.cc
@@ -199,9 +199,9 @@ const char *_sys_errlist[] NO_COPY_INIT =
 /* EL2HLT 44 */ Level 2 halted,
 /* EDEADLK 45 */Resource deadlock avoided,
 /* ENOLCK 46 */ No locks available,
-error 47,
-error 48,
-error 49,
+NULL,
+NULL,
+NULL,
 /* EBADE 50 */  Invalid exchange,
 /* EBADR 51 */  Invalid request descriptor,
 /* EXFULL 52 */ Exchange full,
@@ -210,8 +210,8 @@ const char *_sys_errlist[] NO_COPY_INIT =
 /* EBADSLT 55 */Invalid slot,
 /* EDEADLOCK 56 */  File locking deadlock error,
 /* EBFONT 57 */ Bad font file format,
-error 58,
-error 59,
+NULL,
+NULL,
 /* ENOSTR 60 */ Device not a stream,
 /* ENODATA 61 */No data available,
 /* ETIME 62 */  Timer expired,
@@ -224,13 +224,13 @@ const char *_sys_errlist[] NO_COPY_INIT =
 /* ESRMNT 69 */ Srmount error,
 /* ECOMM 70 */  Communication error on send,
 /* EPROTO 71 */ Protocol error,
-error 72,
-error 73,
+NULL,
+NULL,
 /* EMULTIHOP 74 */  Multihop attempted,
 /* ELBIN 75 */  Inode is remote (not really error),
 /* EDOTDOT 76 */RFS specific error,
 /* EBADMSG 77 */Bad message,
-error 78,
+NULL,
 /* EFTYPE 79 */ Inappropriate file type or format,
 /* ENOTUNIQ 80 */   Name not unique on network,
 /* EBADFD 81 */ File descriptor in bad state,
@@ -245,17 +245,17 @@ const char *_sys_errlist[] NO_COPY_INIT =
 /* ENOTEMPTY 90   */Directory not empty,
 /* ENAMETOOLONG 91 */   File name too long,
 /* ELOOP 92 */  Too many levels of symbolic links,
-error 93,
-error 94,
+NULL,
+NULL,
 /* EOPNOTSUPP 95 */ Operation not supported,
 /* EPFNOSUPPORT 96 */   Protocol family not supported,
-error 97,
-error 98,
-error 99,
-error 100,
-error 101,
-error 102,
-error 103,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+  

Re: [PATCH] pthread_yield

[Christopher Faylor]

On Wed, Feb 09, 2011 at 11:49:58PM -0600, Yaakov (Cygwin/X) wrote:
pthread_yield(3) was part of the POSIX.1c drafts but never made it into
the final standard.  Nevertheless, it is provided by Linux[1],
FreeBSD[2], OpenBSD[3], AIX[4], and possibly other *NIXes.  

On Linux, this function is implemented as a call to sched_yield(2).
Patch attached.

Please check in.

Thanks.

cgf

Re: /bin/rebaseall fails

[Rafael Kitover]

On 2/8/2011 10:42 AM, David Means wrote:

When running rebaseall, I receive a #13 error from FixImage:

$ /bin/rebaseall
/usr/lib/cygicudata.dll: skipped because nonexistent
/usr/lib/cygicui18n.dll: skipped because nonexistent
/usr/lib/cygicuio.dll: skipped because nonexistent
/usr/lib/cygicule.dll: skipped because nonexistent
/usr/lib/cygiculx.dll: skipped because nonexistent
/usr/lib/cygicutu.dll: skipped because nonexistent
/usr/lib/cygicuuc.dll: skipped because nonexistent
FixImage (/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll) failed
  with last error = 13
$
You have to skip mingw .dlls, I was told this would be fixed in the next 
version of rebaseall.


--
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: after ssh connection is getting closed

[Corinna Vinschen]

On Feb  9 12:14, Sarkar, Kaushik wrote:
 After connecting through ssh immediately my connection is getting
 closed.

I can't reproduce this problem, neither with Cygwin 1.7.7, nor with the
latest Cygwin from CVS, neither with OpenSSH 5.6, nor 5.7, nor 5.8.

However, I *could* reproduce it on my machine when trying to login using
another account than my own.  After some digging it turned out that one
of my DLLs in /bin had 700 permissions, rather than the correct 755
permissions.  That was a result of some debugging I did a couple of days
back.  Anyway, after fixing that, the login worked fine.  Just calling
`chmod 755 /bin/*.dll' did the trick.

Here's another potential cause:  Right now there appears to be a problem
with the latest bash (see the mailing list archives of the last few
days), but for some unknown reason the problem doesn't manifest on all
machines.
I assume you didn't only update cygwin or openssh, but all packages.
Restart setup and revert bash to the older 3.2.51-24 and see if it fixes
your problem.  Or, set the login shell of the account you're trying
to login to to /bin/dash, or /bin/tcsh, or any other non-bash shell
available.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.7: after upgrade lost ability to login via ssh

[Corinna Vinschen]

On Feb  8 21:14, Gerry Reno wrote:
 Something else I just discovered after upgrading to 1.7.7 is that I now
 have lost the ability to login via ssh.
 
 I have OpenSSH installed and running sshd as a service.  Both password
 and keys accepted.  But now neither means will work.
 
 # ssh -i keypair1.pem   Administrator@MACHINE_IP
 Last login: Fri Feb  4 17:19:26 2011 from LOCAL_CLIENT_MACHINE
 Connection to MACHINE_IP closed.
 
 
 So I increased verbosity but did not see anything obvious.

http://cygwin.com/ml/cygwin/2011-02/msg00236.html


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

AW: AW: How to make ls as quick as a Windows dir?

[Paul Maier]

 
 Perhaps it's time for a full problem report.  See the link below for
 specifics on what should be in such a report.
 
 http://cygwin.com/problems.html
 

Larry, for the cygcheck log: 
please mail (only to) me your personal e-mail address.
I can't mail the file to the list.

Paul.


--
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: cppcheck-1.47-1

[Chris Sutcliffe]

Version 1.47-1 of cppcheck has been uploaded, following the upstream release.

cppcheck is a tool for static C/C++ code analysis.  It tries to detect
bugs that your C/C++ compiler don't see.
The goal is no false positives.

cppcheck is versatile. You can check non-standard code that includes
various compiler extensions, inline assembly code, etc.

For a list of changes see:

http://sourceforge.net/news/?group_id=195752id=295096

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read*all*  of the information on unsubscribing that is
available starting at this URL.

Chris


--
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

ADO does not work from bash

[Rafael Kitover]

I first reported this problem to the Win32::OLE Perl module RT queue,
but as it turns out, the problem is in the Cygwin shell environment and
not in the Cygwin perl or the module.

From Cygwin bash:

$ perl -MWin32::OLE -wle 'Win32::OLE-new(ADODB.Connection)'
Win32::OLE(0.1709) error 0x8007007e: The specified module could not be
found at -e line 1

In a cmd.exe window:

c:\users\rkitoverc:\cygwin\bin\perl -MWin32::OLE -wle
Win32::OLE-new(q{ADODB.Connection})

c:\users\rkitover

that executes successfully.

Any ideas what can cause this?

It seems unlikely to be environment variables as Cygwin leaves most
environment variables alone, and COMSPEC is still set to cmd.exe.

--
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: [patch]another sigsegv in environ.cc

[jojelino]

changes introduced.

all file: add __attribute__ ((regparm (x))) explicitly in function 
definition.

environ.cc fix findenv_func that were not prefixed __stdcall
exception.h add body to prevent compilation error with -DDEBUG_EXCEPTION


fhandler_floppy.cc
hookapi.cc
syscalls.cc
in6.h
passwd.cc

merged with [PATCHes] Misc aliasing fixes for building DLL with gcc-4.5.0
Index: winsup/cygwin/environ.cc
===
RCS file: /cvs/src/src/winsup/cygwin/environ.cc,v
retrieving revision 1.183
diff -u -r1.183 environ.cc
--- winsup/cygwin/environ.cc18 May 2010 14:30:50 -  1.183
+++ winsup/cygwin/environ.cc9 Feb 2011 13:47:57 -
@@ -156,7 +156,7 @@
   to the beginning of the environment variable name.  *in_posix is any
   known posix value for the environment variable. Returns a pointer to
   the appropriate conversion structure.  */
-win_env * __stdcall
+win_env * __stdcall __attribute__ ((regparm (3)))
 getwinenv (const char *env, const char *in_posix, win_env *temp)
 {
   if (!conv_start_chars[(unsigned char)*env])
@@ -219,7 +219,7 @@
   free (src);
   MALLOC_CHECK;
 }
-
+typedef char* (__stdcall *pfnenv)(const char*,int*);
 /* Returns pointer to value associated with name, if any, else NULL.
   Sets offset to be the offset of the name/value combination in the
   environment array, for use by setenv(3) and unsetenv(3).
@@ -253,7 +253,7 @@
 
 /* Primitive getenv before the environment is built.  */
 
-static char __stdcall *
+static char* __stdcall
 getearly (const char * name, int *)
 {
   char *ret;
@@ -275,7 +275,7 @@
   return NULL;
 }
 
-static char * (*findenv_func)(const char *, int *) = (char * (*)(const char *, 
int *)) getearly;
+static pfnenv findenv_func = getearly;
 
 /* Returns ptr to value associated with name, if any, else NULL.  */
 
@@ -830,7 +830,7 @@
   FreeEnvironmentStringsW (rawenv);
 
 out:
-  findenv_func = (char * (*)(const char*, int*)) my_findenv;
+  findenv_func = my_findenv;
   __cygwin_environ = envp;
   update_envptrs ();
   if (envp_passed_in)
@@ -856,7 +856,7 @@
   return strcmp (*p, *q);
 }
 
-char * __stdcall
+char * __stdcall __attribute__ ((regparm (3)))
 getwinenveq (const char *name, size_t namelen, int x)
 {
   WCHAR name0[namelen - 1];
@@ -956,7 +956,7 @@
filled with null terminated strings, terminated by double null characters.
Converts environment variables noted in conv_envvars into win32 form
prior to placing them in the string.  */
-char ** __stdcall
+char ** __stdcall __attribute__ ((regparm (3)))
 build_env (const char * const *envp, PWCHAR envblock, int envc,
   bool no_envblock)
 {
Index: winsup/cygwin/exception.h
===
RCS file: /cvs/src/src/winsup/cygwin/exception.h,v
retrieving revision 1.3
diff -u -r1.3 exception.h
--- winsup/cygwin/exception.h   1 Mar 2010 06:39:47 -   1.3
+++ winsup/cygwin/exception.h   9 Feb 2011 13:47:57 -
@@ -20,8 +20,8 @@
   static int handle (EXCEPTION_RECORD *, exception_list *, CONTEXT *, void *);
 public:
 #ifdef DEBUG_EXCEPTION
-  exception ();
-  ~exception ();
+  exception (){};
+  ~exception (){};
 #else
   exception () __attribute__ ((always_inline))
   {
Index: winsup/cygwin/fhandler_floppy.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_floppy.cc,v
retrieving revision 1.57
diff -u -r1.57 fhandler_floppy.cc
--- winsup/cygwin/fhandler_floppy.cc12 Jan 2011 09:16:51 -  1.57
+++ winsup/cygwin/fhandler_floppy.cc9 Feb 2011 13:47:58 -
@@ -57,7 +57,8 @@
__seterrno ();
   else
{
- di = ((DISK_GEOMETRY_EX *) dbuf)-Geometry;
+ DISK_GEOMETRY_EX *dgx = (DISK_GEOMETRY_EX *) dbuf;
+ di = dgx-Geometry;
  if (!DeviceIoControl (get_handle (),
IOCTL_DISK_GET_PARTITION_INFO_EX, NULL, 0,
pbuf, 256, bytes_read, NULL))
Index: winsup/cygwin/hookapi.cc
===
RCS file: /cvs/src/src/winsup/cygwin/hookapi.cc,v
retrieving revision 1.19
diff -u -r1.19 hookapi.cc
--- winsup/cygwin/hookapi.cc11 Sep 2008 04:34:23 -  1.19
+++ winsup/cygwin/hookapi.cc9 Feb 2011 13:47:59 -
@@ -252,7 +252,7 @@
   fh.origfn = NULL;
   fh.hookfn = fn;
   char *buf = (char *) alloca (strlen (name) + sizeof (_64));
-  int i;
+  int i = -1;
   // Iterate through each import descriptor, and redirect if appropriate
   for (PIMAGE_IMPORT_DESCRIPTOR pd = pdfirst; pd-FirstThunk; pd++)
 {
Index: winsup/cygwin/syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.573
diff -u -r1.573 syscalls.cc
--- winsup/cygwin/syscalls.cc   31 Jan 2011 13:58:59 -  1.573
+++ winsup/cygwin/syscalls.cc   9 Feb 2011 13:48:01 -
@@ -1569,7 +1569,7 @@
 

Accessing folders elsewhere than C:\cygwin

[Fergus]

I have Cygwin mounted conventionally under Q:\cygwin.
I would like to access files under Q:\else.
But (for example) ls ../../.. only ever attains \cygwin (and lower).
I can use ls /cygdrive/q/else/ (and lower) but this means knowing the 
drive name (in this case Q:)
I don't much want to change mount points which are currently 
conventionally defined.

Is there a way I can get to Q:\else without knowing the drive name Q:?
Thank you.
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: [patch]another sigsegv in environ.cc

[Corinna Vinschen]

On Feb  9 23:17, jojelino wrote:
 changes introduced.
 
 all file: add __attribute__ ((regparm (x))) explicitly in function
 definition.
 environ.cc fix findenv_func that were not prefixed __stdcall
 exception.h add body to prevent compilation error with -DDEBUG_EXCEPTION
 
 
 fhandler_floppy.cc
 hookapi.cc
 syscalls.cc
 in6.h
 passwd.cc
 
 merged with [PATCHes] Misc aliasing fixes for building DLL with gcc-4.5.0

Please, before sending further patches, see

  http://cygwin.com/contrib.html

especially the section Before you get started.  If you send patches
of significant size, we need a copyright assignment from you.

Also, patches should always be accompanied by a ChangeLog entry, and
non-trivial patches should rather be sent to cygwin-patches.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Accessing folders elsewhere than C:\cygwin

[Greg Chicares]

On 2011-02-09 14:42Z, Fergus wrote:
 I have Cygwin mounted conventionally under Q:\cygwin.
 I would like to access files under Q:\else.
 But (for example) ls ../../.. only ever attains \cygwin (and lower).
 I can use ls /cygdrive/q/else/ (and lower) but this means knowing the 
 drive name (in this case Q:)
 I don't much want to change mount points which are currently 
 conventionally defined.
 Is there a way I can get to Q:\else without knowing the drive name Q:?

ls `cygpath -m /`/../else

--
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: Accessing folders elsewhere than C:\cygwin

[Jeremy Bopp]

On 02/09/2011 08:42 AM, Fergus wrote:
 I have Cygwin mounted conventionally under Q:\cygwin.
 I would like to access files under Q:\else.
 But (for example) ls ../../.. only ever attains \cygwin (and lower).
 I can use ls /cygdrive/q/else/ (and lower) but this means knowing the
 drive name (in this case Q:)
 I don't much want to change mount points which are currently
 conventionally defined.
 Is there a way I can get to Q:\else without knowing the drive name Q:?

If creating a new mount in addition to your standard mounts is out of
the question (not sure if that's what you meant), you could add
something like the following to your .bashrc or .bash_profile file:

function else_path {
  cygpath -u $(cygpath -m /)/../else
}

Then you could refer to the path as follows:

ls $(else_path)
cd $(else_path)

Another option would be to create a temporary mount within one of your
startup files:

mount | grep -q 'on /mnt/else type' ||
  mount $(cygpath -m)/../else /mnt/else

Now you can access Q:\else as /mnt/else.  If you decide you would like
to make a more permanent mount but just for your user, you can read in
the Cygwin Users Guide for how to set that up in a file under
/etc/fstab.d/.  Of course, you can also make the mount available to all
users by adding it to /etc/fstab. :-)

-Jeremy

--
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: Accessing folders elsewhere than C:\cygwin

[Jeremy Bopp]

On 02/09/2011 09:50 AM, Jeremy Bopp wrote:
 mount | grep -q 'on /mnt/else type' ||
   mount $(cygpath -m)/../else /mnt/else
 ^^^
I lost a slash in the above code.  It should be as follows:

mount | grep -q 'on /mnt/else type' ||
  mount $(cygpath -m /)/../else /mnt/else

-Jeremy

--
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: Accessing folders elsewhere than C:\cygwin

[Andrew Schulman]

 I have Cygwin mounted conventionally under Q:\cygwin.
 I would like to access files under Q:\else.
 But (for example) ls ../../.. only ever attains \cygwin (and lower).
 I can use ls /cygdrive/q/else/ (and lower) but this means knowing the 
 drive name (in this case Q:)

Well at some level you're going to have to know the drive name - either in
the path you specify, or in a mount point or a symlink.

 I don't much want to change mount points which are currently 
 conventionally defined.
 Is there a way I can get to Q:\else without knowing the drive name Q:?

You don't have to change any existing mount points, but you can add a new
one in /etc/fstab, e.g.

Q:/else  /else  some_fs  binary 0 0

Or create a symlink:

ln -s /cygdrive/Q/else /else


--
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: after ssh connection is getting closed

[Larry Hall (Cygwin)]

On 2/9/2011 1:45 AM, Sarkar, Kaushik wrote:

After connecting through ssh immediately my connection is getting
closed.


C:\WINDOWSssh -vvv 10.72.248.117 -l cyg_server OpenSSH_5.7p1, OpenSSL

   ^^
Don't use cyg-server to login.  It's not meant for this.  Use a user
that's defined as a local user on the server.  Make sure that user is
in the server's '/etc/passwd'.

--
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

Re: AW: AW: How to make ls as quick as a Windows dir?

[Larry Hall (Cygwin)]

On 2/9/2011 6:31 AM, Paul Maier wrote:




Perhaps it's time for a full problem report.  See the link below for
specifics on what should be in such a report.

http://cygwin.com/problems.html



Larry, for the cygcheck log:
please mail (only to) me your personal e-mail address.
I can't mail the file to the list.


Why can't you attach it to your response to the list?

--
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

[ANNOUNCEMENT] Updated: git-1.7.4-1, git{k,-gui,-completion,-svn}-1.7.4-1

[Eric Blake (cygwin)]

A new release of git, 1.7.4-1, has been uploaded, and will be available
for use when your mirror catches up.  This leaves 1.7.3.3-1 as previous.

NEWS:
=
This is a new upstream release, with upstream release notes attached.
See also the package documentation in /usr/share/doc/git/.

When compiled out of the box, the upstream git maintainers cater to
older cygwin releases, and intentionally disable certain features that
have been reported on their mailing list, even though they work with the
latest cygwin.  Therefore, this build turns those features back on.
However, it means that this version does assume that you are not using
FAT or FAT32 to hold your repositories, since they do not store file
permissions very accurately.

There have been several reports of git over ssh causing problems.  The
root cause of this problem is not yet known but are more likely to lie
in the cygwin dll rather than in git; help in debugging the issue would
be appreciated.  In the meantime, if you have difficulty cloning a
repository over the git protocol, try cloning from an http mirror instead.

DESCRIPTION:

Git is popular version control system designed to handle very large
projects with speed and efficiency; it is used mainly for various open
source projects, most notably the Linux kernel.

Git falls in the category of distributed source code management tools,
similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary
world). Every Git working directory is a full-fledged repository with
full revision tracking capabilities, not dependent on network access or
a central server.

UPDATE:
===
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. Save it and run setup, answer the questions and pick up 'git',
'gitk', 'git-gui', 'git-svn', and/or 'git-completion' from the 'Devel'
category.

DOWNLOAD:
=
Note that downloads from sourceware.org (aka cygwin.com) aren't allowed
due to bandwidth limitations.  This means that you will need to find a
mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

-- 
Eric Blake
volunteer cygwin git maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
List-Unsubscribe:  tag in the email header of this message.  Send email
to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
Git v1.7.4 Release Notes


Updates since v1.7.3


 * The documentation Makefile now assumes by default asciidoc 8 and
   docbook-xsl = 1.73. If you have older versions, you can set
   ASCIIDOC7 and ASCIIDOC_ROFF, respectively.

 * The option parsers of various commands that create new branches (or
   rename existing ones to a new name) were too loose and users were
   allowed to give a branch a name that begins with a dash by creative
   abuse of their command line options, which only led to burning
   themselves.  The name of a branch cannot begin with a dash now.

 * System-wide fallback default attributes can be stored in
   /etc/gitattributes; the core.attributesfile configuration variable can
   be used to customize the path to this file.

 * The thread structure generated by git send-email has changed
   slightly.  Setting the cover letter of the latest series as a reply
   to the cover letter of the previous series with --in-reply-to used
   to make the new cover letter and all the patches replies to the
   cover letter of the previous series; this has been changed to make
   the patches in the new series replies to the new cover letter.

 * The Bash completion script in contrib/ has been adjusted to be usable with
   Bash 4 (options with '=value' didn't complete).  It has been also made
   usable with zsh.

 * Different pagers can be chosen depending on which subcommand is
   being run under the pager, using the pager.subcommand variable.

 * The hardcoded tab-width of 8 that is used in whitespace breakage checks is 
now
   configurable via the attributes mechanism.

 * Support of case insensitive filesystems (i.e. core.ignorecase) has
   been improved.  For example, the gitignore mechanism didn't pay attention
   to case insensitivity.

 * The tree:path syntax for naming a blob in a tree, and the :path
   syntax for naming a blob in the index (e.g. master:Makefile,
   :hello.c) have been extended.  You can start path with ./ to
   implicitly have the (sub)directory you are in prefixed to the
   lookup.  Similarly, 

Re: 1.7.7: after upgrade lost ability to login via ssh

[Gerry Reno]

On 02/09/2011 05:54 AM, Corinna Vinschen wrote:
 On Feb  8 21:14, Gerry Reno wrote:
   
 Something else I just discovered after upgrading to 1.7.7 is that I now
 have lost the ability to login via ssh.

 I have OpenSSH installed and running sshd as a service.  Both password
 and keys accepted.  But now neither means will work.

 # ssh -i keypair1.pem   Administrator@MACHINE_IP
 Last login: Fri Feb  4 17:19:26 2011 from LOCAL_CLIENT_MACHINE
 Connection to MACHINE_IP closed.


 So I increased verbosity but did not see anything obvious.
 
 http://cygwin.com/ml/cygwin/2011-02/msg00236.html


 Corinna

   

Looking around the only thing I can find is in the /var/log/sshd.log:

Could not load host key: /etc/ssh_host_ecdsa_key
Could not load host key: /etc/ssh_host_ecdsa_key
Could not load host key: /etc/ssh_host_ecdsa_key


Not sure this is related to the login problem.

What is a ecdsa key?  How do you generate it?


Regards,
Gerry


--
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: Accessing folders elsewhere than C:\cygwin

[Corinna Vinschen]

On Feb  9 15:37, Greg Chicares wrote:
 On 2011-02-09 14:42Z, Fergus wrote:
  I have Cygwin mounted conventionally under Q:\cygwin.
  I would like to access files under Q:\else.
  But (for example) ls ../../.. only ever attains \cygwin (and lower).
  I can use ls /cygdrive/q/else/ (and lower) but this means knowing the 
  drive name (in this case Q:)
  I don't much want to change mount points which are currently 
  conventionally defined.
  Is there a way I can get to Q:\else without knowing the drive name Q:?
 
 ls `cygpath -m /`/../else

This might result in a DOS path warning, but you can create a variable
containing the parent dir of the Cygwin root as POSIX path without
triggering the DOS path warning:

  cygwin_parent=$(cygpath -ua $(cygpath -ma /)/..)


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.7: after upgrade lost ability to login via ssh

[Corinna Vinschen]

On Feb  9 11:34, Gerry Reno wrote:
 On 02/09/2011 05:54 AM, Corinna Vinschen wrote:
  On Feb  8 21:14, Gerry Reno wrote:

  Something else I just discovered after upgrading to 1.7.7 is that I now
  have lost the ability to login via ssh.
 
  I have OpenSSH installed and running sshd as a service.  Both password
  and keys accepted.  But now neither means will work.
 
  # ssh -i keypair1.pem   Administrator@MACHINE_IP
  Last login: Fri Feb  4 17:19:26 2011 from LOCAL_CLIENT_MACHINE
  Connection to MACHINE_IP closed.
 
 
  So I increased verbosity but did not see anything obvious.
  
  http://cygwin.com/ml/cygwin/2011-02/msg00236.html
 
 
  Corinna
 

 
 Looking around the only thing I can find is in the /var/log/sshd.log:
 
 Could not load host key: /etc/ssh_host_ecdsa_key
 Could not load host key: /etc/ssh_host_ecdsa_key
 Could not load host key: /etc/ssh_host_ecdsa_key
 
 
 Not sure this is related to the login problem.

No.  It's just a message.

 What is a ecdsa key?

http://cygwin.com/ml/cygwin-announce/2011-01/msg00016.html

   How do you generate it?

$ man ssh-keygen


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.7: 'Bad address' errors when using Windows 2003 R2 WOW64

[Gerry Reno]

On 02/08/2011 04:10 PM, Gerry Reno wrote:
 On 02/08/2011 03:28 PM, Gerry Reno wrote:
   
 On 02/08/2011 03:14 PM, Larry Hall (Cygwin) wrote:
   
 
 On 2/8/2011 2:47 PM, Gerry Reno wrote:

 snip

 
   
 As you can see it is not just the lapack0.sh file in /etc/profile.d/.
 Even when I remove lapack0.sh the problem just moves to another file.

 And the problem is not consistent except when I try to run bash as a
 login shell and there it occurs without fail for some reason.
   
 
 snap

 Does reverting bash to V3 change anything?

 
   
 It changes slightly.  I don't see the Bad address but more segfaults:

 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 Segmentation fault (core dumped)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 Segmentation fault (core dumped)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)


 And I still get postinstall issues:

 Package: bash
 bash.sh exit code 128
 Package: xorg-server
 xorg-server.sh exit code 128
 Package: Unknown package
 coreutils.sh exit code 128
 libglade2.0.sh exit code 2



 Regards,
 Gerry


   
 
 Some further testing shows that I can still generate Bad address errors:

 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash-3.2$ (for p in $(ls /etc/profile.d/*.sh); do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-3.2$



   

And today I still see some odd things happening even after going back to
bash v3:

bash-3.2$ whoami
ip-0a7a25a3\administrator
bash-3.2$
bash-3.2$ /bin/bash -i
bash-3.2$ exit
exit
  2 [main] bash 1224 sig_send: wait for sig_complete event
failed, signal -3
4, rc -1, Win32 error 5
  2 [main] bash 1224 sig_send: wait for sig_complete event
failed, signal -3
4, rc -1, Win32 error 5
Segmentation fault
bash-3.2$


Regards,
Gerry


--
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

How to detect CygWin SVN?

[Jochen Wiedmann]

Hi,

I'd like to write a script, which ought to work with the CygWin SVN
client as well as any native SVN clients. As a prerequisite, I need to
detect whether the svn program in the path is CygWin SVN or not.
Question is, how to do this? Because the output of svn --version
contains nothing that indicates compilation with CygWin.

Thanks for any suggestions,

Jochen

-- 
I Am What I Am And That's All What I Yam (Popeye)



bash-4.1$ svn --version
svn, version 1.6.15 (r1038135)
   compiled Nov 29 2010, 14:09:28

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme

--
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: How to detect CygWin SVN?

[Jeremy Bopp]

On 02/09/2011 01:10 PM, Jochen Wiedmann wrote:
 Hi,
 
 I'd like to write a script, which ought to work with the CygWin SVN
 client as well as any native SVN clients. As a prerequisite, I need to
 detect whether the svn program in the path is CygWin SVN or not.
 Question is, how to do this? Because the output of svn --version
 contains nothing that indicates compilation with CygWin.

I'm assuming that your script expects svn to be in the PATH, so you
could check to see if the path to the svn client lives within Cygwin's
installation:

if [ $(type -p svn) = '/usr/bin/svn' ]; then
  echo Found Cygwin's svn client
fi

Unless someone goes out of their way to confound things, this should be
good enough.

-Jeremy

--
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: building a cross-compiler for Linux/OSX

[Fabiano Sidler]

Hello? Noone building cross-compilers for cygwin?

Thus spake Fabiano Sidler, 11/02/07 10:50:
 Hi folks!
 
 I'm trying to build a cross-compiler under Linux and MacOSX using this
 script: http://sourceware.org/ml/cygwin/2010-08/txt00010.txt
 I get the same error on Linux and MacOSX after the make of line 340:
 === snip ===
 [...]
 i686-pc-cygwin-c++ -L/opt/devel/cygwin/build/cygwin/i686-pc-cygwin/winsup 
 -L/opt
 /devel/cygwin/build/cygwin/i686-pc-cygwin/winsup/cygwin 
 -L/opt/devel/cygwin/buil
 d/cygwin/i686-pc-cygwin/winsup/w32api/lib -isystem 
 /opt/devel/cygwin/src/cygwin-
 1.7.6-1/winsup/include -isystem 
 /opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/cygw
 in/include -isystem 
 /opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/w32api/include -
 B/opt/devel/cygwin/build/cygwin/i686-pc-cygwin/newlib/ -isystem 
 /opt/devel/cygwi
 n/build/cygwin/i686-pc-cygwin/newlib/targ-include -isystem 
 /opt/devel/cygwin/src
 /cygwin-1.7.6-1/newlib/libc/include-c -nostdinc++  -DHAVE_CONFIG_H  -g 
 -O2 -
 Wno-error -MMD -fomit-frame-pointer -Werror -fmerge-constants -ftracer 
 -mno-use-
 libstdc-wrappers  -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe 
 -fbu
 iltin -fmessage-length=0  -I.  
 -I/opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/cyg
 win  -I/opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/w32api/include 
 -I/opt/devel/c
 ygwin/src/cygwin-1.7.6-1/winsup/cygwin/config/i386 
 -I/opt/devel/cygwin/lib/gcc/i
 686-pc-cygwin/4.5.0/include -fno-rtti -fno-exceptions -o ./fhandler_floppy.o 
 /op
 t/devel/cygwin/src/cygwin-1.7.6-1/winsup/cygwin/fhandler_floppy.cc
 cc1plus: warnings being treated as errors
 /opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/cygwin/fhandler_floppy.cc: In 
 member
  function ?int fhandler_dev_floppy::get_drive_info(hd_geometry*)?:
 /opt/devel/cygwin/src/cygwin-1.7.6-1/winsup/cygwin/fhandler_floppy.cc:59:37: 
 err
 or: dereferencing type-punned pointer will break strict-aliasing rules
 make[3]: *** [fhandler_floppy.o] Error 1
 make[3]: Leaving directory 
 `/opt/devel/cygwin/build/cygwin/i686-pc-cygwin/winsup
 /cygwin'
 make[2]: *** [cygwin] Error 1
 make[2]: Leaving directory 
 `/opt/devel/cygwin/build/cygwin/i686-pc-cygwin/winsup
 '
 make[1]: *** [all-target-winsup] Error 2
 make[1]: Leaving directory `/opt/devel/cygwin/build/cygwin'
 make: *** [all] Error 2
 === snap ===
 
 Anyone able to run the script to completion or a different (and working) way
 to build a cross-compiler for cygwin on Linux and OSX?
 
 Greetings,
 F. Sidler

--
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: How to detect CygWin SVN?

[Jochen Wiedmann]

On Wed, Feb 9, 2011 at 8:17 PM, Jeremy Bopp jer...@bopp.net wrote:

 I'm assuming that your script expects svn to be in the PATH, so you
 could check to see if the path to the svn client lives within Cygwin's
 installation:

 if [ $(type -p svn) = '/usr/bin/svn' ]; then
  echo Found Cygwin's svn client
 fi

 Unless someone goes out of their way to confound things, this should be
 good enough.

Thanks for the idea. However, I'd prefer a solution that works with
the native cmd-Shell too. Otherwise, I'd assume that CygWin is
installed.


-- 
I Am What I Am And That's All What I Yam (Popeye)

--
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: How to detect CygWin SVN?

[Jeremy Bopp]

On 02/09/2011 02:22 PM, Jochen Wiedmann wrote:
 On Wed, Feb 9, 2011 at 8:17 PM, Jeremy Bopp jer...@bopp.net wrote:
 
 I'm assuming that your script expects svn to be in the PATH, so you
 could check to see if the path to the svn client lives within Cygwin's
 installation:

 if [ $(type -p svn) = '/usr/bin/svn' ]; then
  echo Found Cygwin's svn client
 fi

 Unless someone goes out of their way to confound things, this should be
 good enough.
 
 Thanks for the idea. However, I'd prefer a solution that works with
 the native cmd-Shell too. Otherwise, I'd assume that CygWin is
 installed.

Since you want a solution that works in either environment, in what
language are you going to implement your script?  You can do something
very similar in Perl and other such languages, but I can't think of a
single method that would work in both bash and cmd without at least some
syntax tweaks.

-Jeremy

--
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: How to detect CygWin SVN?

[Jochen Wiedmann]

Preferrably cmd

Or, in the alternative, the output of a cmd-Shell invocation to be
analyzed by some Java program.


On Wed, Feb 9, 2011 at 9:26 PM, Jeremy Bopp jer...@bopp.net wrote:
 On 02/09/2011 02:22 PM, Jochen Wiedmann wrote:
 On Wed, Feb 9, 2011 at 8:17 PM, Jeremy Bopp jer...@bopp.net wrote:

 I'm assuming that your script expects svn to be in the PATH, so you
 could check to see if the path to the svn client lives within Cygwin's
 installation:

 if [ $(type -p svn) = '/usr/bin/svn' ]; then
  echo Found Cygwin's svn client
 fi

 Unless someone goes out of their way to confound things, this should be
 good enough.

 Thanks for the idea. However, I'd prefer a solution that works with
 the native cmd-Shell too. Otherwise, I'd assume that CygWin is
 installed.

 Since you want a solution that works in either environment, in what
 language are you going to implement your script?  You can do something
 very similar in Perl and other such languages, but I can't think of a
 single method that would work in both bash and cmd without at least some
 syntax tweaks.

 -Jeremy

 --
 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





-- 
I Am What I Am And That's All What I Yam (Popeye)

--
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: bash-4.1.9-3

[Eric Blake (cygwin)]

A new release of bash, 4.1.9-3, has been uploaded and will soon reach a
mirror near you; replacing 4.1.9-2 and leaving bash 3.2.51-24 as previous.

NEWS:
=
This is a minor rebuild which avoids a miscompilation that was causing
bash to crash on some machines during ssh-host-config.

There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by
default.
2. d2u is your friend.  You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file.  If you
absolutely must use files with \r\n line endings, consider mounting the
directory where those files live as a text mount.  However, text mounts
are not as well tested or supported on the cygwin mailing list, so you
may encounter other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific set option, named igncr,
to force bash to ignore \r, independently of cygwin's mount style.  As
of bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files.  I hope to convince the upstream bash maintainer to
accept this patch into a future bash release even on Linux, rather than
keeping it a cygwin-specific patch, but only time will tell.  There are
several ways to activate this option:
4a. For a single affected script, add this line just after the she-bang:
 (set -o igncr) 2/dev/null  set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the option, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired.  Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it.  It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks
the current state of 'set -o igncr'.  If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make
sense to support the option through both set and shopt, and SHELLOPTS
proved to be more powerful.
5. You can also experiment with the IFS variable for controlling how
bash will treat \r during variable expansion.
6. There are varying levels of speed at which bash operates.  The
fastest is on a binary mount with igncr disabled (the default behavior).
 Next would be text mounts with igncr disabled and no \r in the
underlying file. Next would be binary mounts with igncr enabled.  And
the slowest that bash will operate is on text mounts with igncr enabled.
7. As additional cygwin extensions, this version of bash includes:
7a. EXECIGNORE - a colon-separated list of glob patterns to ignore
when completing on executables.  EXECIGNORE=*.dll is common.
7b. completion_strip_exe - using 'shopt -s completion_strip_exe'
makes completion strip .exe suffixes
8. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas.  This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
Thanks to Dan Colascione for providing the EXECIGNORE and
completion_strip_exe patches.

Remember, you must not have any bash or /bin/sh instances running when
you upgrade the bash package.  This release requires cygwin-1.7.7-1 or
later; and it requires libreadline7-6.1.2-2 or later.  See also the
upstream documentation in /usr/share/doc/bash/.

DESCRIPTION:

Bash is an sh-compatible shell that incorporates useful features from
the Korn shell (ksh) and C shell (csh).  It is intended to conform to
the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard.  It offers
functional improvements over sh for both programming and interactive
use. In addition, most sh scripts can be run by Bash without modification.

As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
similar to some Linux distributions (although /bin/sh may swap to dash
at some future time).

UPDATE:
===
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. Save it and run setup, answer the questions and pick up 'bash'
in the 'Base' category (it should already be selected).  As this is an
experimental release, you will need to use the 'Exp' radio button.

DOWNLOAD:
=
Note that downloads from cygwin.com aren't allowed 

Re: 1.7.7: after upgrade lost ability to login via ssh

[Gerry Reno]

On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:
 On 2/8/2011 9:14 PM, Gerry Reno wrote:
 Something else I just discovered after upgrading to 1.7.7 is that I now
 have lost the ability to login via ssh.

 I have OpenSSH installed and running sshd as a service.  Both password
 and keys accepted.  But now neither means will work.

  # ssh -i keypair1.pem   Administrator@MACHINE_IP
  Last login: Fri Feb  4 17:19:26 2011 from LOCAL_CLIENT_MACHINE
  Connection to MACHINE_IP closed.


 So I increased verbosity but did not see anything obvious.


  # ssh -v -i keypair1.pem   Administrator@MACHINE_IP
  OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: Applying options for *
  debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug1: identity file keypair1.pem type -1
  debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.8

 Does reverting OpenSSH to 5.7 make a difference?


Downgraded to 5.7:

bash-4.1$ sshd --version
sshd: unknown option -- -
OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011


From client:

ssh -i keypair1.pem   Administrator@MACHINE_IP
Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
Connection to MACHINE_IP closed.


Nope.  Still have the same problem.  Connection is made but immediately
closes.


Regards,
Gerry





--
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: How to detect CygWin SVN?

[Csaba Raduly]

Hi Jochen,

On 2/9/11, Jochen Wiedmann  wrote:
 Hi,

 I'd like to write a script, which ought to work with the CygWin SVN
 client as well as any native SVN clients. As a prerequisite, I need to
 detect whether the svn program in the path is CygWin SVN or not.
 Question is, how to do this?

Question is, why do you think you need to detect it ?

How about this:
cygcheck `which svn` | grep cygwin1.dll

(you could replace `which svn` with the full path of the svn executable)

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
Ok, it boots. Which means it must be bug-free and perfect.  -- Linus
Torvalds
People disagree with me. I just ignore them. -- Linus Torvalds

--
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: 1.7.7: after upgrade lost ability to login via ssh

[Gerry Reno]

On 02/09/2011 04:56 PM, Gerry Reno wrote:
 On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:
   
 On 2/8/2011 9:14 PM, Gerry Reno wrote:
 
 Something else I just discovered after upgrading to 1.7.7 is that I now
 have lost the ability to login via ssh.

 I have OpenSSH installed and running sshd as a service.  Both password
 and keys accepted.  But now neither means will work.

  # ssh -i keypair1.pem   Administrator@MACHINE_IP
  Last login: Fri Feb  4 17:19:26 2011 from LOCAL_CLIENT_MACHINE
  Connection to MACHINE_IP closed.


 So I increased verbosity but did not see anything obvious.


  # ssh -v -i keypair1.pem   Administrator@MACHINE_IP
  OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: Applying options for *
  debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug1: identity file keypair1.pem type -1
  debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.8
   
 Does reverting OpenSSH to 5.7 make a difference?

 
 Downgraded to 5.7:

 bash-4.1$ sshd --version
 sshd: unknown option -- -
 OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011


 From client:

 ssh -i keypair1.pem   Administrator@MACHINE_IP
 Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
 Connection to MACHINE_IP closed.


 Nope.  Still have the same problem.  Connection is made but immediately
 closes.


   

I'm suspecting this is related to running Cygwin 1.7.

In looking back though some notes I started having bash shell problems
after upgrading from 1.5 to 1.7. 

Now on 1.7 if I try to run bash as a login shell it just gets Bad
address or segfault errors and immediately exits the shell which also
probably affects 'ssh'.

I don't remember having any bash problems when I was running Cygwin 1.5
on this machine.  My notes reflect screen copies showing bash able to
run as a login shell without any problem.


Regards,
Gerry



--
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: 1.7.7: after upgrade lost ability to login via ssh

[Gerry Reno]

On 02/09/2011 05:07 PM, Gerry Reno wrote:
 On 02/09/2011 04:56 PM, Gerry Reno wrote:
   
 On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:
   
 
 On 2/8/2011 9:14 PM, Gerry Reno wrote:
 
   
 Something else I just discovered after upgrading to 1.7.7 is that I now
 have lost the ability to login via ssh.

 I have OpenSSH installed and running sshd as a service.  Both password
 and keys accepted.  But now neither means will work.

  # ssh -i keypair1.pem   Administrator@MACHINE_IP
  Last login: Fri Feb  4 17:19:26 2011 from LOCAL_CLIENT_MACHINE
  Connection to MACHINE_IP closed.


 So I increased verbosity but did not see anything obvious.


  # ssh -v -i keypair1.pem   Administrator@MACHINE_IP
  OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: Applying options for *
  debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug1: identity file keypair1.pem type -1
  debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.8
   
 
 Does reverting OpenSSH to 5.7 make a difference?

 
   
 Downgraded to 5.7:

 bash-4.1$ sshd --version
 sshd: unknown option -- -
 OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011


 From client:

 ssh -i keypair1.pem   Administrator@MACHINE_IP
 Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
 Connection to MACHINE_IP closed.


 Nope.  Still have the same problem.  Connection is made but immediately
 closes.


   
 
 I'm suspecting this is related to running Cygwin 1.7.

 In looking back though some notes I started having bash shell problems
 after upgrading from 1.5 to 1.7. 

 Now on 1.7 if I try to run bash as a login shell it just gets Bad
 address or segfault errors and immediately exits the shell which also
 probably affects 'ssh'.

 I don't remember having any bash problems when I was running Cygwin 1.5
 on this machine.  My notes reflect screen copies showing bash able to
 run as a login shell without any problem.


   
And I did test with today's release of Bash 4.1.9-3 and nothing
improved, same Bad address and segfault errors:

bash-4.1$ bash --version
GNU bash, version 4.1.9(3)-release (i686-pc-cygwin)



Regards,
Gerry



--
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: 1.7.7: after upgrade lost ability to login via ssh

[Larry Hall (Cygwin)]

On 2/9/2011 5:07 PM, Gerry Reno wrote:

On 02/09/2011 04:56 PM, Gerry Reno wrote:

On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:


On 2/8/2011 9:14 PM, Gerry Reno wrote:


Something else I just discovered after upgrading to 1.7.7 is that I now
have lost the ability to login via ssh.

I have OpenSSH installed and running sshd as a service.  Both password
and keys accepted.  But now neither means will work.

  # ssh -i keypair1.pem   Administrator@MACHINE_IP
  Last login: Fri Feb  4 17:19:26 2011 from LOCAL_CLIENT_MACHINE
  Connection to MACHINE_IP closed.


So I increased verbosity but did not see anything obvious.


  # ssh -v -i keypair1.pem   Administrator@MACHINE_IP
  OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: Applying options for *
  debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug1: identity file keypair1.pem type -1
  debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.8


Does reverting OpenSSH to 5.7 make a difference?



Downgraded to 5.7:

 bash-4.1$ sshd --version
 sshd: unknown option -- -
 OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011


 From client:

 ssh -i keypair1.pem   Administrator@MACHINE_IP
 Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
 Connection to MACHINE_IP closed.


Nope.  Still have the same problem.  Connection is made but immediately
closes.





I'm suspecting this is related to running Cygwin 1.7.

In looking back though some notes I started having bash shell problems
after upgrading from 1.5 to 1.7.

Now on 1.7 if I try to run bash as a login shell it just gets Bad
address or segfault errors and immediately exits the shell which also
probably affects 'ssh'.

I don't remember having any bash problems when I was running Cygwin 1.5
on this machine.  My notes reflect screen copies showing bash able to
run as a login shell without any problem.


Yep, that's the way we all run by default (see cygwin.bat).  I agree
that if you're having problems getting bash to behave, it's best to focus
on that issue first.  Your ssh problems may just be another symptom of
the same thing.  How about sending cygcheck output
(http://cygwin.com/problems.html)?  There may be something helpful in
that which someone on the list might pick up on.

--
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

Re: 1.7.7: after upgrade lost ability to login via ssh

[Larry Hall (Cygwin)]

On 2/9/2011 5:56 PM, Gerry Reno wrote:

On 02/09/2011 05:35 PM, Larry Hall (Cygwin) wrote:

On 2/9/2011 5:07 PM, Gerry Reno wrote:

On 02/09/2011 04:56 PM, Gerry Reno wrote:

On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:


On 2/8/2011 9:14 PM, Gerry Reno wrote:


Something else I just discovered after upgrading to 1.7.7 is that
I now
have lost the ability to login via ssh.

I have OpenSSH installed and running sshd as a service.  Both
password
and keys accepted.  But now neither means will work.

   # ssh -i keypair1.pem   Administrator@MACHINE_IP
   Last login: Fri Feb  4 17:19:26 2011 from LOCAL_CLIENT_MACHINE
   Connection to MACHINE_IP closed.


So I increased verbosity but did not see anything obvious.


   # ssh -v -i keypair1.pem   Administrator@MACHINE_IP
   OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
   debug1: Reading configuration data /etc/ssh/ssh_config
   debug1: Applying options for *
   debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
   debug1: Connection established.
   debug1: permanently_set_uid: 0/0
   debug1: identity file keypair1.pem type -1
   debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.8


Does reverting OpenSSH to 5.7 make a difference?



Downgraded to 5.7:

  bash-4.1$ sshd --version
  sshd: unknown option -- -
  OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011



 From client:


  ssh -i keypair1.pem   Administrator@MACHINE_IP
  Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
  Connection to MACHINE_IP closed.


Nope.  Still have the same problem.  Connection is made but immediately
closes.





I'm suspecting this is related to running Cygwin 1.7.

In looking back though some notes I started having bash shell problems
after upgrading from 1.5 to 1.7.

Now on 1.7 if I try to run bash as a login shell it just gets Bad
address or segfault errors and immediately exits the shell which also
probably affects 'ssh'.

I don't remember having any bash problems when I was running Cygwin 1.5
on this machine.  My notes reflect screen copies showing bash able to
run as a login shell without any problem.


Yep, that's the way we all run by default (see cygwin.bat).  I agree
that if you're having problems getting bash to behave, it's best to focus
on that issue first.  Your ssh problems may just be another symptom of
the same thing.  How about sending cygcheck output
(http://cygwin.com/problems.html)?  There may be something helpful in
that which someone on the list might pick up on.



Ok, ran a new cygcheck and attached it.


OK, thanks.  What went wrong with the first installation?

I notice that this is using TS.  Can you try experiment with this machine
locally?  Or perhaps just try:

http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts

--
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

Re: 1.7.7: after upgrade lost ability to login via ssh

[Gerry Reno]

On 02/09/2011 06:43 PM, Larry Hall (Cygwin) wrote:
 On 2/9/2011 5:56 PM, Gerry Reno wrote:
 On 02/09/2011 05:35 PM, Larry Hall (Cygwin) wrote:
 On 2/9/2011 5:07 PM, Gerry Reno wrote:
 On 02/09/2011 04:56 PM, Gerry Reno wrote:
 On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:

 On 2/8/2011 9:14 PM, Gerry Reno wrote:

 Something else I just discovered after upgrading to 1.7.7 is that
 I now
 have lost the ability to login via ssh.

 I have OpenSSH installed and running sshd as a service.  Both
 password
 and keys accepted.  But now neither means will work.

# ssh -i keypair1.pem   Administrator@MACHINE_IP
Last login: Fri Feb  4 17:19:26 2011 from
 LOCAL_CLIENT_MACHINE
Connection to MACHINE_IP closed.


 So I increased verbosity but did not see anything obvious.


# ssh -v -i keypair1.pem   Administrator@MACHINE_IP
OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file keypair1.pem type -1
debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.8

 Does reverting OpenSSH to 5.7 make a difference?


 Downgraded to 5.7:

   bash-4.1$ sshd --version
   sshd: unknown option -- -
   OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011


  From client:

   ssh -i keypair1.pem   Administrator@MACHINE_IP
   Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
   Connection to MACHINE_IP closed.


 Nope.  Still have the same problem.  Connection is made but
 immediately
 closes.




 I'm suspecting this is related to running Cygwin 1.7.

 In looking back though some notes I started having bash shell problems
 after upgrading from 1.5 to 1.7.

 Now on 1.7 if I try to run bash as a login shell it just gets Bad
 address or segfault errors and immediately exits the shell which also
 probably affects 'ssh'.

 I don't remember having any bash problems when I was running Cygwin
 1.5
 on this machine.  My notes reflect screen copies showing bash able to
 run as a login shell without any problem.

 Yep, that's the way we all run by default (see cygwin.bat).  I agree
 that if you're having problems getting bash to behave, it's best to
 focus
 on that issue first.  Your ssh problems may just be another symptom of
 the same thing.  How about sending cygcheck output
 (http://cygwin.com/problems.html)?  There may be something helpful in
 that which someone on the list might pick up on.


 Ok, ran a new cygcheck and attached it.

 OK, thanks.  What went wrong with the first installation?

 I notice that this is using TS.  Can you try experiment with this machine
 locally?  Or perhaps just try:

 http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts


I reduced DEP down to just Windows executables and dlls and then rebooted.

And it actually seemed to make the problem worse:

bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
bash: /etc/profile.d/lapack0.sh: Bad address
bash-4.1$


So DEP in is play here but sort of inverse from what I'd expect.  There
was no switch now to totally disable it.  I guess they want you to
fiddle with the registry to turn it all the way off.


Regards,
Gerry




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: 

Re: 1.7.7: after upgrade lost ability to login via ssh

[Gerry Reno]

On 02/09/2011 07:21 PM, Gerry Reno wrote:
 On 02/09/2011 06:43 PM, Larry Hall (Cygwin) wrote:
   
 On 2/9/2011 5:56 PM, Gerry Reno wrote:
 
 On 02/09/2011 05:35 PM, Larry Hall (Cygwin) wrote:
   
 On 2/9/2011 5:07 PM, Gerry Reno wrote:
 
 On 02/09/2011 04:56 PM, Gerry Reno wrote:
   
 On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:

 
 On 2/8/2011 9:14 PM, Gerry Reno wrote:

   
 Something else I just discovered after upgrading to 1.7.7 is that
 I now
 have lost the ability to login via ssh.

 I have OpenSSH installed and running sshd as a service.  Both
 password
 and keys accepted.  But now neither means will work.

# ssh -i keypair1.pem   Administrator@MACHINE_IP
Last login: Fri Feb  4 17:19:26 2011 from
 LOCAL_CLIENT_MACHINE
Connection to MACHINE_IP closed.


 So I increased verbosity but did not see anything obvious.


# ssh -v -i keypair1.pem   Administrator@MACHINE_IP
OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file keypair1.pem type -1
debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.8

 
 Does reverting OpenSSH to 5.7 make a difference?


   
 Downgraded to 5.7:

   bash-4.1$ sshd --version
   sshd: unknown option -- -
   OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011


 
  From client:
   
   ssh -i keypair1.pem   Administrator@MACHINE_IP
   Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
   Connection to MACHINE_IP closed.


 Nope.  Still have the same problem.  Connection is made but
 immediately
 closes.



 
 I'm suspecting this is related to running Cygwin 1.7.

 In looking back though some notes I started having bash shell problems
 after upgrading from 1.5 to 1.7.

 Now on 1.7 if I try to run bash as a login shell it just gets Bad
 address or segfault errors and immediately exits the shell which also
 probably affects 'ssh'.

 I don't remember having any bash problems when I was running Cygwin
 1.5
 on this machine.  My notes reflect screen copies showing bash able to
 run as a login shell without any problem.
   
 Yep, that's the way we all run by default (see cygwin.bat).  I agree
 that if you're having problems getting bash to behave, it's best to
 focus
 on that issue first.  Your ssh problems may just be another symptom of
 the same thing.  How about sending cygcheck output
 (http://cygwin.com/problems.html)?  There may be something helpful in
 that which someone on the list might pick up on.

 
 Ok, ran a new cygcheck and attached it.
   
 OK, thanks.  What went wrong with the first installation?

 I notice that this is using TS.  Can you try experiment with this machine
 locally?  Or perhaps just try:

 http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts

 
 I reduced DEP down to just Windows executables and dlls and then rebooted.

 And it actually seemed to make the problem worse:

 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$


 So DEP in is play here but sort of inverse from what I'd expect.  There
 was no 

Re: 1.7.7: after upgrade lost ability to login via ssh

[Gerry Reno]

On 02/09/2011 08:04 PM, Gerry Reno wrote:
 On 02/09/2011 07:21 PM, Gerry Reno wrote:
   
 On 02/09/2011 06:43 PM, Larry Hall (Cygwin) wrote:
   
 
 On 2/9/2011 5:56 PM, Gerry Reno wrote:
 
   
 On 02/09/2011 05:35 PM, Larry Hall (Cygwin) wrote:
   
 
 On 2/9/2011 5:07 PM, Gerry Reno wrote:
 
   
 On 02/09/2011 04:56 PM, Gerry Reno wrote:
   
 
 On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:

 
   
 On 2/8/2011 9:14 PM, Gerry Reno wrote:

   
 
 Something else I just discovered after upgrading to 1.7.7 is that
 I now
 have lost the ability to login via ssh.

 I have OpenSSH installed and running sshd as a service.  Both
 password
 and keys accepted.  But now neither means will work.

# ssh -i keypair1.pem   Administrator@MACHINE_IP
Last login: Fri Feb  4 17:19:26 2011 from
 LOCAL_CLIENT_MACHINE
Connection to MACHINE_IP closed.


 So I increased verbosity but did not see anything obvious.


# ssh -v -i keypair1.pem   Administrator@MACHINE_IP
OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file keypair1.pem type -1
debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.8

 
   
 Does reverting OpenSSH to 5.7 make a difference?


   
 
 Downgraded to 5.7:

   bash-4.1$ sshd --version
   sshd: unknown option -- -
   OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011


 
   
  From client:
   
 
   ssh -i keypair1.pem   Administrator@MACHINE_IP
   Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
   Connection to MACHINE_IP closed.


 Nope.  Still have the same problem.  Connection is made but
 immediately
 closes.



 
   
 I'm suspecting this is related to running Cygwin 1.7.

 In looking back though some notes I started having bash shell problems
 after upgrading from 1.5 to 1.7.

 Now on 1.7 if I try to run bash as a login shell it just gets Bad
 address or segfault errors and immediately exits the shell which also
 probably affects 'ssh'.

 I don't remember having any bash problems when I was running Cygwin
 1.5
 on this machine.  My notes reflect screen copies showing bash able to
 run as a login shell without any problem.
   
 
 Yep, that's the way we all run by default (see cygwin.bat).  I agree
 that if you're having problems getting bash to behave, it's best to
 focus
 on that issue first.  Your ssh problems may just be another symptom of
 the same thing.  How about sending cygcheck output
 (http://cygwin.com/problems.html)?  There may be something helpful in
 that which someone on the list might pick up on.

 
   
 Ok, ran a new cygcheck and attached it.
   
 
 OK, thanks.  What went wrong with the first installation?

 I notice that this is using TS.  Can you try experiment with this machine
 locally?  Or perhaps just try:

 http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts

 
   
 I reduced DEP down to just Windows executables and dlls and then rebooted.

 And it actually seemed to make the problem worse:

 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ 

Re: [ANNOUNCEMENT] Updated: OpenSSH-5.8p1-1

[Hans Horn]

On 2/8/2011 3:58 PM, Hans Horn wrote:

On 2/8/2011 3:32 PM, Cyrille Lefevre wrote:


Le 08/02/2011 22:42, Hans Horn a écrit :

Trying some of the more recent revisions listed on the Cygwin Time
Machine.
e.g. ftp://www.fruitbat.org/pub/cygwin/circa/2011/01/11/194023

All give me Unable to get ...setup.bz2.sig and
then Unable to get ...setup.ini.sig.

What gives?


does setup -K http://mirrors.kernel.org/sourceware/cygwin/setup.bz2.sig
help ?

Regards,

Cyrille Lefevre


Nope - I get exactly the same behavior.



Folks,

I had to summon the Cygwin Time Machine via setup with the -X flag, 
which suppresses the disable the lookup of the signature file (according 
to http://www.fruitbat.org/Cygwin/index.html).


So I finally got a hold of openssh 5.6p1-2, which solved my ssh 
connection issues.


thx.,
H.



--
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: 1.7.7: after upgrade lost ability to login via ssh

[Gerry Reno]

On 02/09/2011 08:21 PM, Gerry Reno wrote:
 On 02/09/2011 08:04 PM, Gerry Reno wrote:
   
 On 02/09/2011 07:21 PM, Gerry Reno wrote:
   
 
 On 02/09/2011 06:43 PM, Larry Hall (Cygwin) wrote:
   
 
   
 On 2/9/2011 5:56 PM, Gerry Reno wrote:
 
   
 
 On 02/09/2011 05:35 PM, Larry Hall (Cygwin) wrote:
   
 
   
 On 2/9/2011 5:07 PM, Gerry Reno wrote:
 
   
 
 On 02/09/2011 04:56 PM, Gerry Reno wrote:
   
 
   
 On 02/08/2011 11:07 PM, Larry Hall (Cygwin) wrote:

 
   
 
 On 2/8/2011 9:14 PM, Gerry Reno wrote:

   
 
   
 Something else I just discovered after upgrading to 1.7.7 is that
 I now
 have lost the ability to login via ssh.

 I have OpenSSH installed and running sshd as a service.  Both
 password
 and keys accepted.  But now neither means will work.

# ssh -i keypair1.pem   Administrator@MACHINE_IP
Last login: Fri Feb  4 17:19:26 2011 from
 LOCAL_CLIENT_MACHINE
Connection to MACHINE_IP closed.


 So I increased verbosity but did not see anything obvious.


# ssh -v -i keypair1.pem   Administrator@MACHINE_IP
OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to MACHINE_IP [MACHINE_IP] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file keypair1.pem type -1
debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.8

 
   
 
 Does reverting OpenSSH to 5.7 make a difference?


   
 
   
 Downgraded to 5.7:

   bash-4.1$ sshd --version
   sshd: unknown option -- -
   OpenSSH_5.7p1, OpenSSL 0.9.8r 8 Feb 2011


 
   
 
  From client:
   
 
   
   ssh -i keypair1.pem   Administrator@MACHINE_IP
   Last login: Wed Feb  9 12:54:08 2011 from LOCAL_CLIENT_IP
   Connection to MACHINE_IP closed.


 Nope.  Still have the same problem.  Connection is made but
 immediately
 closes.



 
   
 
 I'm suspecting this is related to running Cygwin 1.7.

 In looking back though some notes I started having bash shell problems
 after upgrading from 1.5 to 1.7.

 Now on 1.7 if I try to run bash as a login shell it just gets Bad
 address or segfault errors and immediately exits the shell which also
 probably affects 'ssh'.

 I don't remember having any bash problems when I was running Cygwin
 1.5
 on this machine.  My notes reflect screen copies showing bash able to
 run as a login shell without any problem.
   
 
   
 Yep, that's the way we all run by default (see cygwin.bat).  I agree
 that if you're having problems getting bash to behave, it's best to
 focus
 on that issue first.  Your ssh problems may just be another symptom of
 the same thing.  How about sending cygcheck output
 (http://cygwin.com/problems.html)?  There may be something helpful in
 that which someone on the list might pick up on.

 
   
 
 Ok, ran a new cygcheck and attached it.
   
 
   
 OK, thanks.  What went wrong with the first installation?

 I notice that this is using TS.  Can you try experiment with this machine
 locally?  Or perhaps just try:

 http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts

 
   
 
 I reduced DEP down to just Windows executables and dlls and then rebooted.

 And it actually seemed to make the problem worse:

 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash: /etc/profile.d/lapack0.sh: Bad address
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 bash-4.1$ (for p in $(ls /etc/profile.d/*.sh);do . $p;done)
 

Updated: cppcheck-1.47-1

[Chris Sutcliffe]

Version 1.47-1 of cppcheck has been uploaded, following the upstream release.

cppcheck is a tool for static C/C++ code analysis.  It tries to detect
bugs that your C/C++ compiler don't see.
The goal is no false positives.

cppcheck is versatile. You can check non-standard code that includes
various compiler extensions, inline assembly code, etc.

For a list of changes see:

http://sourceforge.net/news/?group_id=195752id=295096

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read*all*  of the information on unsubscribing that is
available starting at this URL.

Chris

Updated: git-1.7.4-1, git{k,-gui,-completion,-svn}-1.7.4-1

[Eric Blake (cygwin)]

A new release of git, 1.7.4-1, has been uploaded, and will be available
for use when your mirror catches up.  This leaves 1.7.3.3-1 as previous.

NEWS:
=
This is a new upstream release, with upstream release notes attached.
See also the package documentation in /usr/share/doc/git/.

When compiled out of the box, the upstream git maintainers cater to
older cygwin releases, and intentionally disable certain features that
have been reported on their mailing list, even though they work with the
latest cygwin.  Therefore, this build turns those features back on.
However, it means that this version does assume that you are not using
FAT or FAT32 to hold your repositories, since they do not store file
permissions very accurately.

There have been several reports of git over ssh causing problems.  The
root cause of this problem is not yet known but are more likely to lie
in the cygwin dll rather than in git; help in debugging the issue would
be appreciated.  In the meantime, if you have difficulty cloning a
repository over the git protocol, try cloning from an http mirror instead.

DESCRIPTION:

Git is popular version control system designed to handle very large
projects with speed and efficiency; it is used mainly for various open
source projects, most notably the Linux kernel.

Git falls in the category of distributed source code management tools,
similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary
world). Every Git working directory is a full-fledged repository with
full revision tracking capabilities, not dependent on network access or
a central server.

UPDATE:
===
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. Save it and run setup, answer the questions and pick up 'git',
'gitk', 'git-gui', 'git-svn', and/or 'git-completion' from the 'Devel'
category.

DOWNLOAD:
=
Note that downloads from sourceware.org (aka cygwin.com) aren't allowed
due to bandwidth limitations.  This means that you will need to find a
mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

-- 
Eric Blake
volunteer cygwin git maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
List-Unsubscribe:  tag in the email header of this message.  Send email
to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
Git v1.7.4 Release Notes


Updates since v1.7.3


 * The documentation Makefile now assumes by default asciidoc 8 and
   docbook-xsl = 1.73. If you have older versions, you can set
   ASCIIDOC7 and ASCIIDOC_ROFF, respectively.

 * The option parsers of various commands that create new branches (or
   rename existing ones to a new name) were too loose and users were
   allowed to give a branch a name that begins with a dash by creative
   abuse of their command line options, which only led to burning
   themselves.  The name of a branch cannot begin with a dash now.

 * System-wide fallback default attributes can be stored in
   /etc/gitattributes; the core.attributesfile configuration variable can
   be used to customize the path to this file.

 * The thread structure generated by git send-email has changed
   slightly.  Setting the cover letter of the latest series as a reply
   to the cover letter of the previous series with --in-reply-to used
   to make the new cover letter and all the patches replies to the
   cover letter of the previous series; this has been changed to make
   the patches in the new series replies to the new cover letter.

 * The Bash completion script in contrib/ has been adjusted to be usable with
   Bash 4 (options with '=value' didn't complete).  It has been also made
   usable with zsh.

 * Different pagers can be chosen depending on which subcommand is
   being run under the pager, using the pager.subcommand variable.

 * The hardcoded tab-width of 8 that is used in whitespace breakage checks is 
now
   configurable via the attributes mechanism.

 * Support of case insensitive filesystems (i.e. core.ignorecase) has
   been improved.  For example, the gitignore mechanism didn't pay attention
   to case insensitivity.

 * The tree:path syntax for naming a blob in a tree, and the :path
   syntax for naming a blob in the index (e.g. master:Makefile,
   :hello.c) have been extended.  You can start path with ./ to
   implicitly have the (sub)directory you are in prefixed to the
   lookup.  Similarly, 

Updated: bash-4.1.9-3

[Eric Blake (cygwin)]

A new release of bash, 4.1.9-3, has been uploaded and will soon reach a
mirror near you; replacing 4.1.9-2 and leaving bash 3.2.51-24 as previous.

NEWS:
=
This is a minor rebuild which avoids a miscompilation that was causing
bash to crash on some machines during ssh-host-config.

There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by
default.
2. d2u is your friend.  You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file.  If you
absolutely must use files with \r\n line endings, consider mounting the
directory where those files live as a text mount.  However, text mounts
are not as well tested or supported on the cygwin mailing list, so you
may encounter other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific set option, named igncr,
to force bash to ignore \r, independently of cygwin's mount style.  As
of bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files.  I hope to convince the upstream bash maintainer to
accept this patch into a future bash release even on Linux, rather than
keeping it a cygwin-specific patch, but only time will tell.  There are
several ways to activate this option:
4a. For a single affected script, add this line just after the she-bang:
 (set -o igncr) 2/dev/null  set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the option, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired.  Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it.  It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks
the current state of 'set -o igncr'.  If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make
sense to support the option through both set and shopt, and SHELLOPTS
proved to be more powerful.
5. You can also experiment with the IFS variable for controlling how
bash will treat \r during variable expansion.
6. There are varying levels of speed at which bash operates.  The
fastest is on a binary mount with igncr disabled (the default behavior).
 Next would be text mounts with igncr disabled and no \r in the
underlying file. Next would be binary mounts with igncr enabled.  And
the slowest that bash will operate is on text mounts with igncr enabled.
7. As additional cygwin extensions, this version of bash includes:
7a. EXECIGNORE - a colon-separated list of glob patterns to ignore
when completing on executables.  EXECIGNORE=*.dll is common.
7b. completion_strip_exe - using 'shopt -s completion_strip_exe'
makes completion strip .exe suffixes
8. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas.  This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
Thanks to Dan Colascione for providing the EXECIGNORE and
completion_strip_exe patches.

Remember, you must not have any bash or /bin/sh instances running when
you upgrade the bash package.  This release requires cygwin-1.7.7-1 or
later; and it requires libreadline7-6.1.2-2 or later.  See also the
upstream documentation in /usr/share/doc/bash/.

DESCRIPTION:

Bash is an sh-compatible shell that incorporates useful features from
the Korn shell (ksh) and C shell (csh).  It is intended to conform to
the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard.  It offers
functional improvements over sh for both programming and interactive
use. In addition, most sh scripts can be run by Bash without modification.

As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
similar to some Linux distributions (although /bin/sh may swap to dash
at some future time).

UPDATE:
===
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. Save it and run setup, answer the questions and pick up 'bash'
in the 'Base' category (it should already be selected).  As this is an
experimental release, you will need to use the 'Exp' radio button.

DOWNLOAD:
=
Note that downloads from cygwin.com aren't allowed