Input method in cygwin-x ?

2015-03-24 Thread Arthur Tu
Is there a way to use input method in cygwin-x environment?

For example, when I invoke emacs with
"
ssh -X remote-machine
emacs
""

I can't use either input methods in local windows machine or those in
remote linux server.

Thanks,
Arthur

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



[PATCH] cygcheck-dep 2.0-1: Bogus output from -l option

2015-03-24 Thread Christian Franke
The 'cygcheck-dep -l' output also lists various packages which are 
actually required by other packages.


Testcase:

$ cygcheck -f /bin/cygcheck-dep
cygcheck-dep-2.0-1

$ cygcheck-dep -c -N ncursesw
 ncursesw: is recursively needed for ( )

$ cygcheck-dep -c -N ncurses
 ncurses: is recursively needed for ( ncursesw )

$ cygcheck-dep -c -l | grep '^ ncurses'
 ncurses
 ncursesw

The attached patch should fix that.

Christian

--- cygcheck-dep.orig	2013-12-06 22:08:41.0 +0100
+++ cygcheck-dep	2015-03-25 07:25:10.336495900 +0100
@@ -581,7 +581,7 @@
 fi
 
 if [ "$f_nonleaves_be_necessary" ]; then
-  nonleaf_pkgs="$(IFS=$'\n' sort -n <<<"${pkg_drequisites[*]}" | sed '/^$/d' | uniq -c | sort -r | sed 's/^.* //')"
+  nonleaf_pkgs="$(IFS=$'\n'; tr ' ' '\n' <<<"${pkg_drequisites[*]}" | sed '/^$/d' | sort -n | uniq)"
 fi
 ### */
 

--
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 Git thinks files are changed when they aren't

2015-03-24 Thread Achim Gratz
Chloe writes:
> Cygwin Git always thinks files are changed even when they
> aren't. After a commit with a Windows Git, Cygwin Git shows files as
> modified.

Then either don't mix Cygwin's and whatever Windows' Git you're using or
tell Git to ignore the mode bits altogether (check the documentation for
global.filemode in git-config).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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 Git thinks files are changed when they aren't

2015-03-24 Thread Jim Garrison
On 3/24/2015 5:50 PM, Yaakov Selkowitz wrote:
> On Tue, 2015-03-24 at 16:42 -0400, Chloe wrote:
>> Cygwin Git always thinks files are changed even when they aren't. After 
>> a commit with a Windows Git, Cygwin Git shows files as modified.
> [snip]
>> $ git diff .project
>> diff --git a/.project b/.project
>> old mode 100644
>> new mode 100755
> 
> This is your answer.  On Windows, everything is executable, so changing
> a file with any native Windows program is bound to set the executable
> bit.  A change in permissions is considered a modification in git, hence
> the message.
> 
> To avoid this, you'll probably have to git clone with your Windows git
> to start with, as Cygwin programs won't change the permissions unless
> you tell them to.

See http://stackoverflow.com/questions/1580596

git config core.fileMode false


-- 
Jim Garrison (j...@acm.org)
PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88

--
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: update trouble 1.7.35

2015-03-24 Thread Steve Johnson
Corinna Vinschen  cygwin.com> writes:

> 
> 
> from the keyserver hkp://keys.gnupg.net.  However, what about my
> questions about setting "db" only in nsswitch.conf?  Does it help?
> Do you have a SID history, too, by any chance?
> 

The last test that I did was with "db" only in nsswitch.conf and unfortunately 
no, it did not help. I have also checked and I do not have an SID history. I 
hightly doubted as this is a new account, but double checked and all OK.

I have sent trace file and cygcheck -srv to your other specified email address.

Thanks again,
Steve Johnson





--
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 Git thinks files are changed when they aren't

2015-03-24 Thread Yaakov Selkowitz
On Tue, 2015-03-24 at 16:42 -0400, Chloe wrote:
> Cygwin Git always thinks files are changed even when they aren't. After 
> a commit with a Windows Git, Cygwin Git shows files as modified.
[snip]
> $ git diff .project
> diff --git a/.project b/.project
> old mode 100644
> new mode 100755

This is your answer.  On Windows, everything is executable, so changing
a file with any native Windows program is bound to set the executable
bit.  A change in permissions is considered a modification in git, hence
the message.

To avoid this, you'll probably have to git clone with your Windows git
to start with, as Cygwin programs won't change the permissions unless
you tell them to.

--
Yaakov





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



Re: mkpasswd: option to force the 'primary' domain?

2015-03-24 Thread Corinna Vinschen
On Mar 24 13:29, Linda Walsh wrote:
> Corinna Vinschen wrote:
> >On Mar 20 11:58, Tim Magee wrote:
> >>Now then,
> >>
> >>Since Cygwin 1.7.34 dropped, mkpasswd has been problematic for us.  Our
> >>problem is with the way user names pulled from outside the primary domain
> >>get decorated.  My question is: will there ever be a way to tell
> >>mkpasswd/mkgroup "make  the one whose users get
> >>undecorated names"?
> 
> >I'm not planning this.  The idea is that mkpasswd/mkgroup create account
> >names compatible with the "db"-based accounts and everyhing else is left
> >to post-creation manipulation.
> ---
> I never quite managed to understand this -- as my pw/grp files on
> my client machines were already in sync with my domain setup and
> worked as it would in a real Win Domain (i.e. Domain applied when I signed
> into a machine that wasn't the domain controller and was using domain
> credentials).  If I logged into a machine with a local account, there has 
> never
> been a domain name to have to bother with -- so for me user-logins were 
> prefixed
> with the domain only when they were in a domain.
> 
> This has been the way windows has worked for as long as I've run a domain 
> server --
> if a local machine is not in a domain, then it's username-only, but if it is
> in a domain, then I'd need to type-or-add the local-machine name to NOT login
> via the domain creds.
> 
> For local accounts, the RID==the UID, for domain accounts the RID==the UID on
> the domain controller.
> 
> Do I understand that cygwin is no longer compatible with window's (and
> samba's) naming convention?  That would be a pain.

Did you go to the trouble to read the new documentation under
https://cygwin.com/cygwin-ug-net/ntsec.html?  It's all explained there.
If you don't like it, use passwd and group files with changed user names.


Corinna

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


pgpMx06v_5eW3.pgp
Description: PGP signature


Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 19:43, Steve Johnson wrote:
> Corinna Vinschen  cygwin.com> writes:
> 
> > 
> > This "uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)"
> > should only happen if you have /etc/nsswitch.conf is set to "files"
> > only, and there's no entry in /etc/passwd with a matching SID.
> > That's the only way I can reproduce this behaviour.
> > 
> > Corinna
> > 
> 
> 
> Hi Corinna,
> 
> Where could I get the gpg key to send, as you had suggested earlier? I've 
> tried 
> posting replies with the requested information many times, but they all have 
> seemed to fail...

from the keyserver hkp://keys.gnupg.net.  However, what about my
questions about setting "db" only in nsswitch.conf?  Does it help?
Do you have a SID history, too, by any chance?


Corinna

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


pgpfCrHM2mKvH.pgp
Description: PGP signature


Cygwin Git thinks files are changed when they aren't

2015-03-24 Thread Chloe
Cygwin Git always thinks files are changed even when they aren't. After 
a commit with a Windows Git, Cygwin Git shows files as modified.


Windows Git
--
C:\Users\Chloe\workspace\AffiliateArbitrage>git status
On branch master
nothing to commit, working directory clean

C:\Users\Chloe\workspace\AffiliateArbitrage>git --version
git version 1.9.5.msysgit.1
-

Cygwin Git
-
$ git status
On branch master
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   .project
... dozens of files 

$ git --version
git version 2.1.4

$ git diff .project
diff --git a/.project b/.project
old mode 100644
new mode 100755


$ ls -l .project
-rwxrwx---+ 1 Chloe None 574 Mar 10 21:28 .project


$ uname -a
CYGWIN_NT-6.3-WOW xps 1.7.35(0.287/5/3) 2015-03-04 12:07 i686 Cygwin

-





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



Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 17:56, Lemke, Michael  ST/HZA-ZSW wrote:
> On Tuesday, March 24, 2015 5:49 PM Corinna Vinschen wrote:
> >> Note that "they" did a domain switch here at some point.  My installation 
> >> is really old and the passwd certainly is from before that domain change.
> >
> >That explains it.  Please recreate your /etc/passwd and /etc/group
> >files with mkpasswd and mkgroup, or, even better, just discard them.
> >
> 
> I just created new ones.  I like passwd/group much better than AD, sorry.  
> Just like real unix before the invention of yellow pages and nis.

Yeah, but real unix these days is NIS+ or FreeIPA, or... even AD :)

> This 
> way I can easily give different shells to different users (not that it is
> really important at the moment).

