Re: gnuplot caca terminal work on Cygwin-x86 but not Cygwin-x86_64

[Corinna Vinschen]

On May 13 08:54, Tatsuro MATSUOKA wrote:
> --- On Mon, 2014/5/12, Corinna Vinschen  wrote:
> > First, are you shure this is running under the snapshot?  what does
> > `uname -a' print when called right before the below gdb call?
> 
> I have mis-operated. I have copied snapshot cywin1.dll to Cygwin_x86 but not 
> Cygwin_x86_64.  I corrected makatake and found :
> 
> $ gdb src/gnuplot
> [...]
> 
> G N U P L O T
> Version 5.0 patchlevel alphalast modified 2014-05-11
> 
> Copyright (C) 1986-1993, 1998, 2004, 2007-2014
> Thomas Williams, Colin Kelley and many others
> 
> gnuplot home: http://www.gnuplot.info
> mailing list: gnuplot-b...@lists.sourceforge.net
> faq, bugs, etc:   type "help FAQ"
> immediate help:   type "help"  (plot window: hit 'h')
> 
> Terminal type set to 'qt'
> gnuplot> plot sin(x)
> [New Thread 5892.0xba4]
> [New Thread 5892.0x41c]
> [New Thread 5892.0x142c]
> [New Thread 5892.0x10ec]
> [Thread 5892.0x10ec exited with code 0]
> [New Thread 5892.0xae0]
> [New Thread 5892.0x1a68]
> [New Thread 5892.0x1bf0]
> Could not connect to gnuplot_qt "qtgnuplot3112" . Starting a new one
> 
> Warning: slow font initializationgnuplot> Quit
> (gdb) Undefined command: "rq".  Try "help".
> (gdb) Undefined command: "q2".  Try "help".
> (gdb) A debugging session is active.
> 
> 
> Segmentation fault is no longer happned.
> The behavior similar to that happened at Cygwin_x86.
> 
> Anyway thanks your advise.

Ok, so we know now that the crash was spurious and fixed in the
snapshots.  That's good to know.  I can't help you with the other
problems, unfortunately.


Corinna

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


pgpjSlX6KfRAd.pgp
Description: PGP signature

[BUG] /bin/sh crashes with the recent cygwin1.dll on x86/64

[Pavel Fedin]

 Hello! I have updated my Cygwin installation and it is completely unusable.
 First, shell scripts stopped working. I have traced this down to /bin/sh
executable apparently doing nothing. Running under strace gives this:
---cut ---
$ strace /bin/sh --version
1   1 [main] sh (6756)
**
   86  87 [main] sh (6756) Program name: C:\cygwin64\bin\sh.exe (windows
pid 6756)
   30 117 [main] sh (6756) OS version:   Windows NT-6.1
   27 144 [main] sh (6756)
**
  101 245 [main] sh (6756) sigprocmask: 0 = sigprocmask (0, 0x1802BBC68,
0x0)
  438 683 [main] sh 6756 open_shared: name shared.5, n 5, shared
0x18003 (wanted 0x18003), h 0x70, *m 6
   51 734 [main] sh 6756 user_heap_info::init: heap base 0x6,
heap top 0x6, heap size 0x2000 (536870912)
   56 790 [main] sh 6756 open_shared: name
S-1-5-21-1454471165-515967899-839522115-3227.1, n 1, shared 0x18002
(wanted 0x18002), h 0x68, *m 6
   58 848 [main] sh 6756 user_info::create: opening user shared for
'S-1-5-21-1454471165-515967899-839522115-3227' at 0x18002
   36 884 [main] sh 6756 user_info::create: user shared version AB1FCCE8
   61 945 [main] sh 6756 fhandler_pipe::create: name
\\.\pipe\cygwin-e022582115c10879-6756-sigwait, size 176, mode
PIPE_TYPE_MESSAGE
   821027 [main] sh 6756 fhandler_pipe::create: pipe read handle 0x84
   191046 [main] sh 6756 fhandler_pipe::create: CreateFile: name
\\.\pipe\cygwin-e022582115c10879-6756-sigwait
   471093 [main] sh 6756 fhandler_pipe::create: pipe write handle 0x88
   331126 [main] sh 6756 dll_crt0_0: finished dll_crt0_0 initialization
--- Process 6756, exception c005 at 7780E4E4
49743   50869 [main] sh 6756 __set_errno: void san::leave():315 setting
errno 66168
--- Process 6756, exception c005 at 000180111DA8
Segmentation fault
 --- cut ---

 gcc compiler also crashed, but i did not investigate it. All problems got
fixed when i downgraded cygwin package to version 1.7.28-2.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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: [BUG] /bin/sh crashes with the recent cygwin1.dll on x86/64

[Corinna Vinschen]

On May 13 13:18, Pavel Fedin wrote:
>  Hello! I have updated my Cygwin installation and it is completely unusable.
>  First, shell scripts stopped working. I have traced this down to /bin/sh
> executable apparently doing nothing. Running under strace gives this:
> ---cut ---
> $ strace /bin/sh --version
> 1   1 [main] sh (6756)
> **
>86  87 [main] sh (6756) Program name: C:\cygwin64\bin\sh.exe (windows
> pid 6756)
>30 117 [main] sh (6756) OS version:   Windows NT-6.1
>27 144 [main] sh (6756)
> **
>   101 245 [main] sh (6756) sigprocmask: 0 = sigprocmask (0, 0x1802BBC68,
> 0x0)
>   438 683 [main] sh 6756 open_shared: name shared.5, n 5, shared
> 0x18003 (wanted 0x18003), h 0x70, *m 6
>51 734 [main] sh 6756 user_heap_info::init: heap base 0x6,
> heap top 0x6, heap size 0x2000 (536870912)
>56 790 [main] sh 6756 open_shared: name
> S-1-5-21-1454471165-515967899-839522115-3227.1, n 1, shared 0x18002
> (wanted 0x18002), h 0x68, *m 6
>58 848 [main] sh 6756 user_info::create: opening user shared for
> 'S-1-5-21-1454471165-515967899-839522115-3227' at 0x18002
>36 884 [main] sh 6756 user_info::create: user shared version AB1FCCE8
>61 945 [main] sh 6756 fhandler_pipe::create: name
> \\.\pipe\cygwin-e022582115c10879-6756-sigwait, size 176, mode
> PIPE_TYPE_MESSAGE
>821027 [main] sh 6756 fhandler_pipe::create: pipe read handle 0x84
>191046 [main] sh 6756 fhandler_pipe::create: CreateFile: name
> \\.\pipe\cygwin-e022582115c10879-6756-sigwait
>471093 [main] sh 6756 fhandler_pipe::create: pipe write handle 0x88
>331126 [main] sh 6756 dll_crt0_0: finished dll_crt0_0 initialization
> --- Process 6756, exception c005 at 7780E4E4
> 49743   50869 [main] sh 6756 __set_errno: void san::leave():315 setting
> errno 66168
> --- Process 6756, exception c005 at 000180111DA8
> Segmentation fault
>  --- cut ---
> 
>  gcc compiler also crashed, but i did not investigate it. All problems got
> fixed when i downgraded cygwin package to version 1.7.28-2.

Please try a recent snapshot from http://cygwin.com/snapshots/


Corinna

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


pgpSJD4HEyfw8.pgp
Description: PGP signature

pinfo configure problem

[Andrew Schulman]

I'm trying to build pinfo 0.6.10 in 64-bit.  The configure script halts,
claiming "curses is not usable".  The command that fails is:

  gcc -o conftest.exe -g -O2 -I/usr/include -L/usr/lib -lncursesw
conftest.c 

and this fails because the order of the arguments is wrong.  The command
should be

  gcc -o conftest.exe -g -O2 -I/usr/include conftest.c -L/usr/lib
-lncursesw 

and that succeeds.  So my question is really an autoconf question:  How
can I tell autoconf to fix the order of the compiler arguments?

My autoconf knowledge is pretty thin I'm afraid.  I can provide the
configure.ac script if that would be helpful.  The source is old - I
think the last real update was in 2007, with a small update posted in
2010.

Thanks,
Andrew


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

More testing needed: New passwd/group AD/SAM integration

[Corinna Vinschen]

Hi list,


I'm still interested in testing of the new Cygwin code to have
user/group identification without requiring /etc/passwd and /etc/group
files.

This is a pretty big change, and it would be very helpful if as many
users as possible would be willing to give this a test.

Think about it:  You'll never have to care for /etc/passwd and
/etc/group files again!

The latest preliminary documentation is attached to this mail again.

As usual the changes are present in the latest snapshots:

  http://cygwin.com/snapshots/

The latest snapshots now handle "Microsoft Accounts", a marketing name
for a way to login with your email address(1).  These accounts, if
local (non-domain) accounts, will have the "Users" group as their
primary group in Cygwin by default.  The problems are outlined in
the thread "Problem with "None" Group on Non-Domain Members"(2).

==
IMPORTANT:
==

I'm still a bit unhappy with the account naming strategy and especially
the nsswitch.conf configuration.  It would be more reliable if the user
names would be constructed in always the same way.  So, here are the
things I'm still unsure about:

* db_separator in /etc/nsswitch.conf

  Is it really such a good idea to have a configurable separator
  char in user and group names?  Is it important that it is
  configurable?  Isn't '+' a good choice for the separator and be
  done with it?

* Right now the builtin accounts are prepended by the separator char:

+SYSTEM
+Users
...

  This is how it's done in SFU, but... do we need that?  The builtin
  accounts are unambiguous.  There's no way to create a user or group
  with the same name asd a builtin account.  And while compatibility
  with SFU looks funny, it's not necessary.

  So, shall we drop this prepending of the separator char and make
  the builtin accounts "normal" accounts again, just like before?

SYSTEM
Users
...

* Right now there are three configurable strategies for the account
  naming in /etc/nsswitch.conf:

  db_prefix: auto

This is the default.  If your account is from the primary domain of
your machine, or if your machine is a standalone machine (not a domain
member), your Cygwin account name is just the Windows account
name.
If your account is from another domain, or if you're logged in as
local user on a domain machine, the Cygwin username will be the
combination of Windows domainname and username, with the separator
char in between:

  MY_DOM+username  (foreign domain)
  MACHINE+username (local account)

  db_prefx: primary

Like "auto", but primary domain accounts will be prepended by
the domainname as well.

  db_prefix: always

All accounts, even the builtin accounts, will have the domain
name prepended:

  BUILTIN+Users

  Do we really need this flexibility?


Thanks,
Corinna


(1) ...and a nice way for MSFT to collect your personal information...
(2) http://cygwin.com/ml/cygwin/2014-05/threads.html#00059


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

For as long as Cygwin has existed, it has stored user and group
information in /etc/passwd and /etc/group files.  Under the assumption
that these files would never be too large, the first process in a
process tree, as well as every execing process within the tree would
parse them into structures in memory.  Thus every Cygwin process would
contain an expanded copy of the full information from /etc/passwd and
/etc/group.

This approach has a few downsides.  One of them is that the idea to have
always small files is flawed.  Another one is that reading the entire
file is most of the time entirely useless, since most processes only
need information on their own user and the primary group.  Last but not
least, the passwd and group files have to be maintained separately from
the already existing Windows user databases, the local SAM and Active
Directory.

On the other hand, we have to have a mapping between Windows SIDs and
POSIX uid/gid values (see [1]), so we rely on some mechanism to convert
SIDs to uid/gid values and vice versa.

Microsoft "Services for UNIX" (SFU) (which are unfortunately deprecated
since Windows 8/Server 2012) never used passwd/group files.  Rather, SFU
used a fixed, computational mapping between SIDs and POSIX uid/gid.  It
allows to generate uid/gid values from SIDs and vice versa.  The
mechanism is documented, albeit in a confusing way and spread over
multiple MSDN articles.  The Cygwin approach clones the mapping, with
just tiny differences for backward compatibility.


=
How does it work?
=

The following description assumes you're comfortable with the concept of
Windows SIDs and RIDs.  For a brief introduction, please read [1].

Cygwin's new mapping between SIDs and uid/gid values works in two ways.

- Read /etc/passwd and /etc/group files,

Re: pinfo configure problem

[Corinna Vinschen]

On May 13 06:55, Andrew Schulman wrote:
> I'm trying to build pinfo 0.6.10 in 64-bit.  The configure script halts,
> claiming "curses is not usable".  The command that fails is:
> 
>   gcc -o conftest.exe -g -O2 -I/usr/include -L/usr/lib -lncursesw
> conftest.c 
> 
> and this fails because the order of the arguments is wrong.  The command
> should be
> 
>   gcc -o conftest.exe -g -O2 -I/usr/include conftest.c -L/usr/lib
> -lncursesw 
> 
> and that succeeds.  So my question is really an autoconf question:  How
> can I tell autoconf to fix the order of the compiler arguments?
> 
> My autoconf knowledge is pretty thin I'm afraid.  I can provide the
> configure.ac script if that would be helpful.  The source is old - I
> think the last real update was in 2007, with a small update posted in
> 2010.

Doesn't calling `autoreconf' fix this problem?  If so, if you use
cygport, the default build strategy contains the autoreconf step.
If you defin your own build function, call cygautoreconf as first
step after `cd ${B}'.


Corinna

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


pgpTWL0oFOMe3.pgp
Description: PGP signature

Re: How do start a cygwin shell session from a script ?

[Timothy Madden]

It appears I found my missing shell session settings: the access
rights on the current build and source directories.

The manual build was always run within the user home directory in
cygwin, and cygwin could see the proper access right on all the files
used in the build.

But outside the user home directory, cygwin no longer sees the proper
permissions for directories and files, even though the user running
the cygwin session can very well read and write the files. But cygwin
will list the files with no permissions whatsoever, not even u+r (read
access for the file owner). If I use the Windows `icacls` command to
explicitly add the current user to the ACL on the directory with
inheritable (recursive) "full control" access right, than cygwin can
see the proper access rights too for such directories.

Can this issue maybe be fixed, so cygwin sees the same permissions, on
any files, user that Windows will grant to the current user ?

Thank you,
Timothy Madden

On Mon, May 12, 2014 at 1:12 PM, Timothy Madden  wrote:
> Hello
>
> I have a CMake build script for my application, that among other
> things tries to build libvpx (open-source video codec, see
> webmproject.org).
>
> libvpx library v1.3.0 compiles fine by hand when I open a cygwin
> terminal from the Windows start menu and type in the needed
> `configure`; `make` and `make install` commands.
>
> But when I try to invoke the cygwin shell from my build script, to run
> the same 3 commands with the -lc option to sh.exe (same command line),
> something happens and the build commands no longer work like in the
> real mintty terminal. Then my build fails.
>
> I believe there is something in the cygwin shell session or
> environment that I do not know how to set right when invoking
> $(CYGWIN_DIR)/bin/sh from my CMake script.
>
> Is there a way for me to start a cygwin shell session from the build
> script, that is identical to the one that opens in the mintty terminal
> from the start menu, and run some commands there ?
>
> I checked the environment variables and umask in the mintty terminal
> and in a /bin/sh session that I launch, they are the same in both
> cases. I tried using /bin/sh, /bin/bash, /bin/dash, with both --login
> and -c options. But the automated build always fails, and the manual
> build works.
>
> Thank you,
> Timothy Madden

--
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: ssh fails to start on Windows XP

[Stephan Wurm]

Larry Hall (Cygwin  cygwin.com> writes:
> 
> This suggests to me that one or more packages in your Cygwin installation
> are not up-to-date.  If you haven't rebooted since you last ran setup*.exe,
> do so now.  If you have rebooted, try rerunning setup*.exe and have it
> reinstall everything.  Best tostop all Cygwin processes and services
> first though.  If this doesn't help, submit a complete problem report
> as described by the following link - 
> 

I had the same issue as described by Greg. 

Reinstalling everything fixed the issue. Thank you!



--
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: pinfo configure problem

[Andrew Schulman]

> On May 13 06:55, Andrew Schulman wrote:
> > I'm trying to build pinfo 0.6.10 in 64-bit.  The configure script halts,
> > claiming "curses is not usable".  The command that fails is:
> > 
> >   gcc -o conftest.exe -g -O2 -I/usr/include -L/usr/lib -lncursesw
> > conftest.c 
> > 
> > and this fails because the order of the arguments is wrong.  The command
> > should be
> > 
> >   gcc -o conftest.exe -g -O2 -I/usr/include conftest.c -L/usr/lib
> > -lncursesw 
> > 
> > and that succeeds.  So my question is really an autoconf question:  How
> > can I tell autoconf to fix the order of the compiler arguments?
> > 
> > My autoconf knowledge is pretty thin I'm afraid.  I can provide the
> > configure.ac script if that would be helpful.  The source is old - I
> > think the last real update was in 2007, with a small update posted in
> > 2010.
> 
> Doesn't calling `autoreconf' fix this problem?  If so, if you use
> cygport, the default build strategy contains the autoreconf step.
> If you defin your own build function, call cygautoreconf as first
> step after `cd ${B}'.

No, unfortunately it doesn't.  I ran 'autoreconf -i' first.


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

[ANNOUNCEMENT] Updated, new for x86_64: orpie

[Andrew Schulman]

A new version of orpie, 1.5.2-1, is now available in the Cygwin
distribution.

* New upstream release
* First release for x86_64 in Cygwin
* Rebuilt against OCaml 4

Orpie is a fullscreen RPN calculator for the console.  Its operation is
similar to that of modern HP calculators, but data entry has been
optimized for efficiency on a PC keyboard.  Features include extensive
scientific calculator functionality, command completion, and a visible
interactive stack.

Andrew E. Schulman


***


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

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

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

http://cygwin.com/lists.html#subscribe-unsubscribe

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

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

Re: pinfo configure problem

[Corinna Vinschen]

On May 13 07:49, Andrew Schulman wrote:
> > On May 13 06:55, Andrew Schulman wrote:
> > > I'm trying to build pinfo 0.6.10 in 64-bit.  The configure script halts,
> > > claiming "curses is not usable".  The command that fails is:
> > > 
> > >   gcc -o conftest.exe -g -O2 -I/usr/include -L/usr/lib -lncursesw
> > > conftest.c 
> > > 
> > > and this fails because the order of the arguments is wrong.  The command
> > > should be
> > > 
> > >   gcc -o conftest.exe -g -O2 -I/usr/include conftest.c -L/usr/lib
> > > -lncursesw 
> > > 
> > > and that succeeds.  So my question is really an autoconf question:  How
> > > can I tell autoconf to fix the order of the compiler arguments?
> > > 
> > > My autoconf knowledge is pretty thin I'm afraid.  I can provide the
> > > configure.ac script if that would be helpful.  The source is old - I
> > > think the last real update was in 2007, with a small update posted in
> > > 2010.
> > 
> > Doesn't calling `autoreconf' fix this problem?  If so, if you use
> > cygport, the default build strategy contains the autoreconf step.
> > If you defin your own build function, call cygautoreconf as first
> > step after `cd ${B}'.
> 
> No, unfortunately it doesn't.  I ran 'autoreconf -i' first.

autoreconf -f -i?


Corinna

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


pgp5XoZrCt1cI.pgp
Description: PGP signature

Re: More testing needed: New passwd/group AD/SAM integration

[Henry S. Thompson]

Corinna Vinschen writes:

> I'm still interested in testing of the new Cygwin code to have
> user/group identification without requiring /etc/passwd and /etc/group
> files.

So I installed the 2014-05-09 x86_64 snapshot, and did nothing else
(i.e. left /etc/{passwd,group} alone, didn't create an
/etc/nsswitch.conf), since your attachment didn't contain anything
which said "Minimum necessary to make this all work is ...".

I then successfully launched mintty, but (since the most important
aspect of my 'identity' is my ability to authenticate using Kerberos),
the next thing I tried did not work as expected:

> kinit
Password: 
kinit: krb5_get_init_creds: unable to reach any KDC in realm [the right realm 
for me]
>

Switching back to 1.7.29-2 fixed the problem.

What can I do to help locate the problem (unless you have a Kerberos
principal around you presumably can't reproduce this for yourself)?

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

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

Emacs-w32... crashing problem

[Zdzislaw Meglicki]

Well, the crashing problem in emacs-w32 is greatly improved, 
yet, the program still crashed on me yesterday, after a good
few days of seamless performance. The emacs-version function
returns:

(emacs-version)
"GNU Emacs 24.3.90.1 (x86_64-unknown-cygwin)
 of 2014-05-03 on Fiona"

Other sys params:

Windows 8.1 Pro
AMD A8-5500 APU with Radeon HD Graphics 3.2GHz
8GB RAM
64-bit OS
Cygwin DLL version info:
DLL version: 1.7.29
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 272
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Program options name: Program Options
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5


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

[Steven Penny]

On Tue, May 13, 2014 at 12:56 AM, Christopher Faylor wrote:
> Frankly, please give MSYS2 another try.  We'd all appreciate it.

Look at the facts:

coreutils
newer version released 2 years ago

bash
newer version released 3 years ago

git
newer version released 2 years ago

These are major packages, not just "user X favorite package". Several people
including myself have offered to update them, only to be met with "Sorry, I am
maintainer not you. I will do it when I get time". It gets old after a while.

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

[Peter Rosin]

On 2014-05-13 14:29, Steven Penny wrote:
> On Tue, May 13, 2014 at 12:56 AM, Christopher Faylor wrote:
>> Frankly, please give MSYS2 another try.  We'd all appreciate it.
> 
> Look at the facts:
> 
> coreutils
> newer version released 2 years ago
> 
> bash
> newer version released 3 years ago
> 
> git
> newer version released 2 years ago
> 
> These are major packages, not just "user X favorite package". Several people
> including myself have offered to update them, only to be met with "Sorry, I am
> maintainer not you. I will do it when I get time". It gets old after a while.

Now, I'm just a random user, but exactly because these are major packages, it's
good to have a maintainer that actually understands and fixes problems related
to Cygwin, instead of having a maintainer that just builds the latest version
and uploads it. Given that you seem to love MSYS2 so much, I can report that I
recently dealt with a \r-issue with MSYS2 bash. I'd rather have a maintainer
that insulates me from \r-issues and says "no" before they hit me, than have a
maintainer that don't understand why stripping every \r in sight isn't such a
good idea. (to be fair, I'm not 100% sure it was an issue with the official
MSYS2 bash or if it was some 3rd party patch on top of the official MSYS2 bash,
I don't run MSYS2 personally).

That said, I'd also love a bash update, but I'd rather have a working bash than
a new bash. Because it is a major package.

2 cents

Cheers,
Peter


--
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: Emacs-w32... crashing problem

[Ken Brown]

On 5/13/2014 8:16 AM, Zdzislaw Meglicki wrote:

Well, the crashing problem in emacs-w32 is greatly improved,
yet, the program still crashed on me yesterday, after a good
few days of seamless performance. The emacs-version function
returns:

(emacs-version)
"GNU Emacs 24.3.90.1 (x86_64-unknown-cygwin)
  of 2014-05-03 on Fiona"


Please describe the crash in more detail.  What were you doing when it 
happened?  Did the window just disappear, or did you get a dialogue box 
asking if you want to attach a debugger?  Did you get any messages in 
the terminal that emacs was started from?  Is there a stackdump file?


Can you still get a crash if you start emacs with the -Q option?  I 
realize that it might take several days before you know the answer.


Can you run emacs under gdb and try to get a backtrace when it crashes? 
 You'll have to install the emacs-debuginfo package.  And you may have 
to experiment with breakpoints, but I would start by setting one at 
emacs_abort.


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

Switching off completely logging to Windows event log‏

[sbremal]

Hello

Is there any way to make 'syslog' calls log nowhere. The aim is to leave no 
traces of the application run (strange but this is the requirement), so neither 
the syslog daemon will be available ofr logging into file, nor I want 'syslog' 
to fall back to the Windows event log.

Is this possible through some run time configurtion? Environment variable etc.?

Thanks!


Cheers
B.
  

Re: Update CoreUtils

[Christopher Faylor]

On Tue, May 13, 2014 at 07:29:10AM -0500, Steven Penny wrote:
>These are major packages, not just "user X favorite package". Several people
>including myself have offered to update them, only to be met with "Sorry, I am
>maintainer not you. I will do it when I get time". It gets old after a while.

Frankly, so does your posting style.

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

Can't read from serial port without writing to it before

[Manuel Wienand]

Hello!

I have got the problem, that I can‘t read from a serial port without writing at 
least one byte to it before.
Another workaround is to use an terminal application (I tried with HTerm) and 
connect (and then disconnect again) to the COM port, this seems to fix it for 
the next run.
Closing the COM port properly before exiting the program doesn’t seem to have 
any effect on the faulty behaviour.

Test case:
PC:
Win7 (x64), Cygwin 1.7.29 (x32)

Using a serial cable to connect to a development board which is just spamming 
data over the serial.
⇒ PC reads only, board writes only.
The code of the PC program is attached at the end of this mail.

I hope you are able to reproduce and fix this problem.

Thanks in advance.

Manuel



#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int kbport = -1;

int posix_com_close(int port)
{
  int rtnval = 0;
  if (port != -1)
  {
rtnval = (int) close(port);
  }

  return(rtnval);
}

int posix_com_open(char *devicename)
{
  int rtnval = 0;
  struct termios t;

  int local_databits = CS8; // 8 Databits.
  int local_stopbits = 0;   // 1 Stopbit
  int local_parity = 0; // No parity
  int local_rate = B9600;   // 9600 Baud

  /* Open the com port for read/write access */

  rtnval = open(devicename,O_RDWR);

  t.c_iflag = IGNPAR;
  t.c_oflag = 0;
  t.c_cflag &= ~CSIZE; /* Zero out the CSIZE bits */
  t.c_cflag = CLOCAL | local_databits | local_stopbits | local_parity;
  t.c_lflag = IEXTEN;

  if ((cfsetispeed(&t,local_rate) != -1) && (cfsetospeed(&t,local_rate) != -1))
  {
if (tcsetattr(rtnval,TCSANOW,&t) == -1)
  rtnval = -1;
  }
  else
rtnval = -1;

  return(rtnval);
}

char posix_com_read(int port, char *dst)
{

  if (port != -1)
return(read(port,dst,1) == 1);
  else
return(0);
}

char posix_com_write(int port, char src)
{
  if (port != -1)
return(write(port,&src,1) == 1);
  else
return(0);
}


int main(void)
{
  int myport = 0;
  char inchar = 0;
  int i=0;

  myport = posix_com_open("/dev/ttyS0");

  puts("Starting to receive...");fflush(stdout);
  char test = 'A';
  //posix_com_write(myport, test); // When using this line, reading will always 
work.

  if (myport != -1)
  {

while (i<20)
//while (1) // Since closing the COM port doesn't help, we can use this 
instead.
{
  i++;
  if (posix_com_read(myport,&inchar))
  {
if (isprint(inchar))
  printf("%c",inchar);
else
  printf("<%03d>",inchar);
fflush(stdout);
  }

}
posix_com_close(myport);  // Doesn't help.
return EXIT_SUCCESS;
  }

  return EXIT_SUCCESS;
}


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

bind to multicast address fails

[Moritz Warning]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I try to bind a socket to a multicast address (239.192.202.5). But it fails 
with an error:
"Cannot assign requested address"

Is this not supported using Cygwin? I've added a simple test program in case 
someone wants
to verify.

Thanks,
mwarning
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBCAAGBQJTcioBAAoJECHrh56PP4wpXmYH/AyT0e32GL2GxSr5DZexNEkA
lGY3wYUlNkEjkzrFxTNOoTvDTg0nvDD5q9jMH1WoKObbwbhvG27qn3m/iZL4g/HD
DPW935mCEpSp5ryKGUyHBuS28IkLWYhgFZyUF7Uz0zG3VWcdKPo4G/O+/imT7Un4
+2gPJl7wwVsEtmBnxso3EixBBroLIO/w0gd/4b7XEfsInWhe1/GSTdjROTqUh5bY
gmMJIu3kiShGlYdq0c4BcnPgTcJewfunVMLLyl3zoq2KnHof1BqKGP8k6cibuCRo
SRs0meCQX19azuivoX01synqfddB9x/XHbtoiUe3Mxnq/KhUogh5bI5QJgNyGqI=
=HUpc
-END PGP SIGNATURE-

#include 
#include 
#include 
#include 
#include 
#include 

int main( int argc, char **argv ) {
	struct sockaddr_in sockaddr;
	if( inet_pton(AF_INET, "239.192.202.5", &sockaddr.sin_addr) != 1 ) {
		printf("parse errorr\n");
		return 1;
	}
	sockaddr.sin_family = AF_INET;
	sockaddr.sin_port = htons(6771);

	int sock = socket( AF_INET, SOCK_DGRAM, IPPROTO_UDP );

	socklen_t addrlen= sizeof(struct sockaddr_in);
	if( bind( sock, (struct sockaddr*) &sockaddr, addrlen ) < 0 ) {
		//close( sock );
		printf( "Failed to bind socket to address: %s\n", strerror( errno ) );
		return 1;
	}

	printf("It works.\n");
	//close( sock );
	return 0;
}


main.c.sig
Description: PGP signature
--
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 CoreUtils

[Chris J. Breisch]

Steven Penny wrote:

These are major packages, not just "user X favorite package". Several people
including myself have offered to update them, only to be met with "Sorry, I am
maintainer not you. I will do it when I get time". It gets old after a while.



Well, if you don't want to wait, and you're confident of your ability to 
update, then do so. You don't have to publish the package to use it on 
your own system.


I don't know anything about the git source, but I know that bash and 
coreutils are a pain to update, because there's so much in both that 
depends upon Windows text mode/binary mode annoyances. Also, bash (I 
believe) understands Windows paths, and that doesn't make porting any 
easier either. I spent a very brief time looking at updating bash 
myself, and decided it wasn't worth the pain.


I've done a little with coreutils in the past, and I suspect if I had 
to, I could update it using the patches from the last version as a 
starting point, but I haven't found a need to do so yet.


--
Chris J. Breisch

--
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: More testing needed: New passwd/group AD/SAM integration

[Corinna Vinschen]

On May 13 12:57, Henry S. Thompson wrote:
> Corinna Vinschen writes:
> 
> > I'm still interested in testing of the new Cygwin code to have
> > user/group identification without requiring /etc/passwd and /etc/group
> > files.
> 
> So I installed the 2014-05-09 x86_64 snapshot, and did nothing else
> (i.e. left /etc/{passwd,group} alone, didn't create an
> /etc/nsswitch.conf), since your attachment didn't contain anything
> which said "Minimum necessary to make this all work is ...".

Yes, that was a mistake.  I would be mostely interested in experiences
(and anoyances) by dropping /etc/passwd and /etc/group.  The easiest
way to do that is NOT to move the files out of the way, but just
adding an /etc/nsswitch.conf file with this simple content:

passwd: db
group: db

And, having said that, I'd be really glad for more people reading and
ciriticising the preliminary documentation...

> I then successfully launched mintty, but (since the most important
> aspect of my 'identity' is my ability to authenticate using Kerberos),
> the next thing I tried did not work as expected:
> 
> > kinit
> Password: 
> kinit: krb5_get_init_creds: unable to reach any KDC in realm [the right realm 
> for me]
> >
> 
> Switching back to 1.7.29-2 fixed the problem.
> 
> What can I do to help locate the problem (unless you have a Kerberos
> principal around you presumably can't reproduce this for yourself)?

I can reproduce it.  This has nothing to with the account stuff, but
rather with a problem with the IPV6 definitions in the Mingw-w64 headers
I encountered lately, and which I had to workaround.  Unfortunately
it has unwanted side-effects.  Sigh.  I'm looking into it.


Thanks,
Corinna

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


pgpBUAtmwIvxG.pgp
Description: PGP signature

Re: bind to multicast address fails

[Corinna Vinschen]

On May 13 16:19, Moritz Warning wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> I try to bind a socket to a multicast address (239.192.202.5). But it fails 
> with an error:
> "Cannot assign requested address"
> 
> Is this not supported using Cygwin? I've added a simple test program in case 
> someone wants
> to verify.

It's a problem win the underlying Winsock (again).  Maybe this discussion
on stackoverflow helps you along:

http://stackoverflow.com/questions/6140734/cannot-bind-to-multicast-address-windows

Right now I have no inclination to workaround this problem in Cygwin.
Maybe if you ping me again in a month or so.  Of course, patches are
always welcome...


Corinna

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


pgpENzGA8d59_.pgp
Description: PGP signature

Re: Update CoreUtils

[Steven Penny]

On Tue, May 13, 2014 at 7:46 AM, Peter Rosin wrote:
> I'd rather have a maintainer
> that insulates me from \r-issues and says "no" before they hit me, than have a
> maintainer that don't understand why stripping every \r in sight isn't such a
> good idea.

We already have a system in place for this. The Cygwin installer allows you to
choose "Curr" or "Exp". "Curr" being stable version and "Exp" being
experimental. Except the reality is that the choices are "old" and "old".

--
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: Switching off completely logging to Windows event log‏

[Corinna Vinschen]

On May 13 13:16, sbre...@hotmail.com wrote:
> Hello
> 
> Is there any way to make 'syslog' calls log nowhere. The aim is to leave no 
> traces of the application run (strange but this is the requirement), so 
> neither the syslog daemon will be available ofr logging into file, nor I want 
> 'syslog' to fall back to the Windows event log.
> 
> Is this possible through some run time configurtion? Environment variable 
> etc.?

No, sorry.  You can run syslogd and log to /dev/null.


Corinna

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


pgp3bVPJcBljD.pgp
Description: PGP signature

Re: Update CoreUtils

[Christopher Faylor]

On Tue, May 13, 2014 at 09:59:03AM -0500, Steven Penny wrote:
>On Tue, May 13, 2014 at 7:46 AM, Peter Rosin wrote:
>>I'd rather have a maintainer that insulates me from \r-issues and says
>>"no" before they hit me, than have a maintainer that don't understand
>>why stripping every \r in sight isn't such a good idea.
>
>We already have a system in place for this.  The Cygwin installer
>allows you to choose "Curr" or "Exp".  "Curr" being stable version and
>"Exp" being experimental.  Except the reality is that the choices are
>"old" and "old".

Funny how you're saying "We" as if you are actually contributing
anything other than criticism.

--
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: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

>> At my place I have installed both versions of Cygwin (i.e. 32-bits and 
>> 64-bits) -- of course,
>> in different places.  As "some" of you will have the "same" setup, I would 
>> like you to confirm
>> the following (UNexpected, to me) result:
>>
>>   - I canNOT invoke regedit from 64-bits bash (Yes, I can if bash has been 
>> invoked in ELEVATED mode)
>>   - I can invoke regedit from 64-bits bash (not elevated) as follows: 
>> cygstart regedit
>>   - however, I can invoke regedit from 32-bits bash (not elevated) ...
>>   - likewise, I can invoke regedit from 64-bits cmd (not elevated) ...
>>
>> By UNexpected result I mean: I cannot explain why I canNOT invoke regedit 
>> from 64-bits bash ...
> [snip]
>
>> E:\Cygwin64\bin\bash: /drv/c/WINDOWS/regedit: Permission denied
>
> I can not duplicate your behavior. I can not invoke regedit from any
> non-elevated bash prompt, regardless of whether it is 32-bit or 64-bit.
> I get the above error in both cases.

Hi Chris,

Once more, thank you for your input!

Your system shows indeed the "correct" behaviour :-)

On my system the key

HKEY_CURRENT_USER\Software\Microsoft\Windows 
NT\CurrentVersion\AppCompatFlags\Layers

had a field e:\Cygwin\bin\bash.exe that read ELEVATECREATEPROCESS

Once the field had been deleted, I got the same behaviour as you did.

(do not ask me how the field with THAT value got there -- I simply do not know)

Henri


--
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: bind to multicast address fails

[Moritz Warning]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thanks for the pointer! :)

On 05/13/2014 04:55 PM, Corinna Vinschen wrote:
> On May 13 16:19, Moritz Warning wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hi,
>>
>> I try to bind a socket to a multicast address (239.192.202.5). But it fails 
>> with an error:
>> "Cannot assign requested address"
>>
>> Is this not supported using Cygwin? I've added a simple test program in case 
>> someone wants
>> to verify.
> 
> It's a problem win the underlying Winsock (again).  Maybe this discussion
> on stackoverflow helps you along:
> 
> http://stackoverflow.com/questions/6140734/cannot-bind-to-multicast-address-windows
> 
> Right now I have no inclination to workaround this problem in Cygwin.
> Maybe if you ping me again in a month or so.  Of course, patches are
> always welcome...
> 
> 
> Corinna
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBCAAGBQJTcjX7AAoJECHrh56PP4wpOooIAJSgT+YIAk+VE51D090yJF2W
lA/cedxkIYW2poOeZYrgVF6q76gLHsrD1Ul6Xepbc7hRWBgTBjGYedCa/IUFYNqu
+N/+3RKTSn9VbgixJxN6N3AJip/rcFj/N7lgc9i1HJQX4g0lJa0p9s18sujBH2/J
0RCKf860SSkBHj4sdmCO/EfkfPFFfb6hQjvOYeFdkYP0Blb3Gp5Db9VYqG9WsfxV
o4g5tXyM1TGs5CElkyFwC9fGvpT9o9Q4P/6BvOPxGJ3G10v3rvY3Bdd9QeE5HrpD
UCouBCgcLcL5nBuzWzYqFG6Wklnxnnv3bsoSd199uALAcPtms1djWLiQusbYe4A=
=1QHo
-END PGP SIGNATURE-

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

Re: How do start a cygwin shell session from a script ?

[Larry Hall (Cygwin)]

On 05/13/2014 07:25 AM, Timothy Madden wrote:

It appears I found my missing shell session settings: the access
rights on the current build and source directories.

The manual build was always run within the user home directory in
cygwin, and cygwin could see the proper access right on all the files
used in the build.

But outside the user home directory, cygwin no longer sees the proper
permissions for directories and files, even though the user running
the cygwin session can very well read and write the files. But cygwin
will list the files with no permissions whatsoever, not even u+r (read
access for the file owner). If I use the Windows `icacls` command to
explicitly add the current user to the ACL on the directory with
inheritable (recursive) "full control" access right, than cygwin can
see the proper access rights too for such directories.

Can this issue maybe be fixed, so cygwin sees the same permissions, on
any files, user that Windows will grant to the current user ?


There are some tools that only look at the POSIX permissions (rwxrwxrwx),
which is what Cygwin works to provide.  But if you're using non-Cygwin
tools to create or modify files, these will not necessarily comply with
POSIX permissions.  If using Cygwin alternatives for these tools isn't
an option, you can mount the directory tree in question with the "noacl"
option to tell Cygwin tools to always allow access (see
).  Many
times, this approach works best when you're trying to mix Windows native
and Cygwin tools.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: pinfo configure problem - configure.ac (1/1)

[Andrew Schulman]

configure.ac
Description: Binary data

Re: pinfo configure problem - configure.ac (0/1)

[Andrew Schulman]

> On May 13 07:49, Andrew Schulman wrote:
> > > On May 13 06:55, Andrew Schulman wrote:
> > > > I'm trying to build pinfo 0.6.10 in 64-bit.  The configure script halts,
> > > > claiming "curses is not usable".  The command that fails is:
> > > > 
> > > >   gcc -o conftest.exe -g -O2 -I/usr/include -L/usr/lib -lncursesw
> > > > conftest.c 
> > > > 
> > > > and this fails because the order of the arguments is wrong.  The command
> > > > should be
> > > > 
> > > >   gcc -o conftest.exe -g -O2 -I/usr/include conftest.c -L/usr/lib
> > > > -lncursesw 
> > > > 
> > > > and that succeeds.  So my question is really an autoconf question:  How
> > > > can I tell autoconf to fix the order of the compiler arguments?
> > > 
> > > Doesn't calling `autoreconf' fix this problem?  If so, if you use
> > > cygport, the default build strategy contains the autoreconf step.
> > > If you defin your own build function, call cygautoreconf as first
> > > step after `cd ${B}'.
> > 
> > No, unfortunately it doesn't.  I ran 'autoreconf -i' first.
> 
> autoreconf -f -i?

Alas, no.

Here's configure.ac, in case that's helpful.


--
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: More testing needed: New passwd/group AD/SAM integration

[Corinna Vinschen]

On May 13 16:52, Corinna Vinschen wrote:
> On May 13 12:57, Henry S. Thompson wrote:
> > I then successfully launched mintty, but (since the most important
> > aspect of my 'identity' is my ability to authenticate using Kerberos),
> > the next thing I tried did not work as expected:
> > 
> > > kinit
> > Password: 
> > kinit: krb5_get_init_creds: unable to reach any KDC in realm [the right 
> > realm for me]
> > >
> > 
> > Switching back to 1.7.29-2 fixed the problem.
> > 
> > What can I do to help locate the problem (unless you have a Kerberos
> > principal around you presumably can't reproduce this for yourself)?
> 
> I can reproduce it.  This has nothing to with the account stuff, but
> rather with a problem with the IPV6 definitions in the Mingw-w64 headers
> I encountered lately, and which I had to workaround.  Unfortunately
> it has unwanted side-effects.  Sigh.  I'm looking into it.

I just uploaded new snapshots to http://cygwin.com/snapshots/ which
are supposed to fix this issue.  Kinit worked for me again with this.
I'd be grateful if you could check if it works for you too and, maybe,
test the account stuff a bit more...?


Thanks,
Corinna

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


pgpX9YH1bWCEH.pgp
Description: PGP signature

Re: More testing needed: New passwd/group AD/SAM integration

[Henry S. Thompson]

Corinna Vinschen writes:

> On May 13 16:52, Corinna Vinschen wrote:

>> I can reproduce it.  This has nothing to with the account stuff, but
>> rather with a problem with the IPV6 definitions in the Mingw-w64 headers
>> I encountered lately, and which I had to workaround.  Unfortunately
>> it has unwanted side-effects.  Sigh.  I'm looking into it.
>
> I just uploaded new snapshots to http://cygwin.com/snapshots/ which
> are supposed to fix this issue.  Kinit worked for me again with this.
> I'd be grateful if you could check if it works for you too and, maybe,
> test the account stuff a bit more...?

kinit works.  ssh works.  (New) screen works.

Both with /etc/passwd,group and no nsswitch.conf, and with
/etc/passwd,group,nsswitch.conf with passwd: db group: db

Any trivial way I can test that I am actually _getting_ identities
via the new route?

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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: More testing needed: New passwd/group AD/SAM integration

[Corinna Vinschen]

On May 13 17:29, Henry S. Thompson wrote:
> Corinna Vinschen writes:
> 
> > On May 13 16:52, Corinna Vinschen wrote:
> 
> >> I can reproduce it.  This has nothing to with the account stuff, but
> >> rather with a problem with the IPV6 definitions in the Mingw-w64 headers
> >> I encountered lately, and which I had to workaround.  Unfortunately
> >> it has unwanted side-effects.  Sigh.  I'm looking into it.
> >
> > I just uploaded new snapshots to http://cygwin.com/snapshots/ which
> > are supposed to fix this issue.  Kinit worked for me again with this.
> > I'd be grateful if you could check if it works for you too and, maybe,
> > test the account stuff a bit more...?
> 
> kinit works.  ssh works.  (New) screen works.
> 
> Both with /etc/passwd,group and no nsswitch.conf, and with
> /etc/passwd,group,nsswitch.conf with passwd: db group: db
> 
> Any trivial way I can test that I am actually _getting_ identities
> via the new route?

Call `id' :)


