cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/glib2.0.git;a=search;h=refs/heads/playground;s=Ken+Brown;st=author)
What's the situation? Is there a bug tracking the issues?
Hi Marc,
The last discussion of this that I can recall started here:
https://cygwin.com/pipermail/cygwin-apps/2020-
On 2/8/2022 9:37 AM, Antonio Petrelli wrote:
Il giorno mar 8 feb 2022 alle ore 15:30 marco atzeri
ha scritto:
check if strace give some hints
strace -o /tmp/strace.txt /usr/bin/cygpath --help
The result is here:
https://pastebin.com/n56RTAiu
This looks suspicious:
Process 2480 loaded
/
for a list of changes since the previous release.
Ken Brown
Cygwin's lcms2 maintainer
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe
/
for a list of changes since the previous release.
Ken Brown
Cygwin's lcms2 maintainer
On 1/20/2022 9:33 AM, Jon Turney wrote:
texlive-collection-latexrecommended-doc: untest 20210118-2 and expire 20210118-1
Yes, please. It was just a mistake that I never untested 20210118-2.
Ken
On 1/20/2022 7:14 AM, Glenn Strauss wrote:
lighttpd 1.4.64 removes long-deprecated packages,
including mod_trigger_b4_dl (replaceable with a lua script, if needed)
I am trying to build using lighttpd.cygport and after uploading package
1.4.64-1, I got errors, so I tried adding
On 1/13/2022 5:56 AM, Takashi Yano wrote:
Ken Brown wrote:
2. You can use the ReturnLength parameter of NtQueryInformationProcess to see
how big a buffer is needed. This might be more efficient than repeatedly
doubling the buffer size.
Even if ReturnLength is used, the first
On 1/12/2022 5:41 AM, Corinna Vinschen wrote:
On Jan 11 16:08, Ken Brown wrote:
I don't have time to check this carefully, but it looks to me like the
problem is that process_spawnattr calls setegid and seteuid instead of
setegid32 and seteuid32. This causes truncation of the gid and uid
On 1/11/2022 1:45 PM, Jeremy Drake via Cygwin wrote:
Sorry, I am not subscribed to the list so don't have the message to reply
to for threading purposes, but attached please find a C reproducer that
works on x86_64 but fails on i686. The particular issue seems to be the
POSIX_SPAWN_RESETIDS
On 1/3/2022 9:34 AM, Marco Atzeri wrote:
Hi Guys,
I noticed, from time to time, that on recent Cygwin
$ uname -svr
CYGWIN_NT-10.0 3.3.3(0.341/5/3) 2021-12-03 16:35
there seems to be a "failed race (?)" using the clipboard
$ putclip < Announce_geos
Unable to open the clipboard
Hi Marco,
On 1/2/2022 12:22 PM, Marco Atzeri wrote:
On 05.12.2021 10:34, Achim Gratz wrote:
In order for cygport to work correctly when autoconf 2.71 is requested,
please pull the first commit (b25cb3faa) on my to-upstream branch into
upstream and release a new version. I'd appreciate if the full
On 12/30/2021 5:38 AM, Achim Gratz wrote:
Am 29.12.2021 um 17:12 schrieb Jon Turney:
I think this was the case, at one time.
As I said before, at least info still does; not directly, though (it requires a
bunch of Perl module distribution that will then pull in perl_base at least).
No,
On 12/29/2021 4:44 PM, Gary Johnson wrote:
So, I have
a workaround for the problem, but I'd really like a proper fix, and
there may be other users with this problem.
w3m currently has no maintainer. Would you like to take over?
Ken
--
Problem reports: https://cygwin.com/problems.html
On 12/26/2021 6:12 PM, Ken Brown wrote:
There are some fixes (though not pipe-related) pending for 3.3.4, so I'll push
it to the 3.3 branch after I've heard from Takashi and/or Corinna.
Takashi must be unavailable also, but it's a simple enough fix that I decided to
go ahead and push
On 12/29/2021 3:51 AM, Achim Gratz wrote:
Am 28.12.2021 um 11:57 schrieb Marco Atzeri:
I had the impression it was in the Base category
@ perl_base
sdesc: "Perl programming language interpreter"
ldesc: "Perl programming language interpreter
That split was indeed made to enable making it
On 12/28/2021 3:37 PM, Jim Reisert AD1C wrote:
I'm using the test version of Emacs 28.0.60. I can't seem to load
css-mode (Cascading Style Sheets). I get the following error in the
console window:
0 [main] emacs-X11 1297 child_info_fork::abort: address space
needed by
On 12/26/2021 6:23 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
On 12/26/2021 5:43 PM, Jeremy Drake wrote:
My loops are still going after an hour. I know that ARM64 would have hit
the assert before now.
Well, ARM64 hung up, but didn't hit the assert, so maybe there's some
On 12/26/2021 5:43 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
+ /* NtQueryInformationProcess can return STATUS_SUCCESS with
+invalid handle data for certain processes. See
+
https://github.com/processhacker/processhacker/blob/master/phlib
On 12/26/2021 4:35 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
On 12/26/2021 11:04 AM, Ken Brown wrote:
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation)
can return STATUS_SUCCESS with invalid handle
On 12/26/2021 11:04 AM, Ken Brown wrote:
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can
return STATUS_SUCCESS with invalid handle information. See the comment
starting at line 5754, where it is shown how to detect
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can
return STATUS_SUCCESS with invalid handle information. See the comment starting
at line 5754, where it is shown how to detect this.
If I'm right, the following patch should
On 12/25/2021 11:56 PM, Jeremy Drake wrote:
I set up a windows server 2022 VM last night and went nuts stressing
pacman/GPGME. I was able to reproduce the issue there:
status = 0x, phi->NumberOfHandles = 8261392, n_handle = 256
[#--] 14%
assertion
On 12/25/2021 6:00 PM, Jeremy Drake via Cygwin-patches wrote:
On Sat, 25 Dec 2021, Jeremy Drake via Cygwin-patches wrote:
On Sun, 26 Dec 2021, Takashi Yano wrote:
Could you please check the result of the following test case
in that ARM64 platform?
OK, on Windows 11 ARM64 (same machine
On 12/25/2021 2:20 PM, Jeremy Drake via Cygwin-patches wrote:
On Sun, 26 Dec 2021, Takashi Yano wrote:
Could you please check the result of the following test case
in that ARM64 platform?
I will probably not be able to get to this until tomorrow at the earliest.
But keep in mind the issue
On 12/24/2021 2:42 PM, Jeremy Drake wrote:
On Fri, 24 Dec 2021, Ken Brown wrote:
I agree that it's hard to see how the line you quoted could cause an
exception. But you were using an optimized build, so I'm not sure how
reliable the line-number information is.
Is it feasible to run your test
On 12/23/2021 7:29 PM, Jeremy Drake via Cygwin-patches wrote:
On Thu, 23 Dec 2021, Ken Brown wrote:
- for (ULONG j = 0; j < phi->NumberOfHandles; j++)
+ for (ULONG j = 0; j < min(phi->NumberOfHandles, n_handle); j++)
Reading the preceding code, I don't see how n_
On 12/23/2021 6:10 PM, Jeremy Drake via Cygwin-patches wrote:
diff --git a/winsup/cygwin/fhandler_pipe.cc
b/winsup/cygwin/fhandler_pipe.cc
index ba6b70f55..48713a38d 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1239,7 +1239,7 @@
On 12/23/2021 12:35 PM, Brian Inglis wrote:
Building cygwin 32 doc (with latest packages, git sources, after running
winsup/autogen.sh) get the following doc build failure (not on cygwin 64 - all
builds okay) - anyone seen this before and any clue where to look?
$ ../configure && make
...
On 12/20/2021 12:02 PM, Ken Lobb wrote:
I'm probably missing something that needs to be configured, but I'm trying
to utilize uptime & vmstat and other performance/load utilities in Cygwin.
I installed the libprocps8 package, but none of these utilities can be
found.
Did I miss something?
On 12/10/2021 12:12 PM, Kutty, Rejeesh wrote:
Google says it is part of the Beyond Trust stuff, for security?
I couldn't find anything that tells me how to disable it.
Is this DLL the problem?
Could be. Is Beyond Trust something that you have control over? Can you
uninstall it, or
On 12/10/2021 9:39 AM, Kutty, Rejeesh wrote:
I can't launch setup-x86_64.exe, but setup-x86 runs fine.
[...]
ModLoad: 7ffd`4371 7ffd`4374a000 C:\WINDOWS\SYSTEM32\privman64.dll
What is this and why is it being loaded?
Ken
--
Problem reports:
On 12/9/2021 5:24 AM, Corinna Vinschen wrote:
On Dec 8 19:46, Achim Gratz wrote:
Achim Gratz writes:
+ case "${WANT_AUTOCONF}" in
+ 2.5|'')
+ WANT_AUTOCONF=2.5
+ case $(autoconf --version 2> /dev/null | head -n 1) in
On 9/15/2021 5:13 PM, Ken Brown via Cygwin-announce via Cygwin wrote:
The following packages have been uploaded to the Cygwin distribution as test
releases:
* gd-2.3.3-1
* libgd3-2.3.3-1
* libgd-devel-2.3.3-1
These have now been promoted from test to current.
Ken
--
Problem reports
[Redirected from the cygwin list,
https://cygwin.com/pipermail/cygwin/2021-December/250149.html]
On 12/7/2021 3:08 PM, Ken Brown wrote:
On 12/5/2021 3:50 AM, Achim Gratz wrote:
Autoconf upstream has stated that the 2.7x releases are not fully
backwards compatible. Cygwin therefore chose
On 12/5/2021 3:50 AM, Achim Gratz wrote:
Autoconf upstream has stated that the 2.7x releases are not fully
backwards compatible. Cygwin therefore chose to provide a new
autoconf2.7 package (keeping autoconf2.5 available) and modifying the
wrapper script to allow packaging systems to set
On 12/5/2021 3:50 AM, Achim Gratz wrote:
Autoconf has been updated to the latest upstream release 2.71, see the
packaging notes below. Additionally the automake wrapper has been
updated to the latest upstream version 15 (with some modifications for
Cygwin).
Great work, thanks for doing this.
On 12/2/2021 2:51 PM, Achim Gratz wrote:
As discussed in another thread, Cygwin should have an autoconf2.7
package going forward. It builds just out of the box, so here's the ITP
for it.
Playground (based on autotools2.5, I'll cut the old history in the new repo):
On 12/2/2021 8:32 AM, Corinna Vinschen via Cygwin-apps wrote:
On Dec 2 14:18, ASSI wrote:
As I said, I haven't looked at it in any detail, but it seems that
autoconf is already multi-version, so I guess it would be possible to
introduce an autoconf2.7 package in addition to the existing two.
On 12/2/2021 5:15 AM, Jan Nijtmans via Cygwin-apps wrote:
Somewhere in cygport, a check is done for the autoconf version, please
change this check to allow autoconf 2.71 (as well as 2.59 and 2.69).
Then I can put back the "cygautoreconf" line in tcl.cygport.
You can do this locally until
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 provided by the
On 11/28/2021 11:33 AM, Achim Gratz wrote:
Ken Brown via Cygwin-apps writes:
It's gnulib that changed, not Cygwin or gcc/binutils. This is
actually an old issue:
https://cygwin.com/pipermail/cygwin/2010-April/186342.html
I've built the exact same package (man-db) this Febrary without
On 11/28/2021 10:42 AM, Achim Gratz wrote:
Yaakov Selkowitz via Cygwin-apps writes:
For anyone else who bumps into this, gdb and strace are of no use in
debugging this crash. I finally thought to look at the stackdump
file, and the second address from the top was in a gnulib file. That
was
On 11/26/2021 12:34 PM, Brian Inglis wrote:
On 2021-11-26 06:08, Ken Brown via Cygwin-apps wrote:
On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:
Add gl_cv_have_weak=no to cygconf?
Are you suggesting maintainers should do this, or are you talking about
patching cygport, like
On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:
Add gl_cv_have_weak=no to cygconf?
Are you suggesting maintainers should do this, or are you talking about patching
cygport, like this:
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index
According to https://cygwin.com/packages/summary/cygport-src.html, the cygport
git repo is at
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/cygport.git
But that repo is empty. The correct URL seems to be
https://cygwin.com/git/?p=cygwin-apps/cygport.git
Ken
On 9/29/2021 7:46 PM, Brian Inglis wrote:
There is a gnulib bug in threadlib.m4 from at least serial 29 to serial
31 that incorrectly configures Cygwin support of weak references.
This leads to SIGSEGV stack smashing crashes with no backtrace
@ 0x1 or 0x0005 etc.
Patch attached. Takashi, since you wrote the analogous patch for pipes, could
you take a look?
Thanks.
KenFrom 4f47e64b11ed8d47c62fa89e9b971f44b7e9ab75 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 23 Nov 2021 11:40:56 -0500
Subject: [PATCH] Cygwin: fhandler_fifo::raw_read: handle
Patch attached.From 6d34b62cb8e192071e193516c23419854c3b4127 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 23 Nov 2021 10:13:43 -0500
Subject: [PATCH] Cygwin: fhandler_pipe::raw_read: fix handle leak
Slightly rearrange the code to avoid returning without closing the
event handle
On 11/19/2021 7:07 PM, Andrey Repin via Cygwin wrote:
alternatives is known to make links to nonexistent objects. While this is
possible on *NIX, you can only link to existing objects on Windows.
You're talking about native Windows symlinks, not Cygwin symlinks. The latter
can point to
On 9/8/2020 4:57 PM, Andrew Schulman via Cygwin-announce wrote:
[...]
You can install any number of these packages side-by-side. Separate
packages are needed because in order to synchronize your files, you have to
run compatible versions of Unison on the client and server. Two Unison
executables
On 11/17/2021 3:08 AM, Takashi Yano wrote:
- Call set_pipe_non_blocking(false) only if the pipe will be really
inherited to non-cygwin process.
LGTM, but Corinna should probably take a quick look too, since I'm not very
familiar with this part of the code.
Ken
On 11/16/2021 9:33 AM, Takashi Yano wrote:
- NtReadFile() and NtWriteFile() seems to return STATUS_PENDING
occasionally even in nonblocking mode. This patch adds handling
for STATUS_PENDING in nonblocking mode.
I haven't tested (I assume you have), but LGTM except for two typos below.
On 11/12/2021 12:50 PM, Brian Inglis wrote:
Got these errors trying to build latest ncurses on my system, so retried on
scallywag and got same result, with no clue where that is coming from!
There are no files in the tarball, repo, or build dirs containing 7.4.0
Those paths come from
On 11/10/2021 1:42 PM, Henry S. Thompson wrote:
Ken Brown writes:
The good news is that the bug doesn't seem to occur in XEmacs 21.4
(on 32-bit Cygwin). So one way to approach this would be to bisect
the XEmacs git repo to find the commit that introduced the bug.
You'd probably have to do
On 11/11/2021 4:47 AM, Corinna Vinschen wrote:
On Nov 10 17:22, Ken Brown wrote:
I can't immediately think of anything. But is it really impossible to phase
out DOS path support over a period of time? We could start with a HEADS-UP,
asking for comments, then a deprecation announcement
On 11/10/2021 3:32 PM, corinna-cyg...@cygwin.com wrote:
From: Corinna Vinschen
As I told Takashi in PM, I will try to more often send patches to the
cygwin-patches ML before pushing them, so there's a chance to chime in.
LGTM.
This patch series is supposed to address the `rm -rf' problem
On 11/10/2021 1:45 PM, Henry S. Thompson via Cygwin wrote:
for Ken Brown and Takashi Yano, don't you think?
Even though we made XEmacs unusable?!? :)
But seriously, it was a joint effort among the two of us and Corinna.
Thanks.
Ken
--
Problem reports: https://cygwin.com/problems.html
On 11/10/2021 12:23 PM, Henry S. Thompson wrote:
Ken Brown via Cygwin writes:
On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote:
Back to the drawing board.
It finally occurred to me to stop looking for a bug in
fhandler_pipe::raw_read and instead see if something is in fact
repeatedly
On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote:
Back to the drawing board.
It finally occurred to me to stop looking for a bug in fhandler_pipe::raw_read
and instead see if something is in fact repeatedly writing to the pipe, so that
drain_signal_event_pipe never finishes. Putting
On 11/9/2021 5:20 PM, Ken Brown via Cygwin wrote:
On 11/9/2021 5:16 PM, Ken Brown via Cygwin wrote:
On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote:
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
As you may know, the XEmacs situation is complicated. The old source
repo (bitbucket.org/xemacs
09:11:28 -0500
Ken Brown wrote:
I'll have to reproduce the hang myself in order to test this (or maybe you could
test it), but I now have a new guess: If the read call above keeps failing with
EINTR, then we're in an infinite loop. This could happen because of the
following code in fhandler_pipe
On 11/9/2021 5:16 PM, Ken Brown via Cygwin wrote:
On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote:
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
As you may know, the XEmacs situation is complicated. The old source
repo (bitbucket.org/xemacs) no longer exists. There's a fork that's
still
On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote:
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
As you may know, the XEmacs situation is complicated. The old source
repo (bitbucket.org/xemacs) no longer exists. There's a fork that's
still being maintained, but it's not widely publicised
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
Ken Brown via Cygwin writes:
On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote:
Running on Windows-10 21H1
With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs:
..
#6 0x00018013ffcc in read (fd=3, ptr
On 11/8/2021 9:35 AM, Ken Brown via Cygwin wrote:
On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote:
Running on Windows-10 21H1
With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs:
#0 0x7ffdf31cd474 in ntdll!ZwQueryTimer ()
from /c/Windows/SYSTEM32
On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote:
Running on Windows-10 21H1
With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs:
#0 0x7ffdf31cd474 in ntdll!ZwQueryTimer ()
from /c/Windows/SYSTEM32/ntdll.dll
#1 0x0001800479fa in cygwait (object=,
On 11/5/2021 4:08 PM, Ken Brown via Cygwin wrote:
On 11/5/2021 3:41 PM, Takashi Yano via Cygwin wrote:
What about setting pipe mode to byte by default?
I have a vague recollection that this caused some other problem, but I'll have
to review the email discussions from a few months ago. I'm
Hi Takashi,
On 11/5/2021 3:41 PM, Takashi Yano via Cygwin wrote:
Thanks much for the detailed steps. I could reproduce the problem.
It seems that the cause is the overhaul for the pipe implementation.
I also found the workaround for this issue. Please try:
export CYGWIN=pipe_byte
Corinna,
On 10/17/2021 6:15 PM, Ken Brown via Cygwin wrote:
On 10/17/2021 4:52 PM, Chris Roehrig wrote:
Here's a script that pretty reliably hangs cat after some iterations.
[...]
Thanks! I can reproduce the hang. I'll look into it.
I've done some debugging and have followed up on the cygwin
On 10/18/2021 3:15 PM, Jim Reisert AD1C wrote:
Here is a macro I use quite frequently, with a line like this:
# New Exception Call: PD0TEST/J
The macro consists of:
- CTRL-A
- set mark
- CTRL-F until you get to the start of the field after Call:
- CTRL-W to delete the selected text
-
On 10/23/2021 1:35 AM, Mark Geisert wrote:
Corinna Vinschen wrote:
Just to close this up prior to the 3.3.0 release...
Given we never actually strived for 32<->64 bit interoperability, it's
hard to argue why this should be different for the clipboard stuff.
Running 32 and 64 bit Cygwin
On 10/18/2021 9:43 PM, OwN-3m-All via Cygwin wrote:
I upgraded both libharfbuzz0 and libfreetype6 to the latest version again,
and the issues are back.
I tested these previous versions for both, and they work:
libharfbuzz0 2.7.4-1 and 2.8.1-1 work
libfreetype6 2.10.4-1 and 2.10.4-2 work
The
the fork problems
reported here:
https://cygwin.com/pipermail/cygwin/2021-October/249610.html
Ken Brown
Cygwin's harfbuzz maintainer
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
/cygwin/2021-October/249610.html
Ken Brown
Cygwin's FreeType2 maintainer
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
the fork problems
reported here:
https://cygwin.com/pipermail/cygwin/2021-October/249610.html
Ken Brown
Cygwin's harfbuzz maintainer
/cygwin/2021-October/249610.html
Ken Brown
Cygwin's FreeType2 maintainer
On 10/19/2021 6:11 AM, Friedrich Romstedt via Cygwin wrote:
Hi,
Some months ago (in August 2021) I tried using ImageTk in Python on
Cygwin and stumbled over a dysfunction. To help tracking down the
issue I wrote up an HTML document and uploaded it to
On 10/18/2021 4:43 PM, OwN-3m-All via Cygwin wrote:
Since those are the two DLLs that are causing a problem for you, maybe
that
circular dependency doesn't work well on Cygwin for some reason. Please
try
downgrading to the previous versions of harfbuzz and freetype2 and see if
that
fixes
On 10/17/2021 4:52 PM, Chris Roehrig wrote:
Here's a script that pretty reliably hangs cat after some iterations.
[...]
Thanks! I can reproduce the hang. I'll look into it.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
On 10/16/2021 1:42 PM, Chris Roehrig wrote:
On Mon Sep 27 2021, at 7:26 AM, Ken Brown via Cygwin wrote:
On 9/26/2021 8:57 PM, Chris Roehrig wrote:
I have installed this (completely this time) and have encountered no issues
with it. I'm getting full gigabit speeds with my rsync transfers
On 10/16/2021 9:49 PM, OwN-3m-All via Cygwin wrote:
Hopefully I can strace at some point soon and get back to you with the
results.
I have multiple confirmed reports from other people that this no longer
works though. And again, I tried it on three different fresh installs of
different Windows
On 10/15/2021 4:04 PM, OwN-3m-All via Cygwin wrote:
Downgrading (choosing lower versions) httpd and httpd-mod_php7 didn't
help. Same issue. It appears to be something cygwin specific and not
package related? I don't know...
Running the httpd command under strace might provide a clue. See
On 10/14/2021 10:38 AM, Jim Reisert AD1C wrote:
I have noticed one slight performance issue, which may not be related
to Cygwin at all.
After creating a keyboard macro, the first time the macro is
used/called (^x^e), it does not start right away. Subsequent uses are
as fast as expected. Could
PS files into a number of graphics file formats.
This is an update to the latest upstream release. See
http://www.ghostscript.com/doc/9.55.0/News.htm
for a summary of the changes since the previous release.
Ken Brown
Cygwin's Ghostscript maintainer
--
Problem reports: https
PS files into a number of graphics file formats.
This is an update to the latest upstream release. See
http://www.ghostscript.com/doc/9.55.0/News.htm
for a summary of the changes since the previous release.
Ken Brown
Cygwin's Ghostscript maintainer
On 10/11/2021 2:13 AM, Mark Geisert wrote:
It's just that after submitting the patch I realized that, if we really are
going to support both Cygwin archs (x86_64 and i686), there is still the issue
of different cygcb_t layouts between Cygwin versions being ignored.
Specifically, the
On 10/9/2021 8:49 PM, Takashi Yano wrote:
- If the process having master pty opened is forked, attach_mutex
fails to be closed when master is closed. This patch fixes the
issue.
---
winsup/cygwin/fhandler_console.cc | 2 +-
winsup/cygwin/fhandler_tty.cc | 6 +++---
2 files changed,
provides it.
This struct should maybe be in sys/cygwin.h or similar, if it's expected to be
used in user-space as well.
Good idea.
On 09/10/2021 15:19, Ken Brown wrote:
On 10/8/2021 5:52 AM, Takashi Yano wrote:
How about simply just:
diff --git a/winsup/cygwin/fhandler_clipboard.cc
b/wins
On 10/8/2021 5:52 AM, Takashi Yano wrote:
How about simply just:
diff --git a/winsup/cygwin/fhandler_clipboard.cc
b/winsup/cygwin/fhandler_clipboard.cc
index ccdb295f3..d822f4fc4 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -28,9 +28,10 @@
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
---
On 10/7/2021 4:21 PM, Jim Reisert AD1C wrote:
I'm about to announce a new test release that tries to work around the problem
in a different way. I'd be interested in hearing how that works too.
I updated Emacs and turned off "native-comp-async-query-on-exit".
This time, there was no error
up (which you should do with no cygwin processes
running). But it is not currently done when new .eln files are
created. This is mostly a problem on 32-bit Cygwin and is not yet
solved. The main purpose of this test release of Emacs is to find out
if it is likely to be a problem in the 64-
up (which you should do with no cygwin processes
running). But it is not currently done when new .eln files are
created. This is mostly a problem on 32-bit Cygwin and is not yet
solved. The main purpose of this test release of Emacs is to find out
if it is likely to be a problem in the 64-
On 10/7/2021 10:16 AM, Jim Reisert AD1C wrote:
Could this be the following problem that I mentioned in the release
announcement?
Compilation is done asynchronously, with a log in a buffer called
*Async-native-compile-log*. If you run emacs-w32 and exit while a
compilation is in progress, you
On 10/6/2021 4:22 PM, Jon Turney wrote:
On 06/10/2021 17:23, Jon Turney wrote:
On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote:
This seems to work, with one caveat. Suppose package P requires feature f,
and packages Q, R, S,... provide f. If the user selects P and one or more of
Q, R
On 10/6/2021 11:38 AM, Ken Brown via Cygwin wrote:
On 10/6/2021 10:22 AM, Jim Reisert AD1C wrote:
The test release of GNU Emacs 28.0.50 crashed on me when using
emacs-w32. I can repeat this every time. I attached the trace and
stackdump.
Windows 11 Pro 64-bit
Take Command 27.01.24 x64
Opened
On 10/6/2021 10:22 AM, Jim Reisert AD1C wrote:
The test release of GNU Emacs 28.0.50 crashed on me when using
emacs-w32. I can repeat this every time. I attached the trace and
stackdump.
Windows 11 Pro 64-bit
Take Command 27.01.24 x64
Opened a text file using emacs-w32
Ctrl-X Ctrl-C to exit
On 10/5/2021 2:24 PM, Achim Gratz wrote:
Ken Brown via Cygwin-apps writes:
There are currently five emacs packages: emacs-common, emacs,
emacs-X11, emacs-w32, and emacs-lucid. The first includes things that
are needed by each of the other four, and those four each include an
emacs binary
On 10/5/2021 12:58 PM, Brian Inglis wrote:
On 2021-10-05 09:51, Ken Brown via Cygwin-apps wrote:
I asked this question several years ago
(https://cygwin.com/pipermail/cygwin-apps/2018-October/039451.html), but I'm
repeating it, in a more specific form, in the hope that setup has progressed
The current setup sources fail to build because ~StringChoiceOption is not
defined:
CXXLDsetup.exe
/usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld:
io_stream_cygfile.o:/home/kbrown/src/cygsetup/x86_64/../setup/io_stream_cygfile.cc:40:
undefined reference to
301 - 400 of 4636 matches
Mail list logo
