Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)

2012-08-23 Thread Martin . Fitzpatrick 
Hi,

I have just completed a cygwin install, which seemed to take an 
extraordinary length of time, so I started googling and found the article 
"Setup 1.7.11 texlive postinstall takes 6+ hours". Ken Brown's response to 
that post was hopeful, but may have underestimated the scope of the 
problem, putting it down to "something else going on with your system, 
maybe having to do with your VM." My installation was on a laptop, not a 
VM, and while I wouldn't claim that it's a powerful machine, I'm still 
very surprised at the install time. I also think it remarkable that most 
(something like 90%) of the install time was spent in the texlive 
postinstall phase; so in other words, most of the install ran at an 
acceptable speed (~16 mins to get to the start of the postinstall phase- 
not too bad for a slow laptop) but the first texlive task 
("/etc/postinstall/texlive-collection-basic.sh") then took 25 mins- more 
than the rest of the install up to that point.

So, I would say to Ken Brown- "Keep up the good work"- but please consider 
raising its priority! At the time of writing you had fixed 29 postinstall 
scripts and there were 45 remaining. Some users are being hit very hard by 
this and in fact I aborted the install several times before I realized 
that it wasn't hanging completely and that the postfix to the 
"/etc/postinstall/texlive-..." message in the install window was actually 
changing from time to time- it was that slow! I can send the 
setup.log.full if you want to see the timestamps for yourself.

Regards,
Martin.





This document is strictly confidential and intended only for use by the 
addressee unless otherwise stated.  If you are not the intended recipient, 
please notify the sender immediately and delete it from your system.



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

Re: Cygwin crashes in kill_pgrp, _pinfo truncation issue.

2012-08-23 Thread Andrey Khalyavin 
On Wed, 15 Aug 2012 10:11:16 -0400, Christopher Faylor wrote:
>On Wed, Aug 15, 2012 at 04:54:42PM +0400, Andrey Khalyavin wrote:
>>I finally got a cygwin crash dump from our build bots. It shows, that
>>cygwin1.dll crashes in kill_pgrp function on line:
>>(pid > 1 && p->pgid != pid) ||
>>where p is a pointer to _pinfo. This function enumerates all _pinfo's
>>and executes this line for all of them which pass p->exists() check.
>>In crash dump p points to _pinfo that has process_state equal to
>>PID_IN_USE | PID_EXECED.
>
>Thanks for tracking this down.  I've added a check for "execed" to
>_pinfo::exists.
>
>cgf

I got two more crash dumps from our bots running 20120816 snapshot.
Both of them crashed in this place. process_state equals to
PID_IN_USE | PIE_EXECED and your new check in _pinfo::exist is really there.
So the race condition on process_state field does happens in practice.

Andrey Khalyavin

--
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: Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)

2012-08-23 Thread Earnie Boyd 
On Thu, Aug 23, 2012 at 6:03 AM, Martin.Fitzpatrick wrote:
> Hi,
>
> I have just completed a cygwin install, which seemed to take an
> extraordinary length of time, so I started googling and found the article

If you do the same with the anti-virus disabled does it change the
length of time?

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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: Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)

2012-08-23 Thread Adam Dinwoodie 
Martin.Fitzpatrick@... wrote:
> This document is strictly confidential and intended only for use by the 
> addressee unless otherwise stated.  If you are not the intended recipient, 
> please notify the sender immediately and delete it from your system.

Martin, per , disclaimers
like this aren't appropriate for a public mailing list. Emails to this list
are seen by a very wide number of people and are publicly archived online
indefinitely.

Overseers, as requested, have a disclaimer that seems to have slipped through
the filter.

--
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: Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)

2012-08-23 Thread Ken Brown 

On 8/23/2012 6:03 AM, martin.fitzpatr...@sita.aero wrote:

Hi,