You can do that in AD as well.  Or, as long as all users want the same
shell, you can simply use `db_shell: /bin/tcsh'.

> In nsswitch.conf I put 
> passwd: files db
> group: files db

That's the default setting.  You can simply remove nsswitch.conf in this
case, which should result in a slightly faster startup because Cygwin
doesn't have to scan YA file.

> and ls listings seem to look fine.  Login is also possible again
> with correct tcsh shell.

I'm glad to read that.

> >The problem is the domain switch which also changed the SID of your user
> >account.  The old SID, which you also have in your passwd, is not
> >returned by the server anymore.  But it's stored in your SID history in
> >AD and when asking for it you get an answer.
> 
> So, to sort of sum this up: the new cygwin doesn't deal well with 
> contradicting entries in passwd and AD. 

Basically, yes.  More to the point, your user token and your passwd
file contradict each other.  The user and owner entry in your
user token is your new SID.  The old SID only shows up in the token's
group list, afaik.

> >Downside: Cygwin can't handle the old SIDs from your SID history quite
> >correctly.  
> 
> Actually, with "files db" it seems to handle it quite well.  I get the same
> username for both kind of files.  There are still lots of files in my
> home I created before the domain switch.

Ok, I just can't guarantee that it always works.  The SID history stuff
is a weird solution for a weird problem.

> >Trying to support them as well would slow down the user and
> >group lookups a lot.  If you can live with what we just found out and
> >the solution I suggested, I'd be rather happy :}
> >
> 
> Yes, I am happy now.

Then I am, too :)


Thanks,
Corinna

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


pgpECx_4Boib6.pgp
Description: PGP signature


Re: mkpasswd: option to force the 'primary' domain?

2015-03-24 Thread Linda Walsh

Corinna Vinschen wrote:

On Mar 20 11:58, Tim Magee wrote:

Now then,

Since Cygwin 1.7.34 dropped, mkpasswd has been problematic for us.  Our
problem is with the way user names pulled from outside the primary domain
get decorated.  My question is: will there ever be a way to tell
mkpasswd/mkgroup "make  the one whose users get
undecorated names"?



I'm not planning this.  The idea is that mkpasswd/mkgroup create account
names compatible with the "db"-based accounts and everyhing else is left
to post-creation manipulation.

---
I never quite managed to understand this -- as my pw/grp files on
my client machines were already in sync with my domain setup and
worked as it would in a real Win Domain (i.e. Domain applied when I signed
into a machine that wasn't the domain controller and was using domain
credentials).  If I logged into a machine with a local account, there has never
been a domain name to have to bother with -- so for me user-logins were prefixed
with the domain only when they were in a domain.

This has been the way windows has worked for as long as I've run a domain 
server --
if a local machine is not in a domain, then it's username-only, but if it is
in a domain, then I'd need to type-or-add the local-machine name to NOT login
via the domain creds.

For local accounts, the RID==the UID, for domain accounts the RID==the UID on
the domain controller.  

Do I understand that cygwin is no longer compatible with window's (and samba's) 
naming convention?  That would be a pain.






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



X server sets VMIN? (was Re: Under /bin/script, characters get printed in four-character chunks)

2015-03-24 Thread Corinna Vinschen
On Mar 24 19:59, Denis Excoffier wrote:
> On 2015-02-28 16:30, Corinna Vinschen wrote:
> > I can not reproduce this in mintty, nor in a Cygwin xterm started on a
> > remote X server running under Linux.  I can reproduce this with a local
> > xterm started via startxwin.  But, and that's the problem, I can
> > reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
> > last but not least also with a debug version of the Cygwin DLL in which I
> > backed out all PTY-related changes since last November.
> > 
> > I'm not sure this is a giveaway, but from that it seems this problem
> > is not directly related to a Cygwin change in the last months.
> > 
> > So, jturney and I are wondering when exactly you encountered this problem
> > for the first time.  Did it coincide with a certain Cygwin release,
> > or a certain X server?  Or new X libs, perhaps?
> > 
> > Anything you can provide to narrow down the potential culprit would be
> > helpful.
> > 
> Well. Here is some more inputs.
> 
> This is connected with the "min" option of stty. When this occurs,
> 'stty -a' says '4' for min. If i change into 'stty min 5' the characters
> come by chunks of 5.
> 
> I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and
> i definitely don't understand where the 4 comes from. In any case, 4 should 
> not be
> the problem, because 'stty min 4' is perfectly legitimate.
> 
> The doc of stty says that 'min' (and 'time') are used in case of '-icanon'.
> However, i found in fhandler_tty.cc that it seems not to be always the case.
> After i applied the following patch:
> 
> diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc 
> cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
> --- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc 
> 2015-03-17 11:42:16.0 +0100
> +++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc  
> 2015-03-24 19:32:42.0 +0100
> @@ -715,7 +715,7 @@
>  
>if (is_nonblocking () || !ptr) /* Indicating tcflush(). */
>  time_to_wait = 0;
> -  else if ((get_ttyp ()->ti.c_lflag & ICANON))
> +  else if (!(get_ttyp ()->ti.c_lflag & ICANON))

No, this is wrong.  You're switching the code for icanon with the
code for -icanon.  -icanon in stty means ICANON is switched off.

I just gave it another try and the behaviour is perfectly valid.

The real problem is that "something" is setting VMIN to 4.  And that's
somehow inside the X server, if I'm not completely wrong:

- If you start an xterm from mintty like this:

xterm -display :0

  and then call `stty -a' in it, you'll see that min is 1, and then
  script will behave as desired.

- However, if you start xterm from the X server tray icon and then
  call `stty -a' in it, min is set to 4 and script will misbehave.
  If you call `stty min 1' before calling script, script will work
  as expected again.

So, why does the X server (or whatever controls starting applications
from the X server tray icon) set VMIN to 4?


Corinna

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


pgp8r2SZejK72.pgp
Description: PGP signature


Re: update trouble 1.7.35

2015-03-24 Thread Steve Johnson
Corinna Vinschen  cygwin.com> writes:

> 
> This "uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)"
> should only happen if you have /etc/nsswitch.conf is set to "files"
> only, and there's no entry in /etc/passwd with a matching SID.
> That's the only way I can reproduce this behaviour.
> 
> Corinna
> 


Hi Corinna,

Where could I get the gpg key to send, as you had suggested earlier? I've tried 
posting replies with the requested information many times, but they all have 
seemed to fail...

Sorry for the added complexity.

Thanks,
Steve Johnson


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



Under /bin/script, characters get printed in four-character chunks

2015-03-24 Thread Denis Excoffier
On 2015-02-28 16:30, Corinna Vinschen wrote:
> 
> On Feb 28 15:19, Denis Excoffier wrote:
>> On 2015-02-28 13:13, Corinna Vinschen wrote:
>>> 
>>> On Feb 28 00:23, Denis Excoffier wrote:
 On 2015-02-27 18:52, Corinna Vinschen wrote:
> 
> I released another TEST version of the next upcoming Cygwin release.
> 
 I have noticed that the behavior of /usr/bin/script is not better than
 previously (probably the change resides near
 https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html).
 
 For at least several weeks, the behavior was ok, except for the
 Return key, which had to be hit several times to take effect. But the
 other characters were ok.
 
 Now (after 2015-02-26), only every fourth character that i type
 is flushed to the command line, Return key included. For example,
 suppose that my command is "abcdefgh": only after i hit the 'd' key
 is "abcd" displayed, and only after i hit the 'h' key the
 "efgh" is displayed (the command line reads "abcdefgh"); now
 i have to hit four times the return key to "enter" the command.
 
 Previously, the fourth-character-delay was probably already there,
 but only for the Return key.
>>> 
>>> I can't reproduce this.  I started script, script starts my shell, and
>>> then I can type and I see every character I type immediately, including
>>> the ENTER key.  I tried with SHELL set to /bin/tcsh as well as with
>>> /bin/bash.
>>> 
>> Oops, forgot to mention: it is under xterm only. Under cmd.exe or under
>> mintty, all is correct.
> 
> Since when do you see this problem?
> 
> I can not reproduce this in mintty, nor in a Cygwin xterm started on a
> remote X server running under Linux.  I can reproduce this with a local
> xterm started via startxwin.  But, and that's the problem, I can
> reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
> last but not least also with a debug version of the Cygwin DLL in which I
> backed out all PTY-related changes since last November.
> 
> I'm not sure this is a giveaway, but from that it seems this problem
> is not directly related to a Cygwin change in the last months.
> 
> So, jturney and I are wondering when exactly you encountered this problem
> for the first time.  Did it coincide with a certain Cygwin release,
> or a certain X server?  Or new X libs, perhaps?
> 
> Anything you can provide to narrow down the potential culprit would be
> helpful.
> 
Well. Here is some more inputs.

This is connected with the "min" option of stty. When this occurs,
'stty -a' says '4' for min. If i change into 'stty min 5' the characters
come by chunks of 5.

I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and
i definitely don't understand where the 4 comes from. In any case, 4 should not 
be
the problem, because 'stty min 4' is perfectly legitimate.

The doc of stty says that 'min' (and 'time') are used in case of '-icanon'.
However, i found in fhandler_tty.cc that it seems not to be always the case.
After i applied the following patch:

diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc 
cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
--- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc   
2015-03-17 11:42:16.0 +0100
+++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
2015-03-24 19:32:42.0 +0100
@@ -715,7 +715,7 @@
 
   if (is_nonblocking () || !ptr) /* Indicating tcflush(). */
 time_to_wait = 0;