Corinna

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


pgpHBkRmw7Si6.pgp
Description: PGP signature

Re: pinfo configure problem - configure.ac (1/1)

[Corinna Vinschen]

On May 13 11:32, Andrew Schulman wrote:
[autoconf.ac]

Hmm, I'm not seeing anything fishy in this file.  But I'm not the
exactly the autoconf expert either.

Any autoconf guru available?


Corinna

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


pgprF3VVRmcr0.pgp
Description: PGP signature

Re: pinfo configure problem - configure.ac (0/1)

[Andrew Schulman]

> > On May 13 07:49, Andrew Schulman wrote:
> > > > On May 13 06:55, Andrew Schulman wrote:
> > > > > I'm trying to build pinfo 0.6.10 in 64-bit.  The configure script 
> > > > > halts,
> > > > > claiming "curses is not usable".  The command that fails is:
> > > > > 
> > > > >   gcc -o conftest.exe -g -O2 -I/usr/include -L/usr/lib -lncursesw
> > > > > conftest.c 
> > > > > 
> > > > > and this fails because the order of the arguments is wrong.  The 
> > > > > command
> > > > > should be
> > > > > 
> > > > >   gcc -o conftest.exe -g -O2 -I/usr/include conftest.c -L/usr/lib
> > > > > -lncursesw 
> > > > > 
> > > > > and that succeeds.  So my question is really an autoconf question:  
> > > > > How
> > > > > can I tell autoconf to fix the order of the compiler arguments?
> > > > 
> > > > Doesn't calling `autoreconf' fix this problem?  If so, if you use
> > > > cygport, the default build strategy contains the autoreconf step.
> > > > If you defin your own build function, call cygautoreconf as first
> > > > step after `cd ${B}'.
> > > 
> > > No, unfortunately it doesn't.  I ran 'autoreconf -i' first.
> > 
> > autoreconf -f -i?
> 
> Alas, no.
> 
> Here's configure.ac, in case that's helpful.

I seem to have worked around it by setting LIBS=-lncursesw.  Apparently
LIBS is appended to the gcc command line after the list of source files.

Thanks for looking into it.


--
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: More testing needed: New passwd/group AD/SAM integration

[Henry S. Thompson]

Corinna Vinschen writes:

> On May 13 17:29, Henry S. Thompson wrote:
>> Any trivial way I can test that I am actually _getting_ identities
>> via the new route?
>
> Call `id' :)

