Pasting issues with Gnome Calculator
I've installed Gnome Calculator and I'm having a rather difficult time pasting to it. I work on Notepad++ and when I'm ready to have a formula calculated I paste it to GC. When trying to use Ctrl-V or Shift-Ins it very rarely, if ever worked, it seems to past old formula, nothing in Windows clipboard. It seems I very often, if not always, need to go through mouse selection (of the text) then copying using the contextual menu then in Gnome Calculator pasting using the mouse. Is there a way to more easily paste in Gnome Calculator ? Thank you kindly for your help -- 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
[ITA] ruby-gio2 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gio2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5295797846 ruby-gio2.cygport.diff Description: Binary data
Re: [ITA] ruby-gobject-introspection 4.1.7
Of the packages that need to be rebuilt for the latest ruby, ruby-gnome will be prioritized. https://www.cygwin.com/packages/reports/ruby_rebuilds.html - ruby-cairo-gobject - ruby-gio2 - ruby-goocanvas* - ruby-gstreamer1.0 - ruby-gtk* - ruby-pango - ruby-vte On Thu, Jun 15, 2023 at 2:39 PM Marco Atzeri via Cygwin-apps wrote: > > On 12/06/2023 16:18, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > > > > > Cygportfile: > > - > > https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gobject-introspection > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/5244423932 > > changed maintainer > > let me know the next ones you plan to work on > as I will be off in the coming days > > Regards > Marco > >
Re: [PATCH v3 0/3] use wincap in format_proc_cpuinfo for user_shstk
On 2023-06-16 13:51, Corinna Vinschen wrote: Hi Brian, On Jun 16 11:17, Brian Inglis wrote: v Fixes: 41fdb869f998 "fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo" ^ v In test for for AMD/Intel Control flow Enforcement Technology user mode shadow stack support replace Windows version tests with test of wincap member addition has_user_shstk with Windows version dependent value ^ Is that actually the final version? It's still missing the commit message text explaining things and the "Fixes" line... Hi Corinna, Is more required above? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: Trying to figure out what is wrong in a colleague's Cygwin setup
Actually, I was mistaken. I was given incomplete information. I'm getting much of this second hand. Adding that to the PATH made no difference. It appears this is something specific to "kubectl". They ended up setting the KUBECONFIG environment variable to "C:\Users\\.kube\config", which is very odd, as that is basically the default value of it, and I have never set that, and I've never seen this problem. Whatever. They're working now. On Fri, Jun 16, 2023 at 12:17 PM Mike Gran wrote: > > Ok, well, we managed to resolve this, but I don't understand why what we > > did would fix this. > > > In system environment variables in Windows, they added "c:\cygwin64\bin" > to > > the end of the PATH. That fixes the problem. That just doesn't make any > > sense to me. In a Cygwin shell, "/usr/bin" is in the PATH, which is the > > same as "c:\cygwin64\bin". > > Hello David- > The fact that their uname said MINGW implies they weren't running > "real" Cygwin, but, actually MSYS, which is the slightly modified Cygwin > that is bundled with MINGW to allow it to run bash and other > coreutils. > > MSYS has its own location for '/usr/bin', which is probably > c:/msys64/usr/bin or similar. It won't look in c:/cygwin64 by default. > > Just a guess, but, hope this helps. > -Mike Gran > -- 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
Re: [PATCH] include/cygwin/limits.h: add XATTR_{NAME,SIZE,LIST}_MAX
On Fri, Jun 16, 2023 at 9:49 PM Corinna Vinschen wrote: > Even a SSD has "disk" in it's name :) That actually stands for drive :-) > Let's keep it at that. I pushed your patchset. Thanks for merging! :-) Any rough estimate when this will be in a live release? Regards and best wishes, Philippe
Re: [PATCH] include/cygwin/limits.h: add XATTR_{NAME,SIZE,LIST}_MAX
On Jun 16 17:43, Philippe Cerfon wrote:
> Hey.
>
> On Fri, Jun 16, 2023 at 5:04 PM Corinna Vinschen
> wrote:
> > Oh well. Now that I see it in real life, my idea to use the entire
> > expression inline wasn't that great, it seems...
>
> ^^
>
>
> > I didn't want to keep MAX_EA_NAME_LEN because now that we have an
> > official name for the value, having an unofficial name using a different
> > naming convention is a bit weird.
> >
> > On the other hand, having a macro for the expression certainly looks
> > much cleaner. Also, only one place to change (should a change ever be
> > necessary).
>
> Does both make sense.
>
>
> > Sorry about that.
>
> No worries :-)
>
>
> > What do you think about something like _XATTR_NAME_MAX_ONDISK_?
>
> Really with trailing/leading underscores? If you try to keep it out of
> the "official namespace", then I'd would perhaps make more sense to
> mark this as being cygwin specific like CYGWIN_XATTR_NAME_MAX_ONDISK
> or so?
> Also - may be nitpicking - but storage is not really guaranteed to be
> a disk anymore. Maybe ONSTORAGE instead? But admittedly ONDISK sounds
> more common ("on disk format", etc.).
You're right, of course. Disk is just like everyone talks about it.
Even a SSD has "disk" in it's name :)
> > I can also just push the patches and we discuss this further afterwards,
> > your call.
>
> Well you know the naming convention used in your code much better than I do.
>
> Attached patches use _XATTR_NAME_MAX_ONDISK_ as you proposed.
>
> Just pick whichever name you like best, and either tell me and I
> provide a new patch, or just sed 's/_XATTR_NAME_MAX_ONDISK_/foobar/g'
> (+ maybe align text wrapping of comments if necessary).
Let's keep it at that. I pushed your patchset.
Thanks!
Corinna
Re: [PATCH v3 0/3] use wincap in format_proc_cpuinfo for user_shstk
Hi Brian, On Jun 16 11:17, Brian Inglis wrote: > Fixes: 41fdb869f998 "fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 > cpuinfo" > > In test for for AMD/Intel Control flow Enforcement Technology user mode > shadow stack support replace Windows version tests with test of wincap > member addition has_user_shstk with Windows version dependent value > > Signed-off-by: Brian Inglis > > Brian Inglis (3): > wincap.h: add wincap member has_user_shstk > wincap.cc: set wincap member has_user_shstk true for 2004+ > fhandler/proc.cc: use wincap.has_user_shstk > > winsup/cygwin/fhandler/proc.cc| 8 > winsup/cygwin/local_includes/wincap.h | 2 ++ > winsup/cygwin/wincap.cc | 10 ++ > 3 files changed, 16 insertions(+), 4 deletions(-) > > -- > 2.39.0 Is that actually the final version? It's still missing the commit message text explaining things and the "Fixes" line... Thanks, Corinna
Re: Trying to figure out what is wrong in a colleague's Cygwin setup
> Ok, well, we managed to resolve this, but I don't understand why what we > did would fix this. > In system environment variables in Windows, they added "c:\cygwin64\bin" to > the end of the PATH. That fixes the problem. That just doesn't make any > sense to me. In a Cygwin shell, "/usr/bin" is in the PATH, which is the > same as "c:\cygwin64\bin". Hello David- The fact that their uname said MINGW implies they weren't running "real" Cygwin, but, actually MSYS, which is the slightly modified Cygwin that is bundled with MINGW to allow it to run bash and other coreutils. MSYS has its own location for '/usr/bin', which is probably c:/msys64/usr/bin or similar. It won't look in c:/cygwin64 by default. Just a guess, but, hope this helps. -Mike Gran -- 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
Re: "Couldn't compute FAST_CWD pointer"
>I started seeing this error with more recent builds of Windows, so I went to >the Cygwin site and ran the latest installer to get the most recent binaries. >I've had to do this periodically in the past 15 years, and fresh binaries have >resolved my issues in the past. This time, the error persisted. A quick >search seems to point to different versions of GCC used to compile Cygwin >might have compatibility issues with different versions of Windows. I'd like >to help get this resolved if I can. >Thanks, >Sam >Error: >g:\os2\src\onecore\base\devices\association>ls >Cygwin WARNING: > Couldn't compute FAST_CWD pointer. This typically occurs if you're using > an older Cygwin version on a newer Windows. Please update to the latest > available Cygwin version from https://cygwin.com/. If the problem persists, > please see https://cygwin.com/problems.html >MbsSourcesCop_nonfatal.err buildchk.metadata >buildfre.exec.json client samples >So, I have a recent build of Windows. It seems like this issue popped up like >a week or two ago, so it probably started 5-10 build numbers ago. >0:000> vertarget >Windows 10 Version 25888 MP (28 procs) Free x64 >Product: WinNt, suite: SingleUserTS >Edition build lab: 25888.1000.amd64fre.rs_dplat.230614-1400 >Build layer: DesktopEditions -> 25888.1000.amd64fre.rs_dplat.230614-1400 >Build layer: OnecoreUAP -> 25888.1000.amd64fre.rs_dplat.230614-1400 >Build layer: ShellCommon -> 25888.1000.amd64fre.rs_dplat.230614-1400 >Build layer: OSClient -> 25888.1000.amd64fre.rs_dplat.230614-1400 >Debug session time: Fri Jun 16 12:02:33.676 2023 (UTC - 7:00) >System Uptime: 0 days 8:43:16.926 >Process Uptime: 0 days 0:13:15.247 > Kernel time: 0 days 0:00:00.015 > User time: 0 days 0:00:00.000 >This is after I got the most recent version of Cygwin from the installer, it >looks like version 3.4.6 built on Feb 14 2023. >0:000> lmDvmcygwin1 >Browse full module list >start end module name >7ff9`0381 7ff9`03b12000 cygwin1(deferred) >Image path: g:\bin\cygwin1.dll >Image name: cygwin1.dll >Browse all global symbols functions data >Timestamp:Tue Feb 14 05:25:13 2023 (63EB8BB9) >CheckSum: 002D984A >ImageSize:00302000 >File version: 3003.3.0.0 >Product version: 3003.3.0.0 >File flags: 0 (Mask 3F) >File OS: 4 Unknown Win32 >File type:2.0 Dll >File date:. >Translations: 0409.04b0 >Information from resource tables: >CompanyName: Red Hat >ProductName: Cygwin >InternalName: cygwin1.dll >OriginalFilename: cygwin1.dll >ProductVersion: 3.4.6 >FileVersion: 3.4.6 >FileDescription: Cygwin POSIX Emulation DLL >LegalCopyright: Copyright (c) Cygwin Authors 1996-2023 https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- 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
"Couldn't compute FAST_CWD pointer"
I started seeing this error with more recent builds of Windows, so I went to the Cygwin site and ran the latest installer to get the most recent binaries. I've had to do this periodically in the past 15 years, and fresh binaries have resolved my issues in the past. This time, the error persisted. A quick search seems to point to different versions of GCC used to compile Cygwin might have compatibility issues with different versions of Windows. I'd like to help get this resolved if I can. Thanks, Sam Error: g:\os2\src\onecore\base\devices\association>ls Cygwin WARNING: Couldn't compute FAST_CWD pointer. This typically occurs if you're using an older Cygwin version on a newer Windows. Please update to the latest available Cygwin version from https://cygwin.com/. If the problem persists, please see https://cygwin.com/problems.html MbsSourcesCop_nonfatal.err buildchk.metadata buildfre.exec.json client samples So, I have a recent build of Windows. It seems like this issue popped up like a week or two ago, so it probably started 5-10 build numbers ago. 0:000> vertarget Windows 10 Version 25888 MP (28 procs) Free x64 Product: WinNt, suite: SingleUserTS Edition build lab: 25888.1000.amd64fre.rs_dplat.230614-1400 Build layer: DesktopEditions -> 25888.1000.amd64fre.rs_dplat.230614-1400 Build layer: OnecoreUAP -> 25888.1000.amd64fre.rs_dplat.230614-1400 Build layer: ShellCommon -> 25888.1000.amd64fre.rs_dplat.230614-1400 Build layer: OSClient -> 25888.1000.amd64fre.rs_dplat.230614-1400 Debug session time: Fri Jun 16 12:02:33.676 2023 (UTC - 7:00) System Uptime: 0 days 8:43:16.926 Process Uptime: 0 days 0:13:15.247 Kernel time: 0 days 0:00:00.015 User time: 0 days 0:00:00.000 This is after I got the most recent version of Cygwin from the installer, it looks like version 3.4.6 built on Feb 14 2023. 0:000> lmDvmcygwin1 Browse full module list start end module name 7ff9`0381 7ff9`03b12000 cygwin1(deferred) Image path: g:\bin\cygwin1.dll Image name: cygwin1.dll Browse all global symbols functions data Timestamp:Tue Feb 14 05:25:13 2023 (63EB8BB9) CheckSum: 002D984A ImageSize:00302000 File version: 3003.3.0.0 Product version: 3003.3.0.0 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type:2.0 Dll File date:. Translations: 0409.04b0 Information from resource tables: CompanyName: Red Hat ProductName: Cygwin InternalName: cygwin1.dll OriginalFilename: cygwin1.dll ProductVersion: 3.4.6 FileVersion: 3.4.6 FileDescription: Cygwin POSIX Emulation DLL LegalCopyright: Copyright (c) Cygwin Authors 1996-2023 -- 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
Re: Trying to figure out what is wrong in a colleague's Cygwin setup
Ok, well, we managed to resolve this, but I don't understand why what we did would fix this. In system environment variables in Windows, they added "c:\cygwin64\bin" to the end of the PATH. That fixes the problem. That just doesn't make any sense to me. In a Cygwin shell, "/usr/bin" is in the PATH, which is the same as "c:\cygwin64\bin". On Thu, Jun 15, 2023 at 2:07 PM David Karr wrote: > (I replied with this earlier directly to someone who I didn't realize had > only replied to me.) > > I do have a couple other clues that I've noticed while continuing to debug > this. > > This person also has "git bash" installed, which is certainly similar to > Cygwin, but not quite the same. In his gitbash shell, he does not get this > error. > > If it matters, here is the "uname -a" output (hostname elided): > > CYGWIN_NT-10.0-22000 ... 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64 > Cygwin > > If it matters, here is the same from his gitbash shell: > > MINGW64_NT-10.0-22000 ... 3.1.7-340.x86_64 2021-03-26 22:17 UTC x86_64 > Msys > > He is running Windows 11 (as I am). > > What else can I try to narrow this down? > > On Tue, Jun 13, 2023 at 2:54 PM David Karr > wrote: > >> I have been using Cygwin for many years, although I wouldn't call myself >> an advanced user. >> >> I'm working with some much newer users. They set up Cygwin, but I didn't >> see them do it. I ran "uname -a" and it was about the same as mine. I >> compared the output of "env|sort" and I saw some differences, but I can't >> tell if they were significant. >> >> When I run the following command: >> >> kubectl config use-context dev2ff >> >> It works perfectly fine, setting the correct context. When this user I'm >> working with runs the same command, he gets this (replacing his userid with >> "..."): >> >> error: FindFirstFile C:\cygwin64\home\.../.kube/config: The directory >> name is invalid. >> >> He did have "HOME=/c/Users/...", but I had him change it to "/home/...", >> but that didn't make any difference. >> >> I'm not sure what could be happening here. >> > -- 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
[PATCH v3 3/3] fhandler/proc.cc: use wincap.has_user_shstk
Signed-off-by: Brian Inglis
---
winsup/cygwin/fhandler/proc.cc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/winsup/cygwin/fhandler/proc.cc b/winsup/cygwin/fhandler/proc.cc
index 3c79762e0fbd..cbc49a12a417 100644
--- a/winsup/cygwin/fhandler/proc.cc
+++ b/winsup/cygwin/fhandler/proc.cc
@@ -1486,12 +1486,12 @@ format_proc_cpuinfo (void *, char *)
/* ftcprint (features1, 6, "split_lock_detect");*//* MSR_TEST_CTRL
split lock */
- /* cpuid 0x0007 ecx & Windows [20]20H1/[20]2004+ */
- if (maxf >= 0x0007 && wincap.osname () >= "10.0"
-&& wincap.build_number () >= 19041)
+ /* Windows [20]20H1/[20]2004/19041 user shadow stack */
+ if (maxf >= 0x0007 && wincap.has_user_shstk ())
{
+ /* cpuid 0x0007 ecx CET shadow stack */
cpuid (, , , , 0x0007, 0);
- ftcprint (features1, 7, "user_shstk"); /* "user shadow stack"
*/
+ ftcprint (features1, 7, "user_shstk"); /* user shadow stack */
}
/* cpuid 0x0007:1 eax */
--
2.39.0
[PATCH v3 2/3] wincap.cc: set wincap member has_user_shstk true for 2004+
Signed-off-by: Brian Inglis
---
winsup/cygwin/wincap.cc | 10 ++
1 file changed, 10 insertions(+)
diff --git a/winsup/cygwin/wincap.cc b/winsup/cygwin/wincap.cc
index 91d5d9df8889..30d9c14e8d3b 100644
--- a/winsup/cygwin/wincap.cc
+++ b/winsup/cygwin/wincap.cc
@@ -31,6 +31,7 @@ static const wincaps wincap_8_1 = {
has_linux_tcp_keepalive_sockopts:false,
has_tcp_maxrtms:false,
has_con_broken_tabs:false,
+has_user_shstk:false,
},
};
@@ -52,6 +53,7 @@ static const wincaps wincap_10_1507 = {
has_linux_tcp_keepalive_sockopts:false,
has_tcp_maxrtms:false,
has_con_broken_tabs:false,
+has_user_shstk:false,
},
};
@@ -73,6 +75,7 @@ static const wincaps wincap_10_1607 = {
has_linux_tcp_keepalive_sockopts:false,
has_tcp_maxrtms:true,
has_con_broken_tabs:false,
+has_user_shstk:false,
},
};
@@ -94,6 +97,7 @@ static const wincaps wincap_10_1703 = {
has_linux_tcp_keepalive_sockopts:false,
has_tcp_maxrtms:true,
has_con_broken_tabs:true,
+has_user_shstk:false,
},
};
@@ -115,6 +119,7 @@ static const wincaps wincap_10_1709 = {
has_linux_tcp_keepalive_sockopts:true,
has_tcp_maxrtms:true,
has_con_broken_tabs:true,
+has_user_shstk:false,
},
};
@@ -136,6 +141,7 @@ static const wincaps wincap_10_1803 = {
has_linux_tcp_keepalive_sockopts:true,
has_tcp_maxrtms:true,
has_con_broken_tabs:true,
+has_user_shstk:false,
},
};
@@ -157,6 +163,7 @@ static const wincaps wincap_10_1809 = {
has_linux_tcp_keepalive_sockopts:true,
has_tcp_maxrtms:true,
has_con_broken_tabs:true,
+has_user_shstk:false,
},
};
@@ -178,6 +185,7 @@ static const wincaps wincap_10_1903 = {
has_linux_tcp_keepalive_sockopts:true,
has_tcp_maxrtms:true,
has_con_broken_tabs:true,
+has_user_shstk:false,
},
};
@@ -199,6 +207,7 @@ static const wincaps wincap_10_2004 = {
has_linux_tcp_keepalive_sockopts:true,
has_tcp_maxrtms:true,
has_con_broken_tabs:true,
+has_user_shstk:true,
},
};
@@ -220,6 +229,7 @@ static const wincaps wincap_11 = {
has_linux_tcp_keepalive_sockopts:true,
has_tcp_maxrtms:true,
has_con_broken_tabs:false,
+has_user_shstk:true,
},
};
--
2.39.0
[PATCH v3 1/3] wincap.h: add wincap member has_user_shstk
Signed-off-by: Brian Inglis
---
winsup/cygwin/local_includes/wincap.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/winsup/cygwin/local_includes/wincap.h
b/winsup/cygwin/local_includes/wincap.h
index 29a7a63de7f6..c14872787ca2 100644
--- a/winsup/cygwin/local_includes/wincap.h
+++ b/winsup/cygwin/local_includes/wincap.h
@@ -32,6 +32,7 @@ struct wincaps
unsigned has_linux_tcp_keepalive_sockopts : 1;
unsigned has_tcp_maxrtms : 1;
unsigned has_con_broken_tabs : 1;
+unsigned has_user_shstk: 1;
};
};
@@ -84,6 +85,7 @@ public:
bool IMPLEMENT (has_linux_tcp_keepalive_sockopts)
bool IMPLEMENT (has_tcp_maxrtms)
bool IMPLEMENT (has_con_broken_tabs)
+ bool IMPLEMENT (has_user_shstk)
void disable_case_sensitive_dirs ()
{
--
2.39.0
[PATCH v3 0/3] use wincap in format_proc_cpuinfo for user_shstk
Fixes: 41fdb869f998 "fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo" In test for for AMD/Intel Control flow Enforcement Technology user mode shadow stack support replace Windows version tests with test of wincap member addition has_user_shstk with Windows version dependent value Signed-off-by: Brian Inglis Brian Inglis (3): wincap.h: add wincap member has_user_shstk wincap.cc: set wincap member has_user_shstk true for 2004+ fhandler/proc.cc: use wincap.has_user_shstk winsup/cygwin/fhandler/proc.cc| 8 winsup/cygwin/local_includes/wincap.h | 2 ++ winsup/cygwin/wincap.cc | 10 ++ 3 files changed, 16 insertions(+), 4 deletions(-) -- 2.39.0
Re: [PATCH] include/cygwin/limits.h: add XATTR_{NAME,SIZE,LIST}_MAX
Hey.
On Fri, Jun 16, 2023 at 5:04 PM Corinna Vinschen
wrote:
> Oh well. Now that I see it in real life, my idea to use the entire
> expression inline wasn't that great, it seems...
^^
> I didn't want to keep MAX_EA_NAME_LEN because now that we have an
> official name for the value, having an unofficial name using a different
> naming convention is a bit weird.
>
> On the other hand, having a macro for the expression certainly looks
> much cleaner. Also, only one place to change (should a change ever be
> necessary).
Does both make sense.
> Sorry about that.
No worries :-)
> What do you think about something like _XATTR_NAME_MAX_ONDISK_?
Really with trailing/leading underscores? If you try to keep it out of
the "official namespace", then I'd would perhaps make more sense to
mark this as being cygwin specific like CYGWIN_XATTR_NAME_MAX_ONDISK
or so?
Also - may be nitpicking - but storage is not really guaranteed to be
a disk anymore. Maybe ONSTORAGE instead? But admittedly ONDISK sounds
more common ("on disk format", etc.).
> I can also just push the patches and we discuss this further afterwards,
> your call.
Well you know the naming convention used in your code much better than I do.
Attached patches use _XATTR_NAME_MAX_ONDISK_ as you proposed.
Just pick whichever name you like best, and either tell me and I
provide a new patch, or just sed 's/_XATTR_NAME_MAX_ONDISK_/foobar/g'
(+ maybe align text wrapping of comments if necessary).
Thanks,
Philippe
From 82e2ff6f52d7401210247ae396ce3f1f115d93f0 Mon Sep 17 00:00:00 2001
From: Philippe Cerfon
Date: Tue, 30 May 2023 13:16:18 +0200
Subject: [PATCH 1/2] Cygwin: export XATTR_{NAME,SIZE,LIST}_MAX
These are used for example by CPython.
Signed-off-by: Philippe Cerfon
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/include/cygwin/limits.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/winsup/cygwin/include/cygwin/limits.h b/winsup/cygwin/include/cygwin/limits.h
index aefc7c7bd..ea3e2836a 100644
--- a/winsup/cygwin/include/cygwin/limits.h
+++ b/winsup/cygwin/include/cygwin/limits.h
@@ -56,4 +56,11 @@ details. */
#define __PATH_MAX 4096
#define __PIPE_BUF 4096
+/* XATTR_NAME_MAX is the maximum XATTR name length excluding the null
+ * terminator. Since only XATTRs in the `user' namespace are allowed and the
+ * `user.' prefix is not stored, the maximum is increased by 5. */
+#define XATTR_NAME_MAX 260
+#define XATTR_SIZE_MAX 65536
+#define XATTR_LIST_MAX 65536
+
#endif /* _CYGWIN_LIMITS_H__ */
--
2.40.1
From 4c94f80fc817bee0e59da39397391cf2409cf029 Mon Sep 17 00:00:00 2001
From: Philippe Cerfon
Date: Tue, 6 Jun 2023 02:52:49 +0200
Subject: [PATCH 2/2] Cygwin: use new XATTR_{NAME,SIZE}_MAX instead of
MAX_EA_{NAME,VALUE}_LEN
Signed-off-by: Philippe Cerfon
---
winsup/cygwin/ntea.cc | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/winsup/cygwin/ntea.cc b/winsup/cygwin/ntea.cc
index a400fcb2b..70815649c 100644
--- a/winsup/cygwin/ntea.cc
+++ b/winsup/cygwin/ntea.cc
@@ -17,9 +17,11 @@ details. */
#include "tls_pbuf.h"
#include
#include
+#include
-#define MAX_EA_NAME_LEN256
-#define MAX_EA_VALUE_LEN 65536
+/* On storage the `user.` prefix is not included but the terminating null byte
+ is needed.*/
+#define _XATTR_NAME_MAX_ONDISK_ (XATTR_NAME_MAX - strlen("user.") + 1)
/* At least one maximum sized entry fits.
CV 2014-04-04: NtQueryEaFile function chokes on buffers bigger than 64K
@@ -27,13 +29,13 @@ details. */
on a remote share, at least on Windows 7 and later.
In theory the buffer should have a size of
- sizeof (FILE_FULL_EA_INFORMATION) + MAX_EA_NAME_LEN
- + MAX_EA_VALUE_LEN
+ sizeof (FILE_FULL_EA_INFORMATION) + _XATTR_NAME_MAX_ONDISK_
+ + XATTR_SIZE_MAX
(65804 bytes), but we're opting for simplicity here, and
a 64K buffer has the advantage that we can use a tmp_pathbuf
buffer, rather than having to alloca 64K from stack. */
-#define EA_BUFSIZ MAX_EA_VALUE_LEN
+#define EA_BUFSIZ XATTR_SIZE_MAX
#define NEXT_FEA(p) ((PFILE_FULL_EA_INFORMATION) (p->NextEntryOffset \
? (char *) p + p->NextEntryOffset : NULL))
@@ -55,7 +57,7 @@ read_ea (HANDLE hdl, path_conv , const char *name, char *value, size_t size)
returns the last EA entry of the file infinitely. Even utilizing the
optional EaIndex only helps marginally. If you use that, the last
EA in the file is returned twice. */
- char lastname[MAX_EA_NAME_LEN];
+ char lastname[_XATTR_NAME_MAX_ONDISK_];
__try
{
@@ -95,7 +97,7 @@ read_ea (HANDLE hdl, path_conv , const char *name, char *value, size_t size)
__leave;
}
- if ((nlen = strlen (name)) >= MAX_EA_NAME_LEN)
+ if ((nlen = strlen (name)) >= _XATTR_NAME_MAX_ONDISK_)
{
set_errno (EINVAL);
__leave;
@@ -197,7 +199,7 @@ read_ea (HANDLE hdl, path_conv , const char *name, char *value, size_t size)
/* For compatibility with Linux, we always
Re: [PATCH] include/cygwin/limits.h: add XATTR_{NAME,SIZE,LIST}_MAX
Hi Philippe,
On Jun 16 16:09, Philippe Cerfon wrote:
> Hey Corinna.
>
> On Wed, Jun 7, 2023 at 12:06 PM Corinna Vinschen
> wrote:
> > Hmm, the comparisons would have to check for XATTR_NAME_MAX anyway,
> > so maybe inlining is cleaner in this case.
>
> Please have a look at the updated and attached patches.
>
> Thanks,
> Philippe.
Oh well. Now that I see it in real life, my idea to use the entire
expression inline wasn't that great, it seems...
I didn't want to keep MAX_EA_NAME_LEN because now that we have an
official name for the value, having an unofficial name using a different
naming convention is a bit weird.
On the other hand, having a macro for the expression certainly looks
much cleaner. Also, only one place to change (should a change ever be
necessary).
Sorry about that.
What do you think about something like _XATTR_NAME_MAX_ONDISK_?
I can also just push the patches and we discuss this further afterwards,
your call.
Thanks,
Corinna
> @@ -55,7 +54,7 @@ read_ea (HANDLE hdl, path_conv , const char *name, char
> *value, size_t size)
> returns the last EA entry of the file infinitely. Even utilizing the
> optional EaIndex only helps marginally. If you use that, the last
> EA in the file is returned twice. */
> - char lastname[MAX_EA_NAME_LEN];
> + char lastname[(XATTR_NAME_MAX + 1 - strlen("user."))];
>
>__try
> {
> @@ -95,7 +94,7 @@ read_ea (HANDLE hdl, path_conv , const char *name, char
> *value, size_t size)
> __leave;
> }
>
> - if ((nlen = strlen (name)) >= MAX_EA_NAME_LEN)
> + if ((nlen = strlen (name)) >= (XATTR_NAME_MAX + 1 - strlen("user.")))
> {
> set_errno (EINVAL);
> __leave;
> @@ -197,7 +196,7 @@ read_ea (HANDLE hdl, path_conv , const char *name,
> char *value, size_t size)
> /* For compatibility with Linux, we always prepend "user." to
>the attribute name, so effectively we only support user
>attributes from a application point of view. */
> - char tmpbuf[MAX_EA_NAME_LEN * 2];
> + char tmpbuf[(XATTR_NAME_MAX + 1 - strlen("user.")) * 2];
> char *tp = stpcpy (tmpbuf, "user.");
> stpcpy (tp, fea->EaName);
> /* NTFS stores all EA names in uppercase unfortunately. To
> @@ -297,7 +296,7 @@ write_ea (HANDLE hdl, path_conv , const char *name,
> const char *value,
>/* Skip "user." prefix. */
>name += 5;
>
> - if ((nlen = strlen (name)) >= MAX_EA_NAME_LEN)
> + if ((nlen = strlen (name)) >= (XATTR_NAME_MAX + 1 - strlen("user.")))
> {
> set_errno (EINVAL);
> __leave;
> --
> 2.40.1
>
[ANNOUNCEMENT] cygwin 3.4.7-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.7-1 * cygwin-devel-3.4.7-1 * cygwin-doc-3.4.7-1 Bug Fixes - - Fix CPU_SET(3) macro type mismatch by making the macros type-safe. Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html - kill(1): don't print spurious error message. Addresses: https://cygwin.com/pipermail/cygwin/2023-March/253291.html - Align behaviour of dirname in terms of leading slashes to POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html - Fix reading CONIN$ in non cygwin apps when stdin is not a pty. Addresses https://cygwin.com/pipermail/cygwin/2023-April/253424.html - Fix bug in cygheap allocation size computation after fork. Addresses: https://cygwin.com/pipermail/cygwin-developers/2023-April/012620.html - Fix return value of ilogbl(NaN). Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253511.html - Fix error handling in readlinkat. Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253510.html - Fix return code and errno set by renameat2, if oldfile and newfile refer to the same file, and the RENAME_NOREPLACE flag is set. Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253514.html -- 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
cygwin 3.4.7-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.7-1 * cygwin-devel-3.4.7-1 * cygwin-doc-3.4.7-1 Bug Fixes - - Fix CPU_SET(3) macro type mismatch by making the macros type-safe. Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html - kill(1): don't print spurious error message. Addresses: https://cygwin.com/pipermail/cygwin/2023-March/253291.html - Align behaviour of dirname in terms of leading slashes to POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html - Fix reading CONIN$ in non cygwin apps when stdin is not a pty. Addresses https://cygwin.com/pipermail/cygwin/2023-April/253424.html - Fix bug in cygheap allocation size computation after fork. Addresses: https://cygwin.com/pipermail/cygwin-developers/2023-April/012620.html - Fix return value of ilogbl(NaN). Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253511.html - Fix error handling in readlinkat. Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253510.html - Fix return code and errno set by renameat2, if oldfile and newfile refer to the same file, and the RENAME_NOREPLACE flag is set. Addresses: https://cygwin.com/pipermail/cygwin/2023-April/253514.html
Re: [PATCH] include/cygwin/limits.h: add XATTR_{NAME,SIZE,LIST}_MAX
Hey Corinna.
On Wed, Jun 7, 2023 at 12:06 PM Corinna Vinschen
wrote:
> Hmm, the comparisons would have to check for XATTR_NAME_MAX anyway,
> so maybe inlining is cleaner in this case.
Please have a look at the updated and attached patches.
Thanks,
Philippe.
From 82e2ff6f52d7401210247ae396ce3f1f115d93f0 Mon Sep 17 00:00:00 2001
From: Philippe Cerfon
Date: Tue, 30 May 2023 13:16:18 +0200
Subject: [PATCH 1/2] Cygwin: export XATTR_{NAME,SIZE,LIST}_MAX
These are used for example by CPython.
Signed-off-by: Philippe Cerfon
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/include/cygwin/limits.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/winsup/cygwin/include/cygwin/limits.h b/winsup/cygwin/include/cygwin/limits.h
index aefc7c7bd..ea3e2836a 100644
--- a/winsup/cygwin/include/cygwin/limits.h
+++ b/winsup/cygwin/include/cygwin/limits.h
@@ -56,4 +56,11 @@ details. */
#define __PATH_MAX 4096
#define __PIPE_BUF 4096
+/* XATTR_NAME_MAX is the maximum XATTR name length excluding the null
+ * terminator. Since only XATTRs in the `user' namespace are allowed and the
+ * `user.' prefix is not stored, the maximum is increased by 5. */
+#define XATTR_NAME_MAX 260
+#define XATTR_SIZE_MAX 65536
+#define XATTR_LIST_MAX 65536
+
#endif /* _CYGWIN_LIMITS_H__ */
--
2.40.1
From 34a2e210082ddbf87d2c9569b6b14775a6cc5b95 Mon Sep 17 00:00:00 2001
From: Philippe Cerfon
Date: Tue, 6 Jun 2023 02:52:49 +0200
Subject: [PATCH 2/2] Cygwin: use new XATTR_{NAME,SIZE}_MAX instead of
MAX_EA_{NAME,VALUE}_LEN
Signed-off-by: Philippe Cerfon
---
winsup/cygwin/ntea.cc | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/winsup/cygwin/ntea.cc b/winsup/cygwin/ntea.cc
index a400fcb2b..ef1fdf4cc 100644
--- a/winsup/cygwin/ntea.cc
+++ b/winsup/cygwin/ntea.cc
@@ -17,9 +17,7 @@ details. */
#include "tls_pbuf.h"
#include
#include
-
-#define MAX_EA_NAME_LEN256
-#define MAX_EA_VALUE_LEN 65536
+#include
/* At least one maximum sized entry fits.
CV 2014-04-04: NtQueryEaFile function chokes on buffers bigger than 64K
@@ -27,13 +25,14 @@ details. */
on a remote share, at least on Windows 7 and later.
In theory the buffer should have a size of
- sizeof (FILE_FULL_EA_INFORMATION) + MAX_EA_NAME_LEN
- + MAX_EA_VALUE_LEN
+ sizeof (FILE_FULL_EA_INFORMATION)
+ + (XATTR_NAME_MAX + 1 - strlen("user."))
+ + XATTR_SIZE_MAX
(65804 bytes), but we're opting for simplicity here, and
a 64K buffer has the advantage that we can use a tmp_pathbuf
buffer, rather than having to alloca 64K from stack. */
-#define EA_BUFSIZ MAX_EA_VALUE_LEN
+#define EA_BUFSIZ XATTR_SIZE_MAX
#define NEXT_FEA(p) ((PFILE_FULL_EA_INFORMATION) (p->NextEntryOffset \
? (char *) p + p->NextEntryOffset : NULL))
@@ -55,7 +54,7 @@ read_ea (HANDLE hdl, path_conv , const char *name, char *value, size_t size)
returns the last EA entry of the file infinitely. Even utilizing the
optional EaIndex only helps marginally. If you use that, the last
EA in the file is returned twice. */
- char lastname[MAX_EA_NAME_LEN];
+ char lastname[(XATTR_NAME_MAX + 1 - strlen("user."))];
__try
{
@@ -95,7 +94,7 @@ read_ea (HANDLE hdl, path_conv , const char *name, char *value, size_t size)
__leave;
}
- if ((nlen = strlen (name)) >= MAX_EA_NAME_LEN)
+ if ((nlen = strlen (name)) >= (XATTR_NAME_MAX + 1 - strlen("user.")))
{
set_errno (EINVAL);
__leave;
@@ -197,7 +196,7 @@ read_ea (HANDLE hdl, path_conv , const char *name, char *value, size_t size)
/* For compatibility with Linux, we always prepend "user." to
the attribute name, so effectively we only support user
attributes from a application point of view. */
- char tmpbuf[MAX_EA_NAME_LEN * 2];
+ char tmpbuf[(XATTR_NAME_MAX + 1 - strlen("user.")) * 2];
char *tp = stpcpy (tmpbuf, "user.");
stpcpy (tp, fea->EaName);
/* NTFS stores all EA names in uppercase unfortunately. To
@@ -297,7 +296,7 @@ write_ea (HANDLE hdl, path_conv , const char *name, const char *value,
/* Skip "user." prefix. */
name += 5;
- if ((nlen = strlen (name)) >= MAX_EA_NAME_LEN)
+ if ((nlen = strlen (name)) >= (XATTR_NAME_MAX + 1 - strlen("user.")))
{
set_errno (EINVAL);
__leave;
--
2.40.1
Adding GNOME Text Editor
Dear Cygwin community, I saw that `gedit` (an older Gnome editor) is part of Cygwin (it's an orphaned package though): https://cygwin.com/packages/summary/gedit.html However the new modern default editor, based on libadwaita, namely - GNOME Text Editor (g-t-e) https://gitlab.gnome.org/GNOME/gnome-text-editor is not yet part of Cygwin. And it's a pity since g-t-e has an automatic Windows port as part of it's CI: https://gitlab.gnome.org/GNOME/gnome-text-editor/-/blob/main/.gitlab-ci.yml#L90 so adding it to cygwin probably would require minimal effort. May I ask you to add GNOME Text Editor to Cygwin, please? Thank you! ST -- 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
Re: cygwin-pkg-maint enhancements
On Jun 11 19:01, Jon Turney via Cygwin-apps wrote: > > I've deployed an update to calm which makes a few small improvements to the > way cygwin-pkg-maint is handled: > > * Lines starting with a '#' are now ignored as a comment > > * There's now a simple facility for grouping packages: > > Define a group with a line starting with '@', e.g.: > > @upstream_project Maintainer1/Maintainer2 > > Then @upstream_project can used in a package's maintainer list, as a > reference to that list of maintainers. That's a great change. Thanks! Would adding glob patterns help, too? Kind of like aspell aspell-* instead of having to mention every single language pack, or autoconf* automake* Corinna
Re: [PATCH v3 3/3] fhandler/proc.cc: use wincap.has_user_shstk
On Jun 16 10:28, Corinna Vinschen wrote:
> Hi Brain,
>
>
> thanks for the patch. Sorry to hassle you again, but I forget to mention
> this yesterday and I'm still only partially available. So, here goes:
>
> It would be really great if you could resend your patchset with three
> changes in the commit message:
>
> - For obvious reasons, the message text in your cover message won't make
> it into the git repo. However, the commit messages in git should
> reflect why the change was made, so a future interested reader has
> a chance to understand why a change was made.
Along these lines, given this patch fixes another one, the message text
should ideally outline what was wrong with the original patch and that
the new method doing things fixes it.
>
> - As I already mentioned a couple of times on this list (but not
> lately), it would be great if you could always add a "Signed-off-by:"
> line.
>
> - Also, given this patch fixes an earlier patch, it should contain
> a line
>
> Fixes: <12-digit-SHA1> ("commit headline")
>
> In this case, patch 3 of the series should contain
>
> Fixes: 41fdb869f998 ("fhandler/proc.cc(format_proc_cpuinfo): Add Linux
> 6.3 cpuinfo")
>
>
> Thanks,
> Corinna
>
>
> On Jun 15 18:16, Brian Inglis wrote:
> > ---
> > winsup/cygwin/fhandler/proc.cc | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/winsup/cygwin/fhandler/proc.cc b/winsup/cygwin/fhandler/proc.cc
> > index 3c79762e0fbd..2eaf436dc122 100644
> > --- a/winsup/cygwin/fhandler/proc.cc
> > +++ b/winsup/cygwin/fhandler/proc.cc
> > @@ -1486,12 +1486,12 @@ format_proc_cpuinfo (void *, char *)
> >
> > /* ftcprint (features1, 6, "split_lock_detect");*//* MSR_TEST_CTRL
> > split lock */
> >
> > - /* cpuid 0x0007 ecx & Windows [20]20H1/[20]2004+ */
> > - if (maxf >= 0x0007 && wincap.osname () >= "10.0"
> > -&& wincap.build_number () >= 19041)
> > + /* Windows [20]20H1/[20]2004/19041 user shadow stack */
> > + if (maxf >= 0x0007 && wincap.has_user_shstk ())
> > {
> > + /* cpuid 0x0007 ecx CET shadow stack */
> > cpuid (, , , , 0x0007, 0);
> > - ftcprint (features1, 7, "user_shstk"); /* "user shadow stack"
> > */
> > + ftcprint (features1, 7, "user_shstk"); /* user shadow stack */
> > }
> >
> >/* cpuid 0x0007:1 eax */
> > --
> > 2.39.0
Re: [PATCH v3 3/3] fhandler/proc.cc: use wincap.has_user_shstk
Hi Brain,
thanks for the patch. Sorry to hassle you again, but I forget to mention
this yesterday and I'm still only partially available. So, here goes:
It would be really great if you could resend your patchset with three
changes in the commit message:
- For obvious reasons, the message text in your cover message won't make
it into the git repo. However, the commit messages in git should
reflect why the change was made, so a future interested reader has
a chance to understand why a change was made.
- As I already mentioned a couple of times on this list (but not
lately), it would be great if you could always add a "Signed-off-by:"
line.
- Also, given this patch fixes an earlier patch, it should contain
a line
Fixes: <12-digit-SHA1> ("commit headline")
In this case, patch 3 of the series should contain
Fixes: 41fdb869f998 ("fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3
cpuinfo")
Thanks,
Corinna
On Jun 15 18:16, Brian Inglis wrote:
> ---
> winsup/cygwin/fhandler/proc.cc | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/winsup/cygwin/fhandler/proc.cc b/winsup/cygwin/fhandler/proc.cc
> index 3c79762e0fbd..2eaf436dc122 100644
> --- a/winsup/cygwin/fhandler/proc.cc
> +++ b/winsup/cygwin/fhandler/proc.cc
> @@ -1486,12 +1486,12 @@ format_proc_cpuinfo (void *, char *)
>
> /* ftcprint (features1, 6, "split_lock_detect");*//* MSR_TEST_CTRL
> split lock */
>
> - /* cpuid 0x0007 ecx & Windows [20]20H1/[20]2004+ */
> - if (maxf >= 0x0007 && wincap.osname () >= "10.0"
> - && wincap.build_number () >= 19041)
> + /* Windows [20]20H1/[20]2004/19041 user shadow stack */
> + if (maxf >= 0x0007 && wincap.has_user_shstk ())
> {
> + /* cpuid 0x0007 ecx CET shadow stack */
> cpuid (, , , , 0x0007, 0);
> - ftcprint (features1, 7, "user_shstk"); /* "user shadow stack"
> */
> + ftcprint (features1, 7, "user_shstk"); /* user shadow stack */
> }
>
>/* cpuid 0x0007:1 eax */
> --
> 2.39.0