-  else if ((get_ttyp ()->ti.c_lflag & ICANON))
+  else if (!(get_ttyp ()->ti.c_lflag & ICANON))
 time_to_wait = INFINITE;
   else
 {


and the problem was gone. Let's try an explanation:
the problem is present since "the beginning", at least
since 2000-02-17, see
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_tty.cc;hb=1fd5e000ace55b323124c7e556a7a864b972a5c4,
and recent (2014-11-13) changes in fhandler_tty.cc made it to appear.

Perhaps i'm also completely wrong.

Hoping this will help,

Regards,

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



Re: update trouble 1.7.35

2015-03-24 Thread Andrey Repin
Greetings, Lemke, Michael  ST/HZA-ZSW!

> I just created new ones.  I like passwd/group much better than AD, sorry.
> Just like real unix before the invention of yellow pages and nis.  This 
> way I can easily give different shells to different users

You can give them in AD the same way. And they will persist through your
system reinstalls and hardware changes.
Having millions of separate file "databases" you have to maintain was never a
good idea, and people were always looking for ways to simplify the management
overhead.

> (not that it is really important at the moment).

> In nsswitch.conf I put 
> passwd: files db
> group: files db

> and ls listings seem to look fine.  Login is also possible again
> with correct tcsh shell.

>>The problem is the domain switch which also changed the SID of your user
>>account.  The old SID, which you also have in your passwd, is not
>>returned by the server anymore.  But it's stored in your SID history in
>>AD and when asking for it you get an answer.

> So, to sort of sum this up: the new cygwin doesn't deal well with 
> contradicting entries in passwd and AD.

It doesn't deal with them at all. It works with what it is given.

> Or something like that.  Maybe you can at least make the login process
> generate an error message.

What kind of error message?

> I just
> realize there is one (which started this whole thread) but if you start 
> cygwin from a minty shortcut (as I do and as it is the default I think) all 
> you get is a flashing window.  I added "-h always" to the mintty options
> to actually see the message.

Weird local setups, like yours, is what was the primary reason to rewrite the
user handling in Cygwin in first place. To have more transparent link to the
underlying system calls.

>>> 
>>> I noticed something else: With nsswitch.conf db:
>>> 
>>> > ls -l
>>> ...
>>> -rw-rwxr--+ 1 lemkemch OLDDOMAIN+Domain Users  10057 Oct 21  2013 
>>> testresults.xml
>>> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users  0 Nov  9  2010 
>>> tidy4aug00
>>> drwxrwxr-x+ 1 lemkemch Domain Users   0 May 14  2014 tinymce
>>> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users  0 Jan 13  2012 
>>> tomahawk-1.1.11
>>> ...
>>> > ls -ln
>>> ...
>>> -rw-rwxr--+ 1 1051305 1073742337  10057 Oct 21  2013 testresults.xml
>>> drwxr-xr-x+ 1 1051305 1073742337  0 Nov  9  2010 tidy4aug00
>>> drwxrwxr-x+ 1 11757881049089  0 May 14  2014 tinymce
>>> drwxr-xr-x+ 1 1051305 1073742337  0 Jan 13  2012 tomahawk-1.1.11
>>> ...
>>> 
>>> Note the different numerical id's that translate to the same username.
>>> Don't know if it means anything.  I just find it weird.
>>
>>That's due to your SID history.  It's a bit hard to explain, but that
>>occurs when "they" switch to a new domain with different SIDs.  When
>>asking for the new and the old SID, the same username is returned since
>>both are your SIDs, one old, one new.
>>
>>I strongly recommend not to use the old SID anymore.  The reason is that
>>Cygwin will create all these files with the old SIDs.  However, your
>>actual user token has the new SID.  Uh, as I wrote, hard to explain and
>>a weird situation.

> Ok, I think I get it.

>>
>>Downside: Cygwin can't handle the old SIDs from your SID history quite
>>correctly.  

> Actually, with "files db" it seems to handle it quite well.  I get the same
> username for both kind of files.  There are still lots of files in my
> home I created before the domain switch.

That's because Cygwin ask system "who is that man with this face(SID)?" and
get the answer, that it is you, because that SID is in your history.
Nothing is changed, really. And nothing should, in this regard.

>>Trying to support them as well would slow down the user and
>>group lookups a lot.  If you can live with what we just found out and
>>the solution I suggested, I'd be rather happy :}
>>

> Yes, I am happy now.

You can get better results, if you define default shell in nsswitch.conf,
rather than hose Cygwin back into 20'st century with your files db.
I assume, you're the only one who's using this system, right?
So, the change wouldn't affect anyone else.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 24.03.2015, <21:37>

Sorry for my terrible english...


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



Re: static vs. shared linking

2015-03-24 Thread David Stacey

On 24/03/2015 00:02, David Stacey wrote:

I've been having difficulty building poco-1.6.0 for Cygwin for some
time. I've managed to produce a test case that shows the problem:

https://dl.dropboxusercontent.com/u/119453582/Cygwin/crashtest.tar.xz

This archive contains source files that produce a very simple library.
When linked statically, the code works fine. However, when linked as a
shared DLL, the test crashes with a core dump. The behaviour is
identical on x86 and x86_64 architectures.

Have I made a stupid error in the compilation of the shared case, or is
something more interesting going on?


I don't know if anyone has managed to look at this. I haven't had a 
deluge of e-mails telling me that I've done something silly (which is a 
shame, because then I could fix it quickly and move on). For the sake of 
a straw to clutch at, I tried compiling with clang++ rather than g++, 
and got the same result:


$ ./go.sh
Running test (static link)...
Done.

Running test (shared link)...
./go.sh: line 19:  3744 Aborted (core dumped) 
./shared_test

Done.

Any help or hints would be greatly appreciated.

Dave.



--
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: update trouble 1.7.35