OK, so that does yield. . .rather different results than it used to.

Poking around with id compared to the the contents of /etc/passwd
(from mkpasswd) and also compared to what my x86 install (not using
snapshot) does, I see one glitch and one difference:

Glitch (also true for x86 1.7.29-2):
  id returns effectively immediately for all users and non-users _except_:
   > time id Administrators
uid=544(+Administrators) gid=544(+Administrators)
groups=11(+Authenticated Users),544(+Administrators)

real0m2.296s
user0m0.015s
sys 0m0.015s

Difference:

 [x86 1.7.29]> id TrustedInstaller
   uid=4294967294(TrustedInstaller) gid=4294967294(TrustedInstaller)
   groups=4294967294(TrustedInstaller)

 [x86_64 snapshot]> id TrustedInstaller
   id: TrustedInstaller: no such user

That's all I've found, happy to try other tests anyone can suggest.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

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

[Steven Penny]

On Tue, May 13, 2014 at 10:04 AM, Christopher Faylor wrote:
> Funny how you're saying "We" as if you are actually contributing
> anything other than criticism.

You want me to contribute? Give me maintenance over one of the aforementioned
packages. Ball is in your court.

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

[Chris J. Breisch]

Steven Penny wrote:

On Tue, May 13, 2014 at 10:04 AM, Christopher Faylor wrote:

