Re: [ANNOUNCEMENT] Updated: mintty 2.8.4

[Jim Garrison via cygwin]

On 2/5/2018 6:01 PM, Andrew Schulman wrote:
>> I have uploaded mintty 2.8.4 with the following changes:
> 
> I'll just take this opportunity to say thanks for maintaining this really
> central application in Cygwin. I use it every day to get my work done. Andrew

Same here.  mintty is the workhorse of Cygwin for many of us.

--
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: [ANNOUNCEMENT] Updated: mintty 2.8.4 {GOLDSTAR]

[Robert McBroom]

On 02/06/2018 12:35 AM, Brian Inglis wrote:

On 2018-02-05 21:45, Yaakov Selkowitz wrote:

On 2018-02-05 20:01, Andrew Schulman wrote:

I have uploaded mintty 2.8.4 with the following changes:

I'll just take this opportunity to say thanks for maintaining this really
central application in Cygwin. I use it every day to get my work done. Andrew

Then let's do something about it. :-D

He should be severely castigated for his prescient behaviour of adding new
features and fixing problems before we can report them. Should we pin an old
guy's Gold Watch on him, give him five Golden Rings^WStars so long after Xmas,
or do his mintty actions deserve the most extreme treatment, [Oh, no! *NOT*...]
the (Pink) Plush Hippo?


AVG ANTIVIRUS on Win 7 thinks mintty is a virus after update. Shame on them.


--
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: [ANNOUNCEMENT] Updated: mintty 2.8.4 {GOLDSTAR]

[Brian Inglis]

On 2018-02-05 21:45, Yaakov Selkowitz wrote:
> On 2018-02-05 20:01, Andrew Schulman wrote:
>>> I have uploaded mintty 2.8.4 with the following changes:
>>
>> I'll just take this opportunity to say thanks for maintaining this really
>> central application in Cygwin. I use it every day to get my work done. Andrew
> 
> Then let's do something about it. :-D

He should be severely castigated for his prescient behaviour of adding new
features and fixing problems before we can report them. Should we pin an old
guy's Gold Watch on him, give him five Golden Rings^WStars so long after Xmas,
or do his mintty actions deserve the most extreme treatment, [Oh, no! *NOT*...]
the (Pink) Plush Hippo?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: [ANNOUNCEMENT] Updated: mintty 2.8.4 {GOLDSTAR]

[Yaakov Selkowitz]

On 2018-02-05 20:01, Andrew Schulman wrote:
>> I have uploaded mintty 2.8.4 with the following changes:
> 
> I'll just take this opportunity to say thanks for maintaining this really
> central application in Cygwin. I use it every day to get my work done. Andrew

Then let's do something about it. :-D

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: mintty 2.8.4

[Andrew Schulman]

> I have uploaded mintty 2.8.4 with the following changes:

I'll just take this opportunity to say thanks for maintaining this really
central application in Cygwin. I use it every day to get my work done. 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

Updated: mintty 2.8.4

[Thomas Wolff]

I have uploaded mintty 2.8.4 with the following changes:

Character handling and rendering
  * Emoji support (mintty/wsltty#82, #600, ~#671, ~#430).
  * Fixed double-width handling within right-to-left text.

Window handling
  * Ctrl+Alt+mouse-click/drag moves the window (#729).
  * Apply Virtual Tab position catching also on Alt+F2 (#699).
  * Workaround for Windows failing to consider the taskbar properly 
when maximizing with no or frame-only border (#732).
  * Workaround for caption-less window exceeding borders (#733) on 
Windows 10.


Mouse handling
  * More selective suppression of mouse action on focus-click 
(mintty/wsltty#88, #717).

  * Fixed mouse function in search bar (#85), broken since 2.8.2 (#717).

Desktop integration
  * Support for taskbar "Tasks" list ("jump list") (#290).
  * Session launcher icons (#699).

Configuration
  * Options Emojis, EmojiPlacement to configure emojis style and display
  * Option TaskCommands to configure a taskbar icon task list ("jump 
list").

  * Limit tweaking of empty shortcut start dir to Start menu case (#737).

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

--
Thomas

[ANNOUNCEMENT] Updated: mintty 2.8.4

[Thomas Wolff]

I have uploaded mintty 2.8.4 with the following changes:

Character handling and rendering
  * Emoji support (mintty/wsltty#82, #600, ~#671, ~#430).
  * Fixed double-width handling within right-to-left text.

Window handling
  * Ctrl+Alt+mouse-click/drag moves the window (#729).
  * Apply Virtual Tab position catching also on Alt+F2 (#699).
  * Workaround for Windows failing to consider the taskbar properly 
when maximizing with no or frame-only border (#732).
  * Workaround for caption-less window exceeding borders (#733) on 
Windows 10.


Mouse handling
  * More selective suppression of mouse action on focus-click 
(mintty/wsltty#88, #717).

  * Fixed mouse function in search bar (#85), broken since 2.8.2 (#717).

Desktop integration
  * Support for taskbar "Tasks" list ("jump list") (#290).
  * Session launcher icons (#699).

Configuration
  * Options Emojis, EmojiPlacement to configure emojis style and display
  * Option TaskCommands to configure a taskbar icon task list ("jump 
list").

  * Limit tweaking of empty shortcut start dir to Start menu case (#737).

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

--
Thomas

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

Re: setup 2.886 release candidate - please test

[Achim Gratz]

Jon Turney writes:
>>> Which I can easily believe happens, due to the rather weird way that
>>> the data from a parser reduction is transferred into the package
>>> database.
>
> Can you test the attached patch, please?

Thanks, this works for the last package problem, although I can't
account for all the possible corner cases that may exist elsewhere.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: RPC clnt_create() adress already in use

[Corinna Vinschen]

On Feb  5 15:06, Corinna Vinschen wrote:
> On Feb  5 14:34, Corinna Vinschen wrote:
> > On Feb  5 12:26, Corinna Vinschen wrote:
> > > To reiterate the problem we observe:
> > > 
> > > - socket()
> > > - setsockopt (SO_REUSEADDR)
> > > - bind() succeeds
> > > - connect() fails with EADDRINUSE while socket is still in TIME_WAIT
> > > 
> > > using bindresvport in place of bind only marginally changes the
> > > situation, in particular if the second parameter is set and requests a
> > > port number != 0.  What happens in that case is that bindresvport calls
> > > bind with this port number and checks if bind returns EADDRINUSE.
> > > 
> > > Only then it tries to bind other port numbers in the reserved range.
> > > But we now know that bind will never return EADDINUSE if the SO_REUSEADDR
> > > socket option has been set.
> > > 
> > > Even assuming the process calls bindresvport(sock, NULL) we may end up
> > > returning a port number already in use if the process is the only Cygwin
> > > process on the system.  The reason is that Cygwin uses a round robin
> > > approach which relies on having a globally shared value called
> > > last_used_bindresvport.  If the process is the only Cygwin process on
> > > the system, this information is lost after exiting the process, so the
> > > next process will start with the same start port number and bind will
> > > again fail to notice the client with EADDRINUSE.
> > > 
> > > What potential solutions to this problem do we have?
> > > 
> > > - bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
> > >   sure bind fails.
> > 
> > Nope, no way.  Even enforcing SO_EXCLUSIVEADDRUSE results in the
> > second bind succeeding and the subsequent connect failing.  The
> > entire SO_REUSEADDR/SO_EXCLUSIVEADDRUSE semantics only works as
> > desired on the server side apparently
> > 
> > > - bindresvport could check every local address for being free prior
> > >   to calling bind.  However, there's a potential race here.
> > > 
> > > - DisconnectEx?  Never tried this Winsock extension but it might be
> > >   worth a shot.
> 
> I think I have a very simple solution for the scenario which calls
> bindresvport with port number.  Still looking for a solution for
> the second problem...

I've pushed a few patches and uploaded new developer snapshots to
https://cygwin.com/snapshots.  Please give them a try.


Thanks,
Corinna

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


signature.asc
Description: PGP signature

[newlib-cygwin] Cygwin: bindresvport: check correctness of address family

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=2f61f65601b842af126c64cf02a556425afa1709

commit 2f61f65601b842af126c64cf02a556425afa1709
Author: Corinna Vinschen 
Date:   Mon Feb 5 21:00:15 2018 +0100

Cygwin: bindresvport: check correctness of address family

Assuming the address parameter is non-NULL, the test in
cygwin_bindresvport_sa only tests if the address family is
supported at all, which is insufficient.

Check if the incoming address family matches the socket
address family and for being AF_INET in cygwin_bindresvport
since the latter doesn't support any other family.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/net.cc | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index b689012..cd43347 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
@@ -2482,6 +2482,11 @@ cygwin_bindresvport_sa (int fd, struct sockaddr *sa)
  memset (, 0, sizeof sst);
  sa->sa_family = fh->get_addr_family ();
}
+  else if (sa->sa_family != fh->get_addr_family ())
+   {
+ set_errno (EPFNOSUPPORT);
+ __leave;
+   }
 
   switch (sa->sa_family)
{
@@ -2529,10 +2534,14 @@ cygwin_bindresvport_sa (int fd, struct sockaddr *sa)
   return ret;
 }
 
-
 extern "C" int
 cygwin_bindresvport (int fd, struct sockaddr_in *sin)
 {
+  if (sin && sin->sin_family != AF_INET)
+{
+  set_errno (EAFNOSUPPORT);
+  return -1;
+}
   return cygwin_bindresvport_sa (fd, (struct sockaddr *) sin);
 }

[newlib-cygwin] Cygwin: bindresvport: Guard prototypes with __MISC_VISIBLE

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=b08e6690a676b9b58abbb676c9e9233f6f2f5c54

commit b08e6690a676b9b58abbb676c9e9233f6f2f5c54
Author: Corinna Vinschen 
Date:   Mon Feb 5 21:06:29 2018 +0100

Cygwin: bindresvport: Guard prototypes with __MISC_VISIBLE

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/include/netinet/in.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/winsup/cygwin/include/netinet/in.h 
b/winsup/cygwin/include/netinet/in.h
index da0265b..862e456 100644
--- a/winsup/cygwin/include/netinet/in.h
+++ b/winsup/cygwin/include/netinet/in.h
@@ -16,8 +16,10 @@ extern "C"
 {
 #endif
 
+#if __MISC_VISIBLE
 extern int bindresvport (int, struct sockaddr_in *);
 extern int bindresvport_sa (int, struct sockaddr *);
+#endif
 
 #ifdef __cplusplus
 };

[newlib-cygwin] Cygwin: bindresvport: Try hard to find unused port

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=e9ff2d697871eb78f7a4bc246868c855c052a859

commit e9ff2d697871eb78f7a4bc246868c855c052a859
Author: Corinna Vinschen 
Date:   Mon Feb 5 21:05:09 2018 +0100

Cygwin: bindresvport: Try hard to find unused port

Workaround the problem that bind doesn't fail with EADDRINUSE
if a socket with the same local address is still in TIME_WAIT.

Use IP Helper functions to check if such a socket exist and don't
even try this port, if so.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/autoload.cc |  2 ++
 winsup/cygwin/net.cc  | 90 ++-
 2 files changed, 84 insertions(+), 8 deletions(-)

diff --git a/winsup/cygwin/autoload.cc b/winsup/cygwin/autoload.cc
index 349f5e7..199821d 100644
--- a/winsup/cygwin/autoload.cc
+++ b/winsup/cygwin/autoload.cc
@@ -573,6 +573,8 @@ LoadDLLfunc (GetIfEntry, 4, iphlpapi)
 LoadDLLfunc (GetIpAddrTable, 12, iphlpapi)
 LoadDLLfunc (GetIpForwardTable, 12, iphlpapi)
 LoadDLLfunc (GetNetworkParams, 8, iphlpapi)
+LoadDLLfunc (GetTcpTable, 12, iphlpapi)
+LoadDLLfunc (GetTcp6Table, 12, iphlpapi)
 LoadDLLfunc (GetUdpTable, 12, iphlpapi)
 LoadDLLfunc (if_indextoname, 8, iphlpapi)
 LoadDLLfunc (if_nametoindex, 4, iphlpapi)
diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index cd43347..3fadb2b 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
@@ -2461,6 +2461,66 @@ if_freenameindex (struct if_nameindex *ptr)
 #define PORT_HIGH  (IPPORT_RESERVED - 1)
 #define NUM_PORTS  (PORT_HIGH - PORT_LOW + 1)
 
+/* port is in host byte order */
+static in_port_t
+next_free_port (sa_family_t family, in_port_t in_port)
+{
+  DWORD ret;
+  ULONG size = 0;
+  char *tab = NULL;
+  PMIB_TCPTABLE tab4 = NULL;
+  PMIB_TCP6TABLE tab6 = NULL;
+
+  /* Start testing with incoming port number. */
+  in_port_t tst_port = in_port;
+  in_port_t res_port = 0;
+  in_port_t tab_port;
+
+  do
+{
+  if (family == AF_INET)
+   ret = GetTcpTable ((PMIB_TCPTABLE) tab, , TRUE);
+  else
+   ret = GetTcp6Table ((PMIB_TCP6TABLE) tab, , TRUE);
+
+  if (ret == ERROR_INSUFFICIENT_BUFFER)
+   tab = (char *) realloc (tab, size);
+}
+  while (ret == ERROR_INSUFFICIENT_BUFFER);
+
+  tab4 = (PMIB_TCPTABLE) tab;
+  tab6 = (PMIB_TCP6TABLE) tab;
+
+  /* dwNumEntries has offset 0 in both structs. */
+  for (int idx = tab4->dwNumEntries - 1; idx >= 0; --idx)
+{
+  if (family == AF_INET)
+   tab_port = ntohs (tab4->table[idx].dwLocalPort);
+  else
+   tab_port = ntohs (tab6->table[idx].dwLocalPort);
+  /* Skip table entries with too high port number. */
+  if (tab_port > tst_port)
+   continue;
+  /* Is the current port number free? */
+  if (tab_port < tst_port)
+   {
+ res_port = tst_port;
+ break;
+   }
+  /* Decrement port and handle underflow of the reserved area. */
+  if (--tst_port < PORT_LOW)
+   {
+ tst_port = PORT_HIGH;
+ idx = tab4->dwNumEntries;
+   }
+  /* Check if we're round to the incoming port. */
+  if (tst_port == in_port)
+   break;
+}
+  free (tab);
+  return res_port;
+}
+
 extern "C" int
 cygwin_bindresvport_sa (int fd, struct sockaddr *sa)
 {
@@ -2469,6 +2529,7 @@ cygwin_bindresvport_sa (int fd, struct sockaddr *sa)
   struct sockaddr_in6 *sin6 = NULL;
   socklen_t salen;
   int ret = -1;
+  LONG port, next_port;
 
   __try
 {
@@ -2507,21 +2568,34 @@ cygwin_bindresvport_sa (int fd, struct sockaddr *sa)
 but that may lead to EADDRINUSE scenarios when calling bindresvport
 on the client side.  So we ignore any port value that the caller
 supplies, just like glibc. */
-  LONG myport;
 
+  /* Note that repeating this loop NUM_PORTS times is arbitrary.  The
+ job is mainly done by next_free_port() but it doesn't cover bound
+sockets.  And calling and checking GetTcpTable and subsequently
+calling bind is inevitably racy.  We have to continue if bind fails
+with EADDRINUSE. */
   for (int i = 0; i < NUM_PORTS; i++)
{
- while ((myport = InterlockedExchange (
+ while ((port = InterlockedExchange (
_shared->last_used_bindresvport, -1)) == -1)
yield ();
- if (myport == 0 || --myport < PORT_LOW)
-   myport = PORT_HIGH;
- InterlockedExchange (_shared->last_used_bindresvport, myport);
-
+ next_port = port;
+ if (next_port == 0 || --next_port < PORT_LOW)
+   next_port = PORT_HIGH;
+ /* Returns 0 if no reserved port is free. */
+ next_port = next_free_port (sa->sa_family, next_port);
+ if (next_port)
+   port = next_port;
+ InterlockedExchange (_shared->last_used_bindresvport, port);
+ if (next_port == 0)
+   {
+ set_errno (EADDRINUSE);
+  

[newlib-cygwin] Cygwin: Use SO_EXCLUSIVEADDRUSE

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=9dc34cea28d55c91a5b751530daf39a697cd1794

commit 9dc34cea28d55c91a5b751530daf39a697cd1794
Author: Corinna Vinschen 
Date:   Mon Feb 5 19:22:47 2018 +0100

Cygwin: Use SO_EXCLUSIVEADDRUSE

We're still using ~SO_REUSEADDR because SO_EXCLUSIVEADDRUSE wasn't
defined in Mingw.  But it is in Mingw-w64, so fix it.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/fhandler_socket.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc
index cc75b97..6eac689 100644
--- a/winsup/cygwin/fhandler_socket.cc
+++ b/winsup/cygwin/fhandler_socket.cc
@@ -1154,7 +1154,7 @@ fhandler_socket::bind (const struct sockaddr *name, int 
namelen)
 for a more detailed description. */
  int on = 1;
  int ret = ::setsockopt (get_socket (), SOL_SOCKET,
- ~(SO_REUSEADDR),
+ SO_EXCLUSIVEADDRUSE,
  (const char *) , sizeof on);
  debug_printf ("%d = setsockopt(SO_EXCLUSIVEADDRUSE), %E", ret);
}

[newlib-cygwin] Cygwin: bindresvport_sa: Ignore incoming port number

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=34f031982fbf9ce6eb23e47f7f0aeede175cd596

commit 34f031982fbf9ce6eb23e47f7f0aeede175cd596
Author: Corinna Vinschen 
Date:   Mon Feb 5 19:27:55 2018 +0100

Cygwin: bindresvport_sa: Ignore incoming port number

Ignore port number just like glibc, otherwise suffer EADDRINUSE
in subsequent connect calls.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/net.cc | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index 8969e7c..b689012 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
@@ -2467,7 +2467,6 @@ cygwin_bindresvport_sa (int fd, struct sockaddr *sa)
   struct sockaddr_storage sst;
   struct sockaddr_in *sin = NULL;
   struct sockaddr_in6 *sin6 = NULL;
-  in_port_t port;
   socklen_t salen;
   int ret = -1;
 
@@ -2489,27 +2488,20 @@ cygwin_bindresvport_sa (int fd, struct sockaddr *sa)
case AF_INET:
  salen = sizeof (struct sockaddr_in);
  sin = (struct sockaddr_in *) sa;
- port = sin->sin_port;
  break;
case AF_INET6:
  salen = sizeof (struct sockaddr_in6);
  sin6 = (struct sockaddr_in6 *) sa;
- port = sin6->sin6_port;
  break;
default:
  set_errno (EPFNOSUPPORT);
  __leave;
}
 
-  /* If a non-zero port number is given, try this first.  If that succeeds,
-or if the error message is serious, return. */
-  if (port)
-   {
- ret = fh->bind (sa, salen);
- if (!ret || (get_errno () != EADDRINUSE && get_errno () != EINVAL))
-   __leave;
-   }
-
+  /* Originally we tried to use the incoming port number first here,
+but that may lead to EADDRINUSE scenarios when calling bindresvport
+on the client side.  So we ignore any port value that the caller
+supplies, just like glibc. */
   LONG myport;
 
   for (int i = 0; i < NUM_PORTS; i++)

Re: Installing new openssl 1.1.0 in Cygwin

[Achim Gratz]

Annie writes:
> I run into a problem after installing the brand new openssl 1.1.0 under
> CygWin. The package available from the cygwin package manager,
> installing version 1.0.0n, worked fine.

Take the cygport file from that package, change the version and use that
to build.  You may have to refresh patches if there are any.


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

SD adaptation for Waldorf microQ V2.22R2:
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: cpan broken ???

[Achim Gratz]

Pavel Fedin writes:
>  Neither anything called "yaml" is listed in setup.exe

Well, I have

perl-CPAN-Meta-YAML
perl-Test-YAML
perl-YAML
perl-YAML-LibYAML
perl-YAML-Tiny

in setup.


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

SD adaptation for Waldorf microQ V2.22R2:
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: cpan broken ???

[Achim Gratz]

Pavel Fedin writes:
>  I am trying to install a Perl module via CPAN and it fails:

You apparently didn't ask cpan to install prerequisites.  Note that you
should not install via CPAN if any of those modules are available in
Cygwin unless you really know what you are doing.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
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 2.763 32bit SSHD public key auth. failure on Windows Server 2016 R2 64bit

[Achim Gratz]

Aliaksei Hladkikh writes:
> Can't connect to Cygwin SSHD using public key set up, but same Cygwin 
> configuration/OS/client
> works with Cygwin 2.763 32bit on Windows Server 2008 R2 64bit.
> See var/log/messages extracts.
>
> Seems to be connected with SeTcbPrivilege problem because of 
> "fatal: seteuid 1049698: Operation not permitted" log record, but ALL 
> existing Local Policy privileges were granted
> to dsm user under which Windows service runs or Administrators group where 
> dsm is a member,
> gpupdate executed and service restarted.

FWIW, I think I am seeing the same problem on Windows Server 2012 R2
ever since that came out.  I think this is some security feature as the
same thing happily works on non-server Windows of all versions I have
access to, possibly controlled by a group policy, although I have not
found anyone who seems to know about it.  But it does work for other
people in other environments, so there must be some setting somewhere
that prevents it.

My current work-around is to run sshd as the user that logs in (in may
case it's always the same user) so it doesn't have to switch SID.

> Going to try x64 Cygwin, but it's scary to change that Server 2016 R2.

You can install both Cygwin versions in parallel, just don't re-create
the ssh user when setting up sshd.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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: cpan broken ???

[Jostein Berntsen]

On 05.02.18,18:26, Pavel Fedin wrote:
> > -Original Message-
> > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
> > Csaba Raduly
> > Sent: Monday, February 05, 2018 6:00 PM
> > To: cygwin list 
> > Subject: Re: cpan broken ???
> > 
> > On Mon, Feb 5, 2018 at 3:45 PM, Jostein Berntsen wrote:
> > > On 05.02.18,16:59, Pavel Fedin wrote:
> > >>  I am trying to install a Perl module via CPAN and it fails:
> > >> --- cut ---
> > ...
> > >> Warning: prerequisite Test::Warn 0 not found.
> > >> Could not load PERL_YAML_BACKEND 'YAML'
> > >>  at /usr/share/perl5/5.26/CPAN/Meta.pm line 622.
> > >> Warning: No success on command[/usr/bin/perl Makefile.PL]
> > >>   YANICK/Parallel-ForkManager-1.19.tar.gz
> > >>   /usr/bin/perl Makefile.PL -- NOT OK
> > >>
> > >> --- cut ---
> > >>  I've just updated; the system is x86-64. How to fix this?
> > >>
> > >
> > > You can try "sudo cpan install YAML" first on the command line. Also
> > > check that you have 'make' installed.
> [p.fedin] 
> 
> sudo?? On Cygwin???
> 

Sorry, that should be:

"cpan install YAML" in cygwin.


Jostein



--
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: Installing new openssl 1.1.0 in Cygwin

[Andrey Repin]

Greetings, Annie!

> Hallo,
> I run into a problem after installing the brand new openssl 1.1.0 under
> CygWin. The package available from the cygwin package manager,
> installing version 1.0.0n, worked fine.
> But installing the source file from
> https://www.openssl.org/source/openssl-1.1.0g.tar.gz
> with (./config; make; make install; openssl version)
> ends with no output at all.

> The problem was solved after setting the excute permissions
>  chmod a+rx cygcrypto-1.1.dll cygssl-1.1.dll
> in the default directory /usr/local/bin.

> Is this a CygWin or an OpenSSL issue?

Neither, it's a Windows issue. Windows libraries are executables.


-- 
With best regards,
Andrey Repin
Monday, February 5, 2018 20:50:05

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: cpan broken ???

[Pavel Fedin]

 Hello!

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
> Csaba Raduly
> Sent: Monday, February 05, 2018 6:00 PM
> To: cygwin list 
> Subject: Re: cpan broken ???
> 
> On Mon, Feb 5, 2018 at 3:45 PM, Jostein Berntsen wrote:
> > On 05.02.18,16:59, Pavel Fedin wrote:
> >>  I am trying to install a Perl module via CPAN and it fails:
> >> --- cut ---
> ...
> >> Warning: prerequisite Test::Warn 0 not found.
> >> Could not load PERL_YAML_BACKEND 'YAML'
> >>  at /usr/share/perl5/5.26/CPAN/Meta.pm line 622.
> >> Warning: No success on command[/usr/bin/perl Makefile.PL]
> >>   YANICK/Parallel-ForkManager-1.19.tar.gz
> >>   /usr/bin/perl Makefile.PL -- NOT OK
> >>
> >> --- cut ---
> >>  I've just updated; the system is x86-64. How to fix this?
> >>
> >
> > You can try "sudo cpan install YAML" first on the command line. Also
> > check that you have 'make' installed.
[p.fedin] 

sudo?? On Cygwin???

> >
> 
> It says
> /usr/bin/perl Makefile.PL -- NOT OK
> 
> I believe 'make' was not run at all. Maybe something (either the
> package or CPAN itself) needs YAML.
[p.fedin] 

--- cut ---
$ cpan install YAML
CPAN: Storable loaded ok (v2.62)
Reading '/home/p.fedin/.cpan/Metadata'
  Database was generated on Mon, 05 Feb 2018 12:17:02 GMT
Running install for module 'YAML'
CPAN: Digest::SHA loaded ok (v6.01)
CPAN: Compress::Zlib loaded ok (v2.074)
Checksum for 
/home/p.fedin/.cpan/sources/authors/id/T/TI/TINITA/YAML-1.24.tar.gz ok
'YAML' not installed, will not store persistent state
CPAN: CPAN::Meta::Requirements loaded ok (v2.140)
CPAN: Parse::CPAN::Meta loaded ok (v2.150010)
CPAN: CPAN::Meta loaded ok (v2.150010)
The content of '/home/p.fedin/.cpan/build/YAML-1.24-3/META.json' is not a HASH 
reference. Cannot use it.
Configuring T/TI/TINITA/YAML-1.24.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Warning: prerequisite Test::YAML 1.05 not found.
Could not load PERL_YAML_BACKEND 'YAML'
 at /usr/share/perl5/5.26/CPAN/Meta.pm line 622.
Warning: No success on command[/usr/bin/perl Makefile.PL]
  TINITA/YAML-1.24.tar.gz
  /usr/bin/perl Makefile.PL -- NOT OK
--- cut ---
 Neither anything called "yaml" is listed in setup.exe


Kind regards,
Pavel Fedin
Senior 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: cpan broken ???

[Csaba Raduly]

On Mon, Feb 5, 2018 at 3:45 PM, Jostein Berntsen wrote:
> On 05.02.18,16:59, Pavel Fedin wrote:
>>  I am trying to install a Perl module via CPAN and it fails:
>> --- cut ---
...
>> Warning: prerequisite Test::Warn 0 not found.
>> Could not load PERL_YAML_BACKEND 'YAML'
>>  at /usr/share/perl5/5.26/CPAN/Meta.pm line 622.
>> Warning: No success on command[/usr/bin/perl Makefile.PL]
>>   YANICK/Parallel-ForkManager-1.19.tar.gz
>>   /usr/bin/perl Makefile.PL -- NOT OK
>>
>> --- cut ---
>>  I've just updated; the system is x86-64. How to fix this?
>>
>
> You can try "sudo cpan install YAML" first on the command line. Also
> check that you have 'make' installed.
>

It says
/usr/bin/perl Makefile.PL -- NOT OK

I believe 'make' was not run at all. Maybe something (either the
package or CPAN itself) needs YAML.

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

Re: RPC clnt_create() adress already in use

[PAULUS, Raimund, TI-ABN]

Hi Mark and Corinna,

i use my program in a production environment running 24 hours a day. Therefore 
it must be as stable as possible and I have different test scenarios. Normally 
the program is the only Cygwin program running at this time. It is running only 
for a short time for data exchange with a linux server. Subsequently an other 
program (not Cygwin) does the rest of the job with the transferred data. After 
some seconds (or minutes) the other program starts my program again for data 
exchange. My program is started by a VB-script (windows script host) or a DOS 
shell script but never in the bash.

Raimund


-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
Mark Geisert
Gesendet: Montag, 5. Februar 2018 11:29
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use

PAULUS, Raimund, TI-ABN wrote:
> Hello Mark,
>
> unfortunately i must correct my statement from Friday.
> The program works, but only if the connections to the server are established 
> in a loop inside the program.
> If the program ends and you start it anew, a connection is not possible for a 
> long time. you have to wait before you can establish a new connection.

That isn't what I saw in my testing.  At one point I had three copies of your 
test_rpc.exe running simultaneously and they all were able to establish 20 
connections and the allocated port numbers were interleaved.

Are you running your test programs directly from a Windows Command Prompt or 
from one of the Cygwin shells like bash?

> Actually only our approaches in the original bindresvport() seem to work for 
> all cases.
> You have proposed to use the static variable usecount in 
> bindresvport(). But how is the value of the variable handled if the program 
> starts anew. Is it possible to get an used portnumber and run in EADDRINUSE?

You must understand that none of the libtirpc approaches is guaranteed to work 
100% of the time.  The problem is that without a lot of extra work we can't get 
libtirpc to "know" which ports to avoid.  Our approaches are just different 
strategies for avoiding a port collision, with different chances of working.

Libtirpc's original approach is essentially to have a range of port numbers it 
will try, 600 thru 1023, start with one of them randomly (based on the pid of 
the calling process), increment by one on each use.  This won't work when 
you're calling bindresvport() multiple times within one program because it 
starts from the same port number each time.

My "usecount" modification changes things so we start with the same port number 
as before but increment each time we bindresvport().  Good for one program 
making multiple calls and sort of good for multiple programs at same time.. but 
there is a chance of port number collision between the programs.

Using Cygwin's bindresvport() is the best solution because Cygwin keeps track 
of the last port number it has allocated *to any Cygwin program*.  This is the 
only approach that can deal with multiple programs and multiple calls in one 
program. 
  So we need to nail down why it doesn't seem to work for you.

..mark

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


--
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: cpan broken ???

[Jostein Berntsen]

On 05.02.18,16:59, Pavel Fedin wrote:
>  I am trying to install a Perl module via CPAN and it fails:
> --- cut ---
> $ cpan install Parallel::ForkManager
> CPAN: Storable loaded ok (v2.62)
> Reading '/home/p.fedin/.cpan/Metadata'
>   Database was generated on Mon, 05 Feb 2018 12:17:02 GMT
> Running install for module 'Parallel::ForkManager'
> CPAN: Digest::SHA loaded ok (v6.01)
> CPAN: Compress::Zlib loaded ok (v2.074)
> Checksum for 
> /home/p.fedin/.cpan/sources/authors/id/Y/YA/YANICK/Parallel-ForkManager-1.19.tar.gz
>  ok
> 'YAML' not installed, will not store persistent state
> CPAN: CPAN::Meta::Requirements loaded ok (v2.140)
> CPAN: Parse::CPAN::Meta loaded ok (v2.150010)
> CPAN: CPAN::Meta loaded ok (v2.150010)
> The content of 
> '/home/p.fedin/.cpan/build/Parallel-ForkManager-1.19-6/META.json' is not a 
> HASH reference. Cannot use it.
> Configuring Y/YA/YANICK/Parallel-ForkManager-1.19.tar.gz with Makefile.PL
> Checking if your kit is complete...
> Looks good
> Warning: prerequisite Test::Warn 0 not found.
> Could not load PERL_YAML_BACKEND 'YAML'
>  at /usr/share/perl5/5.26/CPAN/Meta.pm line 622.
> Warning: No success on command[/usr/bin/perl Makefile.PL]
>   YANICK/Parallel-ForkManager-1.19.tar.gz
>   /usr/bin/perl Makefile.PL -- NOT OK
> 
> --- cut ---
>  I've just updated; the system is x86-64. How to fix this?
> 

You can try "sudo cpan install YAML" first on the command line. Also 
check that you have 'make' installed. 

Jostein

--
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: Searching full, portable Cygwin package for windows and NOT just the installer

[Buchbinder, Barry (NIH/NIAID) [E]]

David Allsopp sent the following at Saturday, February 03, 2018 3:16 AM
>The setup program includes a "Download" option which allows you to
>save the entire package repository locally, which you can use in
>future.

To be explicit:  You can download as David points out, scan the
downloaded packages with your AV, and then install.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


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

Re: Why does /etc/setup/installed.db list tar.bz2 even if tar.xz

[Jon Turney]

On 04/02/2018 11:09, Marco Atzeri wrote:

On 04/02/2018 03:19, Steven Penny wrote:

On Sat, 12 Oct 2013 23:48:00,  wrote:

The installed.db seems to always list packages as being tar.bz2 even
when they are tar.xz.

Is there any reason for this? Or is it a bug?


http://cygwin.com/ml/cygwin/2013-10/msg00170.html

This is an old thread, but it appears this issue was never answered and
persists. For example, /etc/setup/installed.db has entries like this:



it is an historical shortcut in the setup code.
".tar.bz2" is just added to package name and version,
it is not really derived from the package file


$ grep -H  "tar.bz2" package_db.cc
package_db.cc:  pkgm.name + "-" + 
std::string(pkgm.installed.Canonical_version()) + ".tar.bz2 " +



When we moved from bz2 to xz, that shortcut was not changed.


More, it was kept like that for backwards compatibility.

Specifically, cygcheck is a consumer of this file, and until [1], didn't 
know of the existence of other compression types.


The comment [2] above the source line mentioned describes the format of 
installed.db.


[1] 
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=9a2f0cff8fc6706d16356552b86c1e0c8ba35ddf


[2] 
https://sourceware.org/git/gitweb.cgi?p=cygwin-setup.git;a=blob;f=package_db.cc;h=730cb78c3d3ce33907cdd9d3a0de3857694fdc37;hb=HEAD#l292


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

Installing new openssl 1.1.0 in Cygwin

[Annie]

Hallo,
I run into a problem after installing the brand new openssl 1.1.0 under
CygWin. The package available from the cygwin package manager,
installing version 1.0.0n, worked fine.
But installing the source file from
https://www.openssl.org/source/openssl-1.1.0g.tar.gz
with (./config; make; make install; openssl version)
ends with no output at all.

The problem was solved after setting the excute permissions
 chmod a+rx cygcrypto-1.1.dll cygssl-1.1.dll
in the default directory /usr/local/bin.

Is this a CygWin or an OpenSSL issue?

Kind regards,
/Ann.

--
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: RPC clnt_create() adress already in use

[Corinna Vinschen]

On Feb  5 14:34, Corinna Vinschen wrote:
> On Feb  5 12:26, Corinna Vinschen wrote:
> > To reiterate the problem we observe:
> > 
> > - socket()
> > - setsockopt (SO_REUSEADDR)
> > - bind() succeeds
> > - connect() fails with EADDRINUSE while socket is still in TIME_WAIT
> > 
> > using bindresvport in place of bind only marginally changes the
> > situation, in particular if the second parameter is set and requests a
> > port number != 0.  What happens in that case is that bindresvport calls
> > bind with this port number and checks if bind returns EADDRINUSE.
> > 
> > Only then it tries to bind other port numbers in the reserved range.
> > But we now know that bind will never return EADDINUSE if the SO_REUSEADDR
> > socket option has been set.
> > 
> > Even assuming the process calls bindresvport(sock, NULL) we may end up
> > returning a port number already in use if the process is the only Cygwin
> > process on the system.  The reason is that Cygwin uses a round robin
> > approach which relies on having a globally shared value called
> > last_used_bindresvport.  If the process is the only Cygwin process on
> > the system, this information is lost after exiting the process, so the
> > next process will start with the same start port number and bind will
> > again fail to notice the client with EADDRINUSE.
> > 
> > What potential solutions to this problem do we have?
> > 
> > - bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
> >   sure bind fails.
> 
> Nope, no way.  Even enforcing SO_EXCLUSIVEADDRUSE results in the
> second bind succeeding and the subsequent connect failing.  The
> entire SO_REUSEADDR/SO_EXCLUSIVEADDRUSE semantics only works as
> desired on the server side apparently
> 
> > - bindresvport could check every local address for being free prior
> >   to calling bind.  However, there's a potential race here.
> > 
> > - DisconnectEx?  Never tried this Winsock extension but it might be
> >   worth a shot.

I think I have a very simple solution for the scenario which calls
bindresvport with port number.  Still looking for a solution for
the second problem...


Corinna

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


signature.asc
Description: PGP signature

cpan broken ???

[Pavel Fedin]

 Hello everyone!

 I am trying to install a Perl module via CPAN and it fails:
--- cut ---
$ cpan install Parallel::ForkManager
CPAN: Storable loaded ok (v2.62)
Reading '/home/p.fedin/.cpan/Metadata'
  Database was generated on Mon, 05 Feb 2018 12:17:02 GMT
Running install for module 'Parallel::ForkManager'
CPAN: Digest::SHA loaded ok (v6.01)
CPAN: Compress::Zlib loaded ok (v2.074)
Checksum for 
/home/p.fedin/.cpan/sources/authors/id/Y/YA/YANICK/Parallel-ForkManager-1.19.tar.gz
 ok
'YAML' not installed, will not store persistent state
CPAN: CPAN::Meta::Requirements loaded ok (v2.140)
CPAN: Parse::CPAN::Meta loaded ok (v2.150010)
CPAN: CPAN::Meta loaded ok (v2.150010)
The content of 
'/home/p.fedin/.cpan/build/Parallel-ForkManager-1.19-6/META.json' is not a HASH 
reference. Cannot use it.
Configuring Y/YA/YANICK/Parallel-ForkManager-1.19.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Warning: prerequisite Test::Warn 0 not found.
Could not load PERL_YAML_BACKEND 'YAML'
 at /usr/share/perl5/5.26/CPAN/Meta.pm line 622.
Warning: No success on command[/usr/bin/perl Makefile.PL]
  YANICK/Parallel-ForkManager-1.19.tar.gz
  /usr/bin/perl Makefile.PL -- NOT OK

--- cut ---
 I've just updated; the system is x86-64. How to fix this?

Kind regards,
Pavel Fedin
Senior 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: RPC clnt_create() adress already in use

[Corinna Vinschen]

On Feb  5 12:26, Corinna Vinschen wrote:
> On Feb  5 02:29, Mark Geisert wrote:
> > Using Cygwin's bindresvport() is the best solution because Cygwin keeps
> > track of the last port number it has allocated *to any Cygwin program*.
> > This is the only approach that can deal with multiple programs and multiple
> > calls in one program.  So we need to nail down why it doesn't seem to work
> > for you.
> 
> Apart from all the above, there may still be a problem in the given scenario.
> 
> To reiterate the problem we observe:
> 
> - socket()
> - setsockopt (SO_REUSEADDR)
> - bind() succeeds
> - connect() fails with EADDRINUSE while socket is still in TIME_WAIT
> 
> using bindresvport in place of bind only marginally changes the
> situation, in particular if the second parameter is set and requests a
> port number != 0.  What happens in that case is that bindresvport calls
> bind with this port number and checks if bind returns EADDRINUSE.
> 
> Only then it tries to bind other port numbers in the reserved range.
> But we now know that bind will never return EADDINUSE if the SO_REUSEADDR
> socket option has been set.
> 
> Even assuming the process calls bindresvport(sock, NULL) we may end up
> returning a port number already in use if the process is the only Cygwin
> process on the system.  The reason is that Cygwin uses a round robin
> approach which relies on having a globally shared value called
> last_used_bindresvport.  If the process is the only Cygwin process on
> the system, this information is lost after exiting the process, so the
> next process will start with the same start port number and bind will
> again fail to notice the client with EADDRINUSE.
> 
> What potential solutions to this problem do we have?
> 
> - bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
>   sure bind fails.

Nope, no way.  Even enforcing SO_EXCLUSIVEADDRUSE results in the
second bind succeeding and the subsequent connect failing.  The
entire SO_REUSEADDR/SO_EXCLUSIVEADDRUSE semantics only works as
desired on the server side apparently

> - bindresvport could check every local address for being free prior
>   to calling bind.  However, there's a potential race here.
> 
> - DisconnectEx?  Never tried this Winsock extension but it might be
>   worth a shot.


Corinna

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


signature.asc
Description: PGP signature

Re: gawk: regression with unary plus

[Corinna Vinschen]

On Feb  5 13:05, Houder wrote:
> On Sun, 04 Feb 2018 14:59:30, Steven Penny wrote:
> > Previously conversions could be triggered by either adding zero (+0), unary
> > plus (+) or unary minus (-) [1]:
> [snip]
> 
> > However now conversion only happens with adding zero and unary minus:
> [snip]
> 
> > Does anyone know where this change was mentioned or why it was done?
> > 
> > [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
> 
> For those who are interested:
> 
> https://unix.stackexchange.com/questions/421904/regression-with-unary-plus
> (Regression with unary plus, by Steven Penny)
> 
> As suggested by Stéphane Chazelas in his response, the change in behaviour is
> problably not intentional.
> 
> Modifying (i.e. extend it) the '0p_unary_plus CASE' in interpret.h, restores
> the previous behaviour.
> 
> Henri

I forwarded this to the gawk devel ML.


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: gawk: regression with unary plus

[Houder]

On Sun, 04 Feb 2018 14:59:30, Steven Penny wrote:
> Previously conversions could be triggered by either adding zero (+0), unary
> plus (+) or unary minus (-) [1]:
[snip]

> However now conversion only happens with adding zero and unary minus:
[snip]

> Does anyone know where this change was mentioned or why it was done?
> 
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html

For those who are interested:

https://unix.stackexchange.com/questions/421904/regression-with-unary-plus
(Regression with unary plus, by Steven Penny)

As suggested by Stéphane Chazelas in his response, the change in behaviour is
problably not intentional.

Modifying (i.e. extend it) the '0p_unary_plus CASE' in interpret.h, restores
the previous behaviour.

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: RPC clnt_create() adress already in use

[Corinna Vinschen]

On Feb  5 02:29, Mark Geisert wrote:
> PAULUS, Raimund, TI-ABN wrote:
> > Hello Mark,
> > 
> > unfortunately i must correct my statement from Friday.
> > The program works, but only if the connections to the server are 
> > established in a loop inside the program.
> > If the program ends and you start it anew, a connection is not possible for 
> > a long time. you have to wait before you can establish a new connection.
> 
> That isn't what I saw in my testing.  At one point I had three copies of
> your test_rpc.exe running simultaneously and they all were able to establish
> 20 connections and the allocated port numbers were interleaved.
> 
> Are you running your test programs directly from a Windows Command Prompt or
> from one of the Cygwin shells like bash?
> 
> > Actually only our approaches in the original bindresvport() seem to work 
> > for all cases.
> > You have proposed to use the static variable usecount in bindresvport(). 
> > But how is the value of the variable handled if the program starts anew. Is 
> > it possible to get an used portnumber
> > and run in EADDRINUSE?
> 
> You must understand that none of the libtirpc approaches is guaranteed to
> work 100% of the time.  The problem is that without a lot of extra work we
> can't get libtirpc to "know" which ports to avoid.  Our approaches are just
> different strategies for avoiding a port collision, with different chances
> of working.
> 
> Libtirpc's original approach is essentially to have a range of port numbers
> it will try, 600 thru 1023, start with one of them randomly (based on the
> pid of the calling process), increment by one on each use.  This won't work
> when you're calling bindresvport() multiple times within one program because
> it starts from the same port number each time.
> 
> My "usecount" modification changes things so we start with the same port
> number as before but increment each time we bindresvport().  Good for one
> program making multiple calls and sort of good for multiple programs at same
> time.. but there is a chance of port number collision between the programs.
> 
> Using Cygwin's bindresvport() is the best solution because Cygwin keeps
> track of the last port number it has allocated *to any Cygwin program*.
> This is the only approach that can deal with multiple programs and multiple
> calls in one program.  So we need to nail down why it doesn't seem to work
> for you.

Apart from all the above, there may still be a problem in the given scenario.

To reiterate the problem we observe:

- socket()
- setsockopt (SO_REUSEADDR)
- bind() succeeds
- connect() fails with EADDRINUSE while socket is still in TIME_WAIT

using bindresvport in place of bind only marginally changes the
situation, in particular if the second parameter is set and requests a
port number != 0.  What happens in that case is that bindresvport calls
bind with this port number and checks if bind returns EADDRINUSE.

Only then it tries to bind other port numbers in the reserved range.
But we now know that bind will never return EADDINUSE if the SO_REUSEADDR
socket option has been set.

Even assuming the process calls bindresvport(sock, NULL) we may end up
returning a port number already in use if the process is the only Cygwin
process on the system.  The reason is that Cygwin uses a round robin
approach which relies on having a globally shared value called
last_used_bindresvport.  If the process is the only Cygwin process on
the system, this information is lost after exiting the process, so the
next process will start with the same start port number and bind will
again fail to notice the client with EADDRINUSE.

What potential solutions to this problem do we have?

- bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
  sure bind fails.

- bindresvport could check every local address for being free prior
  to calling bind.  However, there's a potential race here.

- DisconnectEx?  Never tried this Winsock extension but it might be
  worth a shot.


Corinna

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


signature.asc
Description: PGP signature

Re: RPC clnt_create() adress already in use

[Mark Geisert]

PAULUS, Raimund, TI-ABN wrote:

Hello Mark,

unfortunately i must correct my statement from Friday.
The program works, but only if the connections to the server are established in 
a loop inside the program.
If the program ends and you start it anew, a connection is not possible for a 
long time. you have to wait before you can establish a new connection.


That isn't what I saw in my testing.  At one point I had three copies of your 
test_rpc.exe running simultaneously and they all were able to establish 20 
connections and the allocated port numbers were interleaved.


Are you running your test programs directly from a Windows Command Prompt or 
from one of the Cygwin shells like bash?



Actually only our approaches in the original bindresvport() seem to work for 
all cases.
You have proposed to use the static variable usecount in bindresvport(). But 
how is the value of the variable handled if the program starts anew. Is it 
possible to get an used portnumber
and run in EADDRINUSE?


You must understand that none of the libtirpc approaches is guaranteed to work 
100% of the time.  The problem is that without a lot of extra work we can't get 
libtirpc to "know" which ports to avoid.  Our approaches are just different 
strategies for avoiding a port collision, with different chances of working.


Libtirpc's original approach is essentially to have a range of port numbers it 
will try, 600 thru 1023, start with one of them randomly (based on the pid of 
the calling process), increment by one on each use.  This won't work when you're 
calling bindresvport() multiple times within one program because it starts from 
the same port number each time.


My "usecount" modification changes things so we start with the same port number 
as before but increment each time we bindresvport().  Good for one program 
making multiple calls and sort of good for multiple programs at same time.. but 
there is a chance of port number collision between the programs.


Using Cygwin's bindresvport() is the best solution because Cygwin keeps track of 
the last port number it has allocated *to any Cygwin program*.  This is the only 
approach that can deal with multiple programs and multiple calls in one program. 
 So we need to nail down why it doesn't seem to work for you.


..mark

--
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: Cannot install built library to mingw sysroot

[Пётр Б .]

Nvm I found solution already:
http://cygwin.com/ml/cygwin/2010-04/msg00651.html

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

Cannot install built library to mingw sysroot

[Пётр Б .]

I have built and installed GraphicsMagick with this command:

$ ../configure '--host=x86_64-w64-mingw32' '--disable-shared'
--prefix=/usr/x86_64-w64-mingw32/sys-root/mingw CXXFLAGS="-flto
-ffat-lto-objects" && make && make install

Installation fails because apparently there is no permission to create
files in mingw sysroot:

$ mkdir /usr/x86_64-w64-mingw32/sys-root/mingw/share/whatever
mkdir: cannot create directory
‘/usr/x86_64-w64-mingw32/sys-root/mingw/share/whatever’: Permission
denied

What's the problem and how can I solve it in most straightforward way?

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

Re: [PATCH v2 0/3] catgets APIs, gencat tool

[Corinna Vinschen]

On Feb  2 16:10, Yaakov Selkowitz wrote:
> On 2018-01-19 13:26, Yaakov Selkowitz wrote:
> > On 2018-01-19 13:04, Corinna Vinschen wrote:
> >> Are you going to provide a catgets deprecation package?
> > 
> > Yes.
>  Done.

Thanks!


Corinna

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


signature.asc
Description: PGP signature

Re: RPC clnt_create() adress already in use

[PAULUS, Raimund, TI-ABN]

Hello Mark,

unfortunately i must correct my statement from Friday.
The program works, but only if the connections to the server are established in 
a loop inside the program.
If the program ends and you start it anew, a connection is not possible for a 
long time. you have to wait before you can establish a new connection.

Actually only our approaches in the original bindresvport() seem to work for 
all cases.
You have proposed to use the static variable usecount in bindresvport(). But 
how is the value of the variable handled if the program starts anew. Is it 
possible to get an used portnumber 
and run in EADDRINUSE?

Greetings
Raimund

-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
PAULUS, Raimund, TI-ABN
Gesendet: Freitag, 2. Februar 2018 13:58
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use

Hi Mark,

it works. Maybe it's the best solution for the problem.

Greetings

Raimund


-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
Mark Geisert
Gesendet: Freitag, 2. Februar 2018 09:11
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use

Mark Geisert wrote:
> Corinna Vinschen wrote:
>> On Jan 31 00:15, Mark Geisert wrote:
>>> PAULUS, Raimund, TI-ABN wrote:
 Hi Mark,

 in my email
 (https://sourceware.org/ml/cygwin/2017-12/msg00194.html) i described 2 
 approaches. I prefer  nr 1.
 Here the part of the source in bindresvport.c:
 [...]
> [...]
>>
>> I'm a bit puzzled here in terms of using your own bindresvport.  
>> Cygwin implements bindresvport{_sa} for quite some time, 2006 or earlier.
>
> Yeesh; I did not know that.  Thanks for pointing that out. So that 
> means there's another possible way to try solving the OP's issue: by 
> using Cygwin's
> bindresvport* in place of the one supplied with libtirpc.
>
> If we see the OP's issue with Cygwin's bindresvport*, I think it makes 
> more sense to patch libtirpc than to change Cygwin's bindresvport*.
> The crux of OP's issue is that libtirpc's code expects to see 
> EADDRINUSE errors from bind() whereas on Cygwin they aren't often seen until 
> you connect().
>
> I'll look into using Cygwin's bindresvport() in the next day or two.

My testing shows that OP's original issue goes away when libtirpc is compiled 
to use Cygwin's bindresvport() directly rather than using its own version of 
that function.

Raimund, could you try this newest possible solution?  Before the first 
#include in bindresvport.c, add the line
 #ifndef __CYGWIN__
and at the end of the file, add the line
 #endif
Then rebuild your libtirpc and your test programs linking against it, then run 
your tests.  If this proves to solve your original problem then I'll submit a 
patch of libtirpc to the Cygwin package maintainer.

Thank you,

..mark


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