> - 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
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 UTF-16. UTF-8 doesn't know surrogate
On 2021-11-24 02:25, Corinna Vinschen via Cygwin wrote:
On Nov 24 09:36, Duncan Roe wrote:
On Tue, Nov 23, 2021 at 11:18:25AM -0700, Brian Inglis wrote:
On Nov 23 19:27, Duncan Roe wrote:
Btw to whoever maintains grep for cygwin: 'make check' should pass on
next release (I patched out the
On Nov 24 09:36, Duncan Roe wrote:
> On Tue, Nov 23, 2021 at 11:18:25AM -0700, Brian Inglis wrote:
> > > On Nov 23 19:27, Duncan Roe wrote:
> > > > Btw to whoever maintains grep for cygwin: 'make check' should pass on
> > > > next release (I patched out the surrogate-pair failre).
> >
> > I had no
On Tue, Nov 23, 2021 at 11:18:25AM -0700, Brian Inglis wrote:
> On 2021-11-23 02:50, Corinna Vinschen via Cygwin wrote:
> > On Nov 23 19:27, Duncan Roe wrote:
> > > On Mon, Nov 22, 2021 at 02:06:19PM +0100, cygwin wrote:
> > > > On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
> > > > > On Nov
On 2021-11-23 02:50, Corinna Vinschen via Cygwin wrote:
On Nov 23 19:27, Duncan Roe wrote:
On Mon, Nov 22, 2021 at 02:06:19PM +0100, cygwin wrote:
On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
On Nov 22 16:20, Duncan Roe wrote:
#include
#include
int
main (void)
{
int retcod;
On Nov 23 19:27, Duncan Roe wrote:
> On Mon, Nov 22, 2021 at 02:06:19PM +0100, cygwin wrote:
> > On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
> > > On Nov 22 16:20, Duncan Roe wrote:
> > > > #include
> > > > #include
> > > >
> > > > int
> > > > main (void)
> > > > {
> > > > int retcod;
On Mon, Nov 22, 2021 at 02:06:19PM +0100, cygwin wrote:
> On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
> > On Nov 22 16:20, Duncan Roe wrote:
> > > Hi,
> > >
> > > I stumbled across this when running 'make check' in the grep source
> > > directory.
> > >
> > > test-raise failed when it
On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
> On Nov 22 16:20, Duncan Roe wrote:
> > Hi,
> >
> > I stumbled across this when running 'make check' in the grep source
> > directory.
> >
> > test-raise failed when it didn't a few weeks ago.
>
> Pretty unlikely. This code didn;'t change
On Nov 22 16:20, Duncan Roe wrote:
> Hi,
>
> I stumbled across this when running 'make check' in the grep source directory.
>
> test-raise failed when it didn't a few weeks ago.
Pretty unlikely. This code didn;'t change for ages. I just checked
against Cygwin 3.2.0 and it also returns
Hi,
I stumbled across this when running 'make check' in the grep source directory.
test-raise failed when it didn't a few weeks ago. I cut it down to the STC at
the end of this email
Under Linux:
> 16:15:57$ ./test-raise
> raise(-1) returned -1
Under Cygwin:
> 16:16:51$ ./test-raise.exe
>
I've read through the Cygwin FAQ, googled around, and I wasn't able to find the
appropriate answer, which is why I'm sending it to this mailing list.
Apologies if this is not the correct place.
At the end of setup-x86_64.exe run, I get a popup about an Unknown package
error.
As instructed, I
?check_suite_focus=true
The error is:
In file included from pp-log10.c:56:
1744<https://github.com/PDLPorters/pdl/runs/4134966240?check_suite_focus=true#step:11:1744>ops.pd:
In function ‘pdl_log10_readdata’:
1745<https://github.com/PDLPorters/pdl/runs/4134966240?check_suite_focus=true#ste
Dear Cygwin folks,
As shown in this run of PDL (Perl Data Language)’s CI, our new use of tgmath.h
is causing a problem with log10:
https://github.com/PDLPorters/pdl/runs/4134966240?check_suite_focus=true
The error is:
In file included from pp-log10.c:56:
1744<https://github.com/PDLPorters/
On 10/8/2021 12:28 PM, Takashi Yano wrote:
- If two or more pty masters are opened in a process, closing master
causes error when closing attach_mutex. This patch fixes the issue.
Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-October/012418.html
---
winsup/cygwin
- If two or more pty masters are opened in a process, closing master
causes error when closing attach_mutex. This patch fixes the issue.
Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-October/012418.html
---
winsup/cygwin/fhandler_tty.cc | 7 +--
winsup/cygwin/release/3.3.0
On 22/09/2021 02:50, Richard Beels via Cygwin wrote:
At 9/21/2021 at 12:28, Shakespearean monkeys danced on Jason Pyeron's
keyboard and said:
If the last execution of the setup used download only and the setup is
used with -q and without either -D or -L it still defaults to -D
Adding -Y
*I'm not sure this is really a cygwin problem but I don't know where
else to ask. I'm runing a python3 script to extract a web page:**
*
#!/usr/bin/python3
# This script auto submitsw do not call complaints
from bs4 import BeautifulSoup
from requests_html import HTMLSession
from urllib.parse
At 9/21/2021 at 12:28, Shakespearean monkeys danced on Jason Pyeron's
keyboard and said:
If the last execution of the setup used download only and the setup
is used with -q and without either -D or -L it still defaults to -D
Adding -Y does not change the behavior either.
Workaround was to
If the last execution of the setup used download only and the setup is used
with -q and without either -D or -L it still defaults to -D
Adding -Y does not change the behavior either.
Workaround was to launch setup, advance to “select download source”, select
install, advance to next
On Thu, 16 Sep 2021 15:44:06 -0400
Bryan VanSchouwen wrote:
> I just tried performing an analysis in the Octave software (GNU Octave,
> version 5.2.0), using the attached "dm" input file, and the following
> commands:
> load dm
> cdmt = cor(dm.')
>
> However, I
Hello.
I just tried performing an analysis in the Octave software (GNU Octave,
version 5.2.0), using the attached "dm" input file, and the following
commands:
load dm
cdmt = cor(dm.')
However, I encountered the following error message:
error: 'cor' undefined near line 1 column 8
Wha
On Sep 7 19:27, Takashi Yano wrote:
> - Currently, error handling of write() in pty master side is broken.
> This patch fixes that.
> ---
> winsup/cygwin/fhandler_termios.cc | 24 +++-
> winsup/cygwin/fhandler_tty.cc | 11 +++
> 2 files chan
201 - 300 of 7045 matches
Mail list logo