I have just completed a cygwin install, which seemed to take an
extraordinary length of time, so I started googling and found the article
"Setup 1.7.11 texlive postinstall takes 6+ hours". Ken Brown's response to
that post was hopeful, but may have underestimated the scope of the
problem, putting it down to "something else going on with your system,
maybe having to do with your VM." My installation was on a laptop, not a
VM, and while I wouldn't claim that it's a powerful machine, I'm still
very surprised at the install time. I also think it remarkable that most
(something like 90%) of the install time was spent in the texlive
postinstall phase; so in other words, most of the install ran at an
acceptable speed (~16 mins to get to the start of the postinstall phase-
not too bad for a slow laptop) but the first texlive task
("/etc/postinstall/texlive-collection-basic.sh") then took 25 mins- more
than the rest of the install up to that point.

So, I would say to Ken Brown- "Keep up the good work"- but please consider
raising its priority! At the time of writing you had fixed 29 postinstall


There is definitely some inefficiency in the postinstall scripts when 
many texlive-collection-* packages are installed at once.  I'm working 
on finding a better way of doing it.  See the thread starting at


  http://cygwin.com/ml/cygwin-apps/2012-08/msg1.html


scripts and there were 45 remaining. Some users are being hit very hard by
this and in fact I aborted the install several times before I realized
that it wasn't hanging completely and that the postfix to the
"/etc/postinstall/texlive-..." message in the install window was actually
changing from time to time- it was that slow! I can send the
setup.log.full if you want to see the timestamps for yourself.


Yes, I would like to see setup.log.full.  If it's huge, you can send it 
off list, or just post it somewhere for me to download.


Ken

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

mkshortcut -P (from xinit.sh)

2012-08-23 Thread Denis Excoffier 

Hello,

I have a problem with mkshortcut, namely the one
used in /etc/postinstall/xinit.sh.

% mkshortcut -P /usr/bin/run.exe
Abort
%

this takes 1 minute to abort, and nothing is performed. Without -P, no
problem of course. I also have no problem to write into the
`cygpath -P` directory.

% cygpath -P
/cygdrive/d/Documents and Settings/dexcoff1/Menu Démarrer/Programmes
%

I must say that my installation of Cygwin is "For me only". I do not
have any Administrator priviledges. I use the 20120817 Cygwin snapshot
and latest packages.

I include the strace output with the mkshortcut.exe.stackdump.

Hope this helps,

Denis Excoffier.
% /usr/bin/env -i PATH=/usr/bin /usr/bin/strace /usr/bin/mkshortcut -P 
/usr/bin/run.exe
3   3 [main] mkshortcut (1640) 
**
   85  88 [main] mkshortcut (1640) Program name: 
D:\Home\dexcoff1\dexcoff1\cyg12e\bin\mkshortcut.exe (windows pid 1640)
   36 124 [main] mkshortcut (1640) OS version:   Windows NT-5.1
   33 157 [main] mkshortcut (1640) 
**
  158 315 [main] mkshortcut (1640) sigprocmask: 0 = sigprocmask (0, 
0x6123D428, 0x610FBB80)
  332 647 [main] mkshortcut 1640 open_shared: name shared.5, n 5, shared 
0x60FF (wanted 0x60FF), h 0x798, *m 6
   42 689 [main] mkshortcut 1640 heap_init: heap base 0x2000, heap top 
0x2000, heap size 0x1800 (402653184)
   46 735 [main] mkshortcut 1640 open_shared: name 
S-1-5-21-2047029477-161106353-1238779560-28430.1, n 1, shared 0x60FE 
(wanted 0x60FE), h 0x7A0, *m 6
   46 781 [main] mkshortcut 1640 user_info::create: opening user shared for 
'S-1-5-21-2047029477-161106353-1238779560-28430' at 0x60FE
   36 817 [main] mkshortcut 1640 user_info::create: user shared version 
6467403B
   54 871 [main] mkshortcut 1640 fhandler_pipe::create: name 
\\.\pipe\cygwin-2880dde9dfe79b35-1640-sigwait, size 164, mode PIPE_TYPE_MESSAGE
   62 933 [main] mkshortcut 1640 fhandler_pipe::create: pipe read handle 
0x784
   33 966 [main] mkshortcut 1640 fhandler_pipe::create: CreateFile: name 
