On Fri, 7 Feb 2025, Roland Mainz via Cygwin wrote:
> Hi!
>
>
>
> [Slightly offtopic, but I am banging my head against this problem most
> of the day]
> What symlink value should |MRxCreate()| return on |STATUS_REPARSE| to
> redirect to another DOS drive or UNC path ? I tried something like
>
On Fri, 7 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 6 13:31, Jeremy Drake via Cygwin wrote:
> > Now that my patch to escape characters in /proc/mounts has been applied,
> > I'll get back to what I was thinking about back in June. I would like to
> > have a way to list Windows volume
On Feb 7 11:11, Corinna Vinschen via Cygwin wrote:
> On Feb 6 13:31, Jeremy Drake via Cygwin wrote:
> > Now that my patch to escape characters in /proc/mounts has been applied,
> > I'll get back to what I was thinking about back in June. I would like to
> > have a way to list Windows volume root
On Feb 6 13:31, Jeremy Drake via Cygwin wrote:
> Now that my patch to escape characters in /proc/mounts has been applied,
> I'll get back to what I was thinking about back in June. I would like to
> have a way to list Windows volume roots in Cygwin, and it seems to make
> sense to me to expose th
Hi Jeremy,
On 2/6/2025 1:22 PM, Jeremy Drake via Cygwin wrote:
We were attempting to build util-linux 2.40.2 for MSYS2, based on the
source package of util-linux-2.40.2-2 from Cygwin [1]. We were scratching
our heads as to why it wasn't building tasksel for us, when it did in your
package. I e
On Feb 6 12:47, Andrey Repin via Cygwin wrote:
> Greetings, Corinna Vinschen via Cygwin!
>
> > On Feb 4 14:47, Jeremy Drake via Cygwin wrote:
> >> On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
> >>
> >> > it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
> >> > "remote"
Greetings, Corinna Vinschen via Cygwin!
> On Feb 4 14:47, Jeremy Drake via Cygwin wrote:
>> On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
>>
>> > it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
>> > "remote" filesystems:
>> > snip
>> > 2582/* Don't
On Wed, 5 Feb 2025 at 16:56, Corinna Vinschen via Cygwin
wrote:
>
> On Feb 4 14:47, Jeremy Drake via Cygwin wrote:
> > On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
> >
> > > it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
> > > "remote" filesystems:
> > > snip ---
I second the request; although there are (already) 240 perl packages
available in cygwin, this is an especially useful one. I would volunteer to
port it but I am, regrettably, not fluent in cygport yet. I hope to remedy
this someday, and at that time, I will be focused on bringing in new (to
cygwin
On Feb 4 14:47, Jeremy Drake via Cygwin wrote:
> On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
>
> > it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
> > "remote" filesystems:
> > snip
> > 2582/* Don't handle junctions on remote filesystems as
> > sym
>> import subprocess
> >
> > >>> subprocess.run(['./test.exe', '"', " a b c"]) # should be only 2 args
> >
> > argv[0] = ./test
> >
> > argv[1] = \
> >
> > argv[2] = a
> >
> > argv[3] = b
> >
>
Hi Marco,
> $ python3.12
> Python 3.12.8 (main, Jan 31 2025, 21:29:51) [GCC 12.4.0] on cygwin
> Type "help", "copyright", "credits" or "license" for more information.
> import subprocess
> subprocess.run(['./test.exe', '"', " a b c"])
> argv[0] = ./test
> argv[1] = "
> argv[2] = a b c
>
On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
> it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
> "remote" filesystems:
> snip
> 2582/* Don't handle junctions on remote filesystems as
> symlinks. This type
> 2583 of reparse point is handl
On Feb 4 12:08, Corinna Vinschen via Cygwin wrote:
> $ cat > mk-dev-nfs.c < [...]
Copy/Paste error, try this one:
#include
#include
#include
typedef struct {
DWORD ReparseTag;
WORD ReparseDataLength;
WORD Reserved;
struct {
BYTE DataBuffer[1];
} GenericRepa
Hi Thomas,
On Jan 30 21:59, Thomas Wolff via Cygwin wrote:
>
> Am 28.01.2025 um 09:56 schrieb Corinna Vinschen via Cygwin:
> > On Jan 28 00:50, Thomas Wolff via Cygwin wrote:
> > > Am 27.01.2025 um 12:17 schrieb Takashi Yano via Cygwin:
> > > > Hi Thomas,
> > > >
> > > > A few days ago, Corinna
On Jan 31 14:23, Roland Mainz via Cygwin wrote:
> On Thu, Jan 30, 2025 at 2:34 PM Cedric Blancher
> wrote:
> [snip]
> > Does the ms-nfs41-client support NFS_SPECFILE_FIFO and NFS_SPECFILE_SOCK?
>
> No, but if Cygwin implements this for the Microsoft NFSv3 client then
> I'll add support for ms-nfs
On 04/02/2025 07:15, Splitline Huang via Cygwin wrote:
Hello Cygwin team,
I am splitline from DEVCORE research team. I recently have observed an
inconsistency
in how Cygwin handles command-line parsing compared to Microsoft’s
implementation.
According to Microsoft’s documentation [1], the \" s
Hi all,
The 'col' executable and man page are now included in the -2 build of
its containing package. Look for util-linux-2.40.2-2 on your favorite
Cygwin download site shortly.
The -2 upgrade announcement is here:
https://cygwin.com/pipermail/cygwin-announce/2025-February/012128.html
Sorry
On 2025-01-31 06:23, Roland Mainz via Cygwin wrote:
On Thu, Jan 30, 2025 at 2:34 PM Cedric Blancher
wrote:
[snip]
Does the ms-nfs41-client support NFS_SPECFILE_FIFO and NFS_SPECFILE_SOCK?
No, but if Cygwin implements this for the Microsoft NFSv3 client then
I'll add support for ms-nfs41-clie
On Thu, Jan 30, 2025 at 2:34 PM Cedric Blancher
wrote:
[snip]
> Does the ms-nfs41-client support NFS_SPECFILE_FIFO and NFS_SPECFILE_SOCK?
No, but if Cygwin implements this for the Microsoft NFSv3 client then
I'll add support for ms-nfs41-client and ms-nfs42-client ASAP.
But I really would prefer
On 31/01/2025 13:35, Michael Cook via Cygwin-apps wrote:
After GTG (Good to Go) approval from other packagers
and you providing your SSH Key
ok, I've tested the newly built astyle.exe and it's working fine.
I infer that I need to wait for the cygwin-pkg-maint page to be updated
with my name
On 30/01/2025 23:11, Charles Perkins wrote:
Hello Marco,
After I modified the permissions I decided to re-run the setup and
install of X11. That did work without any errors. However, I am still
getting the same problem: "winMultiWindowXMsgProc - Fatal error 1 on xcb
connection"
On 31/01/2025 04:41, Mercurio, Steven W-CTR (FAA) via Cygwin wrote:
I need to install a newer version of Ansible but that required a newer version
of python. Is it hard to create a cygwin package? I tried and failed to
compile python 3.13.1 from source in cygwin.
Hi Steven,
There is a te
Am 28.01.2025 um 09:56 schrieb Corinna Vinschen via Cygwin:
On Jan 28 00:50, Thomas Wolff via Cygwin wrote:
Am 27.01.2025 um 12:17 schrieb Takashi Yano via Cygwin:
Hi Thomas,
A few days ago, Corinna asked me to check a problem of TTY.
The problem is as follows.
Reproduce steps:
(1) Open min
I eventually fixed it by gaining ownership again via:
CMD as admin
Start explorer
Properties on the Cygwin-X start menu
Security tab
Set on top of the screen the right user and check the all children
A few times yes and rerun setup.exe again
(for the more windows oriented guys like me 😊)
Hi Matthew,
On 1/29/2025 12:16 AM, Matthew "mirage335" Hines via Cygwin wrote:
/usr/bin/col.exe is apparently missing from the more recent version of the
'util-linux' package 'util-linux-2.40.2-1'
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Futil-linux%2Futil-linux-2.39.3-2&grep=u
On 29/01/2025 16:44, Takashi Yano via Cygwin wrote:
Hi Marco,
Hi Takashi,
It is not an issue of .viminfo. I removed it and
/usr/bin/vi reports anyway the issue as Achim wrote
Indeed. I reinstall vim 9.1.1054, then the issue came back...
"filetype plugin on" in /etc/virc
might be the culpr
On 29/01/2025 17:10, Michael Cook via Cygwin wrote:
The version of astyle provided by Cygwin is quite old. Version 2.06 is from
2016.
Would it be reasonable to update to the latest version?
https://astyle.sourceforge.net/notes.html
That old 2.06 accepts some options that were long ago deprecat
rks fine from my side and there were no patch on filetypes.vim so
> >>> it is vanilla based.
> >>
> >> Hmmm… it actually works when I explicitly start vim, but I get the error
> >> when I start vi. I have another system where it's OK, so let me do a
> >&
get the error
when I start vi. I have another system where it's OK, so let me do a
re-install of all related packages and see what happens. Maybe there
was some hiccup during the last update that I didn't catch.
I also encountered the same issue, however, the issue is not
reprod
when I start vi. I have another system where it's OK, so let me do a
> re-install of all related packages and see what happens. Maybe there
> was some hiccup during the last update that I didn't catch.
I also encountered the same issue, however, the issue is not
reproducible no
em where it's OK, so let me do a
> re-install of all related packages and see what happens. Maybe there
> was some hiccup during the last update that I didn't catch.
Haha, no there wasn't… just on that other system vi is aliased to vim.
So also on that system, running vi produ
Marco Atzeri via Cygwin writes:
> It works fine from my side and there were no patch on filetypes.vim so
> it is vanilla based.
Hmmm… it actually works when I explicitly start vim, but I get the error
when I start vi. I have another system where it's OK, so let me do a
re-install of
On 29/01/2025 12:04, Marco Atzeri wrote:
On 29/01/2025 11:28, ASSI via Cygwin wrote:
Marco Atzeri via Cygwin-announce writes:
New versions 9.1.1054-1 of
vim
Starting vim complains about non-available functions in a config file
"filetypes.vim", which is part of the distribution. Is there
On 29/01/2025 11:28, ASSI via Cygwin wrote:
Marco Atzeri via Cygwin-announce writes:
New versions 9.1.1054-1 of
vim
Starting vim complains about non-available functions in a config file
"filetypes.vim", which is part of the distribution. Is there some
setting missing?
Regards,
Achim.
Marco Atzeri via Cygwin-announce writes:
> New versions 9.1.1054-1 of
>
>vim
Starting vim complains about non-available functions in a config file
"filetypes.vim", which is part of the distribution. Is there some
setting missing?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQ
On 27/01/2025 22:01, Charles Perkins via Cygwin wrote:
Hello folks,
I have had multiple problems trying to install X11 on Cygwin. I am
running Cygwin on Windows 11 on my Asus VivoBook.
The initial X11 installation showed Error 3 for the sub-installation of
xinit.
Looking through previous
On Jan 28 09:00, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Jan 27 20:35, Corinna Vinschen via Cygwin wrote:
> > > On Jan 27 19:59, Christian Franke via Cygwin wrote:
> > > > Christian Franke wrote:
> > > > > Found with 'stress-ng --workload ...':
> > > > >
> >
On Jan 28 00:50, Thomas Wolff via Cygwin wrote:
>
> Am 27.01.2025 um 12:17 schrieb Takashi Yano via Cygwin:
> > Hi Thomas,
> >
> > A few days ago, Corinna asked me to check a problem of TTY.
> > The problem is as follows.
> >
> > Reproduce steps:
> > (1) Open mintty.
> > (2) Open another mintty.
Corinna Vinschen via Cygwin wrote:
On Jan 27 20:35, Corinna Vinschen via Cygwin wrote:
On Jan 27 19:59, Christian Franke via Cygwin wrote:
Christian Franke wrote:
Found with 'stress-ng --workload ...':
If mq_receive is called on an empty queue and mq_send is called later
from a different thre
Am 27.01.2025 um 12:17 schrieb Takashi Yano via Cygwin:
Hi Thomas,
A few days ago, Corinna asked me to check a problem of TTY.
The problem is as follows.
Reproduce steps:
(1) Open mintty.
(2) Open another mintty.
(3) Place the second mintty window over the first one.
(4) Hold ctrl key down.
(
On Jan 27 20:35, Corinna Vinschen via Cygwin wrote:
> On Jan 27 19:59, Christian Franke via Cygwin wrote:
> > Christian Franke wrote:
> > > Found with 'stress-ng --workload ...':
> > >
> > > If mq_receive is called on an empty queue and mq_send is called later
> > > from a different thread, both f
On Jan 27 19:59, Christian Franke via Cygwin wrote:
> Christian Franke wrote:
> > Found with 'stress-ng --workload ...':
> >
> > If mq_receive is called on an empty queue and mq_send is called later
> > from a different thread, both functions never return and signals
> > (including SIGKILL) are no
Christian Franke wrote:
Found with 'stress-ng --workload ...':
If mq_receive is called on an empty queue and mq_send is called later
from a different thread, both functions never return and signals
(including SIGKILL) are no longer processed.
Testcase (attached):
$ uname -r
3.5.5-1.x86_64
On Jan 27 16:18, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Jan 27 08:12, Christian Franke via Cygwin wrote:
> > > But there is a regression:
> > > stat() now returns st_mode = 0 for the queue file which results in an
> > > invalid S_IFMT field:
> > >
> > > $ un
Corinna Vinschen via Cygwin wrote:
On Jan 27 08:12, Christian Franke via Cygwin wrote:
Corinna Vinschen via Cygwin-announce wrote:
The following packages have been uploaded to the Cygwin distribution:
* cygwin-3.5.6-1
* cygwin-devel-3.5.6-1
* cygwin-doc-3.5.6-1
Fixes:
--
...
- Fix mq_un
On 26/01/2025 08:09, Marco Atzeri wrote:
On 25/01/2025 21:16, ASSI via Cygwin wrote:
Marco Atzeri via Cygwin writes:
That fixes the issue of both packages getting installed, but does not
fix the issue of wget and wget2 requiring an unmaintained library even
in their latest version.
Regards
On Jan 27 08:12, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin-announce wrote:
> > The following packages have been uploaded to the Cygwin distribution:
> >
> > * cygwin-3.5.6-1
> > * cygwin-devel-3.5.6-1
> > * cygwin-doc-3.5.6-1
> >
> > Fixes:
> > --
> >
> > ...
> >
> >
Corinna Vinschen via Cygwin-announce wrote:
The following packages have been uploaded to the Cygwin distribution:
* cygwin-3.5.6-1
* cygwin-devel-3.5.6-1
* cygwin-doc-3.5.6-1
Fixes:
--
...
- Fix mq_unlink().
Addresses: https://cygwin.com/pipermail/cygwin/2025-January/257119.html
Now
On 25/01/2025 21:16, ASSI via Cygwin wrote:
Marco Atzeri via Cygwin writes:
That fixes the issue of both packages getting installed, but does not
fix the issue of wget and wget2 requiring an unmaintained library even
in their latest version.
Regards,
Achim.
Noted.
I am testing the build o
On 2025-01-25 12:31, Paul Eggert via Cygwin wrote:
On 2025-01-24 05:27, Andreas BROCKMANN via Bug reports for GNU grep wrote:
The 1st command below correctly reports trailing spaces, for Unix and Windows
format files.
The 2nd one incorrectly reports all lines.
grep -sHn -i " [[:cntrl:]]*$"
Hi Andrey.
On Saturday, January 25, 2025 07:22 AM, Andrey Repin expressed:
>
> > takeown /R /F c:\cygwin64\*
>
> Eh. That was absolutely unnecessary. Given the path, you most likely had it
> installed with administrator rights. Thus no need to adjust permissions on
> whole tree.
> Only your /home/
Marco Atzeri via Cygwin writes:
> I had the impression to have properly declared
>
> NAME="gnupg2"
> VERSION=2.4.7
> RELEASE=1
>
> OBSOLETES="gnupg"
>
> and so setup.ini has
>
> @ gnupg2
> sdesc: "GNU tool for secure communication and data storage"
> ...
> obsoletes: gnupg
>
> so what went wrong ?
On 2025-01-24 05:27, Andreas BROCKMANN via Bug reports for GNU grep wrote:
The 1st command below correctly reports trailing spaces, for Unix and Windows
format files.
The 2nd one incorrectly reports all lines.
grep -sHn -i " [[:cntrl:]]*$" *.vhd
grep -sHn -i "\s[[:cntrl:]]*$" *.vhd
I do
Greetings, José Isaías Cabrera!
>> My windows account just changed from e608313 to u618346 and I would like to
>> > use the old setup that I had on the old account under the new account in
>> > cygwin. How is this possible? Thanks.
>> >
>>
>> This may be possible by using the native Windows icacls
On 2025-01-24 12:30, Soren via Cygwin wrote:
Hello folks. A few weeks ago, on Dec 19, I wrote to you all on the cygwin
list "[...] I am able to ssh into those [Debian] boxes from my Cygwin box
without any trouble. But when I try to ssh *into* my Cygwin box, the
connection attempt times out." Etc.
On Fri, 24 Jan 2025 10:55:18 +0100
Michael Soegtrop wrote:
> Dear Cygwin Team,
>
> I just wanted to confirm that I haven't seen issues with recent test
> releases. But the test versions change to fast to say conclusively that
> each of the versions are OK.
>
> The last version for which I did s
On 24/01/2025 19:02, Brian Inglis via Cygwin wrote:
On 2025-01-24 10:00, ASSI via Cygwin wrote:
ASSI via Cygwin writes:
Turns out that the (fresh) installation of Cygwin on this machine which
has exactly the same package selection was hosed up by a different
package installation order: Some ti
Hello folks. A few weeks ago, on Dec 19, I wrote to you all on the cygwin
list "[...] I am able to ssh into those [Debian] boxes from my Cygwin box
without any trouble. But when I try to ssh *into* my Cygwin box, the
connection attempt times out." Etc. So now, I wanted to inform the
community that
On 2025-01-24 10:56, Mercurio, Steven W-CTR (FAA) via Cygwin wrote:
I installed Cygwin and was hoping to do what I did a long time ago which is to have an
actual mate desktop as an alt desktop. The XFCE desktop seems to work but not mate. I
also seem to not be able to install the mate-session
On 2025-01-24 10:00, ASSI via Cygwin wrote:
ASSI via Cygwin writes:
Turns out that the (fresh) installation of Cygwin on this machine which
has exactly the same package selection was hosed up by a different
package installation order: Some time ago the GnuPG2 package was
changed to replace /usr
ASSI via Cygwin writes:
> Turns out that the (fresh) installation of Cygwin on this machine which
> has exactly the same package selection was hosed up by a different
> package installation order: Some time ago the GnuPG2 package was
> changed to replace /usr/bin/gpg (and gpg2 is now a symlink to
d not modify permissions. I clone with rsync over the already existing,
unchanged files from git, so there should be anyways no need for rsync to
re-transfer or modify the files.
Why clone a git repo with rsync when you can just use git from Linux to Windows?
The directory in question is a subf
over the already existing,
unchanged files from git, so there should be anyways no need for rsync to
re-transfer or modify the files.
Why clone a git repo with rsync when you can just use git from Linux to Windows?
The directory in question is a subfolder on the C: drive, which is an
NTFS-form
Dear Cygwin Team,
I just wanted to confirm that I haven't seen issues with recent test
releases. But the test versions change to fast to say conclusively that
each of the versions are OK.
The last version for which I did see failures was:
3.6.0-0.321.g23f4aac7e760 (2 failures in 10 runs)
Th
directory, and clone again from git!
Here are the details:
I'm using rsync options --verbose --recursive --delete which in my eyes
should not modify permissions. I clone with rsync over the already
existing,
unchanged files from git, so there should be anyways no need for rsync to
re-transf
h rsync over the already existing,
> unchanged files from git, so there should be anyways no need for rsync to
> re-transfer or modify the files.
>
> The directory in question is a subfolder on the C: drive, which is an
> NTFS-formatted NVMe. I created the parent folder as a normal use
On Thursday, January 23, 2025 02:47 PM, Bill Stewart expressed:
>
> On Thu, Jan 23, 2025 at 12:33 PM Jose I Cabrera wrote:
>
> My windows account just changed from e608313 to u618346 and I would like to
> > use the old setup that I had on the old account under the new account in
> > cygwin. How is
On Thu, Jan 23, 2025 at 12:33 PM Jose I Cabrera wrote:
My windows account just changed from e608313 to u618346 and I would like to
> use the old setup that I had on the old account under the new account in
> cygwin. How is this possible? Thanks.
>
This may be possible by using the native Windows
On Jan 23 19:46, Takashi Yano via Cygwin wrote:
> On Wed, 22 Jan 2025 10:42:39 -0800 (PST)
> Jeremy Drake wrote:
> > On Tue, 14 Jan 2025, Takashi Yano via Cygwin wrote:
> >
> > > Personally, I personally prefer releasing 3.5.6 ASAP.
> >
> > Is this the plan, now that the hangs seem to be resolved
On Wed, 22 Jan 2025 10:42:39 -0800 (PST)
Jeremy Drake wrote:
> On Tue, 14 Jan 2025, Takashi Yano via Cygwin wrote:
>
> > Personally, I personally prefer releasing 3.5.6 ASAP.
>
> Is this the plan, now that the hangs seem to be resolved? (Maybe after
> additional confirmation/testing?)
I think s
On 22/01/2025 17:47, Bill Stewart via Cygwin wrote:
On Wed, Jan 22, 2025 at 7:17 AM Marco Atzeri wrote:
Lester,
it seems to me that you have a clear problem in COMMUNICATION. Do NOT
reply to me only. Reply to the mailing list.
I am NOT your personal support HOTLINE.
This is the last advise.
Hi Cygwin list,
Replying to this email to let you know that we've sent updated information on
the proposed changes to cygwin-developers, including a patch, which we've also
sent to cygwin-patches.
The patch replaces the following undocumented API calls with the corresponding
documented APIs:
On Tue, 14 Jan 2025, Takashi Yano via Cygwin wrote:
> Personally, I personally prefer releasing 3.5.6 ASAP.
Is this the plan, now that the hangs seem to be resolved? (Maybe after
additional confirmation/testing?)
--
Problem reports: https://cygwin.com/problems.html
FAQ: h
ASSI via Cygwin writes:
> I've got a new machine with Win11 at work, copied over all my
> configuration from the old Win10 one, but I can't seem to get gpg2 to
> show the passphrase prompt through the W32 GUI of GPG agent. In fact
> the agent doesn't seem to even start (the named pipes do not get
On Jan 21 16:30, Jeremy Drake via Cygwin wrote:
> I've been trying to track down why ruby 3.4.1 is failing to build for
> msys2. I've now confirmed that this same issue reproduces with
> upstream Cygwin 3.5.4 and 3.6.0-0.335.gb879cd1661ad, so I thought I'd
> bring it up here:
>
> when building ru
On Jan 22 00:37, Roland Mainz via Cygwin wrote:
> Hi!
>
>
>
> If a Windows filesystem does not support a type of timestamp it sets
> the matching timestamp field in |FILE_BASIC_INFO| to |0LL| (e.g. see
> Windows-driver-samples/filesys/cdfs/fileinfo.c:
> |Buffer->LastAccessTime.QuadPart = 0|
On Wed, Jan 22, 2025 at 7:17 AM Marco Atzeri wrote:
Lester,
> it seems to me that you have a clear problem in COMMUNICATION. Do NOT
> reply to me only. Reply to the mailing list.
>
> I am NOT your personal support HOTLINE.
> This is the last advise.
>
Indeed. Here are some other references that m
On 2025-01-22 01:00, ASSI via Cygwin wrote:
I've got a new machine with Win11 at work, copied over all my
configuration from the old Win10 one, but I can't seem to get gpg2 to
show the passphrase prompt through the W32 GUI of GPG agent. In fact
the agent doesn't seem to even start (the named pip
On 21/01/2025 15:26, Lester Ingber wrote:
No, the problem is not "solved" at all.
We just have to click away now-seven instances of python!
Thanks anyway.
Lester
Lester,
it seems to me that you have a clear problem in COMMUNICATION.
Do NOT reply to me only. Reply to the mailing list.
I am N
On Mon, 20 Jan 2025 10:48:55 +0100
Michael Soegtrop wrote:
> Dear Cygwin Team,
>
> apparently there was a change in the test release (what I get when I run
> cygwin setup with --allow-test-packages) in the last few days. With the
> latest test release I see CI failures again with the same effect
On Wed, 22 Jan 2025 at 00:38, Roland Mainz via Cygwin wrote:
>
> Hi!
>
>
>
> If a Windows filesystem does not support a type of timestamp it sets
> the matching timestamp field in |FILE_BASIC_INFO| to |0LL| (e.g. see
> Windows-driver-samples/filesys/cdfs/fileinfo.c:
> |Buffer->LastAccessTime.
On 22 Jan 2025, at 09:00, ASSI via Cygwin wrote:
>
> I've got a new machine with Win11 at work, copied over all my
> configuration from the old Win10 one, but I can't seem to get gpg2 to
> show the passphrase prompt through the W32 GUI of GPG agent. In fact
> the agent doesn't seem to even start
On Tue, 21 Jan 2025, Jeremy Drake via Cygwin wrote:
> I did not see this happen with ruby 3.3.7, or when building with -j1.
Sorry, spoke too soon, I did see this immediately with 3.3.7 as well.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/fa
On 20/01/2025 20:11, Lester Ingber wrote:
I got an update OK.
I just had to click on a mirror.
Thanks.
Lester
Hi Lester
nice to know that you solved the problem.
Next time please REALLY reads https://cygwin.com/problems.html
and send a mail with useful info for us to understand your problem,
On 2025-01-20 08:13, Lester Ingber via Cygwin wrote:
> Today I had SEVEN python requests to OK?
> How can I stop this nonsense?
Why, Learn Lisp. :)
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/doc
On 20/01/2025 18:28, Lester Ingber wrote:
I attach cygcheck.out .
Thanks.
Lester
Hi Lester,
please reply on the cygwin mailing list.
You are still NOT saying what is the problem you are seeing.
Which python programs are giving you issue ?
Have you issue running setup or when ?
Things I noti
On 20/01/2025 17:13, Lester Ingber via Cygwin wrote:
Today I had SEVEN python requests to OK?
How can I stop this nonsense?
Lester
Hi Lester
Some info more will help to understand what is your problem.
We are NOT in front of your computer and we have NO clue
of what is happening to you.
Pl
Dear Cygwin Team,
apparently there was a change in the test release (what I get when I run
cygwin setup with --allow-test-packages) in the last few days. With the
latest test release I see CI failures again with the same effect - make
just hangs after finished builds.
Here is the version and
[Redirecting to Cygwin mailing list.]
On 1/19/2025 5:32 PM, Charles Henkel wrote:
By the way, I run emacs by invoking "emacs", not "emacs-gtk". I just
noticed that my /usr/bin/emacs is linked to /etc/alternatives/emacs
which is linked to /usr/bin/emacs-lucid.exe :
[...]
How in the heck that h
y end, but I am doubting it's
a generic issue.
-Original Message-
From: Ken Brown
Sent: Sunday, January 19, 2025 2:41 PM
To: Charles Henkel ; cygwin@cygwin.com
Subject: Re: emacs 29.4-1: Connection lost to X server
On 1/18/2025 11:52 AM, Charles Henkel via Cyg
Greetings, Kaz Kylheku!
> Hi All,
> In a (admittedly not current) version of 64 bit Cygwin, I'm observing a funny
> behavior:
> The GetCommandLineW function returns a command line which consists of the
> executable name only; the arguments are missing.
Why you are using native calls inside Cyg
On 1/18/2025 11:52 AM, Charles Henkel via Cygwin wrote:
Context:
Both Win 10 (10.0.19044) and Win 11 (24H2)
Latest versions you get installing as of 15jan2025:
cygwin 3.5.5-1
emacs 29.4-1
On Sun, Jan 19, 2025 at 10:05 AM Brian Inglis via Cygwin
wrote:
> On 2025-01-19 05:56, Devste Devste via Cygwin wrote:
> > strace -o strace.log dirname -- /some/path/here
> > There are 2 points that could make it significantly faster and
> > shouldn't be too hard to implement?
> ...
Drop all the
On 2025-01-19 05:56, Devste Devste via Cygwin wrote:
strace -o strace.log dirname -- /some/path/here
There are 2 points that could make it significantly faster and
shouldn't be too hard to implement?
Criticisms as expected to be accompanied by code and all Patches are
Thoughtfully Considered (
On 2025-01-19 05:55, Devste Devste via Cygwin wrote:
strace -o strace.log dirname -- /some/path/here
Cygwin via Git for Windows 2.47.x
Windows 10
I see:
3249 60966 [main] dirname 31200 time: 1736590460 = time(0x0)
On average it shows between 2000-4000 duration (I'm using Cloudflare's
ntp ser
On 1/16/25 01:17, Brian Inglis via Cygwin wrote:
With Windows Update patches pending restart, Windows sometimes acts
weird
This was not my case though:
_ it did not work before the upgrades were even downloaded;
_ it worked after they were installed;
_ I never tried in between.
N.B. I'm not s
On 13/01/2025 09.59, Andrey Repin wrote:
> But I know that the program is a windows program, thus a setting for>
>manually disabling the conversion made sense (at least in my head).
You might find this bit useful. For example the AWS CLI binary is windoze and
doesn't play nicely with unix-style p
Dear Cygwin Team,
I now had 12 successful CI runs in a row using the test version of
cygwin (installed with setup -t). Since it failed about 60% before, this
is strong evidence that this issue is fixed by the test release.
IMHO the test release should be officially released asap.
Thanks & be
On Jan 17 16:16, Christian Franke via Cygwin wrote:
> mq_unlink() does not unlink anything and always returns -1 with errno =
> EPERM.
Yeah, that's a result of commit f2dc492df0f3. I guess checking for
isdevfd_dev() is a bit over the top. Feel free to provide a patch,
otherwise I'll look into it
1 - 100 of 96785 matches
Mail list logo