Funny how you're saying "We" as if you are actually contributing
anything other than criticism.


You want me to contribute? Give me maintenance over one of the aforementioned
packages. Ball is in your court.

If you're ready to maintain something, then you must have successfully 
built the version of the package you want to maintain, applied any 
necessary Cygwin patches, and gotten it to successfully work on your 
machine.


Since you've done all that, I am touched by your concern that the rest 
of us are running out-of-date stuff, and am glad that you are so eager 
to contribute. I'm sure Eric et al. would be happy to accept the 
assistance. PTC. (http://cygwin.com/acronyms/#PTC)


Of course, if you haven't yet successfully built the version of the 
package you want to maintain, haven't applied the necessary Cygwin 
patches, and haven't gotten it to successfully work on your machine, 
then it's a bit ludicrous to expect someone to name you the maintainer 
of said package. You haven't shown any evidence of your ability to 
perform in that capacity.




--
Chris J. Breisch

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

[Larry Hall (Cygwin)]

On 05/13/2014 02:36 PM, Chris J. Breisch wrote:

Steven Penny wrote:

On Tue, May 13, 2014 at 10:04 AM, Christopher Faylor wrote:

Funny how you're saying "We" as if you are actually contributing
anything other than criticism.


You want me to contribute? Give me maintenance over one of the aforementioned
packages. Ball is in your court.


If you're ready to maintain something, then you must have successfully built
the version of the package you want to maintain, applied any necessary
Cygwin patches, and gotten it to successfully work on your machine.

Since you've done all that, I am touched by your concern that the rest of us
are running out-of-date stuff, and am glad that you are so eager to
contribute. I'm sure Eric et al. would be happy to accept the assistance.
PTC. (http://cygwin.com/acronyms/#PTC)

Of course, if you haven't yet successfully built the version of the package
you want to maintain, haven't applied the necessary Cygwin patches, and
haven't gotten it to successfully work on your machine, then it's a bit
ludicrous to expect someone to name you the maintainer of said package. You
haven't shown any evidence of your ability to perform in that capacity.


...and Eric has.  Until he relinquishes his packages or disappears, the
majority (at least) of those on the list that use his packages appreciate
his efforts in the past and look forward to his support going forward.

If Eric decides to give up one or more of the packages you're interested
in picking up as maintainer, then we'll all be appreciative of your efforts
too. :-)


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: pinfo configure problem - configure.ac (0/1)

[Eric Blake]

On 05/13/2014 09:32 AM, Andrew Schulman wrote:

>> autoreconf -f -i?
> 
> Alas, no.
> 
> Here's configure.ac, in case that's helpful.

which contains:

# curses
AC_CHECK_CURSES
if ! test "x$USE_CURSES" = "xtrue"; then
AC_MSG_ERROR([Curses not found. You need curses to compile pinfo])
fi

But without a definition for AC_CHECK_CURSES, I still don't know enough.
 I hate packages that assume they can use the AC_ namespace for their
third-party macros.  Can you find the definition of that macro in a .m4
file that gets included?  That's probably the place that's creating the
bogus command line.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Does /etc/profile need to set MANPATH?

[Chris J. Breisch]

I've been working on getting man-db in a state where I can submit a 
package for it. I had been baffled by the failure of one of the tests 
that was dealing with overriding the man_db.conf file, so had been 
struggling to get a version that passes everything before I submitted it.


I finally discovered that the root cause was that MANPATH was being set 
from /etc/profile and that this value was conflicting with the test and 
causing it to fail. Unsetting MANPATH allowed the test to succeed[1].


My question is then, is it necessary to set this value? Is it something 
required by the current version of man that we're using? If so, man-db 
seems to override this necessity as it makes considerable effort to work 
out a reasonable manpath on it's own.


Perhaps this discussion belongs in cygwin-apps. I'll be happy to take it 
elsewhere.


---
[1] The failure of this test also seems to me to indicate an upstream 
bug. If MANPATH is set, man-db always ignores the data in the 
man_db.conf file, even if the conf file is specified on the command 
line. Worse, man-db actually reads the conf file, but then ignores the 
data. Perhaps this is working as designed, but if so, the design seems 
flawed from my perspective. From my research, this does not appear to be 
a Cygwin specific issue, although I haven't yet tried to reproduce it on 
a Linux system.



--
Chris J. Breisch

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

[Eric Blake]

On 05/13/2014 12:47 PM, Larry Hall (Cygwin) wrote:

>> Of course, if you haven't yet successfully built the version of the
>> package
>> you want to maintain, haven't applied the necessary Cygwin patches, and
>> haven't gotten it to successfully work on your machine, then it's a bit
>> ludicrous to expect someone to name you the maintainer of said
>> package. You
>> haven't shown any evidence of your ability to perform in that capacity.
> 
> ...and Eric has.  Until he relinquishes his packages or disappears, the
> majority (at least) of those on the list that use his packages appreciate
> his efforts in the past and look forward to his support going forward.
> 
> If Eric decides to give up one or more of the packages you're interested
> in picking up as maintainer, then we'll all be appreciative of your efforts
> too. :-)