\\.\pipe\cygwin-2880dde9dfe79b35-1640-sigwait
   601026 [main] mkshortcut 1640 fhandler_pipe::create: pipe write handle 
0x780
   421068 [main] mkshortcut 1640 dll_crt0_0: finished dll_crt0_0 
initialization
11496   12564 [sig] mkshortcut 1640 wait_sig: entering ReadFile loop, 
my_readsig 0x784, my_sendsig 0x780
  142   12706 [main] mkshortcut 1640 mount_info::conv_to_posix_path: 
conv_to_posix_path (D:\Home\dexcoff1\dexcoff1\cygscf, no-keep-rel, no-add-slash)
   39   12745 [main] mkshortcut 1640 normalize_win32_path: 
D:\Home\dexcoff1\dexcoff1\cygscf = normalize_win32_path 
(D:\Home\dexcoff1\dexcoff1\cygscf)
   40   12785 [main] mkshortcut 1640 mount_info::conv_to_posix_path: 
/cygdrive/d/Home/dexcoff1/dexcoff1/cygscf = conv_to_posix_path 
(D:\Home\dexcoff1\dexcoff1\cygscf)
   49   12834 [main] mkshortcut 1640 sigprocmask: 0 = sigprocmask (0, 
0x200180A8, 0x610FBB80)
  112   12946 [main] mkshortcut 1640 _cygwin_istext_for_stdio: fd 0: not open
   22   12968 [main] mkshortcut 1640 _cygwin_istext_for_stdio: fd 1: not open
   24   12992 [main] mkshortcut 1640 _cygwin_istext_for_stdio: fd 2: not open
   74   13066 [main] mkshortcut (1640) open_shared: name cygpid.1640, n 1640, 
shared 0x60FD (wanted 0x60FD), h 0x730, *m 2
   26   13092 [main] mkshortcut 1640 pinfo::thisproc: myself dwProcessId 1640
   32   13124 [main] mkshortcut 1640 time: 1345726845 = time(0)
  476   13600 [main] mkshortcut 1640 reg_key::build_reg: failed to create key 
Cygwin in the registry
  417   14017 [main] mkshortcut 1640 reg_key::build_reg: failed to create key 
Cygwin in the registry
   49   14066 [main] mkshortcut 1640 environ_init: GetEnvironmentStrings 
returned 0x1
   34   14100 [main] mkshortcut 1640 parse_options: glob (called func)
   41   14141 [main] mkshortcut 1640 parse_options: returning
   30   14171 [main] mkshortcut 1640 environ_init: 0x20028290: CYGWIN=noglob
   46   14217 [main] mkshortcut 1640 getwinenv: can't set native for PATH= 
since no environ yet
   41   14258 [main] mkshortcut 1640 mount_info::conv_to_posix_path: 
conv_to_posix_path (D:\Home\dexcoff1\dexcoff1\cyg12e\bin, keep-rel, 
no-add-slash)
   18   14276 [main] mkshortcut 1640 normalize_win32_path: 
D:\Home\dexcoff1\dexcoff1\cyg12e\bin = normalize_win32_path 
(D:\Home\dexcoff1\dexcoff1\cyg12e\bin)
   25   14301 [main] mkshortcut 1640 mount_info::conv_to_posix_path: /usr/bin = 
conv_to_posix_path (D:\Home\dexcoff1\dexcoff1\cyg12e\bin)
   63   14364 [main] mkshortcut 1640 win_env::add_cache: posix /usr/bin
   24   14388 [main] mkshortcut 1640 win_env::add_cache: native 
PATH=D:\Home\dexcoff1\dexcoff1\cyg12e\bin
   21   14409 [main] mkshortcut 1640 posify_maybe: env var converted to 
PATH=/usr/bin
   65   14474 [main] mkshortcut 1640 environ_init: 0x20038330: PATH=/usr/bin
   47   14521 [main] mkshortcut 1640 environ_init: 0x200282B8:

Glitch-free texlive-collection-basic.sh and other uses of setup v.2.510.2.2

2012-08-23 Thread Fergus 

