Possible Cygwin setup regression with --prune-install

Hi, I have a use-case for Cygwin setup, which I admit will seem strange, whereby I want it to do an "Install" with no packages selected at all. ie., just setup a "skeleton" of a Cygwin install. I value it, because based my own experience with the Cygwin setup code, it seems to "bootstrap" the

Re: [ANNOUNCEMENT] TEST: fetchmail 6.4.0.rc3-1

Hello, on 2019/8/29 10:54, René Berber wrote: Check the sslcertpath parameter used by fetchmail, see if it points to the certificates (/etc/pki/tls/certs or /etc/ssl/certs). Also sslkey if there is one. The parameter(s) could/should be in ~/.fetchmailrc . Yes the certs files are there: $

Re: [ANNOUNCEMENT] TEST: fetchmail 6.4.0.rc3-1

On 8/28/2019 8:46 PM, Eliza wrote: > Hello, Hi, > on 2019/8/29 9:35, René Berber wrote: >> You probably have to (re)install (package) ca-certificates. >> >> Or, if you are using your own installed certificate, it may be installed >> in the wrong place (i.e. that causes the not found error seen

Re: [ANNOUNCEMENT] TEST: fetchmail 6.4.0.rc3-1

Hello, on 2019/8/29 9:35, René Berber wrote: You probably have to (re)install (package) ca-certificates. Or, if you are using your own installed certificate, it may be installed in the wrong place (i.e. that causes the not found error seen above, its either not installed, or not in the right

Re: [ANNOUNCEMENT] TEST: fetchmail 6.4.0.rc3-1

On 8/28/2019 8:15 PM, Eliza wrote: > I still got the error: > > unable to get local issuer certificate > fetchmail: Broken certification chain at: /C=US/O=DigiCert > Inc/OU=www.digicert.com/CN=GeoTrust RSA CA 2018 > fetchmail: This could mean that the server did not provide the > intermediate

Re: [ANNOUNCEMENT] TEST: fetchmail 6.4.0.rc3-1

Corinna, on 2019/8/28 20:49, Corinna Vinschen wrote: The following packages have been uploaded to the Cygwin distribution: * fetchmail-6.4.0.rc3-1 This is a test release for the upcoming fetchmail 6.4.0. I still got the error: unable to get local issuer certificate fetchmail: Broken

Re: fetchmail issue

on 2019/8/28 20:55, Corinna Vinschen wrote: The old fetchmail was not linked against openSSL and so was unable to handle pops/imaps. I've uploaded a test release of the upcoming new version of fetchmail, 6.4.0, based on the latest rc3:

Re: Bug report: Killing a native process may not actually kill it

On Wed, 28 Aug 2019 15:57:23, Quanah Gibson-Mount wrote: My original post contained a link to a patch allowing for Cygwin to correctly terminate native Windows processes. I understand it is not the position of the Cygwin project to deal with situation, so I think we can just let it drop. I

Re: socat error message

>Hi, >Using socat 2.0.0-b5, I got following error message: >1 [main] socat 5436 find_fast_cwd: WARNING: Couldn't compute FAT_CWD pointe= >r. Please report this problem to the public mailing list cyg...@cycwin.com<= >mailto:cyg...@cycwin.com> >Hence, I am reporting this. >This is on Windows 10

socat error message

Hi, Using socat 2.0.0-b5, I got following error message: 1 [main] socat 5436 find_fast_cwd: WARNING: Couldn't compute FAT_CWD pointer. Please report this problem to the public mailing list cyg...@cycwin.com Hence, I am reporting this. This is on Windows 10 64 bit

Re: Bug report: Killing a native process may not actually kill it

--On Wednesday, August 28, 2019 2:33 PM -0700 Kaz Kylheku <920-082-4...@kylheku.com> wrote: Cygwin can't introduce Unix-like shutdown mechanisms (like the handling a non-fatal signal) into non-Cygwin processes which have no concept of that. It makes no sense. My original post contained a

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Wed, 28 Aug 2019 08:33:05, Eric Blake wrote: > On 8/27/19 7:51 AM, Houder wrote: > > > > 64-@@ mkdir 'e:\' # creates subdirectory e: ! > > Had you typed: > > mkdir 'e:/' > > I would expect subdirectory ./e: to be created. But with 'e:\', that > is a DOS style path, so I would lean

Re: Bug report: Killing a native process may not actually kill it

On 2019-08-28 08:59, Quanah Gibson-Mount wrote: --On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen wrote: Not likely. Cygwin handles Ctrl-C by generating SIGINT. This only works reliably with Cygwin processes. There's $ /bin/kill -f to call the Win32 function

Re: Bug report: Killing a native process may not actually kill it

On Aug 28 08:59, Quanah Gibson-Mount wrote: > > > --On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen > wrote: > > > Not likely. Cygwin handles Ctrl-C by generating SIGINT. This only > > works reliably with Cygwin processes. There's > > > > $ /bin/kill -f > > > > to call the

Re: Home directory not accessible but really there...

Silly me -- problem was due to a typo in an old (and forgotten) fstab.d file. Never mind. Sorry for the troubles... "" wrote at about 15:47:59 -0400 on Tuesday, August 27, 2019: > In summary: > 1. Home directory is not accessible via: 'cd ' or 'cd ~' (it >takes me to /tmp) and 'ls -al

ssh-add fails to find .ssh directory/key when home directory mounted via fstab

When I use an fstab.d file to mount my home directory at an alternative point, everything seems to work (so far) except for ssh-add that returns with exit code 2 (error) seemingly because it can't find the .ssh folder and associated key. Note that the perms of the .ssh folder and contained keys

Re: Bug report: Killing a native process may not actually kill it

--On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen wrote: Not likely. Cygwin handles Ctrl-C by generating SIGINT. This only works reliably with Cygwin processes. There's $ /bin/kill -f to call the Win32 function TerminateProcess(pid) on a non-Cygwin process or an

Re: Bug report: Killing a native process may not actually kill it

On Aug 28 08:18, Quanah Gibson-Mount wrote: > > > --On Thursday, July 25, 2019 11:32 AM -0700 Quanah Gibson-Mount > wrote: > > > As found and reported to the MSYS team back in 2006 by Howard Chu, if a > > native process is spawned, control-C, the kill command, etc, may not > > actually kill

Re: Bug report: Killing a native process may not actually kill it

--On Thursday, July 25, 2019 11:32 AM -0700 Quanah Gibson-Mount wrote: As found and reported to the MSYS team back in 2006 by Howard Chu, if a native process is spawned, control-C, the kill command, etc, may not actually kill the process. Details are here: I haven't seen a reply to

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Aug 28 16:15, Corinna Vinschen wrote: > On Aug 28 08:36, Eric Blake wrote: > > On 8/28/19 7:59 AM, Corinna Vinschen wrote: > > > > > mkdir(2) has some special code from 2009 which drops trailing > > > {back}slashes to perform a bordercase in mkdir Linux-compatible. > > > This code

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Aug 28 08:36, Eric Blake wrote: > On 8/28/19 7:59 AM, Corinna Vinschen wrote: > > > mkdir(2) has some special code from 2009 which drops trailing > > {back}slashes to perform a bordercase in mkdir Linux-compatible. > > This code snippet doesn't exist in rmdir(2). > > Dropping

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On 8/28/19 7:59 AM, Corinna Vinschen wrote: > mkdir(2) has some special code from 2009 which drops trailing > {back}slashes to perform a bordercase in mkdir Linux-compatible. > This code snippet doesn't exist in rmdir(2). Dropping trailing slashes to be Linux-compatible is okay.

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On 8/27/19 7:51 AM, Houder wrote: > > 64-@@ mkdir 'e:\' # creates subdirectory e: ! Had you typed: mkdir 'e:/' I would expect subdirectory ./e: to be created. But with 'e:\', that is a DOS style path, so I would lean towards requiring './e:\' if you want to create a literal directory

Re: bug with grep 3.0.2 in cygwin 3.0.7

On 8/28/19 2:16 AM, ak...@free.fr wrote: > Hi, > I encounter some problem with grep option -E on cygwin 3.0.7 > > > echo "a^b" | grep "a^b" #answer a^b ie it's OK POSIX says: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html "A BRE special character has special

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Aug 28 09:16, Houder wrote: > On Tue, 27 Aug 2019 11:44:17, Vince Rice wrote: > > > > On Aug 27, 2019, at 11:28 AM, Houder wrote: > > > > > > On Tue, 27 Aug 2019 17:25:49, Corinna Vinschen wrote: > > >> > > >> mkdir(2) has some special code from 2009 which drops trailing > > >> {back}slashes

Re: fetchmail issue

On Aug 28 19:49, Eliza wrote: > I run fetchmail in Cygwin64 terminal, got the error: > > $ fetchmail > fetchmail:/home/Administrator/.fetchmailrc:3: SSL 不可用 在 ssl > > Can you help with the issue? The old fetchmail was not linked against openSSL and so was unable to handle pops/imaps. I've

Re: HEADS UP package "fetchmail" vulnerable and 6.4.0 release candidate out

Hi Matthias, On Aug 20 19:49, Matthias Andree wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Corinna, and everyone else who is interested, > > checking , > I see that Cygwin packages a very old fetchmail version that has

[ANNOUNCEMENT] TEST: fetchmail 6.4.0.rc3-1

The following packages have been uploaded to the Cygwin distribution: * fetchmail-6.4.0.rc3-1 This is a test release for the upcoming fetchmail 6.4.0. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

TEST: fetchmail 6.4.0.rc3-1

The following packages have been uploaded to the Cygwin distribution: * fetchmail-6.4.0.rc3-1 This is a test release for the upcoming fetchmail 6.4.0.

Re: bug with grep 3.0.2 in cygwin 3.0.7

On 8/28/2019 3:16 AM, ak...@free.fr wrote: Hi, I encounter some problem with grep option -E on cygwin 3.0.7 echo "a^b" | grep "a^b" #answer a^b ie it's OK but echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO I have to backslash ^ to be OK like : grep -E 'a\^b' Is-it a bug ? I

[newlib-cygwin] Cygwin: get_posix_access: avoid negative subscript

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=398476acd2dca8d68044e1b6e68eb41a16086f79 commit 398476acd2dca8d68044e1b6e68eb41a16086f79 Author: Ken Brown Date: Mon Aug 26 13:38:31 2019 -0400 Cygwin: get_posix_access: avoid negative subscript Don't refer to lacl[pos]

Re: [ANNOUNCEMENT] LLVM/Clang 8.0.1-1

On Wed, 2019-08-28 at 04:47 -0700, Steven Penny wrote: > On Tue, 27 Aug 2019 22:24:57, Yaakov Selkowitz wrote: > > The following packages have been uploaded to the Cygwin distribution: > > * clang-8.0.1-1 > > I noticed that Cygwin Clang requires GCC. why is that? Debian doesnt: > >

fetchmail issue

I run fetchmail in Cygwin64 terminal, got the error: $ fetchmail fetchmail:/home/Administrator/.fetchmailrc:3: SSL 不可用 在 ssl Can you help with the issue? thanks. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

Re: [ANNOUNCEMENT] LLVM/Clang 8.0.1-1

On Tue, 27 Aug 2019 22:24:57, Yaakov Selkowitz wrote: The following packages have been uploaded to the Cygwin distribution: * clang-8.0.1-1 I noticed that Cygwin Clang requires GCC. why is that? Debian doesnt: https://packages.debian.org/buster/clang-7 -- Problem reports:

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Wed, 28 Aug 2019 10:32:27, john doe wrote: > As hinted out in here, backporting the code snippet from mkdir to rmdir > would solve your issue. No, the reverse. Removing the snippet from mkdir() would solve my issue. rmdir() does the right thing; currently, mkdir() does the wrong thing.

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On 8/28/2019 9:16 AM, Houder wrote: > On Tue, 27 Aug 2019 11:44:17, Vince Rice wrote: > >>> On Aug 27, 2019, at 11:28 AM, Houder wrote: >>> >>> On Tue, 27 Aug 2019 17:25:49, Corinna Vinschen wrote: mkdir(2) has some special code from 2009 which drops trailing {back}slashes to

bug with grep 3.0.2 in cygwin 3.0.7

Hi, I encounter some problem with grep option -E on cygwin 3.0.7 echo "a^b" | grep "a^b" #answer a^b ie it's OK but echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO I have to backslash ^ to be OK like : grep -E 'a\^b' Is-it a bug ? I don't know if all versions of cygwin and

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Tue, 27 Aug 2019 11:44:17, Vince Rice wrote: > > On Aug 27, 2019, at 11:28 AM, Houder wrote: > > > > On Tue, 27 Aug 2019 17:25:49, Corinna Vinschen wrote: > >> > >> mkdir(2) has some special code from 2009 which drops trailing > >> {back}slashes to perform a bordercase in mkdir

Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

On Aug 27 14:37, Brian Inglis wrote: > On 2019-08-27 11:54, Achim Gratz wrote: > > Corinna Vinschen writes: > >> mkdir(2) has some special code from 2009 which drops trailing > >> {back}slashes to perform a bordercase in mkdir Linux-compatible. > >> This code snippet doesn't exist in rmdir(2). > >

Re: [PATCH] Cygwin: get_posix_access: avoid negative subscript

On Aug 27 20:00, Ken Brown wrote: > On 8/27/2019 4:13 AM, Corinna Vinschen wrote: > > On Aug 26 17:43, Ken Brown wrote: > >> Don't refer to lacl[pos] unless we know that pos >= 0. > > > > I'm not sure this is entirely right. Moving the assignment to > > class_perm/def_class_perm into the