2015-03-24 Thread Lemke, Michael ST/HZA-ZSW
On Tuesday, March 24, 2015 5:49 PM Corinna Vinschen wrote:
>On Mar 24 16:25, Lemke, Michael  ST/HZA-ZSW wrote:
>> On March 24, 2015 4:50 PM Corinna Vinschen wrote:
>> >On Mar 24 15:19, Lemke, Michael  ST/HZA-ZSW wrote:
>> >> C:\NCygwin\bin>cat ..\etc\nsswitch.conf
>> >> passwd: files
>> >> group: files
>> >> 
>> >> C:\NCygwin\bin>getent passwd %USERNAME%
>> >> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1
>> >> 846952604-2729:/home/lemkemch:/bin/tcsh
>> >
>> >Is that what you have in /etc/passwd?
>> 
>> Oops, thought I also showed passwd:
>> 
>> C:\NCygwin\bin>cat ..\etc\passwd
>> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1846952604-2729:/home/lemkemch:/bin/tcsh
>> 
>> >
>> >> C:\NCygwin\bin>id
>> >> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) 
>> >> groups=545(Users),555
>> >> (Remote Desktop Users)
>> >
>> >what does `mkpasswd -d | grep -i lemkemch' print?
>> 
>> C:\NCygwin\bin>mkpasswd -d | grep -i lemkemch
>> lemkemch:*:1175788:1049089:\lemkemch,S-1-5-21-435809281-806517502-2525237208-127212:/home/lemkemch:/bin/bash
>
>Ouch.  Your user SID from AD is different to the one in /etc/passwd.
>
>> Note that "they" did a domain switch here at some point.  My installation 
>> is really old and the passwd certainly is from before that domain change.
>
>That explains it.  Please recreate your /etc/passwd and /etc/group
>files with mkpasswd and mkgroup, or, even better, just discard them.
>

I just created new ones.  I like passwd/group much better than AD, sorry.  
Just like real unix before the invention of yellow pages and nis.  This 
way I can easily give different shells to different users (not that it is
really important at the moment).

In nsswitch.conf I put 
passwd: files db
group: files db

and ls listings seem to look fine.  Login is also possible again
with correct tcsh shell.

>The problem is the domain switch which also changed the SID of your user
>account.  The old SID, which you also have in your passwd, is not
>returned by the server anymore.  But it's stored in your SID history in
>AD and when asking for it you get an answer.

So, to sort of sum this up: the new cygwin doesn't deal well with 
contradicting entries in passwd and AD.  Or something like that.  Maybe 
you can at least make the login process generate an error message.  I just
realize there is one (which started this whole thread) but if you start 
cygwin from a minty shortcut (as I do and as it is the default I think) all 
you get is a flashing window.  I added "-h always" to the mintty options
to actually see the message.

>> 
>> I noticed something else: With nsswitch.conf db:
>> 
>> > ls -l
>> ...
>> -rw-rwxr--+ 1 lemkemch OLDDOMAIN+Domain Users  10057 Oct 21  2013 
>> testresults.xml
>> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users  0 Nov  9  2010 
>> tidy4aug00
>> drwxrwxr-x+ 1 lemkemch Domain Users   0 May 14  2014 tinymce
>> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users  0 Jan 13  2012 
>> tomahawk-1.1.11
>> ...
>> > ls -ln
>> ...
>> -rw-rwxr--+ 1 1051305 1073742337  10057 Oct 21  2013 testresults.xml
>> drwxr-xr-x+ 1 1051305 1073742337  0 Nov  9  2010 tidy4aug00
>> drwxrwxr-x+ 1 11757881049089  0 May 14  2014 tinymce
>> drwxr-xr-x+ 1 1051305 1073742337  0 Jan 13  2012 tomahawk-1.1.11
>> ...
>> 
>> Note the different numerical id's that translate to the same username.
>> Don't know if it means anything.  I just find it weird.
>
>That's due to your SID history.  It's a bit hard to explain, but that
>occurs when "they" switch to a new domain with different SIDs.  When
>asking for the new and the old SID, the same username is returned since
>both are your SIDs, one old, one new.
>
>I strongly recommend not to use the old SID anymore.  The reason is that
>Cygwin will create all these files with the old SIDs.  However, your
>actual user token has the new SID.  Uh, as I wrote, hard to explain and
>a weird situation.

Ok, I think I get it.

>
>Downside: Cygwin can't handle the old SIDs from your SID history quite
>correctly.  

Actually, with "files db" it seems to handle it quite well.  I get the same
username for both kind of files.  There are still lots of files in my
home I created before the domain switch.

>Trying to support them as well would slow down the user and
>group lookups a lot.  If you can live with what we just found out and
>the solution I suggested, I'd be rather happy :}
>

Yes, I am happy now.


Thanks,
Michael


Re: xterm does not launch from a local shell after upgrade...

2015-03-24 Thread Marco Atzeri



On 3/24/2015 6:03 PM, gary.bar...@datasoft.com wrote:

I had not upgraded in sometime the last setup.exe I had downloaded was
12/18/2014 then most recently 3/18/2015.




After completing the install/upgrades I attempt to restart xwin via
startxwin command. Now I get an instance appearing on my task bar and in
the typical iconized item in the task list, I also now have an active
application showing in the upper left hand corner of my display. When I
attempt to launch xterm, or any other xapplication,  from the Cygwin
command line it responds ‘xterm: Xt error: Can't open display:’ or
associated applications name. If I attempt to launch xterm from a
Windows desktop shortcut ‘C:\cygwin\bin\run.exe -p /usr/X11R6/bin
xterm -display 127.0.0.1:0.0 -ls +ah -aw -rightbar -sb -sl 1000
/bin/bash’ a window flashes on the screen and disappears. I have


change in:
 run -p /usr/bin xterm -display :0.0 -ls +ah -aw -rightbar -sb -sl 1000 
/bin/bash


Currently the Xserver is not using anymore TCP connection
so 127.0.0.1 is causing the "Can't open display"
see "-nolisten tcp' deafult on:

https://www.cygwin.com/ml/cygwin-xfree-announce/2015-02/msg00014.html

/usr/X11R6/bin
  is not used by long time

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



xterm does not launch from a local shell after upgrade...

2015-03-24 Thread gary.barnes
I had not upgraded in sometime the last setup.exe I had downloaded was
12/18/2014 then most recently 3/18/2015.

The purpose of the most recent upgrade was to install Qt libraries and
include files so that my code built on Linux would not show hundreds of
errors and missing definitions when viewing on Windows. However in doing
so several other files were upgraded and I do not know which is the
issue. So here goes…

After completing the install/upgrades I attempt to restart xwin via
startxwin command. Now I get an instance appearing on my task bar and in
the typical iconized item in the task list, I also now have an active
application showing in the upper left hand corner of my display. When I
attempt to launch xterm, or any other xapplication,  from the Cygwin
command line it responds ‘xterm: Xt error: Can't open display:’ or
associated applications name. If I attempt to launch xterm from a
Windows desktop shortcut ‘C:\cygwin\bin\run.exe -p /usr/X11R6/bin
xterm -display 127.0.0.1:0.0 -ls +ah -aw -rightbar -sb -sl 1000
/bin/bash’ a window flashes on the screen and disappears. I have
changed nothing in my Cygwin startups, or methods for starting XServer,
however the only way to open an xterm is through the application in the
upper left corner. Changing the display variable to my ip address,
localhost, or computername does not solve the issue.

Downgrading to 1.17.1.0 from the current version does not help either.
So whatever versions of all the applications that were upgraded from is
unknown to me, and do not know how to downgrade all applications to what
they were on 12/18/2014.

So I am seeing two major changes: XServer that now appears on the
desktop and unable to launch xterm from any place other than the XServer
application.


Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.17.1.0
OS: CYGWIN_NT-6.1-WOW TANGO2 1.7.35(0.287/5/3) 2015-03-04 12:07 i686
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64)
Package: version 1.17.1-1 built 2015-02-13

XWin was started with the following command line:

/usr/bin/XWin :0 -multiwindow -nolisten tcp -auth 
 /home/barnes_g/.serverauth.17268 

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1920 h 1080
winInitializeScreenDefaults - native DPI x 96 y 96
[  7609.151] (II) xorg.conf is not supported
[  7609.151] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for
more information
[  7609.151] LoadPreferences: /home/barnes_g/.XWinrc not found
[  7609.151] LoadPreferences: Loading /etc/X11/system.XWinrc
[  7609.151] LoadPreferences: Done parsing the configuration file...
[  7609.182] winDetectSupportedEngines - DirectDraw4 installed, allowing
ShadowDDNL
[  7609.182] winDetectSupportedEngines - Returning, supported engines
0005
[  7609.198] winSetEngine - Multi Window or Rootless => ShadowGDI
[  7609.198] winScreenInit - Using Windows display depth of 32 bits per
pixel
[  7609.198] winAllocateFBShadowGDI - Creating DIB with width: 3840
height: 1080 depth: 32
[  7609.198] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[  7609.198] winInitVisualsShadowGDI - Masks 00ff ff00 00ff
BPRGB 8 d 24 bpp 32
[  7609.260] MIT-SHM extension disabled due to lack of kernel support
[  7609.260] XFree86-Bigfont extension local-client optimization
disabled due to lack of shared memory support in the kernel
[  7609.260] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[  7609.338] (II) AIGLX: Testing pixelFormatIndex 1
[  7609.369] GL_VERSION: 4.2.11320 Compatibility Profile Context
[  7609.369] GL_VENDOR:  ATI Technologies Inc.
[  7609.369] GL_RENDERER:AMD Radeon HD 7570
[  7609.369] (II) AIGLX: enabled GLX_SGI_make_current_read
[  7609.369] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[  7609.369] (II) AIGLX: enabled GLX_SGI_swap_control and
GLX_MESA_swap_control
[  7609.369] (II) AIGLX: enabled GLX_SGIX_pbuffer
[  7609.369] (II) AIGLX: enabled GLX_ARB_multisample and
GLX_SGIS_multisample
[  7609.369] (II) 107 pixel formats reported by
wglGetPixelFormatAttribivARB
[  7609.369] (II) AIGLX: Set GLX version to 1.4
[  7609.385] (II) 30 fbConfigs
[  7609.385] (II) ignored pixel formats: 0 not OpenGL, 12 RBGA float, 30
RGBA unsigned float, 0 unknown pixel type, 35 unaccelerated
[  7609.385] (II) GLX: Initialized Win32 native WGL GL provider for
screen 0
[  7609.650] winPointerWarpCursor - Discarding first warp: 1920 540
[  7609.650] (--) 8 mouse buttons found
[  7609.650] (--) Setting autorepeat to delay=500, rate=31
[  7609.650] (--) Windows keyboard layout: "0409" (0409) "US",
type 4
[  7609.650] (--) Found matching XKB configuration "English (USA)"
[  7609.650] (--) Model = "pc105" Layout = "us" Variant = "none" Options
= "none"
[  7609.650] Rules = "base" Model = "pc105" Layout = "us" Variant =
"none" Options = "none"
[  7609.650] winInitMultiWindowWM - DISPLAY=:0.0
[  7609.650] winMultiWindowXMsgProc - DISPLAY=:0.0
[  7609.869] winProcEstablishConn

Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 16:25, Lemke, Michael  ST/HZA-ZSW wrote:
> On March 24, 2015 4:50 PM Corinna Vinschen wrote:
> >On Mar 24 15:19, Lemke, Michael  ST/HZA-ZSW wrote:
> >> C:\NCygwin\bin>cat ..\etc\nsswitch.conf
> >> passwd: files
> >> group: files
> >> 
> >> C:\NCygwin\bin>getent passwd %USERNAME%
> >> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1
> >> 846952604-2729:/home/lemkemch:/bin/tcsh
> >
> >Is that what you have in /etc/passwd?
> 
> Oops, thought I also showed passwd:
> 
> C:\NCygwin\bin>cat ..\etc\passwd
> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1846952604-2729:/home/lemkemch:/bin/tcsh
> 
> >
> >> C:\NCygwin\bin>id
> >> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) 
> >> groups=545(Users),555
> >> (Remote Desktop Users)
> >
> >what does `mkpasswd -d | grep -i lemkemch' print?
> 
> C:\NCygwin\bin>mkpasswd -d | grep -i lemkemch
> lemkemch:*:1175788:1049089:\lemkemch,S-1-5-21-435809281-806517502-2525237208-127212:/home/lemkemch:/bin/bash

Ouch.  Your user SID from AD is different to the one in /etc/passwd.

> Note that "they" did a domain switch here at some point.  My installation 
> is really old and the passwd certainly is from before that domain change.

That explains it.  Please recreate your /etc/passwd and /etc/group
files with mkpasswd and mkgroup, or, even better, just discard them.

The problem is the domain switch which also changed the SID of your user
account.  The old SID, which you also have in your passwd, is not
returned by the server anymore.  But it's stored in your SID history in
AD and when asking for it you get an answer.

> >> Anything else you'd like me try?
> >
> >Can you change /etc/nsswitch.conf to "db" only, stop all cygwin
> >processes and restart a shell?  What does `getent passwd %USERNAME%'
> >and `id' print now?  How does an strace of this getent call look like?
> 
> C:\NCygwin\bin>vi ..\etc\nsswitch.conf
> 
> C:\NCygwin\bin>cat ..\etc\nsswitch.conf
> passwd: db
> group: db
> 
> C:\NCygwin\bin>getent passwd %USERNAME%
> lemkemch:*:1175788:1049089:XXX\lemkemch,S-1-5-21-435809281-806517502-25
> 25237208-127212:/home/lemkemch:/bin/bash
> 
> C:\NCygwin\bin>id
> uid=1175788(lemkemch) gid=1049089(Domain Users) groups=1049089(Domain 
> Users),...
> many many groups I don't like to post here.