On today's update of texlive-collection-basic I got the exit message
Package: texlive-collection-basic
texlive-collection-basic.sh exit code 148
which typically seems to follow most texlive installations.
At subsequent uses of setup, even when there is nothing new to install, 
the "unknown package" /etc/postinstall/texlive-collection-basic.sh is 
again run, resulting in the same exit code, and this behaviour is 
recurrent. The attempt takes an unbelievable 4 minutes each time, even 
on a moderately new and fast machine (XP Pro SP3).
There is a way round this. I use good old setup v.2.510.2.2 (c. 2005) 
having deleted "message:" entries from setup.ini , which this old 
version doesn't understand. Hey presto, the script is run, exits just 
fine, and there is no recurrence. There may be other ways, but I don't 
know them and can't remember reading about them here.


With the editing of setup.ini described above which is a bit of a chore, 
my preference is to use v.2.510 for everything, including brand new 
installs both of 1.7 and the Legacy 1.5. Doing this, I have not 
experienced another setup annoyance, where a request to install Cygwin 
at location H:\ is ignored, and the installation proceeds remorselessly 
to C:\cygwin\.


Unfortunately, despite a clear chain of .. requires: -> requires: -> 
requires: .. in setup.ini, I found after using v.2.510.2.2 for a brand 
new install, one missing dependency. I'm not exactly certain how an 
engine that works its way correctly through very many essentially 
identical instruction lists can have slipped up with just one, but this 
did occur [can't remember details but they are there somewhere on this 
list and I will look for them]. This rather dented my confidence in and 
reliance upon this old favourite. Otherwise I would use it the whole time.


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: Perl 5.14 and XML::Parser

2012-08-23 Thread Thomas Wicklund 
On Friday, August 17, 2012 4:50 PM, Reini Urban wrote:
>On Thu, Aug 16, 2012 at 6:55 AM, Christopher Faylor  wrote:
>> On Wed, Aug 15, 2012 at 10:04:48PM -0600, Thomas Wicklund wrote:
>>>The update of perl on to 5.14 moved some perl modules to a new
>>>perl_vendor package which is not installed by default.  The
>>>announcement I found stated that perl_vendor is modules "which are
>>>mainly required to build and test and report test results of other CPAN
>>>modules."
>
>That was the short summary, yes.
>
>>>I find that the XML::Parser module (at least) has been moved.  I've
>>>been using this module for years to parse XML output for a set of
>>>Subversion tools.  I had a couple hours of digging today to figure out
>>>why a coworker started getting errors after updating Cygwin, then
>>>figuring out the new package.
>
>As an request from Yaakov and also from upstream p5p
>I have moved all non-core packages to the new perl_vendor.
>
>>>As an occasional user of perl I would much prefer that the maximum
>>>number of packages be included in the distribution (since disk space
>>>and bandwidth are constantly becoming cheaper) than to have to spend
>>>time figuring out why something can't be found.
>
>This is right. I really sympathize with you and all others.
>But unfortunately I had to made this move for political reasons,
>not technical ones.

Thank you for the response.  While the new package was annoying and
took some time to figure out, I was more concerned that the
announcement implied that the new package was for modules which
weren't of general use.

I didn't see the original announcement (we rarely update cygwin) so it
took a while to find.  However, even if I had seen the announcement I
wouldn't have had any reason think it would affect me.

Thomas Wicklund

--
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: Glitch-free texlive-collection-basic.sh and other uses of setup v.2.510.2.2

2012-08-23 Thread Fergus 

Unfortunately, despite a clear chain of
.. requires: -> requires: -> requires: ..
in setup.ini, I found after using v.2.510.2.2
for a brand new install, one missing dependency.


As follows:


Attempting to run pdftex I am getting:
/usr/bin/pdftex.exe: error while loading shared libraries:
?: cannot open shared object file: No such file or directory



~> cygcheck /bin/pdftex.exe
... cygcheck: track_down: could not find cygsasl2-2.dll
So I installed cyrus-sasl. Thereafter, perfect.
Should I have known about this requirement (or maybe just libsasl2)?
Can it be included, as a requirement, somewhere appropriate?



