Shaddy Baddah writes:
> Getting consistent permission denied errors on postinstall of
> ca-certificate.
>
> It appears to be oversight, out of a well-intentioned attempt to
> protect script generated reference files.
This is caused by p11-kit removing write permissions even for the user
from the
Hi,
On 26/08/2022 1:22 pm, Shaddy Baddah wrote:
-B, no privelege elevation). Both installs have had an manual
manipulation of the directory, or its parents up to /etc.
Both installs have *not* had any manual manipulation...
--
Regards,
Shaddy
--
Problem reports:
permission denied errors on postinstall of
ca-certificate.
It appears to be oversight, out of a well-intentioned attempt to
protect script generated reference files.
There error as it appears in setup.log.full:
2022/08/26 11:39:07 running: e:\cygwin-x86_64\bin\bash.exe --norc
--noprofile "
Hi, Getting consistent permission denied errors on postinstall of
ca-certificate. It appears to be oversight, out of a well-intentioned
attempt to protect script generated reference files. There error as it
appears in setup.log.full: 2022/08/26 11:39:07 running:
e:\cygwin-x86_64\bin\bash.exe
gt; >>>
> >>>>>> Preparing autoconf2.1-2.13-12.x86_64
> >>>>>> Unpacking source autoconf-2.13.tar.gz
> >>> *** Info: applying patch autoconf2.1-texinfo.patch (-p2):
> >>> patching file autoconf.texi
> >>>>
ying patch autoconf2.1-texinfo.patch (-p2):
patching file autoconf.texi
Preparing working source directory
*** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
patching file CYGWIN-PATCHES/autoconf2.1.README
Compiling autoconf2.1-2.13-12.x86_64
*** ERROR: could not detect autoco
Hi, there is an error in the cloc latest release. This has been reported
before (https://www.mail-archive.com/cygwin@cygwin.com/msg169201.html), but
still isn't fixed as far as I can tell. It appears as if work has started,
but has not yet been completed. (
https://github.com/jaalto/cygwin-package
AM marco atzeri wrote:
> On Mon, Jul 25, 2022 at 3:12 AM Thomas DiModica via Cygwin wrote:
> >
> > Since 8.2.3755-1, Vim has given me an error message about being unable
> to open the defaults.vim file whenever I open a file with vi. I do not see
> this message with 8.
On Mon, Jul 25, 2022 at 3:12 AM Thomas DiModica via Cygwin wrote:
>
> Since 8.2.3755-1, Vim has given me an error message about being unable to
> open the defaults.vim file whenever I open a file with vi. I do not see this
> message with 8.2.0486-1. Notably, vi --version for
On 7/24/2022 8:11 PM, Thomas DiModica via Cygwin wrote:
Since 8.2.3755-1, Vim has given me an error message about being
unable to open the defaults.vim file whenever I open a file with vi.
I do not see this message with 8.2.0486-1. Notably, vi --version for
the last two updates tell me
Since 8.2.3755-1, Vim has given me an error message about being unable to open
the defaults.vim file whenever I open a file with vi. I do not see this message
with 8.2.0486-1. Notably, vi --version for the last two updates tell me that
the user vimrc file is "/home/Marco/.virc", r
acking source autoconf-2.13.tar.gz
> > *** Info: applying patch autoconf2.1-texinfo.patch (-p2):
> > patching file autoconf.texi
> > >>> Preparing working source directory
> > *** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
> > patchi
conf2.1-2.13-12.cygwin.patch (-p2):
> patching file CYGWIN-PATCHES/autoconf2.1.README
> >>> Compiling autoconf2.1-2.13-12.x86_64
> *** ERROR: could not detect autoconf version; perhaps set AUTOCONF_VERSION?
>
> Have you an idea of the cause of the problem?
> I tried to dow
ollowing message:
>
> Command terminated
> Error detected while processing BufRead Autocommands for "*.pl"..function
> dist#ft#FTpl[10]..FileType
> Autocommands for "*"..function 11_LoadFTPlugin[18]..script
> /usr/share/vim/vim82/ftplugin/perl.
> vim[57
Hi,
I recently ran the installer and it updated vim to 8.2
:version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:00:24)
Included patches: 1-4372
Now when I open a perl script, I get the following message:
Command terminated
Error detected while processing BufRead Autocommands
fo: applying patch autoconf2.1-texinfo.patch (-p2):
patching file autoconf.texi
>>> Preparing working source directory
*** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
patching file CYGWIN-PATCHES/autoconf2.1.README
>>> Compiling autoconf2.1-2.13-12.x86_64
*** ERRO
Greetings, Jim McNamara!
> I took the bottom of the sha256sum
> file where it was ascii armor and pasted it into notepad and saved it.
Thus destroyed the very possiblity of checking your setup.
Do not touch the signature file. Save it literal.
> I don't know why it isn't verifying.
You did
text lines longer than 19995 characters
>> gpg: Signature made Fri May 6 10:21:35 2022 EDT using RSA key ID
38AB71F4
>> gpg: BAD signature from "Fedora (36)
"
>>
>> I am having a difficult time. I think they are breaking into my
computer.
>> They made
(36) "
>
> I am having a difficult time. I think they are breaking into my computer.
> They made it so I can't verify files.
>
> Is there any way I can fix it so that this error goes away?
Start by checking gpg itself.
$ which gpg
/usr/bin/gpg
$ gpg --version
gpg (GnuPG) 1.
uot;
I am having a difficult time. I think they are breaking into my computer.
They made it so I can't verify files.
Is there any way I can fix it so that this error goes away?
Start by checking gpg itself.
$ which gpg
/usr/bin/gpg
$ gpg --version
gpg (GnuPG) 1.4.23
Copyright (C) 2015 Fre
uot;
I am having a difficult time. I think they are breaking into my computer.
They made it so I can't verify files.
Is there any way I can fix it so that this error goes away?
thanks,
jim
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Doc
database of coastal outlines
(Netcdf files). I have used the netcdf libraries etc. from the Cygwin
depository when compiling GMT.
gshhg_version: cannot open file "/GMT6/gshhg-gmt-2.3.6/binned_border_f.nc"
(-101).
gmtget [ERROR]: 1. GSHHG: Found /GMT6/gshhg-gmt-2.3.6/binned_border_f.nc but
c
> - Original Message -
>
> From: "Jon Turney"
> To: "Tatsuro MATSUOKA"; "The Cygwin Mailing List" <
> Date: 2022/06/13 月 01:29
> Subject: Re: meson build error on gedit-3.32.2
>
>
> On 08/06/2022 06:48, Tatsuro MATSUOKA wrote
I can't reproduce this.
I think perhaps maybe you are encountering a meson bug (already fixed in
upstream) that this warning is emitted when you make an unusual choice
of prefix?
data/meson.build:19:0: ERROR: Function does not take positional arguments.
To fix this error, you'll need to bac
thon files installed by Meson might not be found by python
interpreter.
This warning can be avoided by setting "python.purelibdir" option.
Configuring config.h using configuration
data/meson.build:19:0: ERROR: Function does not take positional arguments.
Please give me suggestions for settin
Thank you! This looks like it may help.
8<
From: Cygwin on behalf of
Brian Inglis
Sent: Sunday, April 24, 2022 1:08 PM
To: cygwin@cygwin.com
Subject: Re: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) on Windows 10
On 2022-04-24 08:02, John Balkunas wrote:
> Hello,
verything is ready to go on my Win10 machine for compiling.
However, when I switch to the directory I unpacked the chrony-4.2 to and run the
"./configure" command (I used no switches) from within the Cygwin64 Terminal I
see the following:
Command: "./configure"
Result:
error
On 4/24/2022 10:37 AM, René Berber wrote:
On 4/24/2022 10:3 AM, John Balkunas wrote:
Thank you! It makes sense. Upon further reading it looks like
chrony's docs say it does not run on/support Windows.
That is not the same as not supporting Cygwin.
[snip]
Taken from chrony's FAQ:
"7.1.
On 4/24/2022 10:3 AM, John Balkunas wrote:
Thank you! It makes sense. Upon further reading it looks like
chrony's docs say it does not run on/support Windows.
That is not the same as not supporting Cygwin.
Looks like I should be trying to get NTP running instead of Chrony
for time clock
the Cywin64 Terminal, I see the following 3 results:
[snip]
Command: "./configure"
Result:
error: CYGWIN_NT-10.0-x86_64 is not supported (yet?)
That message is from chrony, there's no apparent problem with Cygwin.
The message is just telling you that the OS CYGWIN* is not one know
for
compiling. However, when I switch to the directory I unpacked the chrony-4.2
to and run the "./configure" command (I used no switches) from within the
Cygwin64 Terminal I see the following:
Command: "./configure"
Result:
error: CYGWIN_NT-10.0-x86_64 is not suppo
On 4/7/2022 3:03 PM, Eliot Moss wrote:
But it's odd to have a man page for something in one package
and the executable in another, no?
Yes. The man page shouldn't be in the xpdf package. I'll fix that the next
time I update xpdf.
Ken
--
Problem reports:
On 4/7/2022 11:13 AM, airplanemath via Cygwin wrote:
> On Thu, Apr 07 2022, Eliot Moss wrote:
>
>> Dear Cygwin-ers --
>>
>> Today I had use for pdftotext. It man page is installed, but the program
>> itself is missing. On Ubuntu (etc.) it is part of the xpdf package, the
>> Cygwin version of
On Thu, Apr 07 2022, Eliot Moss wrote:
> Dear Cygwin-ers --
>
> Today I had use for pdftotext. It man page is installed, but the program
> itself is missing. On Ubuntu (etc.) it is part of the xpdf package, the
> Cygwin version of which I have installed. pdftotext.cc is in the source
>
Dear Cygwin-ers --
Today I had use for pdftotext. It man page is installed, but the program
itself is missing. On Ubuntu (etc.) it is part of the xpdf package, the
Cygwin version of which I have installed. pdftotext.cc is in the source
package, but its executable is not present in the
When I execute some GUI application like gedit, gvim, and etcs, warning
messages appear.
WARNING **: Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message
bus without replying
If there is method to surpress these, please
When I execute some GUI application like gedit, gvim, and etcs, warning
messages appear.
WARNING **: Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message
bus without replying
If there is method to surpress these, please
> Please pause here for a moment. Are you using Cygwin ssh or MS Windows
provided
> variant? Cygwin rsync is unable to use native Windows apps as tunnel
wrappers.
> Be it OpenSSH or PuTTY's plink. With exactly the message you see above.
This was the problem.
I installed OpenSSH from Cygwin,
> Please pause here for a moment. Are you using Cygwin ssh or MS Windows
provided
> variant? Cygwin rsync is unable to use native Windows apps as tunnel
wrappers.
> Be it OpenSSH or PuTTY's plink. With exactly the message you see above.
I think we may (finally!) be getting somewhere now.
I am
ut on the screen:
> opening connection using: ssh -l root marketing.propfinancing.com rsync
> --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args)
> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
> rsync error: error in rsync protocol data stream (code 12
pen_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug3: read - ERROR from cb :87, io:027
On Sat, Mar 26, 2022 at 11:49:18PM -0500, Neil Aggarwal wrote:
> The big stumper for me is that scp works. What could cause rsync to act
> differently?
Likely answer: your server configuration, such as ssh config,
shell configuration, PATH, etc. which are a bit off-topic for
the cygwin list.
Wayne:
> Perhaps the networking drivers are buggy
This is an AlmaLinux 8 server, which is a binary clone of RHEL.
It is possible but hard to believe the networking drivers would
be a problem.
> Perhaps you have firewall or selinux rules that are closing the
> connection.
I configured the
bytes from the remote
side. At that point it gets a closed socket error.
Thus, the issue isn't rsync but that the connection is closing without
either side being able to send/receive any data. (Both sides are
seeing the connection go away.) Perhaps the networking drivers are
buggy. Or perhaps yo
Adam:
Thanks for the opinion on the version differences.
Regarding my server setup, this command works:
scp r...@marketing.propfinancing.com:/var/www/svnDumps/* "c:\\Tmp"
So I am not completely convinced the problem lies in the network or my
server.
It would be nice to get rsync working since
On Fri, Mar 25, 2022 at 12:36:55PM -0500, Neil Aggarwal wrote:
> Adam:
>
> I tried doing an upload using this command:
> rsync test.xml r...@marketing.propfinancing.com:/tmp
>
> I still get an error:
> rsync: connection unexpectedly closed (0 bytes received so far) [Re
connection using: ssh -l root marketing.propfinancing.com
rsync --server --sender -e.LsfxCIvu --msgs2stderr --msgs2stderr .
/var/www/svnDumps (12 args)
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226)
[sender
On Fri, Mar 25, 2022 at 10:37 AM Neil Aggarwal wrote:
> I still get an error:
> rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
> rsync error: error in rsync protocol data stream (code 12) at io.c(226)
> [Receiver=3.1.3]
> rsync: connection unexpectedly
Adam:
I tried doing an upload using this command:
rsync test.xml r...@marketing.propfinancing.com:/tmp
I still get an error:
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226)
[Receiver=3.1.3]
rsync
l root marketing.propfinancing.com rsync
--server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args)
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226)
[sender=3.1.3]
rsync: connection unexpectedly closed (0 bytes recei
Adam:
> Looking slightly closer at the logs, this reads to me like the remote
> server is closing the connection, so I expect you'll need help from
> whoever provides/supports that remote server to work out why it's doing
> that.
I am responsible for the remote server. I will look into that.
do the sync over an SSH connection.
>
> When I remove it:
> rsync --debug=ALL r...@marketing.propfinancing.com:/var/www/svnDumps
> /cygdrive/c/Tmp
>
> I still get the error:
> opening connection using: ssh -l root marketing.propfinancing.com
> rsync --server --sender -e
bug=ALL r...@marketing.propfinancing.com:/var/www/svnDumps
/cygdrive/c/Tmp
I still get the error:
opening connection using: ssh -l root marketing.propfinancing.com
rsync --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args)
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error
> /cygdrive/c/Tmp
>
> Here is the output:
>
> opening connection using: ssh -l root marketing.propfinancing.com rsync
> --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args)
>
> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>
> rsync
marketing.propfinancing.com rsync
--server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args)
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226)
[sender=3.1.3]
rsync: connection unexpectedly closed (0 bytes
On 2022-03-13 07:04, Jon Turney wrote:
On 12/03/2022 17:54, Brian Inglis wrote:
Building locally I get the message below on 64 & 32 bit package builds:
ERROR: python_nghttp2-1.47.0-cp38-cp38-cygwin_3_3_4_x86_64.whl is not
a supported wheel on this platform.
but not in the conf
On 12/03/2022 17:54, Brian Inglis wrote:
Building locally I get the message below on 64 & 32 bit package builds:
ERROR: python_nghttp2-1.47.0-cp38-cp38-cygwin_3_3_4_x86_64.whl is not a
supported wheel on this platform.
but not in the confines of a scallywag build: what do I need to re
Building locally I get the message below on 64 & 32 bit package builds:
ERROR: python_nghttp2-1.47.0-cp38-cp38-cygwin_3_3_4_x86_64.whl is not a
supported wheel on this platform.
but not in the confines of a scallywag build: what do I need to remove
or change to build locally?
Most rele
Greetings, Adam Dinwoodie!
> On Sat, Mar 05, 2022 at 09:26:06AM +0300, lvm wrote:
>> The identical /etc/skel/.bashrc and /etc/defaults/etc/skel/.bashrc contain
>> the same line
>>
>> # export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
Not a nitpick or anything, but I've found a
On Sat, Mar 05, 2022 at 09:26:06AM +0300, lvm wrote:
> The identical /etc/skel/.bashrc and /etc/defaults/etc/skel/.bashrc contain
> the same line
>
> # export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
>
> But HISTCONTROL values should be colon separated, not comma separated. This
>
The identical /etc/skel/.bashrc and /etc/defaults/etc/skel/.bashrc contain
the same line
# export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
But HISTCONTROL values should be colon separated, not comma separated. This
line is commented out, but if someone like me tries to use it without
- This patch fixes the handle leak which occurs when exec() fails
with an error. The duplicated handles will be closed when the
exec'ed process is terminated. However, if exec() fails, the code
path does not reach to the code closing the duplicated handles.
To implement this fix more
On 16.02.2022 23:34, Scott Wood wrote:
Whenever I try to enable the ssl module in apache2 (original dist version
or custom compiled version) I get the following error:
$ apachectl -k start
[Wed Feb 16 17:29:11.188154 2022] [core:emerg] [pid 47724] (88)Function not
implemented: AH00023: Couldn't
Whenever I try to enable the ssl module in apache2 (original dist version
or custom compiled version) I get the following error:
$ apachectl -k start
[Wed Feb 16 17:29:11.188154 2022] [core:emerg] [pid 47724] (88)Function not
implemented: AH00023: Couldn't create the mpm-accept mutex
(88)Function
On 2022-02-02 21:34, Niclas Helbig wrote:
The log Text told me to send you this.
I am no Code-wizzard, so I dont really know what this means.
I dont have Surface Wind Layer and WAFS Turbulence unfortunatly.
Would really like to fix that but dont know how.
...
0 [main] WIN32wgrib2 5128
Hello there,
The log Text told me to send you this.
I am no Code-wizzard, so I dont really know what this means.
I dont have Surface Wind Layer and WAFS Turbulence unfortunatly.
Would really like to fix that but dont know how.
Greetings,
Niclas
0 [main] WIN32wgrib2 5128 find_fast_cwd:
ywag/runs/5007960186?check_suite_focus=true
>
> This worked well on 2022-01-22:
> https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=libdeflate==3754
>
>
> I wonder cygwin-3.3.4-1 might have an issue.
> When I updated to cygwin-3.3.4-1, an error occurred with cygwin1.dll.
> And t
On Mon, 31 Jan 2022 14:15:41 +, © Fxzx mic
> I am installing these packages with cygwin/cygwin-install-action@master:
>
>
>
> cmake make gdb mingw64-x86_64-gcc-g++
>
>
>
> on Github Action. However, the following error occurred:
>
>
>
> Changi
On Mon, Jan 31, 2022 at 3:16 PM © Fxzx mic wrote:
>
> I am installing these packages with cygwin/cygwin-install-action@master:
>
> cmake make gdb mingw64-x86_64-gcc-g++
> on Github Action. However, the following error occurred:
>
> Changing gid back to original
> running
I am installing these packages with cygwin/cygwin-install-action@master:
cmake make gdb mingw64-x86_64-gcc-g++
on Github Action. However, the following error occurred:
Changing gid back to original
running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"
abn
On 22/01/2022 05:34, Marco Atzeri wrote:
On 21.01.2022 17:03, Hamish McIntyre-Bhatty wrote:
On 21/01/2022 14:06, Jon Turney wrote:
On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote:
Hi there,
Recently, I created a test package for python-imaging, and the CI
system gave a build error that I
On 21.01.2022 17:03, Hamish McIntyre-Bhatty wrote:
On 21/01/2022 14:06, Jon Turney wrote:
On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote:
Hi there,
Recently, I created a test package for python-imaging, and the CI
system gave a build error that I didn't see locally:
*** ERROR: unknown
On 21/01/2022 14:06, Jon Turney wrote:
On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote:
Hi there,
Recently, I created a test package for python-imaging, and the CI
system gave a build error that I didn't see locally:
*** ERROR: unknown wheel filename.
This only occurred for the Python
On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote:
Hi there,
Recently, I created a test package for python-imaging, and the CI system
gave a build error that I didn't see locally:
*** ERROR: unknown wheel filename.
This only occurred for the Python 3.8 build (3.6 and 3.7 are
unaffected
.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433:
/usr/include/sys/unistd.h:23:9: error: redundant redeclaration of ‘int
chmod(const char*, mode_t)’ in same scope [-Werror=redundant-decls]
23 | int chmod (const char *__path, mode_t __mode);
| ^
In file included from /usr
/wxWidgets-3.1.5/tests/testprec.h:5,
from
/home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433:
/usr/include/sys/unistd.h:23:9: error: redundant redeclaration of ‘int
chmod(const char*, mode_t)’ in same scope [-Werror=redundant-decls
/include/wx/evtloop.h:14,
from
/home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5,
from
/home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433:
/usr/include/sys/unistd.h:23:9: error
Hi there,
Recently, I created a test package for python-imaging, and the CI system
gave a build error that I didn't see locally:
*** ERROR: unknown wheel filename.
This only occurred for the Python 3.8 build (3.6 and 3.7 are
unaffected). Considering some of the library name changes between
On Jan 19 08:12, Anton Lavrentiev via Cygwin-patches wrote:
> - When dn_comp() failed internally there is no longer any need to
> fill the response header since it's now all cleared upon entry
> ---
> winsup/cygwin/libc/minires-os-if.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
- When dn_comp() failed internally there is no longer any need to
fill the response header since it's now all cleared upon entry
---
winsup/cygwin/libc/minires-os-if.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/libc/minires-os-if.c
the same happens even with pthread rather than
> > win32 thread functions.
> >
> > #include
> > #include
> >
> > void *thread(void *p)
> > {
> > system("true");
> > return NULL;
> > }
> >
> > in
2; i++)
pthread_create([i], NULL, thread, NULL);
for (i = 0; i < 2; i++)
pthread_join(threads[i], NULL);
return 0;
}
Executing above code results in hang with message:
0 [waitproc] a 786 proc_waiter: error on read of child wait pipe 0x0,
Wi
in32 thread functions.
#include
#include
void *thread(void *p)
{
system("true");
return NULL;
}
int main()
{
int i;
pthread_t threads[2];
for (i = 0; i < 2; i++)
pthread_create([i], NULL, thread, NULL);
for (i = 0;
On 1/13/2022 1:40 AM, Jay K wrote:
I don't know why I didn't get the reply in email, but this is representative of
the real world code.
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 6:27 AM
To: cyg...@sourceware.org
Subject: Re: proc_waiter: error on read of child wait pipe 0x0
I don't know why I didn't get the reply in email, but this is representative of
the real world code.
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 6:27 AM
To: cyg...@sourceware.org
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Ok, here is a small
On 12.01.2022 07:27, Jay K wrote:
Ok, here is a small demonstration of the problem.
#include
#include
#include
unsigned __stdcall thread(void* p)
{
unsigned i;
for (i = 0; i < 100; ++i)
system("./a.exe");
return 0;
}
int main()
{
unsigned i;
HANDLE threads[100] = {0};
FILE* f
, "w");
fprintf(f, "int main() { return 0; }\n");
fclose(f);
system("g++ a.c");
for (i = 0; i < 100; ++i)
threads[i] = CreateThread(0, 0, thread, 0,0,0);
for (i = 0; i < 100; ++i)
WaitForSingleObject(threads[i], -1);
}
$ ./1.exe
0 [main] sh 9287 C:\cyg
AM
To: cyg...@sourceware.org
Subject: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
I get this a lot:
0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
Win32 error
I get this a lot:
0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
716 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
Win32 error
Hi all - and happy 2022 to everybody.
> I ran
> $ rm -vrf /tmp/.X11*
> in order to enable a "fresh start" and all is good.
I have the same problem after the last update. I usually start cygwin
with Xlaunch, and
I get the same error message; now, every time I start
get:
> "A fatal error has occurred and Cygwin/X will now exit.
> Cannot establish any listening sockets."
> Over the years the one-liner typed above has had to evolve with changing
> execs so I'm not surprised, or bothered, at this glitch.
> But can anybody plea
On 08.01.2022 07:57, Fergus Daly wrote:
Not quite sure what recent update has caused this failure.
Up to now (and for a very long time indeed) typing
$ /bin/xinit /bin/xterm -- -nolock -multiwindow
at the mintty prompt has successfully started an xterm process.
Now I get:
"A fatal erro
Not quite sure what recent update has caused this failure.
Up to now (and for a very long time indeed) typing
$ /bin/xinit /bin/xterm -- -nolock -multiwindow
at the mintty prompt has successfully started an xterm process.
Now I get:
"A fatal error has occurred and Cygwin/X will now
cygport qt5-base.cygport compile fails ( *** ERROR: configure failed )
Error massage
ERROR: Feature 'dbus-linked' was enabled, but the pre-condition 'features.dbus
&& libs.dbus' failed.
ERROR: Feature 'system-pcre2' was enabled, but the pre-condition 'libs.pcre2'
failed.
ERROR:
On Nov 27 10:43, Duncan Roe wrote:
> On Wed, Nov 24, 2021 at 10:25:46AM +0100, cygwin wrote: [...]
> >
> > What is that "permanent restriction" in Cygwin? Is that something we
> > could fix or something unfixable? Did you try to debug Cygwin in terms
> > of that problem? If not, could you
On 11/28/2021 3:50 PM, Verachten Bruno via Cygwin wrote:
Hello there,
I installed Remmina tonight, and got this error when launching it:
"error while loading shared libraries: cygssh_threads-4.dll: cannot
open shared object file: No such file or directory
That DLL used to be pro
Hello there,
I installed Remmina tonight, and got this error when launching it:
"error while loading shared libraries: cygssh_threads-4.dll: cannot
open shared object file: No such file or directory
".
Could it be linked to https://bugzilla.redhat.com/show_bug.cgi?id=1618616 ?
Be
S: dfaexec-multibyte
PASS: empty
PASS: empty-line
PASS: empty-line-mb
PASS: encoding-error
PASS: epipe
XFAIL: equiv-classes
PASS: ere
PASS: euc-mb
false-match-mb-non-utf8: skipped test: no support for the zh_CN.gb18030 locale
SKIP: false-match-mb-non-utf8
PASS: fedora
PASS: fgrep-infloop
PASS: fg
On 2021-11-25 05:54, Corinna Vinschen via Cygwin wrote:
On Nov 24 11:01, Brian Inglis via Cygwin wrote:
On 2021-11-24 02:25, Corinna Vinschen via Cygwin wrote:
On Tue, Nov 23, 2021 at 11:18:25AM -0700, Brian Inglis wrote:
Do Cygwin and/or Windows support surrogate pairs in UTF-8?
You mean
On Wed, Nov 24, 2021 at 10:25:46AM +0100, cygwin wrote: [...]
>
> What is that "permanent restriction" in Cygwin? Is that something we
> could fix or something unfixable? Did you try to debug Cygwin in terms
> of that problem? If not, could you extract a reduced, very simple
> stand-alone
201 - 300 of 7067 matches
Mail list logo