So it works.  That's cool.  I'd suggest to throw away your passwd and
group files and live happily ever after.

> > I'm grabbing for straws...
> 
> I noticed something else: With nsswitch.conf db:
> 
> > ls -l
> ...
> -rw-rwxr--+ 1 lemkemch OLDDOMAIN+Domain Users  10057 Oct 21  2013 
> testresults.xml
> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users  0 Nov  9  2010 
> tidy4aug00
> drwxrwxr-x+ 1 lemkemch Domain Users   0 May 14  2014 tinymce
> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users  0 Jan 13  2012 
> tomahawk-1.1.11
> ...
> > ls -ln
> ...
> -rw-rwxr--+ 1 1051305 1073742337  10057 Oct 21  2013 testresults.xml
> drwxr-xr-x+ 1 1051305 1073742337  0 Nov  9  2010 tidy4aug00
> drwxrwxr-x+ 1 11757881049089  0 May 14  2014 tinymce
> drwxr-xr-x+ 1 1051305 1073742337  0 Jan 13  2012 tomahawk-1.1.11
> ...
> 
> Note the different numerical id's that translate to the same username.
> Don't know if it means anything.  I just find it weird.

That's due to your SID history.  It's a bit hard to explain, but that
occurs when "they" switch to a new domain with different SIDs.  When
asking for the new and the old SID, the same username is returned since
both are your SIDs, one old, one new.

I strongly recommend not to use the old SID anymore.  The reason is that
Cygwin will create all these files with the old SIDs.  However, your
actual user token has the new SID.  Uh, as I wrote, hard to explain and
a weird situation.

Downside: Cygwin can't handle the old SIDs from your SID history quite
correctly.  Trying to support them as well would slow down the user and
group lookups a lot.  If you can live with what we just found out and
the solution I suggested, I'd be rather happy :}


Thanks,
Corinna

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


pgpYurFlpwpMx.pgp
Description: PGP signature


Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 12:22, Steve Johnson wrote:
> Unfortunately, that is one piece of information that I forgot to mention
> after I had removed stripped out the output of the commands. I get no output
> whatsoever from getent. Here is the output of the commands, when I had run
> them this morning:
> 
> C:\cygwin64\bin>getent passwd %USERNAME%
> 
> C:\cygwin64\bin>id
> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)
> groups=545(Users),544(Admins),4(A1),66049(A2),11(Auth users),15(This
> org),4095(CurrentSession),66048(LOCAL),1056170(A3),1057070(A4),1051115(A5),1
> 051005(A6),1056095(A7),1056192(A8),1051509(A9),1054768(A10),1057114(A11),104
> 9887(A12),1068445(A13),1051461(A14),1057115(A15),1056098(A16),1068744(A17),1
> 050912(A18),1068708(A19),1052088(A20),1053844(A21),1057175(A22),1053843(A23)
> ,1051713(A24),1054212(A25),1057536(A26),1050984(A28),1054460(A29),1057071(A3
> 0),1055832(A31),1055117(A32),1051006(A33),1057060(A34),1068699(A35),1054464(
> A36),1054462(A37),1054195(A38),1053997(A39),1054461(A40),1051464(A41),105172
> 5(A42),1057094(A43),1049914(A44),1050873(A44),1051719(A45),1055144(A46),1051
> 617(A47),1056091(A48),1055831(A49),1051093(A50),1068698(A51),1050648(A52),10
> 51842(A53),1051159(A54),1051187(A55),405504(A56)
> 
> I ran id again, before writing this reply, and only got the following:
> 
> C:\cygwin64\bin>id
> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)

So it create a different output the second time?!?

What does your /etc/nsswitch.conf look like?

If you set /etc/nsswitch.conf to

  passwd: db
  group: db

stop all Cygwin processes, start a shell and call `id' again, what
does it look like?  Can you provide an strace of `id' with this
setting?


Thanks,
Corinna

>   2068281 [main] getent 4532 transport_layer_pipes::connect: Try to
> connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
>538334 [main] getent 4532 transport_layer_pipes::connect: Error
> opening the pipe (2)
>468380 [main] getent 4532 client_request::make_request: cygserver un-
> available
> 10223   18603 [main] getent 4532 internal_getlogin: user not found in passwd
> DB

This looks strange.  When connecting cygserver fails, Cygwin is supposed
to fall back to reading /etc/passwd (if "files" is given) and if that
fails as well, fall back to "db" (if "db" is given).  And the latter
should produce additional output, which just doesn't show up.  I don't
see why, unless your /etc/nsswitch.conf forbids "db".

This "uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)"
should only happen if you have /etc/nsswitch.conf is set to "files"
only, and there's no entry in /etc/passwd with a matching SID.
That's the only way I can reproduce this behaviour.


Corinna

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


pgpTNwKz0uhtp.pgp
Description: PGP signature


RE: update trouble 1.7.35

2015-03-24 Thread Habermann, David (D)
>You don't have a setup per chance that doesn't yet have network connectivity 
>when cygserver starts up?  Firewall >opened only when a user logs in?  VPN 
>needs time to establish connection?  Is cygserver dependent on the tcpip 
>>service?

No (at least not today and recently).  I'm hardwired (Ethernet) in my office 
for the last several days.  No firewall on outbound connections.  No VPN (while 
physically in the office).  Confirmed that the cygserver service has 
dependencies set on "Ancillary Function Driver for Winsock" and "TCP/IP 
Protocol Driver".

Dave


--
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: update trouble 1.7.35

2015-03-24 Thread Lemke, Michael ST/HZA-ZSW
On March 24, 2015 4:50 PM Corinna Vinschen wrote:
>On Mar 24 15:19, Lemke, Michael  ST/HZA-ZSW wrote:
>> On Tuesday, March 24, 2015 3:04 PM Corinna Vinschen wrote:
>> >On Mar 24 13:28, Steve Johnson wrote:
>> >> 
>> >> I am having the same issue, but from a fresh install of cygwin64.
>> >> 
>> >
>> >The problem is this:  I can't reproduce this.  I need a means to
>> >reproduce this to be able to fix it.  I'm totally stumped by this weird
>> >problem because it seems LookupAccountSid fails and I never saw that
>> >before and don't see this on my machines and in my environment.
>> 
>> Ok, let's see what I can come up with.
>
>Thanks, but I'm even more puzzled than before.
>
>> For the test I cut
>> down passwd to just a single line and removed /etc/group - the problem 
>> still occurs.  From a cmd window:
>> 
>> C:\NCygwin\bin>cat ..\etc\nsswitch.conf
>> passwd: files
>> group: files
>> 
>> C:\NCygwin\bin>getent passwd %USERNAME%
>> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1
>> 846952604-2729:/home/lemkemch:/bin/tcsh
>
>Is that what you have in /etc/passwd?

Oops, thought I also showed passwd:

C:\NCygwin\bin>cat ..\etc\passwd
lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1846952604-2729:/home/lemkemch:/bin/tcsh

>
>> C:\NCygwin\bin>id
>> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) 
>> groups=545(Users),555
>> (Remote Desktop Users)
>
>what does `mkpasswd -d | grep -i lemkemch' print?

C:\NCygwin\bin>mkpasswd -d | grep -i lemkemch
lemkemch:*:1175788:1049089:\lemkemch,S-1-5-21-435809281-806517502-2525237208-127212:/home/lemkemch:/bin/bash

Note that "they" did a domain switch here at some point.  My installation 
is really old and the passwd certainly is from before that domain change.

>The unknown user is
>totally weird.  It should only occur if your SID doesn't show up in your
>/etc/passwd file.  Also, if /etc/nsswitch.conf is "files" only, and
>you don't have a group file, there should be only one group in your `id'
>output, the primary group 10513.  
>Here's how it looks like for me:
>
>  $ getent passwd corinna
>  
> corinna:unused:11001:11125:U-VINSCHEN\corinna,S-1-5-21-2913048732-1697188782-3448811101-1001:/home/corinna:/bin/tcsh
>  $ id
>  uid=11001(corinna) gid=11125 groups=11125
>
>Did you stop all cygwin processes after doing all the settings,
>including any service?

yep.

>
>> strace output (hopefully) attached.
>> 
>> Anything else you'd like me try?
>
>Can you change /etc/nsswitch.conf to "db" only, stop all cygwin
>processes and restart a shell?  What does `getent passwd %USERNAME%'
>and `id' print now?  How does an strace of this getent call look like?

C:\NCygwin\bin>vi ..\etc\nsswitch.conf

C:\NCygwin\bin>cat ..\etc\nsswitch.conf
passwd: db
group: db

C:\NCygwin\bin>getent passwd %USERNAME%
lemkemch:*:1175788:1049089:XXX\lemkemch,S-1-5-21-435809281-806517502-25
25237208-127212:/home/lemkemch:/bin/bash

C:\NCygwin\bin>id
uid=1175788(lemkemch) gid=1049089(Domain Users) groups=1049089(Domain Users),...
many many groups I don't like to post here.

> I'm grabbing for straws...

I noticed something else: With nsswitch.conf db:

> ls -l
...
-rw-rwxr--+ 1 lemkemch OLDDOMAIN+Domain Users  10057 Oct 21  2013 
testresults.xml
drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users  0 Nov  9  2010 tidy4aug00
drwxrwxr-x+ 1 lemkemch Domain Users   0 May 14  2014 tinymce
drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users  0 Jan 13  2012 
tomahawk-1.1.11
...
> ls -ln
...
-rw-rwxr--+ 1 1051305 1073742337  10057 Oct 21  2013 testresults.xml
drwxr-xr-x+ 1 1051305 1073742337  0 Nov  9  2010 tidy4aug00
drwxrwxr-x+ 1 11757881049089  0 May 14  2014 tinymce
drwxr-xr-x+ 1 1051305 1073742337  0 Jan 13  2012 tomahawk-1.1.11
...

Note the different numerical id's that translate to the same username.
Don't know if it means anything.  I just find it weird.

Michael


Re: update trouble 1.7.35

2015-03-24 Thread Steve Johnson
Unfortunately, that is one piece of information that I forgot to mention
after I had removed stripped out the output of the commands. I get no output
whatsoever from getent. Here is the output of the commands, when I had run
them this morning:

C:\cygwin64\bin>getent passwd %USERNAME%

C:\cygwin64\bin>id
uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)
groups=545(Users),544(Admins),4(A1),66049(A2),11(Auth users),15(This
org),4095(CurrentSession),66048(LOCAL),1056170(A3),1057070(A4),1051115(A5),1
051005(A6),1056095(A7),1056192(A8),1051509(A9),1054768(A10),1057114(A11),104
9887(A12),1068445(A13),1051461(A14),1057115(A15),1056098(A16),1068744(A17),1
050912(A18),1068708(A19),1052088(A20),1053844(A21),1057175(A22),1053843(A23)
,1051713(A24),1054212(A25),1057536(A26),1050984(A28),1054460(A29),1057071(A3
0),1055832(A31),1055117(A32),1051006(A33),1057060(A34),1068699(A35),1054464(
A36),1054462(A37),1054195(A38),1053997(A39),1054461(A40),1051464(A41),105172
5(A42),1057094(A43),1049914(A44),1050873(A44),1051719(A45),1055144(A46),1051
617(A47),1056091(A48),1055831(A49),1051093(A50),1068698(A51),1050648(A52),10
51842(A53),1051159(A54),1051187(A55),405504(A56)

I ran id again, before writing this reply, and only got the following:

C:\cygwin64\bin>id
uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)


Below is the output from strace of getent command:
2   2 [main] getent (4532)
**
  182 184 [main] getent (4532) Program name: C:\cygwin64\bin\getent.exe
(windows pid 4532)
   57 241 [main] getent (4532) OS version:   Windows NT-6.1
   28 269 [main] getent (4532)
**
  163 432 [main] getent (4532) sigprocmask: 0 = sigprocmask (0, 0x0,
0x1802D1CA8)
  395 827 [main] getent 4532 open_shared: name shared.5, n 5, shared
0x18003 (wanted 0x18003), h 0x60, *m 6
   55 882 [main] getent 4532 user_heap_info::init: heap base
0x6, heap top 0x6, heap size 0x2000 (536870912)
  112 994 [main] getent 4532 open_shared: name S-1-5-21-1155469006-
580272788-1541874228-59418.1, n 1, shared 0x18002 (wanted 0x18002),
h 0x5C, *m 6
   581052 [main] getent 4532 user_info::create: opening user shared for
'S-1-5-21-1155469006-580272788-1541874228-59418' at 0x18002
   871139 [main] getent 4532 user_info::create: user shared version
AB1FCCE8
  1141253 [main] getent 4532 fhandler_pipe::create: name
\\.\pipe\cygwin-e022582115c10879-4532-sigwait, size 11440, mode
PIPE_TYPE_MESSAGE
   841337 [main] getent 4532 fhandler_pipe::create: pipe read handle
0x78
   301367 [main] getent 4532 fhandler_pipe::create: CreateFile: name
\\.\pipe\cygwin-e022582115c10879-4532-sigwait
   551422 [main] getent 4532 fhandler_pipe::create: pipe write handle
0x7C
   821504 [main] getent 4532 dll_crt0_0: finished dll_crt0_0
initialization
 12872791 [sig] getent 4532 wait_sig: entering ReadFile loop, my_readsig
0x78, my_sendsig 0x7C
  2753066 [main] getent 4532 time: 1427207219 = time(0x0)
  1043170 [main] getent 4532 mount_info::conv_to_posix_path:
conv_to_posix_path (C:\cygwin64\bin, no-keep-rel, no-add-slash)
   483218 [main] getent 4532 normalize_win32_path: C:\cygwin64\bin =
normalize_win32_path (C:\cygwin64\bin)
   333251 [main] getent 4532 mount_info::conv_to_posix_path: /usr/bin =
conv_to_posix_path (C:\cygwin64\bin)
   543305 [main] getent 4532 sigprocmask: 0 = sigprocmask (0, 0x0,
0x600018128)
  2113516 [main] getent 4532 _cygwin_istext_for_stdio: fd 0: not open
   393555 [main] getent 4532 _cygwin_istext_for_stdio: fd 1: not open
   253580 [main] getent 4532 _cygwin_istext_for_stdio: fd 2: not open
   943674 [main] getent (4532) open_shared: name cygpid.4532, n 4532,
shared 0x18001 (wanted 0x18001), h 0xB8, *m 2
   363710 [main] ? (4532) time: 1427207219 = time(0x0)
   283738 [main] getent 4532 pinfo::thisproc: myself dwProcessId 4532
  1103848 [main] getent 4532 environ_init: GetEnvironmentStrings
returned 0x408020
   773925 [main] getent 4532 environ_init: 0x6000284F0:
!C:=C:\cygwin64\bin
   523977 [main] getent 4532 environ_init: 0x600028510:
!ExitCode=0002
   724049 [main] getent 4532 environ_init: 0x600028530:
ALLUSERSPROFILE=C:\ProgramData
   594108 [main] getent 4532 environ_init: 0x600028560:
APPDATA=C:\Users\johndoe\AppData\Roaming
   654173 [main] getent 4532 environ_init: 0x600028590:
CLASSPATH=.;C:\Program Files (x86)\Java\jre1.8.0_31\lib\ext\QTJava.zip
   454218 [main] getent 4532 environ_init: 0x6000285E0:
COMMONPROGRAMFILES=C:\Program Files\Common Files
   424260 [main] getent 4532 environ_init: 0x600028620:
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
   424302 [main] getent 4532 environ_init: 0x600028670:
CommonProgramW6432=C:\Program Files\Common Files
   534355 [main] getent 4532 environ_init: 0x6000286B0:
COMPUTERNAME=LAPTOPA
   55 

Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 15:19, Lemke, Michael  ST/HZA-ZSW wrote:
> On Tuesday, March 24, 2015 3:04 PM Corinna Vinschen wrote:
> >On Mar 24 13:28, Steve Johnson wrote:
> >> 
> >> I am having the same issue, but from a fresh install of cygwin64.
> >> 
> >
> >The problem is this:  I can't reproduce this.  I need a means to
> >reproduce this to be able to fix it.  I'm totally stumped by this weird
> >problem because it seems LookupAccountSid fails and I never saw that
> >before and don't see this on my machines and in my environment.
> 
> Ok, let's see what I can come up with.

Thanks, but I'm even more puzzled than before.

> For the test I cut
> down passwd to just a single line and removed /etc/group - the problem 
> still occurs.  From a cmd window:
> 
> C:\NCygwin\bin>cat ..\etc\nsswitch.conf
> passwd: files
> group: files
> 
> C:\NCygwin\bin>getent passwd %USERNAME%
> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1
> 846952604-2729:/home/lemkemch:/bin/tcsh

Is that what you have in /etc/passwd?

> C:\NCygwin\bin>id
> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) 
> groups=545(Users),555
> (Remote Desktop Users)

what does `mkpasswd -d | grep -i lemkemch' print?  The unknown user is
totally weird.  It should only occur if your SID doesn't show up in your
/etc/passwd file.  Also, if /etc/nsswitch.conf is "files" only, and
you don't have a group file, there should be only one group in your `id'
output, the primary group 10513.  Here's how it looks like for me:

  $ getent passwd corinna
  
corinna:unused:11001:11125:U-VINSCHEN\corinna,S-1-5-21-2913048732-1697188782-3448811101-1001:/home/corinna:/bin/tcsh
  $ id
  uid=11001(corinna) gid=11125 groups=11125

Did you stop all cygwin processes after doing all the settings,
including any service?

> strace output (hopefully) attached.
> 
> Anything else you'd like me try?

Can you change /etc/nsswitch.conf to "db" only, stop all cygwin
processes and restart a shell?  What does `getent passwd %USERNAME%'
and `id' print now?  How does an strace of this getent call look like?

I'm grabbing for straws...


Thanks,
Corinna

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


pgpyqs3pDMo52.pgp
Description: PGP signature


RE: update trouble 1.7.35

2015-03-24 Thread Lemke, Michael ST/HZA-ZSW
On Tuesday, March 24, 2015 3:04 PM Corinna Vinschen wrote:
>On Mar 24 13:28, Steve Johnson wrote:
>> 
>> I am having the same issue, but from a fresh install of cygwin64.
>> 
>
>The problem is this:  I can't reproduce this.  I need a means to
>reproduce this to be able to fix it.  I'm totally stumped by this weird
>problem because it seems LookupAccountSid fails and I never saw that
>before and don't see this on my machines and in my environment.