It already is a requirement.  In setup.ini
texlive ==> libpoppler19 ==> libcurl4 ==> libopenldap2_3_0 ==> libsasl2.
So setup.exe should have offered to install it.


Unfortunately (no idea why or how) the otherwise flawlessly beautiful 
setup v.2.510.2.2 as an instrument

of Cygwin installation and maintenance didn't pick this up.

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: Glitch-free texlive-collection-basic.sh and other uses of setup v.2.510.2.2

2012-08-23 Thread Christopher Faylor 
On Thu, Aug 23, 2012 at 03:29:54PM +0100, Fergus wrote:
>On today's update of texlive-collection-basic I got the exit message
>Package: texlive-collection-basic
> texlive-collection-basic.sh exit code 148
>which typically seems to follow most texlive installations.
>At subsequent uses of setup, even when there is nothing new to install, 
>the "unknown package" /etc/postinstall/texlive-collection-basic.sh is 
>again run, resulting in the same exit code, and this behaviour is 
>recurrent. The attempt takes an unbelievable 4 minutes each time, even 
>on a moderately new and fast machine (XP Pro SP3).
>There is a way round this. I use good old setup v.2.510.2.2 (c. 2005) 
>having deleted "message:" entries from setup.ini , which this old 
>version doesn't understand. Hey presto, the script is run, exits just 
>fine, and there is no recurrence. There may be other ways, but I don't 
>know them and can't remember reading about them here.
>
>With the editing of setup.ini described above which is a bit of a chore, 
>my preference is to use v.2.510 for everything, including brand new 
>installs both of 1.7 and the Legacy 1.5. Doing this, I have not 
>experienced another setup annoyance, where a request to install Cygwin 
>at location H:\ is ignored, and the installation proceeds remorselessly 
>to C:\cygwin\.

Please don't bother us with any problems, concerns, or observations
you have about using unsupported versions of setup.exe.

If there is a problem in a postinstall script then it's likely that
someone will fix it.  We definitely will not spend one iota of time
supporting your quixotic attempts to use an ancient version of
setup.exe.

cgf

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

Non-interactive SSH connection fails - error: can't open /dev/tty: No such device or address - Host key verification failed

2012-08-23 Thread Costin Caraivan 
Hello,

Below you can see the log. The connection is from a Windows 2008
Cygwin SSH client to a Windows 2008 Cygwin SSHD server.
The connection works ok when launched from the command line but fails
when launched from Jenkins (Java Continuous Integration server).
Jenkins actually creates a temporary batch script containing exactly
the same command I can run from the command line directly. So: manual
execution - ok, execution through the script - *ko*.
The /dev/tty file exists and is rw for everybody. I tried deleting it
and recreating it, but I can't since Cygwin recreates it before I can
create a link to /dev/ttySO.
The connection uses SSH keys with no passphrases.

