On Tue, 8 Apr 2025 at 12:48, Corinna Vinschen via Cygwin
wrote:
>
> On Apr 3 14:28, Jeremy Drake via Cygwin wrote:
> > On Wed, 2 Apr 2025, Cedric Blancher via Cygwin wrote:
> >
> > > On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin
> > > wrote:
> > > > No, but if we want to *better* supp
On Tue, 17 Jun 2025, Sebastian Feld via Cygwin wrote:
> Now that Microsoft is porting Cygwin to Aarch64:
>
> Do you know how to run Windows Aarch64 in qemu, so people can test
> Cygwin Aarch64 changes?
>
> Sebi
Yes, but as others have said it is too slow to really be practical.
What I've done la
On Tue, Jun 17, 2025 at 12:36 PM Radek Barton via Cygwin
wrote:
> We have never considered QEMU as an option so I can't tell whether it's
> working.
IMO someone at Microsoft engineering management should look at the
issue that Windows-11 does not work on qemu.
Right now there are no ARM64 builds
On Tue, Jun 17, 2025 at 9:57 AM Sebastian Feld via Cygwin
wrote:
> Now that Microsoft is porting Cygwin to Aarch64:
>
> Do you know how to run Windows Aarch64 in qemu, so people can test
> Cygwin Aarch64 changes?
I use this script for Windows 11 experiments (same as
https://nrubsig.kpaste.net/3ac
Hello,
I downloaded the ISO for Windows on ARM64 from Microsoft site and I
installed it with QEMU, but it is absolutely unusable. For example, if you
click on the start button, the menu start to open after 10 seconds. You can
go to tale a coffee if you try to open notepad for example. It happens al
oject.
Radek
From: Cygwin on behalf of
Sebastian Feld via Cygwin
Sent: Tuesday, June 17, 2025 11:01 AM
To: cygwin@cygwin.com
Subject: [EXTERNAL] Re: Cygwin AArch64 testing with Windows AArch64 on qemu?
On Tue, Jun 17, 2025 at 10:10 AM Arthur Norman wrote:
>
> Thanka fo
On Tue, Jun 17, 2025 at 10:10 AM Arthur Norman wrote:
>
> Thanka for the head up - can you provide us with a pointer to Microsoft
> work on Cygwin please?
Check the cygwin-patches mailing list, and the cygwin git log. Lots of
Aarch64 related patches.
> On a Raspberry Pi 5 "botspot-VM" https://gi
Thanka for the head up - can you provide us with a pointer to Microsoft
work on Cygwin please?
On a Raspberry Pi 5 "botspot-VM" https://github.com/Botspot/bvm installed
a Win11 for me fairly happily and despite it not being the fastest machine
it is closer to viable than I might have expected
On Thu, Apr 10, 2025 at 8:14 PM Sebastian Feld
wrote:
>
> Could the maximum symlink depth in Cygwin please be increased for
> cygwin 3.7? We're regularly hitting that limit (seems to be 10).
>
> What is the maximum number of symlink recursion? Rumor is that this is
> 32, but I cannot find it in an
On Mon, 17 Feb 2025 at 11:07, Corinna Vinschen via Cygwin
wrote:
>
> On Feb 16 16:27, Sebastian Feld via Cygwin wrote:
> > On Sat, Feb 15, 2025 at 4:15 PM Cedric Blancher via Cygwin
> > wrote:
> > >
> > > Good afternoon!
> > >
> > > Could Cygwin 3.6 please support fcntl(...,F_FREESP,...) and
> >
On Wed, 4 Jun 2025, Don Slutz via Cygwin wrote:
> Using 3.6.1-1 works fine. I am very sure this is based on the same issue that
> others have reported.
>
> looks like the key in that I get for "getent passwd $(id -u)":
>
> NASUNI+dslutz:*:4096:4096:U-NASUNI\dslutz,S-1-12-1-3596282818-121614275
Hi,
> I see only 1 file 'virc' on my up-to-date cygwin:
> /etc/defaults/etc/virc
This was driving me nuts, I could not reproduce or test the problem.
It turns out that downgrading vim from 9.1.1054-1 to 9.0.2155-2
removes /etc/defaults/etc/virc
and upgrading again does not restore it.
It this
I wrote:
> I want to let this rest for now
So only THEN did I notice:
https://sourceware.org/pipermail/cygwin/2025-January/257212.html
where Marco Atzeri says it will be fixed in the next cygwin release.
Perhaps I misunderstand this.
I see only 1 file 'virc' on my up-to-date cygwin:
/etc/defaul
Hi,
Lee wrote:
> Did /usr/share/vim/vim91/filetype.vim change?
> That's what was causing all the errors in the original post
I only did a quick test to make my previous posts complete and correct.
/usr/share/vim/vim91/filetype.vim is part of vim-common, so it _should_ be
unchanged. I have not ch
On Sun, Jun 1, 2025 at 11:16 AM andkin773--- via Cygwin
wrote:
>
> Hi,
>
> I missed something,
> According to
> https://github.com/vim/vim/issues/17039 :
> > Looks like problem was introduced in 9.1.1054-1
>
> I downgraded vim to check:
> $ cygcheck -c | grep vim
> vim 9.0.21
(I'm not sure if this reply is addressed correctly for the mailing list)
> did
> alias view >/dev/null 2>&1 || alias view=vim -R
> need quotes also ?
Yes.
To be honest, I don't understand why you ask this?
It's easier to see in interactive bash:
$ alias view=vim -R
-bash: alias: -R: not found
$
Hi,
I missed something,
According to
https://github.com/vim/vim/issues/17039 :
> Looks like problem was introduced in 9.1.1054-1
I downgraded vim to check:
$ cygcheck -c | grep vim
vim 9.0.2155-2 OK
vim-common 9.1.1054-1 Incomp
On Sat, May 31, 2025 at 11:37 AM andkin773--- via Cygwin
wrote:
>
> Hi,
>
> I think I found a problem in the Cygwin package vim.
> The same symptom has been reported earlier to both vim and Cygwin, but I
> think the problem has not yet been found.
> https://sourceware.org/pipermail/cygwin/2025-Ja
Thank you for your research, and proposed fix
I had noticed this to from time to time.
did
alias view >/dev/null 2>&1 || alias view=vim -R
need quotes also ?
On Sat, May 31, 2025 at 8:50 AM andkin773--- via Cygwin
wrote:
> Hi,
>
> Oops, I forgot the quotes for the aliases.
> It should be:
>
>
Hi,
Oops, I forgot the quotes for the aliases.
It should be:
alias ex>/dev/null 2>&1 || alias ex="vim -e"
alias rvi >/dev/null 2>&1 || alias rvi="vim -Z"
alias rview >/dev/null 2>&1 || alias rview="vim -RZ"
alias view >/dev/null 2>&1 || alias view="vim -R"
Regards,
Coen
-
2:41 PM
To: Eric Johanson
Cc: cygwin@cygwin.com
Subject: Re: Cygwin Installation app has Rendering Problems when multiple
monitors have different scaling settings
On 25/04/2025 16:18, Eric Johanson via Cygwin wrote:
> I'm using Cygwin installer 2.933 (x86_64). My Windows 11 comput
On 25/04/2025 16:18, Eric Johanson via Cygwin wrote:
I'm using Cygwin installer 2.933 (x86_64). My Windows 11 computer
has multiple monitors: the "main display" has scaling set to 200%
and the other monitor has scaling set to 150%. (The scaling is
configured in the native Windows display settin
Hi,
On 8/04/2025 9:14 pm, Corinna Vinschen via Cygwin wrote:
On Apr 4 16:23, Shaddy Baddah via Cygwin wrote:
On 4/04/2025 10:02 am, Shaddy Baddah via Cygwin wrote:
Hi,
On 4/04/2025 4:49 am, ASSI via Cygwin wrote:
Shaddy Baddah via Cygwin writes:
If I connect an SSH session via the "native"
This issue was resolved after a pc restart, thanx.
On Sun, 13 Apr 2025 at 09:07, Siva kumar wrote:
> Hi all,
> My Cygwin was working perfectly until yesterday. I installed Python 3.13
> and pip and Ansible through Win powershell. I think this corrupted cygwin.
> Now Cygwin is giving fork errors
On Apr 4 16:23, Shaddy Baddah via Cygwin wrote:
>
> On 4/04/2025 10:02 am, Shaddy Baddah via Cygwin wrote:
> > Hi,
> >
> > On 4/04/2025 4:49 am, ASSI via Cygwin wrote:
> > > Shaddy Baddah via Cygwin writes:
> > > > If I connect an SSH session via the "native" OpenSSH instance
> > > > integrated
On Apr 3 14:28, Jeremy Drake via Cygwin wrote:
> On Wed, 2 Apr 2025, Cedric Blancher via Cygwin wrote:
>
> > On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin
> > wrote:
> > > No, but if we want to *better* support this driver, we need either a
> > > patch (preferred) or at least info how
On 4/04/2025 10:02 am, Shaddy Baddah via Cygwin wrote:
Hi,
On 4/04/2025 4:49 am, ASSI via Cygwin wrote:
Shaddy Baddah via Cygwin writes:
If I connect an SSH session via the "native" OpenSSH instance
integrated into Windows, I can do something like the following to a,
at the time, online only,
Hi,
On 4/04/2025 4:49 am, ASSI via Cygwin wrote:
Shaddy Baddah via Cygwin writes:
If I connect an SSH session via the "native" OpenSSH instance
integrated into Windows, I can do something like the following to a,
at the time, online only, not yet downloaded file, and OneDrive will
download it a
On Tue, 1 Apr 2025 at 12:29, Cedric Blancher via Cygwin
wrote:
>
> On Tue, 1 Apr 2025 at 09:46, Cedric Blancher
> wrote:
> >
> > Good morning!
> >
> > For your consideration - we need FEEDBACK, please!
> >
> > New is:
> > - 2nd Spring-Release (🐝)
> > - Improved Windows Extended Attribute (EA) su
On Wed, 2 Apr 2025, Cedric Blancher via Cygwin wrote:
> On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin
> wrote:
> > No, but if we want to *better* support this driver, we need either a
> > patch (preferred) or at least info how to distinguish in
> > fs_info::update(*) between the MSFT d
On 2025-04-03 02:14, Sebastian Feld via Cygwin wrote:
On Tue, Apr 1, 2025 at 12:30 PM Cedric Blancher via Cygwin wrote:
New thread:
Does Cygwin have any requests, or ideas, what could be improved in the
ms-nfs41-client NFSv4.2 driver for Windows? New features?
Windows GUI installer, which a
Shaddy Baddah via Cygwin writes:
> If I connect an SSH session via the "native" OpenSSH instance
> integrated into Windows, I can do something like the following to a,
> at the time, online only, not yet downloaded file, and OneDrive will
> download it ahead of outputing it:
[…]
> But if I connect
On Thu, 3 Apr 2025 at 09:15, Shaddy Baddah via Cygwin wrote:
>
> Hi,
>
> Just for a bit of context, Windows supports Cloud synced files via
> Cloud Storage Providers
> (https://learn.microsoft.com/en-us/windows/win32/shell/integrate-cloud-storage)
>
> The main one is OneDrive, I also use NextCloud
On Tue, Apr 1, 2025 at 12:30 PM Cedric Blancher via Cygwin
wrote:
>
> On Tue, 1 Apr 2025 at 09:46, Cedric Blancher
> wrote:
> >
> > Good morning!
> >
> > For your consideration - we need FEEDBACK, please!
> >
> > New is:
> > - 2nd Spring-Release (🐝)
> > - Improved Windows Extended Attribute (EA)
On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin
wrote:
>
> On Apr 1 12:27, Cedric Blancher via Cygwin wrote:
> > On Tue, 1 Apr 2025 at 09:46, Cedric Blancher
> > wrote:
> > >
> > > Good morning!
> > >
> > > For your consideration - we need FEEDBACK, please!
> > >
> > > New is:
> > > -
On Apr 1 12:27, Cedric Blancher via Cygwin wrote:
> On Tue, 1 Apr 2025 at 09:46, Cedric Blancher
> wrote:
> >
> > Good morning!
> >
> > For your consideration - we need FEEDBACK, please!
> >
> > New is:
> > - 2nd Spring-Release (🐝)
> > - Improved Windows Extended Attribute (EA) support
> > - Spa
Corinna Vinschen via Cygwin wrote:
On Mar 14 17:12, Corinna Vinschen via Cygwin wrote:
On Mar 14 16:50, Corinna Vinschen via Cygwin wrote:
On Mar 14 13:48, Christian Franke via Cygwin wrote:
$ nm /usr/lib/libbsd.dll.a | grep ' arc4random' || echo not found
not found
I guess:
- arc4random_addr
On Mar 14 17:12, Corinna Vinschen via Cygwin wrote:
> On Mar 14 16:50, Corinna Vinschen via Cygwin wrote:
> > On Mar 14 13:48, Christian Franke via Cygwin wrote:
> > > $ nm /usr/lib/libbsd.dll.a | grep ' arc4random' || echo not found
> > > not found
> > >
> > > I guess:
> > > - arc4random_addrando
On Mar 14 16:50, Corinna Vinschen via Cygwin wrote:
> On Mar 14 13:48, Christian Franke via Cygwin wrote:
> > $ nm /usr/lib/libbsd.dll.a | grep ' arc4random' || echo not found
> > not found
> >
> > I guess:
> > - arc4random_addrandom() should be removed from libcygwin.a or added to
> > cygwin/stdl
On Mar 14 13:48, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Mar 13 08:59, Christian Franke via Cygwin wrote:
> > > Problem introduced in a8891c93:
> > >
> > > $ cygcheck -f /usr/include/stdlib.h
> > > cygwin-devel-3.6.0-0.430.ga942476236b5
> > >
> > > $ cygchec
On Fri, 14 Mar 2025 15:18:45 +0100
Corinna Vinschen wrote:
> On Mar 14 21:52, Takashi Yano via Cygwin wrote:
> > On Fri, 14 Mar 2025 13:19:28 +0100
> > Corinna Vinschen wrote:
> > > On Mar 14 20:35, Takashi Yano via Cygwin wrote:
> > > > On Fri, 14 Mar 2025 11:01:25 +0100
> > > > Corinna Vinschen w
On Mar 14 21:52, Takashi Yano via Cygwin wrote:
> On Fri, 14 Mar 2025 13:19:28 +0100
> Corinna Vinschen wrote:
> > On Mar 14 20:35, Takashi Yano via Cygwin wrote:
> > > On Fri, 14 Mar 2025 11:01:25 +0100
> > > Corinna Vinschen wrote:
> > > > I don't think so. I was mulling in circles over this ton
On Fri, 14 Mar 2025 13:19:28 +0100
Corinna Vinschen wrote:
> On Mar 14 20:35, Takashi Yano via Cygwin wrote:
> > On Fri, 14 Mar 2025 11:01:25 +0100
> > Corinna Vinschen wrote:
> > > I don't think so. I was mulling in circles over this tonight
> > > (don't ask me how I slept!) and came to the same
Corinna Vinschen via Cygwin wrote:
On Mar 13 08:59, Christian Franke via Cygwin wrote:
Problem introduced in a8891c93:
$ cygcheck -f /usr/include/stdlib.h
cygwin-devel-3.6.0-0.430.ga942476236b5
$ cygcheck -f /usr/include/bsd/stdlib.h
libbsd-devel-0.12.2-2
$ gcc -c -xc - <<<'#include '
In file
On Mar 14 20:35, Takashi Yano via Cygwin wrote:
> On Fri, 14 Mar 2025 11:01:25 +0100
> Corinna Vinschen wrote:
> > I don't think so. I was mulling in circles over this tonight
> > (don't ask me how I slept!) and came to the same conclusion.
> > But here's the problem:
> >
> > I'm simply not 100%
On Fri, 14 Mar 2025 11:01:25 +0100
Corinna Vinschen wrote:
> On Mar 14 12:56, Takashi Yano via Cygwin wrote:
> > On Fri, 14 Mar 2025 08:12:36 +0900
> > Takashi Yano wrote:
> > > On Thu, 13 Mar 2025 23:46:49 +0100
> > > Corinna Vinschen wrote:
> > > > I have a slighty changed version. This one treat
On Mar 14 12:56, Takashi Yano via Cygwin wrote:
> On Fri, 14 Mar 2025 08:12:36 +0900
> Takashi Yano wrote:
> > On Thu, 13 Mar 2025 23:46:49 +0100
> > Corinna Vinschen wrote:
> > > I have a slighty changed version. This one treats anything other
> > > than 0, 1 or 2 new addresses on the stack as bug
On Fri, 14 Mar 2025 08:18:41 +0900
Takashi Yano wrote:
> On Fri, 14 Mar 2025 08:12:36 +0900
> Takashi Yano wrote:
> > On Thu, 13 Mar 2025 23:46:49 +0100
> > Corinna Vinschen wrote:
> > > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > > > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> >
On Fri, 14 Mar 2025 08:12:36 +0900
Takashi Yano wrote:
> On Thu, 13 Mar 2025 23:46:49 +0100
> Corinna Vinschen wrote:
> > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> > > > What about following patch instead of your sigdelayed patch?
>
On Fri, 14 Mar 2025 08:12:36 +0900
Takashi Yano wrote:
> On Thu, 13 Mar 2025 23:46:49 +0100
> Corinna Vinschen wrote:
> > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> > > > What about following patch instead of your sigdelayed patch?
>
On Thu, 13 Mar 2025 23:46:49 +0100
Corinna Vinschen wrote:
> On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> > > What about following patch instead of your sigdelayed patch?
> > > [...]
> > > @@ -1834,6 +1841,26 @@ _cygtls::call_signal_handl
On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> > What about following patch instead of your sigdelayed patch?
> > [...]
> > @@ -1834,6 +1841,26 @@ _cygtls::call_signal_handler ()
> >signal handler. */
> > thisfunc (thissig, &thiss
On Mar 13 08:59, Christian Franke via Cygwin wrote:
> Problem introduced in a8891c93:
>
> $ cygcheck -f /usr/include/stdlib.h
> cygwin-devel-3.6.0-0.430.ga942476236b5
>
> $ cygcheck -f /usr/include/bsd/stdlib.h
> libbsd-devel-0.12.2-2
>
> $ gcc -c -xc - <<<'#include '
> In file included from :1:
On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> On Thu, 13 Mar 2025 20:42:52 +0900
> Takashi Yano wrote:
> > After the commit:
> >
> > commit a942476236b5e39bf30c533d08df7392e326a4c6 (origin/master,
> > origin/main, origin/HEAD)
> > Author: Corinna Vinschen
> > Date: Wed Mar 12 17:17:31 2025
On Thu, 13 Mar 2025 20:42:52 +0900
Takashi Yano wrote:
> Hi Corinna,
>
> On Thu, 13 Mar 2025 10:40:48 +0100
> Christian Franke wrote:
> > Corinna Vinschen via Cygwin wrote:
> > > On Mar 12 17:06, Corinna Vinschen via Cygwin wrote:
> > >> On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
> > >>>
Hi Corinna,
On Thu, 13 Mar 2025 10:40:48 +0100
Christian Franke wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Mar 12 17:06, Corinna Vinschen via Cygwin wrote:
> >> On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
> >>> On Mar 11 12:32, Christian Franke via Cygwin wrote:
> The attached
Corinna Vinschen via Cygwin wrote:
On Mar 12 17:06, Corinna Vinschen via Cygwin wrote:
On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
On Mar 11 12:32, Christian Franke via Cygwin wrote:
The attached testcase should test the following use cases of setcontext:
- call from regular user space
Corinna wrote:
> Just pushed. Try cygwin-3.6.0-0.430.ga942476236b5 in a bit.
I could not get an xterm to come up using cygwin-3.6.0-0.429. But it
works again using cygwin-3.6.0-0.430. I wonder if it was the
swapcontext () problem or something else.
This was on Windows 11.
--
Jim Reisert AD1
On Mar 12 17:06, Corinna Vinschen via Cygwin wrote:
> On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
> > On Mar 11 12:32, Christian Franke via Cygwin wrote:
> > > The attached testcase should test the following use cases of setcontext:
> > > - call from regular user space
> > > - call from a s
On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
> On Mar 11 12:32, Christian Franke via Cygwin wrote:
> > Corinna Vinschen via Cygwin wrote:
> > > It's not quite clear to me why signal handling should be broken if
> > > setcontext is used inside a signal handler. The incyg flag is false
> > >
On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
> Theoretically, a small update to sigdelayed() would fix the issue: ather
> then poing the original IP from the signal stack after calling the
Make that:
Theoretically, a small update to sigdelayed() would fix the issue:
*R*ather then po*p*
On Mar 11 12:32, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > It's not quite clear to me why signal handling should be broken if
> > setcontext is used inside a signal handler. The incyg flag is false
> > when running the signal handler and that's correct. Theoretic
Corinna Vinschen via Cygwin wrote:
On Mar 8 12:07, Christian Franke via Cygwin wrote:
...
This is possibly a regression introduced in 3.0.6. A comparison of strace
outputs of signal handling before and after the swapcontext() calls reveals
that 'incyg' is incorrectly set after swapcontext(). A
On Mar 10 20:33, Brian Inglis via Cygwin wrote:
> On 2025-03-10 18:56, Dan Shelton via Cygwin wrote:
> > On Mon, 10 Mar 2025 at 21:24, Brian Inglis via Cygwin wrote:
> > > On 2025-03-10 04:35, Martin Wege via Cygwin wrote:
> > > > On Fri, Mar 7, 2025 at 3:42 PM Dan Shelton via Cygwin wrote:
> > > >
On 2025-03-10 18:56, Dan Shelton via Cygwin wrote:
On Mon, 10 Mar 2025 at 21:24, Brian Inglis via Cygwin wrote:
On 2025-03-10 04:35, Martin Wege via Cygwin wrote:
On Fri, Mar 7, 2025 at 3:42 PM Dan Shelton via Cygwin wrote:
Did anyone test whether Cygwin 3.6 will still work on Windows 8? I
kno
On Mon, 10 Mar 2025 at 21:24, Brian Inglis via Cygwin wrote:
>
> On 2025-03-10 04:35, Martin Wege via Cygwin wrote:
> > On Fri, Mar 7, 2025 at 3:42 PM Dan Shelton via Cygwin
> > wrote:
> >> Did anyone test whether Cygwin 3.6 will still work on Windows 8? I
> >> know, Win8 is unsupported, but app
On Mon, 10 Mar 2025 at 11:36, Martin Wege via Cygwin wrote:
>
> On Fri, Mar 7, 2025 at 3:42 PM Dan Shelton via Cygwin
> wrote:
> >
> > Hello!
> >
> > Did anyone test whether Cygwin 3.6 will still work on Windows 8? I
> > know, Win8 is unsupported, but apparently it is still needed
>
> https://cy
On 2025-03-10 04:35, Martin Wege via Cygwin wrote:
On Fri, Mar 7, 2025 at 3:42 PM Dan Shelton via Cygwin wrote:
Did anyone test whether Cygwin 3.6 will still work on Windows 8? I
know, Win8 is unsupported, but apparently it is still needed
https://cygwin.com/ front page says "The Cygwin DLL
On Fri, Mar 7, 2025 at 3:42 PM Dan Shelton via Cygwin wrote:
>
> Hello!
>
> Did anyone test whether Cygwin 3.6 will still work on Windows 8? I
> know, Win8 is unsupported, but apparently it is still needed
https://cygwin.com/ front page says "The Cygwin DLL currently works
with all recent, commer
On Mar 8 12:07, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Mar 6 13:24, Christian Franke via Cygwin wrote:
> > > Found because 'stress-ng --context 1 ...' always hangs.
> > >
> > > The attached testcase uses the example from Linux swapcontext(3) to call
> > >
Corinna Vinschen via Cygwin wrote:
On Mar 6 13:24, Christian Franke via Cygwin wrote:
Found because 'stress-ng --context 1 ...' always hangs.
The attached testcase uses the example from Linux swapcontext(3) to call the
context functions.
Just tested with 3.5.3 and it doesn't work there, eithe
On Mar 6 13:24, Christian Franke via Cygwin wrote:
> Found because 'stress-ng --context 1 ...' always hangs.
>
> The attached testcase uses the example from Linux swapcontext(3) to call the
> context functions.
Just tested with 3.5.3 and it doesn't work there, either.
So yeah, it's a bug, but i
On Mar 5 20:49, Dimitry Andric via Cygwin wrote:
> In my opinion, it is wrong that scanners rely on this information. :-)
Exactly.
> I guess something similar could be done in the Cygwin package. This is
> up to the Cygwin maintainers of course.
And that doesn't change if some distros tweak the
Guys, I already applied a patch.
Thanks,
Corinna
On Mar 5 15:51, Glenn Strauss via Cygwin wrote:
> On Wed, Mar 05, 2025 at 08:27:53PM +, Lavrentiev, Anton (NIH/NLM/NCBI)
> [C] via Cygwin wrote:
> > > We could change this to a macro instead:
> > >
> > > -static inline void setproctitle_init
On Wed, Mar 05, 2025 at 08:27:53PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
via Cygwin wrote:
> > We could change this to a macro instead:
> >
> > -static inline void setproctitle_init (int, char *[], char *[]) {}
> > +#define setproctitle_init(c, a, e)
>
> Changing to the empty marco removes
> We could change this to a macro instead:
>
> -static inline void setproctitle_init (int, char *[], char *[]) {}
> +#define setproctitle_init(c, a, e)
Changing to the empty marco removes the side effects in the arguments (such as
len++, for example),
which may silently break existing code -- so
try to make the case that Tenable needs to change it's method or get an
exception.
Best Regards,
Ted Summers
From: Dimitry Andric
Sent: Wednesday, March 5, 2025 11:50 AM
To: SUMMERS, TED
Cc: cygwin@cygwin.com
Subject: Re: Cygwin OpenSSH version detection by Tenable
CAUTION: External Email
In my opinion, it is wrong that scanners rely on this information. :-) But
putting that discussion aside, the openssh-portable distribution does not
announce its "patch level" in its version banner by default.
See e.g. https://github.com/openssh/openssh-portable/blob/master/version.h,
where SSH
On Mar 5 20:10, Dimitry Andric via Cygwin wrote:
> Maybe it's because -Wsystem-headers is not enabled? I'm unsure what
> gcc's default behavior is with -Wall, but if you add an explicit
> -Wsystem-headers you might still get that warning.
Thanks, that was the reason. With -Wsystem-headers I can r
Maybe it's because -Wsystem-headers is not enabled? I'm unsure what gcc's
default behavior is with -Wall, but if you add an explicit -Wsystem-headers you
might still get that warning.
-Dimitry
> On 5 Mar 2025, at 19:58, Corinna Vinschen via Cygwin
> wrote:
>
> On Mar 5 17:16, Christian Fran
> The error is valid because the addition of this very old C++ feature
> took a very long time :-)
Well, it may be so, but adding the parameter names in those prototype on Cygwin
end of things would be a better and less disruptive approach, IMO.
$.02,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
-
On Mar 5 17:16, Christian Franke via Cygwin wrote:
> Roland Mainz via Cygwin wrote:
> > Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system
> > /usr/include/unistd.h and clang:
> > snip
> > $ clang --version
> > clang version 8.0.1 (tags/RELEASE_801/final)
> > Target: x
Roland Mainz via Cygwin wrote:
Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system
/usr/include/unistd.h and clang:
snip
$ clang --version
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-unknown-windows-cygnus
Thread model: posix
InstalledDir: /usr/bin
$ cl
Takashi Yano via Cygwin wrote:
On Mon, 24 Feb 2025 11:29:59 +0100
Christian Franke wrote:
Found with 'stress-ng --cpu-sched 1':
Testcase (attached):
$ uname -r
3.6.0-0.387.g8cebbb2b42bf.x86_64
$ gcc -o timersig timersig.c
$ ./timersig
638: fork()=639
!...!SIGSTOP: Per
On Mar 4 12:38, Corinna Vinschen via Cygwin wrote:
> On Mar 4 12:20, Lionel Cons via Cygwin wrote:
> > On Tue, 4 Mar 2025 at 11:08, Corinna Vinschen via Cygwin
> > wrote:
> > >
> > > On Mar 3 23:07, Lionel Cons via Cygwin wrote:
> > > > On Mon, 3 Mar 2025 at 12:43, Corinna Vinschen via Cygwin
>
On Mar 4 12:20, Lionel Cons via Cygwin wrote:
> On Tue, 4 Mar 2025 at 11:08, Corinna Vinschen via Cygwin
> wrote:
> >
> > On Mar 3 23:07, Lionel Cons via Cygwin wrote:
> > > On Mon, 3 Mar 2025 at 12:43, Corinna Vinschen via Cygwin
> > > wrote:
> > > >
> > > > On Feb 28 15:36, Lionel Cons via Cy
On Tue, 4 Mar 2025 at 11:08, Corinna Vinschen via Cygwin
wrote:
>
> On Mar 3 23:07, Lionel Cons via Cygwin wrote:
> > On Mon, 3 Mar 2025 at 12:43, Corinna Vinschen via Cygwin
> > wrote:
> > >
> > > On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> > > > We've hit a scalability issue in Cygwin tod
On Mar 3 23:07, Lionel Cons via Cygwin wrote:
> On Mon, 3 Mar 2025 at 12:43, Corinna Vinschen via Cygwin
> wrote:
> >
> > On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> > > We've hit a scalability issue in Cygwin today, the application in
> > > question ran out of POSIX realtime signals (i.e. S
On Mon, 3 Mar 2025 at 12:43, Corinna Vinschen via Cygwin
wrote:
>
> On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> > We've hit a scalability issue in Cygwin today, the application in
> > question ran out of POSIX realtime signals (i.e. SIGRTMIN-SIGRTMAX).
> >
> > Could Cygwin support 128 POSIX r
On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> We've hit a scalability issue in Cygwin today, the application in
> question ran out of POSIX realtime signals (i.e. SIGRTMIN-SIGRTMAX).
>
> Could Cygwin support 128 POSIX realtime signals?
Not possible. sigset_t is an unsigned long, thus we can o
On Mon, 24 Feb 2025 11:29:59 +0100
Christian Franke wrote:
> Found with 'stress-ng --cpu-sched 1':
>
> Testcase (attached):
>
> $ uname -r
> 3.6.0-0.387.g8cebbb2b42bf.x86_64
>
> $ gcc -o timersig timersig.c
>
> $ ./timersig
> 638: fork()=639
> !...!SIGSTOP: Permission de
It seems the " -engine 1" parameter was all that was needed.
Cygwin/X now shows up on my new Windows 11 laptop, as it did on my older
one, with the saved session bringing up three xterm windows and all.
Giving me a richer experience and enabling me to work more efficiently than
when I had to start
On 19/02/2025 19:05, Erik Dybdahl via Cygwin wrote:
Actually, I found a way to make it work somehow, namely by passing "-engine
1" to XWin.exe, following a (21 year old) tip from here:
https://cygwin-xfree.cygwin.narkive.com/maSzrlKY/crash-when-remote-desktop-changes-screen-resolutions
ons. 19.
On Feb 21 12:15, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > ...
> >
> > I just deployed 0.12.2-2 as test. Apart from setproctitle{_init}, it
> > also drops exporting the following symbols already exported from Cygwin:
> >
> > arc4random*
> > explicit_bz
Corinna Vinschen via Cygwin wrote:
...
I just deployed 0.12.2-2 as test. Apart from setproctitle{_init}, it
also drops exporting the following symbols already exported from Cygwin:
arc4random*
explicit_bzero
fpurge
getprogname
reallocarray
reallocf
setprognam
On Feb 20 10:44, Corinna Vinschen via Cygwin wrote:
> On Feb 20 10:39, Corinna Vinschen via Cygwin wrote:
> > On Feb 20 08:34, Christian Franke via Cygwin wrote:
> > > Corinna Vinschen via Cygwin wrote:
> > > > I uploaded a 0.11.8-1 test package which fixes this issue. I'll
> > > > propagate it to
On Feb 20 10:39, Corinna Vinschen via Cygwin wrote:
> On Feb 20 08:34, Christian Franke via Cygwin wrote:
> > Corinna Vinschen via Cygwin wrote:
> > > I uploaded a 0.11.8-1 test package which fixes this issue. I'll
> > > propagate it to non-test when 3.6.0 is released.
> >
> > A quick test with s
On Feb 20 08:34, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Feb 19 16:37, Corinna Vinschen via Cygwin wrote:
> > > On Feb 19 14:40, Corinna Vinschen via Cygwin wrote:
> > > > On Feb 19 14:25, Christian Franke via Cygwin wrote:
> > > > > Corinna Vinschen via Cygwi
Corinna Vinschen via Cygwin wrote:
On Feb 19 16:37, Corinna Vinschen via Cygwin wrote:
On Feb 19 14:40, Corinna Vinschen via Cygwin wrote:
On Feb 19 14:25, Christian Franke via Cygwin wrote:
Corinna Vinschen via Cygwin wrote:
So I think we rather shouldn't supply the libbsd version of
setproc
On Feb 19 16:37, Corinna Vinschen via Cygwin wrote:
> On Feb 19 14:40, Corinna Vinschen via Cygwin wrote:
> > On Feb 19 14:25, Christian Franke via Cygwin wrote:
> > > Corinna Vinschen via Cygwin wrote:
> > > > So I think we rather shouldn't supply the libbsd version of
> > > > setproctitle_init/se
1 - 100 of 8442 matches
Mail list logo