For that matter, I've _already_ offered git up for another maintainer,
and am still waiting (at least 3 months later) for that transition to
completely materialize.  With progress like that, I'm less than
enthusiastic about handing over coreutils or bash.  But if you want to
post a test package for bash and/or coreutils, I'll at least review your
packaging to see if it looks like you preserved all the cygwin-specific
patches I already created, before deciding that handing over
maintainership makes sense.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: More testing needed: New passwd/group AD/SAM integration

[Corinna Vinschen]

On May 13 18:29, Henry S. Thompson wrote:
> Corinna Vinschen writes:
> 
> > On May 13 17:29, Henry S. Thompson wrote:
> >> Any trivial way I can test that I am actually _getting_ identities
> >> via the new route?
> >
> > Call `id' :)
> 
> OK, so that does yield. . .rather different results than it used to.
> 
> Poking around with id compared to the the contents of /etc/passwd
> (from mkpasswd) and also compared to what my x86 install (not using
> snapshot) does, I see one glitch and one difference:
> 
> Glitch (also true for x86 1.7.29-2):
>   id returns effectively immediately for all users and non-users _except_:
>> time id Administrators
> uid=544(+Administrators) gid=544(+Administrators)
> groups=11(+Authenticated Users),544(+Administrators)
> 
> real0m2.296s
> user0m0.015s
> sys 0m0.015s

This shouldn't happen as long as we still have the "+" prepended to
BUILTIN accounts(*).  And, as a matter of fact, I can't reproduce this
with the latest from CVS (== the snapshot you're testing).  Did you exit
your shell and restart it after creating the /etc/nsswitch.conf file as
described in my preliminary documentation?


Thanks,
Corinna

(*) I'd be grateful for input to the questions I asked in my OP, too.

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


pgpsKnBAXDCWp.pgp
Description: PGP signature

Re: Does /etc/profile need to set MANPATH?

[Corinna Vinschen]

On May 13 14:54, Chris J. Breisch wrote:
> I've been working on getting man-db in a state where I can submit a package
> for it. I had been baffled by the failure of one of the tests that was
> dealing with overriding the man_db.conf file, so had been struggling to get
> a version that passes everything before I submitted it.
> 
> I finally discovered that the root cause was that MANPATH was being set from
> /etc/profile and that this value was conflicting with the test and causing
> it to fail. Unsetting MANPATH allowed the test to succeed[1].
> 
> My question is then, is it necessary to set this value? Is it something
> required by the current version of man that we're using? If so, man-db seems
> to override this necessity as it makes considerable effort to work out a
> reasonable manpath on it's own.
> 
> Perhaps this discussion belongs in cygwin-apps. I'll be happy to take it
> elsewhere.

Yes, this might be better discussed in cygwin-apps.  I guess the setting
of MANPATH is mainly historical.

> ---
> [1] The failure of this test also seems to me to indicate an upstream bug.
> If MANPATH is set, man-db always ignores the data in the man_db.conf file,
> even if the conf file is specified on the command line. Worse, man-db
> actually reads the conf file, but then ignores the data. Perhaps this is
> working as designed, but if so, the design seems flawed from my perspective.
> From my research, this does not appear to be a Cygwin specific issue,
> although I haven't yet tried to reproduce it on a Linux system.

Be careful when this works differently on Linux.  The distro you're
testing this on might have additional patches applied, too...
I would suggest to discuss this upstream.


Corinna

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


pgpgqmEdQFfcq.pgp
Description: PGP signature

[ANNOUNCEMENT] Updated, libpipeline-1.3.0-3

[Erwin Waterlander]

INITIAL RELEASE FOR CYGWIN
==

libpipeline is a C library for manipulating pipelines of sub-processes 
in a flexible and convenient way.

See http://libpipeline.nongnu.org/

Libpipeline is required for man-db. Man-db is an alternative 'man' 
package (http://man-db.nongnu.org/). Man-db is used by major Linux 
distributions such as Debian, Suse, and Fedora. A big advantage of 
man-db is better internationalisation support.

Porting of man-db to Cygwin is being worked on.


PORTING NOTES
==

On 32-bit Cygwin one test out of 7 fails (test basic). With a static 
library all tests succeed, but this package contains a shared library, 
which is preferred. Tests with man-db have not shown errors.


On 64-bit Cygwin all tests pass.

The .src.patch file in the source package is not complete. This is due 
to cygport. The complete src.patch file is here:

http://waterlan.home.xs4all.nl/cygwin/libpipeline-3/libpipeline-1.3.0-3.src.patch
This will be solved in the next 1.3.1 release, because the patch is 
already in the upstream source.


best regards,

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

--
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: pinfo configure problem - configure.ac (0/1)

[Andrew Schulman]

> On 05/13/2014 09:32 AM, Andrew Schulman wrote:
> 
> >> autoreconf -f -i?
> > 
> > Alas, no.
> > 
> > Here's configure.ac, in case that's helpful.
> 
> which contains:
> 
> # curses
> AC_CHECK_CURSES
> if ! test "x$USE_CURSES" = "xtrue"; then
>   AC_MSG_ERROR([Curses not found. You need curses to compile pinfo])
> fi
> 
> But without a definition for AC_CHECK_CURSES, I still don't know enough.
>  I hate packages that assume they can use the AC_ namespace for their
> third-party macros.  Can you find the definition of that macro in a .m4
> file that gets included?  That's probably the place that's creating the
> bogus command line.

Thanks.  Note that I did find a workaround, which is to set
LIBS=-lncursesw.

AC_CHECK_CURSES calls AC_CHECK_CURSES_COMPILE, which is the step that
fails.  I've included it below.  The key step seems to be that it calls
AC_LINK_IFELSE, with the curses libs (-lncursesw) appended to LDFLAGS.

dnl
dnl check if the curses header we found, works
dnl
AC_DEFUN([AC_CHECK_CURSES_COMPILE], [

dnl save CFLAGS and LDFLAGS and set new ones
CFLAGS_OLD=$CFLAGS
CFLAGS="$CFLAGS $curses_includes"
LDFLAGS_OLD=$LDFLAGS
LDFLAGS="$LDFLAGS $curses_libs"

dnl do the compile test
AC_MSG_CHECKING([if curses is usable])
AC_LINK_IFELSE([
AC_LANG_PROGRAM(
[[
#include <$curses_h>
]],
[[
initscr();
printw("Hello World !!!");
refresh();
getch();
endwin();
return 0;
]]
)],
[
curses_usable=true
AC_MSG_RESULT([yes])
],
[
curses_usable=false
AC_MSG_RESULT([no])
]
)

dnl restore variables
CFLAGS=$CFLAGS_OLD
LDFLAGS=$LDFLAGS_OLD

])


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

[Christopher Faylor]

On Tue, May 13, 2014 at 01:00:24PM -0500, Steven Penny wrote:
>On Tue, May 13, 2014 at 10:04 AM, Christopher Faylor wrote:
>>Funny how you're saying "We" as if you are actually contributing
>>anything other than criticism.
>
>You want me to contribute?  Give me maintenance over one of the
>aforementioned packages.  Ball is in your court.

You want to contribute?  Stop wasting my time with attitude and learn
the rules.  "Ball is in your court" but I'm not holding my breath for
you to do anything other than kvetch.

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

Re: Update CoreUtils

[Christian Franke]

Eric Blake wrote:

On 05/11/2014 10:42 AM, Steven Penny wrote:

Can we get an update? I can create a build if needed.

I haven't relinquished maintainership of this package yet.  It's still
on my list of things to build, when I get a moment (although free time
has been a bit sparse as of late with the birth of my daughter last month).



Please note that a new x86 coreutils package should not install 
'hostname' and will require a synchronized upload of the x86 hostname 
package. The x86_64 distro already contains a hostname-less coreutils 
and hostname package.


https://sourceware.org/ml/cygwin-apps/2013-04/msg00103.html
https://sourceware.org/ml/cygwin-apps/2013-08/msg00107.html

The download URL from above mail is no longer valid (dyn.com stopped the 
free accounts).

New:

wget -e robots=off -np -nH --cut-dirs=1 -R'index.html*' -r \
http://chrfranke.no-ip.org/cygwin/x86/release/hostname

Christian


--
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: pinfo configure problem - configure.ac (0/1)

[Eric Blake]

On 05/13/2014 01:19 PM, Andrew Schulman wrote:

> 
> AC_CHECK_CURSES calls AC_CHECK_CURSES_COMPILE, which is the step that
> fails.  I've included it below.  The key step seems to be that it calls
> AC_LINK_IFELSE, with the curses libs (-lncursesw) appended to LDFLAGS.

That's a bug in AC_CHECK_CURSES_COMPILE, and should be reported to
whoever wrote that macro.  The autoconf manual says that LDFLAGS is for
-L options, while LIBS is for -l options.

> 
> dnl
> dnl check if the curses header we found, works
> dnl
> AC_DEFUN([AC_CHECK_CURSES_COMPILE], [
> 
> dnl save CFLAGS and LDFLAGS and set new ones
> CFLAGS_OLD=$CFLAGS
> CFLAGS="$CFLAGS $curses_includes"
> LDFLAGS_OLD=$LDFLAGS
> LDFLAGS="$LDFLAGS $curses_libs"

and this is a blatant case of using the wrong env-var for library
probing.  s/LDFLAGS/LIBS/ on these lines, before running autoreconf, and
that should fix it without you manually having to pass LIBS= at the
configure command line.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Update CoreUtils

[Steven Penny]

On Tue, May 13, 2014 at 1:36 PM, Chris J. Breisch wrote:
> Of course, if you haven't yet successfully built the version of the package
> you want to maintain, haven't applied the necessary Cygwin patches, and
> haven't gotten it to successfully work on your machine, then it's a bit
> ludicrous to expect someone to name you the maintainer of said package. You
> haven't shown any evidence of your ability to perform in that capacity.

# Bash
Yes, I have built up to date Bash, this would be my pick if I am allowed
maintainer as I feel it is an important package that should be up to date.

# Git
I have built up to date Git as well, but between Adam Dinwoodie build and
CygwinPorts build Git is "good enough" for now

# CoreUtils
I think I tried and failed to built this a year ago, lately I wanted an up to
date version of "dd" for the "skip_bytes" option, but I dont really need that
now, so it is lower priority
http://unix.stackexchange.com/a/121798

# apt-cyg
I just to add for Christopher Faylor and others that I maintain "apt-cyg" a
Cygwin package manager.
http://github.com/transcode-open/apt-cyg
Granted it is not an official package such as Bash, but it is something.

--
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: pinfo configure problem - configure.ac (0/1)

[Andrew Schulman]

> On 05/13/2014 01:19 PM, Andrew Schulman wrote:
> 
> > 
> > AC_CHECK_CURSES calls AC_CHECK_CURSES_COMPILE, which is the step that
> > fails.  I've included it below.  The key step seems to be that it calls
> > AC_LINK_IFELSE, with the curses libs (-lncursesw) appended to LDFLAGS.
> 
> That's a bug in AC_CHECK_CURSES_COMPILE, and should be reported to
> whoever wrote that macro.  The autoconf manual says that LDFLAGS is for
> -L options, while LIBS is for -l options.

OK.  I think the author of pinfo is long gone, but I'll submit a patch
upstream in case someone is interested.

> > 
> > dnl
> > dnl check if the curses header we found, works
> > dnl
> > AC_DEFUN([AC_CHECK_CURSES_COMPILE], [
> > 
> > dnl save CFLAGS and LDFLAGS and set new ones
> > CFLAGS_OLD=$CFLAGS
> > CFLAGS="$CFLAGS $curses_includes"
> > LDFLAGS_OLD=$LDFLAGS
> > LDFLAGS="$LDFLAGS $curses_libs"
> 
> and this is a blatant case of using the wrong env-var for library
> probing.  s/LDFLAGS/LIBS/ on these lines, before running autoreconf, and
> that should fix it without you manually having to pass LIBS= at the
> configure command line.

Sounds good.  Thanks again.
Andrew


--
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: More testing needed: New passwd/group AD/SAM integration

[Henry S. Thompson]

Corinna Vinschen writes:

> On May 13 18:29, Henry S. Thompson wrote:

>> Glitch (also true for x86 1.7.29-2):
>>   id returns effectively immediately for all users and non-users _except_:
>>> time id Administrators
>> uid=544(+Administrators) gid=544(+Administrators)
>> groups=11(+Authenticated Users),544(+Administrators)
>> 
>> real0m2.296s
>> user0m0.015s
>> sys 0m0.015s
>
> This shouldn't happen as long as we still have the "+" prepended to
> BUILTIN accounts(*).  And, as a matter of fact, I can't reproduce this
> with the latest from CVS (== the snapshot you're testing).  Did you exit
> your shell and restart it after creating the /etc/nsswitch.conf file as
> described in my preliminary documentation?

Yes, and I just re-did that, and I'm still getting the delay.  You did
notice that it's the plural version (Administrator_s_) that has the
delay -- Administrator (no 's') is just as fast as all the others.

Adding the '+' doesn't change the behaviour.

Ah, it occured to me to do an strace, and I found the culprit, I
think:

   19  392152 [main] id 16856 stat_worker: 0 = (\??\C:\C64\dev,0x1802C2940)
   26  392178 [main] id 16856 fstat64: 0 = fstat(1, 0x23A4F0)
   30  392208 [main] id 16856 isatty: 1 = isatty(1)
 1085  393293 [main] id 16856 pwdgrp::fetch_account_from_windows: line: 
<+Administrators:*:544:544:,S-1-5-32-544:/:/sbin/nologin>
2253178 2646471 [main] id 16856 seterrno_from_win_error: 
/home/cygnus/vinschen/mknetrel/src/cygwin-snapshot-20140513-1/winsup/cygwin/sec_auth.cc:244
 windows error 1355
  187 2646658 [main] id 16856 geterrno_from_win_error: unknown windows
error 1355, setting errno to 13

Does that help?

> (*) I'd be grateful for input to the questions I asked in my OP, too.

Sorry, I am just a Un*x guy trying to live on a Windows box, I have
nothing like the necessary Windows sysadmin background to have an
opinion.  I thought I would try your snapshots precisely _because_ I
understand almost nothing about all this -- I followed the 'mkpasswd'
instructions 8 years ago, and never touched things after that, and I
was just trying to help by seeing if there was anything a trial by a
naive user could uncover before things got fully released.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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: Emacs-w32... crashing problem

[Zdzislaw Meglicki]

Ken Brown writeth:

> Please describe the crash in more detail. 
> What were you doing when it happened?  Did 
> the window just disappear, or did you get 
> a dialogue box asking if you want to attach 
> a debugger?  Did you get any messages in the 
> terminal that emacs was started from?  Is 
> there a stackdump file? 

The window just disappeared. There was no dialogue
box that would let me attach gdb to the process.
I did not run it under "-Q" at the time, and I do 
not have a stackdump file (I deleted it).

I will keep an eye on this and if it crashes
again, hopefully letting me attach gdb, I'll 
post a backtrace and the stackdump file, if you'd
like to have a look at it.

Since emacs-w32 is so much better now, it may very
well take days before the next such event!

(greetings to-all)

Gustav Meglicki,
Indiana University

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

wget-1.15-1 vx wget-1.13-4, LANG and cron

[First Last]

I had trouble when I updated to wget-1.15-1.

I have a cron script that grabs a camera picture using
wget.  It failed with the new wget-1.15-1.

1) wget stderr has a line:
 Saving to: 'filename'

In wget-1.13.4-1 the delimiter before the filename is a
backtick and after the filename there is a single quote.
Also if the URL contains a  the filename has
a .

In wget-1.15-1 both delimiters are single quotes, at
least with LANG=C.  A space in the URL results in
a "%20" in the filename.


2) wget-1.15-1 is more sensitive to LANG etc.

When I ran the repaired script from bash it worked fine,
but under cron without setting LC_ALL or LANG the
wget-1.15-1 stderr output filename delimiters were wide
characters.

Setting
   export LC_ALL=C LC_CTYPE=C LANG=C
at the top of the cron script returned the single quote
delimiters.  Working fine now.

--
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: wget-1.15-1 vx wget-1.13-4, LANG and cron

[Eric Blake]

On 05/13/2014 03:49 PM, First Last wrote:
> I had trouble when I updated to wget-1.15-1.
> 
> I have a cron script that grabs a camera picture using
> wget.  It failed with the new wget-1.15-1.
> 
> 1) wget stderr has a line:
>  Saving to: 'filename'
> 
> In wget-1.13.4-1 the delimiter before the filename is a
> backtick and after the filename there is a single quote.

Yes, this was an intentional change upstream (many GNU projects have
been ditching `' quoting in favor of '' quoting, ever since GNU Coding
Standards were changed in light of modern typography looking ugly
compared to the way it looked 30 years ago when GNU first championed `').

> Also if the URL contains a  the filename has
> a .
> 
> In wget-1.15-1 both delimiters are single quotes, at
> least with LANG=C.  A space in the URL results in
> a "%20" in the filename.

Nothing here is cygwin-specific, as I just built wget from stock
upstream.  You'll get better response if you take your issues upstream,
since I suspect they are reproducible on Linux.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Update CoreUtils

[Christopher Faylor]

On Tue, May 13, 2014 at 03:29:40PM -0400, Christopher Faylor wrote:
>On Tue, May 13, 2014 at 01:00:24PM -0500, Steven Penny wrote:
>>On Tue, May 13, 2014 at 10:04 AM, Christopher Faylor wrote:
>>>Funny how you're saying "We" as if you are actually contributing
>>>anything other than criticism.
>>
>>You want me to contribute?  Give me maintenance over one of the
>>aforementioned packages.  Ball is in your court.
>
>You want to contribute?  Stop wasting my time with attitude and learn
>the rules.  "Ball is in your court" but I'm not holding my breath for
>you to do anything other than kvetch.

I've taken the ball back.  We don't need a new maintainer.

I've spoken with Eric.  I'm relieved that he still wants to stay on.

If his, or any other maintainer's update speed is not meeting
expectations then please, as suggested, just build the packages for your
own use.

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

Re: Update CoreUtils

[Steven Penny]

On Tue, May 13, 2014 at 5:51 PM, Christopher Faylor wrote:
> I've taken the ball back.  We don't need a new maintainer.

You clearly do, as I have shown. You are just choosing not to take one on. That
is your right of course. Let us continue the status quo.

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

[ANNOUNCEMENT] Updated: cppcheck-1.65-1

[Chris Sutcliffe]

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

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

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

For a list of changes see:

http://sourceforge.net/p/cppcheck/news/2014/05/cppcheck-165/

 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

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

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

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

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

-- 
Chris Sutcliffe
http://google.com/+ChrisSutcliffe

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

[Christopher Faylor]

On Tue, May 13, 2014 at 06:26:01PM -0500, Steven Penny wrote:
>On Tue, May 13, 2014 at 5:51 PM, Christopher Faylor wrote:
>> I've taken the ball back.  We don't need a new maintainer.
>
>You clearly do, as I have shown.  You are just choosing not to take one
>on.  That is your right of course.  Let us continue the status quo.
>
>>I've spoken with Eric.  I'm relieved that he still wants to stay on.
>>
>>If his, or any other maintainer's update speed is not meeting
>>expectations then please, as suggested, just build the packages for your
>>own use.

You aren't privy to my private conversation with Eric.  I'm clearly
satisfied that he will get around to updating his packages and I am
confident in his ability to follow through on this.

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

fdupes 1.51 exclude patch

[Brendan Brewster]

I have made available a patch for a new "exclude" option for fdupes
1.51 which I feel the Cygwin community, and others, may find useful.
So as not to duplicate the post, please see my post over on the fdupes
site: https://code.google.com/p/fdupes/issues/detail?id=36

Hoping this is found to be a useful feature!

-Brendan (br3wski3)

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

Emacs daemon exit with clients

[Arthur Tu]

I installed the latest 24.4 pretest version. I didn't do experiments
on v24.3 on cygwin.
$ emacs --version
GNU Emacs 24.3.90.1


Problem reproduced by these steps:

1. "emacs -q --daemon"to open a daemon
2. "emacsclient -c" to open a client
3. "Ctrl+x Ctrl+c"in client window to kill the client
4.  "emacsclient -c"  open another client successfully
5. "Ctrl+x Ctrl+c"in client window to kill the client again
6. "emacsclient -c"  the server is not there any more, client won't start

However, on debian(testing) with emacs24.3.1, I can perform step 2 and
step 3 as many times as I like. The server won't shutdown without
commands.

Also, I replace "emacsclient -c" with "emacsclient -c test" and
"Ctrl+x Ctrl+c" with "Ctrl+x #" respectively, and observe the same
behavior.

Is this a bug?

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