Any other extra debugging ideas? By the way, where can I see the
Cygwin SSHD server logs? In /var/logs/sshd.log is empty :(

ssh -t -vvv myu...@server.company.com 'mv -v
/cygdrive/z/deploy-scripts /cygdrive/z/deploy-scripts-`date
+%F_%H-%M-%S`'
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug2: ssh_connect: needpriv 0
debug1: Connecting to server.company.com port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: identity file /.ssh/id_ecdsa type -1
debug1: identity file /.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit:
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,z...@openssh.com
debug2: kex_parse_kexinit: none,z...@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed

Thank you,
_
Costin Caraivan

why don't you publish my messages ? ;) ;((

2012-08-23 Thread Evgeny Tarasov 
For the year I've posted about 3 messages with obvious cygwin
troubles, but I did no see them in the mailing list on the web. Tell
me please, what is the reason? I am sorry, I am capable of writing
nice english text but I think I am quite understandable as is.
Please publish my message about gdb trouble with the newest cygwin1.dll

--
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: why don't you publish my messages ? ;) ;((

2012-08-23 Thread Christopher Faylor 
On Thu, Aug 23, 2012 at 11:34:28PM +0400, Evgeny Tarasov wrote:
>For the year I've posted about 3 messages with obvious cygwin
>troubles, but I did no see them in the mailing list on the web. Tell
>me please, what is the reason? I am sorry, I am capable of writing
>nice english text but I think I am quite understandable as is.
>Please publish my message about gdb trouble with the newest cygwin1.dll

You say you're capable of writing nice english text.  Are you capable of
reading english text bounce messages?  It doesn't seem like you are
since you've received several.

Please don't bother the mailing list with your inability to send
messages here.  Read your bounces.

--
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: Glitch-free texlive-collection-basic.sh and other uses of setup v.2.510.2.2

2012-08-23 Thread Ken Brown 

On 8/23/2012 10:29 AM, Fergus wrote:

On today's update of texlive-collection-basic I got the exit message
Package: texlive-collection-basic
 texlive-collection-basic.sh exit code 148


Please send /var/log/setup.log.full so I can see what the errors were. 
If it's too big, you can send it off list or just post it somewhere for 
me to download.  And please attach your cygcheck output also.


Ken


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

Re: Non-interactive SSH connection fails - error: can't open /dev/tty: No such device or address - Host key verification failed

2012-08-23 Thread Larry Hall (Cygwin) 

On 8/23/2012 2:31 PM, Costin Caraivan wrote:

Hello,

Below you can see the log. The connection is from a Windows 2008
Cygwin SSH client to a Windows 2008 Cygwin SSHD server.
The connection works ok when launched from the command line but fails
when launched from Jenkins (Java Continuous Integration server).
Jenkins actually creates a temporary batch script containing exactly
the same command I can run from the command line directly. So: manual
execution - ok, execution through the script - *ko*.
The /dev/tty file exists and is rw for everybody. I tried deleting it
and recreating it, but I can't since Cygwin recreates it before I can
create a link to /dev/ttySO.
The connection uses SSH keys with no passphrases.


Can we see cygcheck -srv output for both machines?  Does it work going
from client to client or server to server (i.e. 1 machine only).  Are
you up-to-date?  If so, does the latest snapshot help?




Any other extra debugging ideas? By the way, where can I see the
Cygwin SSHD server logs? In /var/logs/sshd.log is empty :(


'/var/log/sshd.log'.  But it will be empty if nothing noteworthy
has occurred.  If you want to see more chatter, add a new service entry
to run sshd with debug flags.  You can grab the details for how to set up
a sshd service from '/bin/ssh-host-config' but the basics are:

/usr/bin/cygrunsrv -I sshd_debug -d "CYGWIN Debug sshd" -p /usr/sbin/sshd -a 
"-D -d -d -d" -y tcpip -u cyg_server -w 


The three "-d" flags are the important part.  To start this service, use:

/usr/bin/cygrunsrv -S sshd_debug

This will need to be restarted with each connection attempt.  Also, you
should stop your regular sshd service while running this so they don't
conflict.

/usr/bin/cygrunsrv -E sshd

Apologies for typos.

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

GDB behaves differently on the final cygwin1.dll 1.7.16 and on a previous one.

2012-08-23 Thread Evgeny Tarasov 
Well,

I've got two different cygwin1.dll's of 1.7.16 version.
The first one was obtained from cvs and built by myself (is it attached to 5th 
june, 2012; as uname -a says)
The other one is of final 20 july, 2012 ver.

So my question is the following:
Why the same GDB does not want to put breakpoints to the same (and any) source 
when I work with the latest of the two.
I always have completely updated cygwin installation, but in order to debug, i 
have to replace the latest cygwin1.dll with the previous.

NOTE. However, if my executables and sources reside on the other partition 
(different from the partition of CYGWIN itself), gdb (with the latest 
cygwin1.dll) works well.
I.e., gdb establishes a breakpoint by command:
break /cygdrive/d/cygwin/home/user/project/file.cpp:
And (there will not be any exaggeration to say) it refuses to do that by command
break /cygdrive/c/cygwin/home/user/project/file.cpp:
;-)
the version of the 5th june works well in the both cases.

Which kind of info should I provide if so?

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

Subscription

2012-08-23 Thread nyjkk...@gmail.com 
subscribe cygwin

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