Ok, let's see what I can come up with.  For the test I cut
down passwd to just a single line and removed /etc/group - the problem 
still occurs.  From a cmd window:

C:\NCygwin\bin>cat ..\etc\nsswitch.conf
passwd: files
group: files

C:\NCygwin\bin>getent passwd %USERNAME%
lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1
846952604-2729:/home/lemkemch:/bin/tcsh

C:\NCygwin\bin>id
uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) groups=545(Users),555
(Remote Desktop Users)


strace output (hopefully) attached.

Anything else you'd like me try?

Michael
1   1 [main] getent (9260) 
**
  143 144 [main] getent (9260) Program name: C:\NCygwin\bin\getent.exe 
(windows pid 9260)
   46 190 [main] getent (9260) OS version:   Windows NT-6.1
   77 267 [main] getent (9260) 
**
  119 386 [main] getent (9260) sigprocmask: 0 = sigprocmask (0, 0x0, 
0x61293748)
  323 709 [main] getent 9260 open_shared: name shared.5, n 5, shared 
0x60FF (wanted 0x60FF), h 0x74, *m 6
   64 773 [main] getent 9260 user_heap_info::init: heap base 0x8000, 
heap top 0x8000, heap size 0x1800 (402653184)
  103 876 [main] getent 9260 open_shared: name 
S-1-5-21-435809281-806517502-2525237208-127212.1, n 1, shared 0x60FE 
(wanted 0x60FE), h 0x70, *m 6
   42 918 [main] getent 9260 user_info::create: opening user shared for 
'S-1-5-21-435809281-806517502-2525237208-127212' at 0x60FE
   22 940 [main] getent 9260 user_info::create: user shared version AB1FCCE8
   38 978 [main] getent 9260 fhandler_pipe::create: name 
\\.\pipe\cygwin-c0a8879476f177eb-9260-sigwait, size 5412, mode PIPE_TYPE_MESSAGE
   481026 [main] getent 9260 fhandler_pipe::create: pipe read handle 0x88
   191045 [main] getent 9260 fhandler_pipe::create: CreateFile: name 
\\.\pipe\cygwin-c0a8879476f177eb-9260-sigwait
   361081 [main] getent 9260 fhandler_pipe::create: pipe write handle 0x90
   231104 [main] getent 9260 dll_crt0_0: finished dll_crt0_0 initialization
  9112015 [sig] getent 9260 wait_sig: entering ReadFile loop, my_readsig 
0x88, my_sendsig 0x90
   742089 [main] getent 9260 time: 1427208969 = time(0x0)
   612150 [main] getent 9260 mount_info::conv_to_posix_path: 
conv_to_posix_path (C:\NCygwin\bin, no-keep-rel, no-add-slash)
   322182 [main] getent 9260 normalize_win32_path: C:\NCygwin\bin = 
normalize_win32_path (C:\NCygwin\bin)
   232205 [main] getent 9260 mount_info::conv_to_posix_path: /usr/bin = 
conv_to_posix_path (C:\NCygwin\bin)
   362241 [main] getent 9260 sigprocmask: 0 = sigprocmask (0, 0x0, 
0x800180A8)
  1772418 [main] getent 9260 _cygwin_istext_for_stdio: fd 0: not open
   332451 [main] getent 9260 _cygwin_istext_for_stdio: fd 1: not open
   322483 [main] getent 9260 _cygwin_istext_for_stdio: fd 2: not open
  1042587 [main] getent (9260) open_shared: name cygpid.9260, n 9260, 
shared 0x60FD (wanted 0x60FD), h 0xD0, *m 2
   252612 [main] ? (9260) time: 1427208969 = time(0x0)
   212633 [main] getent 9260 pinfo::thisproc: myself dwProcessId 9260
   632696 [main] getent 9260 environ_init: GetEnvironmentStrings returned 
0x756E08
   342730 [main] getent 9260 environ_init: 0x80028290: !::=::\
   322762 [main] getent 9260 environ_init: 0x800282A0: !C:=C:\NCygwin\bin
   302792 [main] getent 9260 environ_init: 0x800282C0: !ExitCode=
   312823 [main] getent 9260 environ_init: 0x800282D8: 
ALLUSERSPROFILE=C:\ProgramData
   312854 [main] getent 9260 environ_init: 0x80028300: 
APPDATA=C:\Users\lemkemch\AppData\Roaming
   342888 [main] getent 9260 environ_init: 0x80028330: 
COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files
   332921 [main] getent 9260 environ_init: 0x80028370: 
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
   322953 [main] getent 9260 environ_init: 0x800283B8: 
CommonProgramW6432=C:\Program Files\Common Files
   312984 [main] getent 9260 environ_init: 0x800283F0: 
COMPUTERNAME=P01104393
   323016 [main] getent 9260 environ_init: 0x80028410: 
COMSPEC=C:\Windows\system32\cmd.exe
   333049 [main] getent 9260 parse_options: glob (called func)
   313080 [main] getent 9260 parse_options: returning
   163096 [main] getent 9260 environ_init: 0x80028440: CYGWIN=noglob
   313127 [main] getent 9260 environ_init: 0x80028468: 
DEFLOGDIR=C:\ProgramData\McAfee\Desktop

Hit fork/rebase issue with new updated gcc 4.9.2-3

2015-03-24 Thread dum fk
I got this error after a recent update which pulled in gcc 4.9.2-3:

C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
Similar issue was reported in Dec 2013 such as:
https://cygwin.com/ml/cygwin/2013-12/msg00083.html

After revert to 4.9.2-2 the problem goes away. So I think this is a regression.

Thanks,

Dumm FK

--
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: update trouble 1.7.35

2015-03-24 Thread Achim Gratz
Habermann, David (D  dow.com> writes:
> I am able to produce the failure again (by reverting to
> cygserver starting immediately as a service upon
> bootup).

You don't have a setup per chance that doesn't yet have network connectivity
when cygserver starts up?  Firewall opened only when a user logs in?  VPN
needs time to establish connection?  Is cygserver dependent on the tcpip
service?


Regards,
Achim.



--
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: TIOCPKT mode of PTY is broken if ONLCR bit is cleared.

2015-03-24 Thread Corinna Vinschen
Hi Takashi,

On Mar 23 11:08, Corinna Vinschen wrote:
> On Mar 21 10:40, Takashi Yano wrote:
> > Hi Corinna,
> > 
> > On Fri, 20 Mar 2015 20:12:32 +0100
> > Corinna Vinschen  wrote:
> > 
> > > > For the time being, can you send your assignment as PDF via email
> > > > to my company email address  just so
> > > > we make sure it arrived in *some* way?
> > > 
> > > Even better.  We got legal approval that we can use signed PDFs via
> > > email alone, and that sending snail mail isn't required anymore.
> > > Just sendthe PDF to .
> > 
> > Thank you very much for your effort for approving
> > PDF copyright assignment.
> > 
> > I have just sent it via e-mail.
> 
> And it's all set, finally.  Thanks a lot for not giving up on us :)

Btw., it's not important anymore, but your snail mail arrived finally
at the office, after a mere 18 days on travel.  Three cheers for the
postal services!


Corinna

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


pgpSBxGoDuuiZ.pgp
Description: PGP signature


RE: update trouble 1.7.35

2015-03-24 Thread Habermann, David (D)
> What account is cygserver as service running under?  Your own, or something 
> like LocalSystem, or 
> NetworkService?

In my case it is running under SYSTEM.



Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 15:20, Corinna Vinschen wrote:
> On Mar 24 14:00, Habermann, David (D) wrote:
> > 
> > > - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two
> > > commands, and paste the output into your reply:
> > 
> > >getent passwd %USERNAME%
> > >id
> > 
> > I am able to produce the failure again (by reverting to cygserver
> > starting immediately as a service upon bootup).
> 
> What account is cygserver as service running under?  Your own, or
> something like LocalSystem, or NetworkService?

I tried both with no visible effect.  It just works for me.  Sigh.


Corinna

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


pgpjt377UxW1t.pgp
Description: PGP signature


Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 14:00, Habermann, David (D) wrote:
> 
> > - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two
> > commands, and paste the output into your reply:
> 
> >getent passwd %USERNAME%
> >id
> 
> I am able to produce the failure again (by reverting to cygserver
> starting immediately as a service upon bootup).

What account is cygserver as service running under?  Your own, or
something like LocalSystem, or NetworkService?


Thanks,
Corinna

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


pgpqKhJ_PEFLk.pgp
Description: PGP signature


Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 15:05, Corinna Vinschen wrote:
> On Mar 24 14:00, Habermann, David (D) wrote:
> > 
> > > - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two
> > > commands, and paste the output into your reply:
> > 
> > >getent passwd %USERNAME%
> > >id
> > 
> > I am able to produce the failure again (by reverting to cygserver
> > starting immediately as a service upon bootup).  I would be happy to
> > provide the information above to a particular person or persons, but
> > I'd rather not post it to the internet.  If you want it, please let me
> > know where to send it.  If you don't want you email posted, please
> > free to send directly to 
> > h a b e r m a n n atsymbal dow periadcharacter com
> 
> Guys, please.  Just redact the output.  Names are irrelevant, just
> call them X1, X2, D1, D2, etc.

Oh well, ok.  If all else fails, send the stuff via gpg-encrypted mail
using my public gpg key to my company address vinschen AT redhat DOT
com.  But only if you promise to send an strace of the getent call as
well!


Thanks,
Corinna

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


pgpF3g05X_YZP.pgp
Description: PGP signature


Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 14:00, Habermann, David (D) wrote:
> 
> > - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two
> > commands, and paste the output into your reply:
> 
> >getent passwd %USERNAME%
> >id
> 
> I am able to produce the failure again (by reverting to cygserver
> starting immediately as a service upon bootup).  I would be happy to
> provide the information above to a particular person or persons, but
> I'd rather not post it to the internet.  If you want it, please let me
> know where to send it.  If you don't want you email posted, please
> free to send directly to 
> h a b e r m a n n atsymbal dow periadcharacter com

Guys, please.  Just redact the output.  Names are irrelevant, just
call them X1, X2, D1, D2, etc.


Thanks,
Corinna

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


pgpqxnBHVDf5_.pgp
Description: PGP signature


Re: update trouble 1.7.35

2015-03-24 Thread Corinna Vinschen
On Mar 24 13:28, Steve Johnson wrote:
> Hi Corinna,
> 
> I am having the same issue, but from a fresh install of cygwin64.
> 
> I also tried you recommendation, but it did not work. I tried with
> just files instead of db as well, with the same results. There are no
> passwd or group files in the etc folder, so I don't know if this is
> any relevant information either.

The problem is this:  I can't reproduce this.  I need a means to
reproduce this to be able to fix it.  I'm totally stumped by this weird
problem because it seems LookupAccountSid fails and I never saw that
before and don't see this on my machines and in my environment.

I don't know anything about your environment, for instance.  I don't
know what you mean when you say "I tried with just files instead",
because you didn't say if you also created /etc/passwd and /etc/group
files and then stopped all Cygwin processes and opened the shell again.
Or, FWIW, when you changed nsswitch.conf to "db" only, if you stopped
the processes and started them again, which would be important, per the
documentation.

Details.  I need details.  Or ideally somebody with the problem
willing to debug the stuff.

For a start, the output of cygcheck -svr as outlined in
https://cygwin.com/problems.html would be helpful.  As well as the
output of getent and id as outlined in my other mail.  And ideally
the strace output generated by

  strace -o getent.trace getent passwd $USERNAME

> I would rather not post the results of the 'id' command publicly, so if 
> possible, I would gladly provide them if you contact me directly or give me 
> another mean to provide them.

I don't care for the company name.  I don't care for the actual group
names.  Just redact the output and call the (non-well-known) groups X1,
X2, etc, and the domain names D1, D2, etc.  The posix offset, the gid's
and well-known group names (like Users, Domain Admins, etc) don't contain
any confidential information so you can simply leave them as is.


Thanks,
Corinna

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


pgpy1m_7Ml7cx.pgp
Description: PGP signature


RE: update trouble 1.7.35

2015-03-24 Thread Habermann, David (D)

> - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two
> commands, and paste the output into your reply:

>getent passwd %USERNAME%
>id

I am able to produce the failure again (by reverting to cygserver starting 
immediately as a service upon bootup).  I would be happy to provide the 
information above to a particular person or persons, but I'd rather not post it 
to the internet.  If you want it, please let me know where to send it.  If you 
don't want you email posted, please free to send directly to 
h a b e r m a n n atsymbal dow periadcharacter com




Re: update trouble 1.7.35

2015-03-24 Thread Steve Johnson
Hi Corinna,

I am having the same issue, but from a fresh install of cygwin64.

I also tried you recommendation, but it did not work. I tried with
just files instead of db as well, with the same results. There are no
passwd or group files in the etc folder, so I don't know if this is
any relevant information either.

I would rather not post the results of the 'id' command publicly, so if 
possible, I would gladly provide them if you contact me directly or give me 
another mean to provide them.

Thanks,
Steve Johnson




--
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: X11Forward and xauth problems

2015-03-24 Thread Jon TURNEY

On 23/03/2015 21:27, Andrew DeFaria wrote:

On 3/23/2015 2:06 PM, Jon TURNEY wrote:

On 23/03/2015 20:48, Andrew DeFaria wrote:

Normally I just turn on -X (or put X11Forward yes in ~/.ssh/config) but
that usually results in a noticeable delay in logging in and the
following error:

Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11
forwarding.


Firstly, if you don't want these warnings, use ssh -Y.

(By using ssh -X, you are asking for something which the X server can't
give you, hence the warnings.  See
http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trusted-untrusted-x11-forwarding

for more details)


Yeah but -Y gives me the same thing:


This is similar, but it is not the same.


Adefaria-lt:ssh -Y cm-app-ldev01
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Cm-app-ldev01:


I think this last message here is unusual, and is coming from xauth 
running on the remote server.  Can you you give a few more details on 
what OS that is running?


If you connect using ssh -vv -Y, you should be able to see the xauth 
commands that sshd is running, and if those, or some other step in the 
connection, is the cause of the delay.


You might also try running those xauth commands in the terminal to 
investigate further.



Adefaria-lt:xhost +
access control disabled, clients can connect from any host
Adefaria-lt:ssh cm-app-ldev01
Cm-app-ldev01:export DISPLAY=adefaria-lt:0
Cm-app-ldev01:xclock
Error: Can't open display: adefaria-lt:0
Cm-app-ldev01:


If you want this to work, you will now (since X server 1.17) need to
start the server with the option '-listen tcp'.


Restarted Xwin with -multimonitor and -listen tcp. Now I get:


Sorry for any ambiguity, but you have misunderstood what I wrote.

If you want explicitly setting DISPLAY and allowing access using xhost 
to work, you must start the server with the option '-listen tcp'.


--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

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



Re: mkpasswd: option to force the 'primary' domain?

2015-03-24 Thread Tim Magee



On 20/03/15 18:10, Corinna Vinschen wrote:

On Mar 20 11:58, Tim Magee wrote:

Now then,

Since Cygwin 1.7.34 dropped, mkpasswd has been problematic for us.  Our
problem is with the way user names pulled from outside the primary domain
get decorated.  My question is: will there ever be a way to tell
mkpasswd/mkgroup "make  the one whose users get
undecorated names"?

We have Windows machines in one AD domain, and all our users in a different
AD domain.  According to the 'POSIX accounts, permissions and security'
page, the machine's domain is considered the primary one. "mkpasswd -d" will
generate undecorated names for that domain, and decorated names for any
other named domain.

We use SSH-based tools a great deal here, and we use Cygwin to make our
Windows machines behave like members of our POSIX machine community, so
having our usernames appear the same on all machines is very desirable.

I think I can recreate the pre-1.74 behaviour with a little seddery, but I'd
bet folding money that my seddery isn't future-proof.  So, are
mkpasswd/mkgroup ever likely to get an option to force the "undecorated
users" domain?


I'm not planning this.  The idea is that mkpasswd/mkgroup create account
names compatible with the "db"-based accounts and everyhing else is left
to post-creation manipulation.

Having said that, the new account handling is supposed to be stable on
the user level for quite some time, ideally at least as many years as
the old /etc/passwd&/etc/group-only based code.  Therefore using some
sed script to filter the output of mkpasswd/mkgroup if you dislike the
new account handling is the way to go.


Corinna


Thanks, I feel more confident of my seddery already!

In case anyone else with a similar setup reads this thread: using sed to 
trim off the domain decoration for the chosen domain is WFMing like a 
champ, but you'll want to make sure you're not creating name clashes. 
It's safe for us because we only have users we care about in one domain.


Tim


--
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: Altered behaviour of grep

2015-03-24 Thread Corinna Vinschen
On Mar 24 08:07, Fergus Daly wrote:
> grep -Pl "\xmn"
> used to find files containing the ASCII character mn. For instance
> grep -PL "\x0d" or "\x0a" or usefully "\x00".
> This seems to have been lost with the current version.
> Is this an error? If not, can anybody tell me what new syntax will recover 
> the old behaviour?

I just tested this on Cygwin and Fedora 21, both with grep 2.21:

  $ cat x.sh
  #!/bin/sh
  echo ${0##*/}
  $ grep -Pl '\x30' x.sh
  x.sh
  $ grep -Pl '\x0a' x.sh
  $ 

Same result on both systems, so it finds characters in lines, but not
the line separator itself.  If that worked before, this looks like an
upstream change to me.

A bit of digging shows this thread on the bug-grep mailing list:
http://lists.gnu.org/archive/html/bug-grep/2015-03/msg00015.html

And indeed, if I add a NUL byte to the file and search for it:

 $ grep -Pl '\x0' x.sh
 $ grep -aPl '\x0' x.sh
 x.sh

This does not work for the CR or LF, though.  You may want to discuss
this on the bug-grep ML.


Corinna

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


pgpMy_vdTWdjZ.pgp
Description: PGP signature


RE: Altered behaviour of grep

2015-03-24 Thread Fergus Daly
grep -Pl "\xmn"
used to find files containing the ASCII character mn. For instance
grep -PL "\x0d" or "\x0a" or usefully "\x00".
   ^
I did mean grep -Pl in both cases.
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



Altered behaviour of grep

2015-03-24 Thread Fergus Daly
grep -Pl "\xmn"
used to find files containing the ASCII character mn. For instance
grep -PL "\x0d" or "\x0a" or usefully "\x00".
This seems to have been lost with the current version.
Is this an error? If not, can anybody tell me what new syntax will recover the 
old behaviour?
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