Re: RCS?

[Eliot Moss]

Rebuild the package from source. 32 and 64 but Cygwin have different binary 
models.

Sent from my iPhone

> On Jun 14, 2020, at 8:05 PM, Bill Coffin  wrote:
> 
> I've been using RCS for many years in an older cygwin running, most 
> recently, on Windows 10.  For some reason, my cygwin installation went nuts 
> so I downloaded and installed cygwin64.  cygwin64 works great but doesn't 
> have RCS.  I've searched the net and all other sources (the cygwin archives 
> appear to be unsearchable) and have found nothing helpful.
> 
> I copied the RCS executables, etc.,  from my old cygwin directories into 
> cygwin64, but they don't work.  (I used the RCS package file list as a guide.)
> 
> How can I get a working RCS?
> 
> Thanks,
>Bill
> -- 
> Bill Coffin -- visit us at www.eclipsoid.com
> --
> 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

--
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: RCS?

[Ken Brown via Cygwin]

On 6/14/2020 8:05 PM, Bill Coffin wrote:
I've been using RCS for many years in an older cygwin running, most recently, on 
Windows 10.  For some reason, my cygwin installation went nuts so I downloaded 
and installed cygwin64.  cygwin64 works great but doesn't have RCS.


RCS is available for 64-bit Cygwin.  Just install it using setup-x86_64.exe.

Ken
--
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

RCS?

[Bill Coffin]

I've been using RCS for many years in an older cygwin running, most 
recently, on Windows 10.  For some reason, my cygwin installation went 
nuts so I downloaded and installed cygwin64.  cygwin64 works great but 
doesn't have RCS.  I've searched the net and all other sources (the 
cygwin archives appear to be unsearchable) and have found nothing helpful.


I copied the RCS executables, etc.,  from my old cygwin directories into 
cygwin64, but they don't work.  (I used the RCS package file list as a 
guide.)


How can I get a working RCS?

Thanks,
   Bill
--
Bill Coffin -- visit us at www.eclipsoid.com
--
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 x11 doesn't start after windows 10 upgrade

[Holger, Vodafone]

Hi,

I found a thread which look similar:

http://cygwin.1069669.n5.nabble.com/XWin-startup-crash-x86-64-Windows-10-td126544.html
 


At least I know, that TrendMicro is on my System, if someone can help me, which 
folder is meant to be added to the TrendMicro Exceptions I can check with our 
internal IT.

Regards, Holger 

> Am 14.06.2020 um 23:45 schrieb Steinar Bang :
> 
>> Marco Atzeri via Cygwin :
> 
>> I guess we have only two methods to further going down
> 
>> 1) checking with strace if it is crashing during any system call
> 
>> strace -o XWin.strace /usr/bin/XWin :0 -multiwindow  -auth
> 
>> XWin.strace should contain some hints, hopefully
> 
> XWin.strace attached to this message.
> 
>> 2) use the gdb debugger, but it will require the installation of
> 
>> several debuginfo packages
> 
> Just give me the commands and I will try to follow them.
> 
> --- Process 149068 created
> --- Process 149068 loaded C:\Windows\System32\ntdll.dll at 7ffda7fa
> --- Process 149068 loaded C:\Windows\System32\kernel32.dll at 7ffda6ff
> --- Process 149068 loaded C:\Windows\System32\KernelBase.dll at 
> 7ffda4fe
> --- Process 149068 loaded C:\Windows\System32\advapi32.dll at 7ffda757
> --- Process 149068 thread 151064 created
> --- Process 149068 loaded C:\Windows\System32\msvcrt.dll at 7ffda77d
> --- Process 149068 thread 151172 created
> --- Process 149068 loaded C:\Windows\System32\sechost.dll at 7ffda6e8
> --- Process 149068 loaded C:\cygwin64\bin\cygwin1.dll at 00018004
> --- Process 149068 loaded C:\Windows\System32\rpcrt4.dll at 7ffda70d
> --- Process 149068 loaded C:\Windows\System32\gdi32.dll at 7ffda6f3
> --- Process 149068 loaded C:\Windows\System32\win32u.dll at 7ffda551
> --- Process 149068 loaded C:\Windows\System32\gdi32full.dll at 
> 7ffda5eb
> --- Process 149068 loaded C:\Windows\System32\msvcp_win.dll at 
> 7ffda569
> --- Process 149068 loaded C:\Windows\System32\ucrtbase.dll at 7ffda529
> --- Process 149068 thread 149136 created
> --- Process 149068 loaded C:\Windows\System32\user32.dll at 7ffda662
> --- Process 149068 loaded C:\Windows\System32\ole32.dll at 7ffda605
> --- Process 149068 loaded C:\Windows\System32\combase.dll at 7ffda6b4
> --- Process 149068 loaded C:\Windows\System32\bcryptprimitives.dll at 
> 7ffda549
> --- Process 149068 loaded C:\Windows\System32\shell32.dll at 7ffda787
> --- Process 149068 loaded C:\cygwin64\bin\cygpixman-1-0.dll at 
> 0003f43d
> --- Process 149068 loaded C:\cygwin64\bin\cygtirpc-3.dll at 0003f2dd
> --- Process 149068 loaded C:\cygwin64\bin\cygnettle-6.dll at 0003f4a2
> --- Process 149068 loaded C:\Windows\System32\cfgmgr32.dll at 7ffda53b
> --- Process 149068 loaded C:\cygwin64\bin\cygXau-6.dll at 0003f6c6
> --- Process 149068 loaded C:\cygwin64\bin\cygxcb-composite-0.dll at 
> 0003f2db
> --- Process 149068 loaded C:\cygwin64\bin\cygxcb-ewmh-2.dll at 
> 0003f287
> --- Process 149068 loaded C:\cygwin64\bin\cygxcb-icccm-4.dll at 
> 0003f284
> --- Process 149068 loaded C:\cygwin64\bin\cygxcb-image-0.dll at 
> 0003f283
> --- Process 149068 loaded C:\Windows\System32\SHCore.dll at 7ffda730
> --- Process 149068 loaded C:\Windows\System32\windows.storage.dll at 
> 7ffda573
> --- Process 149068 loaded C:\cygwin64\bin\cygxcb-util-1.dll at 
> 0003f27f
> --- Process 149068 loaded C:\cygwin64\bin\cygxcb-xfixes-0.dll at 
> 0003f27e
> --- Process 149068 loaded C:\cygwin64\bin\cygxcb-1.dll at 0003f289
> --- Process 149068 loaded C:\Windows\System32\dwmapi.dll at 7ffda339
> --- Process 149068 loaded C:\Windows\System32\profapi.dll at 7ffda4e7
> --- Process 149068 loaded C:\cygwin64\bin\cygXdmcp-6.dll at 0003f6ba
> --- Process 149068 loaded C:\Windows\System32\powrprof.dll at 7ffda4ea
> --- Process 149068 loaded C:\cygwin64\bin\cygXfont2-2.dll at 0003f6af
> --- Process 149068 loaded C:\Windows\System32\opengl32.dll at 7ffd79e4
> --- Process 149068 loaded C:\cygwin64\bin\cyggcc_s-seh-1.dll at 
> 0003f5cb
> --- Process 149068 loaded C:\Windows\System32\umpdc.dll at 7ffda4e6
> --- Process 149068 loaded C:\cygwin64\bin\cygxcb-shm-0.dll at 0003f280
> --- Process 149068 loaded C:\Windows\System32\shlwapi.dll at 7ffda72a
> --- Process 149068 loaded C:\Windows\System32\kernel.appcore.dll at 
> 7ffda4ef
> --- Process 149068 loaded C:\cygwin64\bin\cyggssapi_krb5-2.dll at 
> 0003f56d
> --- Process 149068 loaded C:\cygwin64\bin\cygbz2-1.dll at 0003f68e
> --- Process 149068 loaded C:\Windows\System32\cryptsp.dll at 7ffda539
> --- Process 149068 loaded C:\cygwin64\bin\cygfontenc-1.dll at 0003f5d7
> --- Process 149068 loaded 

Re: cygwin x11 doesn't start after windows 10 upgrade

[Steinar Bang]

> Marco Atzeri via Cygwin :

> I guess we have only two methods to further going down

> 1) checking with strace if it is crashing during any system call

>  strace -o XWin.strace /usr/bin/XWin :0 -multiwindow  -auth

> XWin.strace should contain some hints, hopefully

XWin.strace attached to this message.

> 2) use the gdb debugger, but it will require the installation of

> several debuginfo packages

Just give me the commands and I will try to follow them.

--- Process 149068 created
--- Process 149068 loaded C:\Windows\System32\ntdll.dll at 7ffda7fa
--- Process 149068 loaded C:\Windows\System32\kernel32.dll at 7ffda6ff
--- Process 149068 loaded C:\Windows\System32\KernelBase.dll at 7ffda4fe
--- Process 149068 loaded C:\Windows\System32\advapi32.dll at 7ffda757
--- Process 149068 thread 151064 created
--- Process 149068 loaded C:\Windows\System32\msvcrt.dll at 7ffda77d
--- Process 149068 thread 151172 created
--- Process 149068 loaded C:\Windows\System32\sechost.dll at 7ffda6e8
--- Process 149068 loaded C:\cygwin64\bin\cygwin1.dll at 00018004
--- Process 149068 loaded C:\Windows\System32\rpcrt4.dll at 7ffda70d
--- Process 149068 loaded C:\Windows\System32\gdi32.dll at 7ffda6f3
--- Process 149068 loaded C:\Windows\System32\win32u.dll at 7ffda551
--- Process 149068 loaded C:\Windows\System32\gdi32full.dll at 7ffda5eb
--- Process 149068 loaded C:\Windows\System32\msvcp_win.dll at 7ffda569
--- Process 149068 loaded C:\Windows\System32\ucrtbase.dll at 7ffda529
--- Process 149068 thread 149136 created
--- Process 149068 loaded C:\Windows\System32\user32.dll at 7ffda662
--- Process 149068 loaded C:\Windows\System32\ole32.dll at 7ffda605
--- Process 149068 loaded C:\Windows\System32\combase.dll at 7ffda6b4
--- Process 149068 loaded C:\Windows\System32\bcryptprimitives.dll at 
7ffda549
--- Process 149068 loaded C:\Windows\System32\shell32.dll at 7ffda787
--- Process 149068 loaded C:\cygwin64\bin\cygpixman-1-0.dll at 0003f43d
--- Process 149068 loaded C:\cygwin64\bin\cygtirpc-3.dll at 0003f2dd
--- Process 149068 loaded C:\cygwin64\bin\cygnettle-6.dll at 0003f4a2
--- Process 149068 loaded C:\Windows\System32\cfgmgr32.dll at 7ffda53b
--- Process 149068 loaded C:\cygwin64\bin\cygXau-6.dll at 0003f6c6
--- Process 149068 loaded C:\cygwin64\bin\cygxcb-composite-0.dll at 
0003f2db
--- Process 149068 loaded C:\cygwin64\bin\cygxcb-ewmh-2.dll at 0003f287
--- Process 149068 loaded C:\cygwin64\bin\cygxcb-icccm-4.dll at 0003f284
--- Process 149068 loaded C:\cygwin64\bin\cygxcb-image-0.dll at 0003f283
--- Process 149068 loaded C:\Windows\System32\SHCore.dll at 7ffda730
--- Process 149068 loaded C:\Windows\System32\windows.storage.dll at 
7ffda573
--- Process 149068 loaded C:\cygwin64\bin\cygxcb-util-1.dll at 0003f27f
--- Process 149068 loaded C:\cygwin64\bin\cygxcb-xfixes-0.dll at 
0003f27e
--- Process 149068 loaded C:\cygwin64\bin\cygxcb-1.dll at 0003f289
--- Process 149068 loaded C:\Windows\System32\dwmapi.dll at 7ffda339
--- Process 149068 loaded C:\Windows\System32\profapi.dll at 7ffda4e7
--- Process 149068 loaded C:\cygwin64\bin\cygXdmcp-6.dll at 0003f6ba
--- Process 149068 loaded C:\Windows\System32\powrprof.dll at 7ffda4ea
--- Process 149068 loaded C:\cygwin64\bin\cygXfont2-2.dll at 0003f6af
--- Process 149068 loaded C:\Windows\System32\opengl32.dll at 7ffd79e4
--- Process 149068 loaded C:\cygwin64\bin\cyggcc_s-seh-1.dll at 0003f5cb
--- Process 149068 loaded C:\Windows\System32\umpdc.dll at 7ffda4e6
--- Process 149068 loaded C:\cygwin64\bin\cygxcb-shm-0.dll at 0003f280
--- Process 149068 loaded C:\Windows\System32\shlwapi.dll at 7ffda72a
--- Process 149068 loaded C:\Windows\System32\kernel.appcore.dll at 
7ffda4ef
--- Process 149068 loaded C:\cygwin64\bin\cyggssapi_krb5-2.dll at 
0003f56d
--- Process 149068 loaded C:\cygwin64\bin\cygbz2-1.dll at 0003f68e
--- Process 149068 loaded C:\Windows\System32\cryptsp.dll at 7ffda539
--- Process 149068 loaded C:\cygwin64\bin\cygfontenc-1.dll at 0003f5d7
--- Process 149068 loaded C:\cygwin64\bin\cygz.dll at 0003f278
--- Process 149068 loaded C:\Windows\System32\glu32.dll at 7ffd7d2a
--- Process 149068 loaded C:\cygwin64\bin\cygkrb5-3.dll at 0003f4dd
--- Process 149068 loaded C:\cygwin64\bin\cygfreetype-6.dll at 0003f5bf
--- Process 149068 loaded C:\cygwin64\bin\cygk5crypto-3.dll at 0003f4ea
--- Process 149068 loaded C:\cygwin64\bin\cygkrb5support-0.dll at 
0003f51f
--- Process 149068 loaded C:\cygwin64\bin\cygintl-8.dll at 0003f50c
--- Process 149068 loaded C:\cygwin64\bin\cygkrb5support-0.dll at 
0016
--- Process 149068 unloaded DLL at 

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sun, Jun 14, 2020 at 12:09 PM Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> On 2020-06-14 12:16, David Karr via Cygwin wrote:
> > On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis <
> > brian.ing...@systematicsw.ab.ca> wrote:
> >
> >> On 2020-06-14 09:38, David Karr via Cygwin wrote:
> >>> On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
>  On 14.06.2020 08:12, David Karr wrote:
> > On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
> >>> to communicate to our in-house k8s clusters. I often use "kubectl
> >>> exec" to open a shell in a container or directly execute a shell
> >>> command.
> >>> This has worked perfectly fine for a long time.
> >>> A couple of days ago, I discovered that all of these attempts were
> >>> failing with "Upgrade request required".  I hadn't upgraded kubectl
> >>> or Cygwin in quite a while. I doubt our clusters had a k8s upgrade,
> >>> but it's entirely possible.
> >>> A colleague of mine has a very similar desktop configuration
> >>> (Windows 10, Cygwin), and he's not seeing this symptom.
> >>> I noticed that when I ran "kubectl exec" with max verbosity, it
> shows
> >>> the resulting "curl" command that it runs. I tried that resulting
> >>> command, and it results in the same response. I then tried updating
> >>> my Cygwin tools and retesting, no change.> I then took the
> >> entire resulting "kubectl exec" command line and ran
> >>> it in a "cmd" shell.  No problem at all.  No error.
> >>> I know I haven't provided much useful information yet. I wanted to
> >>> get an initial response before I started providing those
> diagnostics.
> >>> Is there a clear issue here that I'm not aware of?
> >>
> > from where is kubectl coming from ?
> > In cygwin I found only a kubectl.py in the ansible package
> >>
> >> It's from here:
> >>
> >>
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
> >>
>  so it is NOT a cygwin program.
>  If the warning is coming about curl, it is likely
>  that using from cygwin you are using the cygwin curl
>  and from CMD the windows one
>  $ which -a curl
>  /usr/bin/curl
>  /cygdrive/c/WINDOWS/system32/curl
>  $ /cygdrive/c/WINDOWS/system32/curl -V
>  curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
>  Release-Date: 2017-11-14, security patched: 2019-11-05
>  Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
> >> smtps
>  telnet tftp
>  Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
> 
>  $ /usr/bin/curl -V
>  curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f
> zlib/1.2.11
>  brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
>  libssh/0.8.7/openssl/zlib nghttp2/1.37.0
>  Release-Date: 2019-09-11
>  Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>  pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
>  Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
>  Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
>  TrackMemory UnixSockets
>  the support Forum https://discuss.kubernetes.io/
>  is probably the most indicate place for guidance
> >>
> >>> I thought it was obvious that it was not working because it was calling
> >> the
> >>> Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.
> >>> And since I'm well aware of the k8s community, I already posted
> questions
> >>> about this in the appropriate place, before I posted here.
> >>> What I was hoping to get here was some indication or thoughts on why a
> >>> process using Windows curl doesn't have a problem, but does have a
> >> problem
> >>> when using Cygwin Curl. This isn't likely something that Cygwin curl is
> >>> doing "wrong", it's just that it's doing something different.
> >>> If it matters, the following is an elided version of the resulting curl
> >>> command:
> >>> curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0
> >> (windows/amd64)
> >>> kubernetes/9e99141" -H "Authorization: Bearer ..." -H
> >>> "X-Stream-Protocol-Version: v4.channel.k8s.io" -H
> >>> "X-Stream-Protocol-Version: v3.channel.k8s.io" -H
> >>> "X-Stream-Protocol-Version: v2.channel.k8s.io" -H
> >>> "X-Stream-Protocol-Version: channel.k8s.io" 'https://
> >>>
> >>
> .../api/v1/namespaces/.../pods/.../exec?command=%2Fbin%2Fls=...=true=true=true'
> >>> I can't tell from the logging what request body it sent. It's possible
> it
> >>> didn't send any.
> >>
> >> We can't tell, not knowing who you are, and from what you are posting,
> >> what may
> >> or may not be obvious to you, where you are seeing "Upgrade request
> >> required",
> >> or where that may be coming from.
> >> That you need diagnostic 

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[Brian Inglis]

On 2020-06-14 12:16, David Karr via Cygwin wrote:
> On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis <
> brian.ing...@systematicsw.ab.ca> wrote:
> 
>> On 2020-06-14 09:38, David Karr via Cygwin wrote:
>>> On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
 On 14.06.2020 08:12, David Karr wrote:
> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
>> On 13.06.2020 20:53, David Karr via Cygwin wrote:
>>> I've been using kubectl in Cygwin on Windows 10 for quite a while,
>>> to communicate to our in-house k8s clusters. I often use "kubectl
>>> exec" to open a shell in a container or directly execute a shell
>>> command.
>>> This has worked perfectly fine for a long time.
>>> A couple of days ago, I discovered that all of these attempts were
>>> failing with "Upgrade request required".  I hadn't upgraded kubectl
>>> or Cygwin in quite a while. I doubt our clusters had a k8s upgrade,
>>> but it's entirely possible.
>>> A colleague of mine has a very similar desktop configuration
>>> (Windows 10, Cygwin), and he's not seeing this symptom.
>>> I noticed that when I ran "kubectl exec" with max verbosity, it shows
>>> the resulting "curl" command that it runs. I tried that resulting
>>> command, and it results in the same response. I then tried updating
>>> my Cygwin tools and retesting, no change.> I then took the
>> entire resulting "kubectl exec" command line and ran
>>> it in a "cmd" shell.  No problem at all.  No error.
>>> I know I haven't provided much useful information yet. I wanted to
>>> get an initial response before I started providing those diagnostics.
>>> Is there a clear issue here that I'm not aware of?
>>
> from where is kubectl coming from ?
> In cygwin I found only a kubectl.py in the ansible package
>>
>> It's from here:
>>
>> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
>>
 so it is NOT a cygwin program.
 If the warning is coming about curl, it is likely
 that using from cygwin you are using the cygwin curl
 and from CMD the windows one
 $ which -a curl
 /usr/bin/curl
 /cygdrive/c/WINDOWS/system32/curl
 $ /cygdrive/c/WINDOWS/system32/curl -V
 curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
 Release-Date: 2017-11-14, security patched: 2019-11-05
 Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
>> smtps
 telnet tftp
 Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL

 $ /usr/bin/curl -V
 curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f zlib/1.2.11
 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
 libssh/0.8.7/openssl/zlib nghttp2/1.37.0
 Release-Date: 2019-09-11
 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
 pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
 Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
 Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
 TrackMemory UnixSockets
 the support Forum https://discuss.kubernetes.io/
 is probably the most indicate place for guidance
>>
>>> I thought it was obvious that it was not working because it was calling
>> the
>>> Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.
>>> And since I'm well aware of the k8s community, I already posted questions
>>> about this in the appropriate place, before I posted here.
>>> What I was hoping to get here was some indication or thoughts on why a
>>> process using Windows curl doesn't have a problem, but does have a
>> problem
>>> when using Cygwin Curl. This isn't likely something that Cygwin curl is
>>> doing "wrong", it's just that it's doing something different.
>>> If it matters, the following is an elided version of the resulting curl
>>> command:
>>> curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0
>> (windows/amd64)
>>> kubernetes/9e99141" -H "Authorization: Bearer ..." -H
>>> "X-Stream-Protocol-Version: v4.channel.k8s.io" -H
>>> "X-Stream-Protocol-Version: v3.channel.k8s.io" -H
>>> "X-Stream-Protocol-Version: v2.channel.k8s.io" -H
>>> "X-Stream-Protocol-Version: channel.k8s.io" 'https://
>>>
>> .../api/v1/namespaces/.../pods/.../exec?command=%2Fbin%2Fls=...=true=true=true'
>>> I can't tell from the logging what request body it sent. It's possible it
>>> didn't send any.
>>
>> We can't tell, not knowing who you are, and from what you are posting,
>> what may
>> or may not be obvious to you, where you are seeing "Upgrade request
>> required",
>> or where that may be coming from.
>> That you need diagnostic help indicates that, what may appear obvious to
>> you,
>> may not be the case, as it is often our assumptions which lead us astray,
>> and we
>> get daily proof that we are imperfect, which is why most of seek to talk
>> over
>> and explain our issues to inanimate objects or colleagues e.g. 

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis <
brian.ing...@systematicsw.ab.ca> wrote:

> On 2020-06-14 09:38, David Karr via Cygwin wrote:
> > On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
> >> On 14.06.2020 08:12, David Karr wrote:
> >>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
>  On 13.06.2020 20:53, David Karr via Cygwin wrote:
> > I've been using kubectl in Cygwin on Windows 10 for quite a while,
> > to communicate to our in-house k8s clusters. I often use "kubectl
> > exec" to open a shell in a container or directly execute a shell
> > command.
> > This has worked perfectly fine for a long time.
> > A couple of days ago, I discovered that all of these attempts were
> > failing with "Upgrade request required".  I hadn't upgraded kubectl
> > or Cygwin in quite a while. I doubt our clusters had a k8s upgrade,
> > but it's entirely possible.
> > A colleague of mine has a very similar desktop configuration
> > (Windows 10, Cygwin), and he's not seeing this symptom.
> > I noticed that when I ran "kubectl exec" with max verbosity, it shows
> > the resulting "curl" command that it runs. I tried that resulting
> > command, and it results in the same response. I then tried updating
> > my Cygwin tools and retesting, no change.> I then took the
> entire resulting "kubectl exec" command line and ran
> > it in a "cmd" shell.  No problem at all.  No error.
> > I know I haven't provided much useful information yet. I wanted to
> > get an initial response before I started providing those diagnostics.
> > Is there a clear issue here that I'm not aware of?
>
> >>> from where is kubectl coming from ?
> >>> In cygwin I found only a kubectl.py in the ansible package
>
>  It's from here:
> 
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
>
> >> so it is NOT a cygwin program.
> >> If the warning is coming about curl, it is likely
> >> that using from cygwin you are using the cygwin curl
> >> and from CMD the windows one
> >> $ which -a curl
> >> /usr/bin/curl
> >> /cygdrive/c/WINDOWS/system32/curl
> >> $ /cygdrive/c/WINDOWS/system32/curl -V
> >> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
> >> Release-Date: 2017-11-14, security patched: 2019-11-05
> >> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
> smtps
> >> telnet tftp
> >> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
> >>
> >> $ /usr/bin/curl -V
> >> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f zlib/1.2.11
> >> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
> >> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
> >> Release-Date: 2019-09-11
> >> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> >> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
> >> Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
> >> Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
> >> TrackMemory UnixSockets
> >> the support Forum https://discuss.kubernetes.io/
> >> is probably the most indicate place for guidance
>
> > I thought it was obvious that it was not working because it was calling
> the
> > Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.
> > And since I'm well aware of the k8s community, I already posted questions
> > about this in the appropriate place, before I posted here.
> > What I was hoping to get here was some indication or thoughts on why a
> > process using Windows curl doesn't have a problem, but does have a
> problem
> > when using Cygwin Curl. This isn't likely something that Cygwin curl is
> > doing "wrong", it's just that it's doing something different.
> > If it matters, the following is an elided version of the resulting curl
> > command:
> > curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0
> (windows/amd64)
> > kubernetes/9e99141" -H "Authorization: Bearer ..." -H
> > "X-Stream-Protocol-Version: v4.channel.k8s.io" -H
> > "X-Stream-Protocol-Version: v3.channel.k8s.io" -H
> > "X-Stream-Protocol-Version: v2.channel.k8s.io" -H
> > "X-Stream-Protocol-Version: channel.k8s.io" 'https://
> >
> .../api/v1/namespaces/.../pods/.../exec?command=%2Fbin%2Fls=...=true=true=true'
> > I can't tell from the logging what request body it sent. It's possible it
> > didn't send any.
>
> We can't tell, not knowing who you are, and from what you are posting,
> what may
> or may not be obvious to you, where you are seeing "Upgrade request
> required",
> or where that may be coming from.
> That you need diagnostic help indicates that, what may appear obvious to
> you,
> may not be the case, as it is often our assumptions which lead us astray,
> and we
> get daily proof that we are imperfect, which is why most of seek to talk
> over
> and explain our issues to inanimate objects or colleagues e.g. talk to the
> rubber duck, teddy bear, plush hippo, etc. (My shelf holds two 

Re: cygwin x11 doesn't start after windows 10 upgrade

[Marco Atzeri via Cygwin]

On 14.06.2020 18:12, Steinar Bang wrote:

"Henry S. Thompson via Cygwin" :



Steinar Bang writes:
[troubles with XWin]



Have a look at what Windows shows as the processes that are running.



I've had intermittent problems with XWin processes running without
actually showing any windows.  You can see process information either
with a special tool such as ProcExp or with the builtin Windows task
manager, via Control-Alt-Delete.



If you find XWin processes, let us know.


There were no XWin processes in the "Processes" tab of the task manager.

I couldn't see any XWin processes in sysinternals procexp64 either.  And
search for "xwin" in procexp gave no matches.



I guess we have only two methods to further going down

1) checking with strace if it is crashing during any system call

 strace -o XWin.strace /usr/bin/XWin :0 -multiwindow  -auth

XWin.strace should contain some hints, hopefully


2) use the gdb debugger, but it will require the installation of
several debuginfo packages

Regards
Marco


--
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: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[Brian Inglis]

On 2020-06-14 09:38, David Karr via Cygwin wrote:
> On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
>> On 14.06.2020 08:12, David Karr wrote:
>>> On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
 On 13.06.2020 20:53, David Karr via Cygwin wrote:
> I've been using kubectl in Cygwin on Windows 10 for quite a while,
> to communicate to our in-house k8s clusters. I often use "kubectl 
> exec" to open a shell in a container or directly execute a shell
> command.
> This has worked perfectly fine for a long time.
> A couple of days ago, I discovered that all of these attempts were
> failing with "Upgrade request required".  I hadn't upgraded kubectl
> or Cygwin in quite a while. I doubt our clusters had a k8s upgrade,
> but it's entirely possible.
> A colleague of mine has a very similar desktop configuration
> (Windows 10, Cygwin), and he's not seeing this symptom.
> I noticed that when I ran "kubectl exec" with max verbosity, it shows
> the resulting "curl" command that it runs. I tried that resulting 
> command, and it results in the same response. I then tried updating
> my Cygwin tools and retesting, no change.> I then took the entire 
> resulting "kubectl exec" command line and ran
> it in a "cmd" shell.  No problem at all.  No error.
> I know I haven't provided much useful information yet. I wanted to
> get an initial response before I started providing those diagnostics.
> Is there a clear issue here that I'm not aware of?

>>> from where is kubectl coming from ?
>>> In cygwin I found only a kubectl.py in the ansible package

 It's from here:
 https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows

>> so it is NOT a cygwin program.
>> If the warning is coming about curl, it is likely
>> that using from cygwin you are using the cygwin curl
>> and from CMD the windows one
>> $ which -a curl
>> /usr/bin/curl
>> /cygdrive/c/WINDOWS/system32/curl
>> $ /cygdrive/c/WINDOWS/system32/curl -V
>> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
>> Release-Date: 2017-11-14, security patched: 2019-11-05
>> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps
>> telnet tftp
>> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
>>
>> $ /usr/bin/curl -V
>> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f zlib/1.2.11
>> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
>> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
>> Release-Date: 2019-09-11
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
>> Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
>> Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
>> TrackMemory UnixSockets
>> the support Forum https://discuss.kubernetes.io/
>> is probably the most indicate place for guidance

> I thought it was obvious that it was not working because it was calling the
> Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.
> And since I'm well aware of the k8s community, I already posted questions
> about this in the appropriate place, before I posted here.
> What I was hoping to get here was some indication or thoughts on why a
> process using Windows curl doesn't have a problem, but does have a problem
> when using Cygwin Curl. This isn't likely something that Cygwin curl is
> doing "wrong", it's just that it's doing something different.
> If it matters, the following is an elided version of the resulting curl
> command:
> curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0 (windows/amd64)
> kubernetes/9e99141" -H "Authorization: Bearer ..." -H
> "X-Stream-Protocol-Version: v4.channel.k8s.io" -H
> "X-Stream-Protocol-Version: v3.channel.k8s.io" -H
> "X-Stream-Protocol-Version: v2.channel.k8s.io" -H
> "X-Stream-Protocol-Version: channel.k8s.io" 'https://
> .../api/v1/namespaces/.../pods/.../exec?command=%2Fbin%2Fls=...=true=true=true'
> I can't tell from the logging what request body it sent. It's possible it
> didn't send any.

We can't tell, not knowing who you are, and from what you are posting, what may
or may not be obvious to you, where you are seeing "Upgrade request required",
or where that may be coming from.
That you need diagnostic help indicates that, what may appear obvious to you,
may not be the case, as it is often our assumptions which lead us astray, and we
get daily proof that we are imperfect, which is why most of seek to talk over
and explain our issues to inanimate objects or colleagues e.g. talk to the
rubber duck, teddy bear, plush hippo, etc. (My shelf holds two ducks and a
pelican awarded by former projects.)

For help with Cygwin, we need to see *whole* commands and all the output between
the shell prompts, preferably with context, in this case including PATH under
Cygwin and MS Windows and/or program paths typed or invoked.

You 

Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[Marco Atzeri via Cygwin]

On 14.06.2020 17:38, David Karr wrote:


On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:

On 14.06.2020 08:12, David Karr wrote:
 >
 >
 > On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
 >
 >     On 13.06.2020 20:53, David Karr via Cygwin wrote:
 >      > I've been using kubectl in Cygwin on Windows 10 for quite
a while, to
 >      > communicate to our in-house k8s clusters. I often use "kubectl
 >     exec" to
 >      > open a shell in a container or directly execute a shell
command.
 >     This has
 >      > worked perfectly fine for a long time.
 >      >
 >      > A couple of days ago, I discovered that all of these attempts
 >     were failing
 >      > with "Upgrade request required".  I hadn't upgraded kubectl or
 >     Cygwin in
 >      > quite a while. I doubt our clusters had a k8s upgrade, but
it's
 >     entirely
 >      > possible.
 >      >
 >      > A colleague of mine has a very similar desktop configuration
 >     (Windows 10,
 >      > Cygwin), and he's not seeing this symptom.
 >      >
 >      > I noticed that when I ran "kubectl exec" with max
verbosity, it
 >     shows the
 >      > resulting "curl" command that it runs. I tried that resulting
 >     command, and
 >      > it results in the same response. I then tried updating my
Cygwin
 >     tools and
 >      > retesting, no change.
 >      >
 >      > I then took the entire resulting "kubectl exec" command
line and
 >     ran it in
 >      > a "cmd" shell.  No problem at all.  No error.
 >      >
 >      > I know I haven't provided much useful information yet. I
wanted
 >     to get an
 >      > initial response before I started providing those
diagnostics. Is
 >     there a
 >      > clear issue here that I'm not aware of?
 >      > --
 >
 >     from where is kubectl coming from ?
 >
 >     In cygwin I found only a kubectl.py in the ansible package
 >
 >
 > It's from here:
 >

https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows

 > .

so it is NOT a cygwin program.

If the warning is coming about curl, it is likely
that using from cygwin you are using the cygwin curl
and from CMD the windows one


$ which -a curl
/usr/bin/curl
/cygdrive/c/WINDOWS/system32/curl



the support Forum https://discuss.kubernetes.io/
is probably the most indicate place for guidance

Regards
Marco


I thought it was obvious that it was not working because it was calling 
the Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.


Obvious not so much to me, evidently ;-)

And since I'm well aware of the k8s community, I already posted 
questions about this in the appropriate place, before I posted here.


What I was hoping to get here was some indication or thoughts on why a 
process using Windows curl doesn't have a problem, but does have a 
problem when using Cygwin Curl. This isn't likely something that Cygwin 
curl is doing "wrong", it's just that it's doing something different.


the Cygwin curl was changed last time on 18 Sep 2019.
So it is not something directly depending from the package, maybe from
the dependencing libraries.

Comparing the help and version outputs the cygwin one is coming from a 
more recent version and has more features than the windows one ;

the only major difference I see is that the windows version
produces output with CRLF termination.

It is possible that kubectl is doing a version check and it misleading
reports a different version as older one.

If it matters, the following is an elided version of the resulting curl 
command:


     curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0 
(windows/amd64) kubernetes/9e99141" -H "Authorization: Bearer ..." -H 
"X-Stream-Protocol-Version: v4.channel.k8s.io 
" -H "X-Stream-Protocol-Version: 
v3.channel.k8s.io " -H 
"X-Stream-Protocol-Version: v2.channel.k8s.io 
" -H "X-Stream-Protocol-Version: 
channel.k8s.io " 
'https://.../api/v1/namespaces/.../pods/.../exec?command=%2Fbin%2Fls=...=true=true=true'


I can't tell from the logging what request body it sent. It's possible 
it didn't send any.


all the options used are basic and present in both versions.
May be CRLF vs LF is present also on POST method

Regards
Marco
--
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 x11 doesn't start after windows 10 upgrade

[Steinar Bang]

> "Henry S. Thompson via Cygwin" :

> Steinar Bang writes:
> [troubles with XWin]

> Have a look at what Windows shows as the processes that are running.

> I've had intermittent problems with XWin processes running without
> actually showing any windows.  You can see process information either
> with a special tool such as ProcExp or with the builtin Windows task
> manager, via Control-Alt-Delete.

> If you find XWin processes, let us know.

There were no XWin processes in the "Processes" tab of the task manager.

I couldn't see any XWin processes in sysinternals procexp64 either.  And
search for "xwin" in procexp gave no matches.

--
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: Country Of Origin Verification - 8944

[Christopher Faylor]

On Thu, Jun 11, 2020 at 11:24:09AM -0600, Brian Inglis wrote:
>On 2020-06-11 10:07, Watson, Christian M. (GRC-V000)[Peerless Technologies
>Corp.] via Cygwin wrote:
>> My name is Christian Watson and I am a Supply Chain Risk Management 
>> Coordinator at NASA Glenn Research Center  As such, I ensure that all NASA 
>> Headquarter IT purchase requests comply with Section 514 of the Consolidated 
>> Appropriations Act, 2018, Public Law 115-141 (amended), enacted February 28, 
>> 2018.  To do so, the country of origin information must be obtained from the 
>> company that develops, produces, manufactures, or assembles the product(s).  
>> Specifically, identify the country where each of the following products were 
>> developed, manufactured, and assembled:
>> 
>> * TightVNC 2.8.27
>> 
>> Additionally, if the country of origin is outside the United States, please 
>> provide any information you may have stating that testing is performed in 
>> the United States prior to supplying products to customers.
>> Lastly, if available, please identify all authorized distributors of the 
>> product in question.
>
>This is the second email like this you have sent to the Cygwin mailing list:
>if you are going to send a bunch of these to the Cygwin mailing list, you 
>should
>save yourself time and energy, and list all the Cygwin packages in one email,
>which may receive no response, unless you are spam blocked.
^^^

...which is a very good possibility if this proves to be write-only email.

cgf

--
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: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:

> On 14.06.2020 08:12, David Karr wrote:
> >
> >
> > On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >
> > On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >  > I've been using kubectl in Cygwin on Windows 10 for quite a
> while, to
> >  > communicate to our in-house k8s clusters. I often use "kubectl
> > exec" to
> >  > open a shell in a container or directly execute a shell command.
> > This has
> >  > worked perfectly fine for a long time.
> >  >
> >  > A couple of days ago, I discovered that all of these attempts
> > were failing
> >  > with "Upgrade request required".  I hadn't upgraded kubectl or
> > Cygwin in
> >  > quite a while. I doubt our clusters had a k8s upgrade, but it's
> > entirely
> >  > possible.
> >  >
> >  > A colleague of mine has a very similar desktop configuration
> > (Windows 10,
> >  > Cygwin), and he's not seeing this symptom.
> >  >
> >  > I noticed that when I ran "kubectl exec" with max verbosity, it
> > shows the
> >  > resulting "curl" command that it runs. I tried that resulting
> > command, and
> >  > it results in the same response. I then tried updating my Cygwin
> > tools and
> >  > retesting, no change.
> >  >
> >  > I then took the entire resulting "kubectl exec" command line and
> > ran it in
> >  > a "cmd" shell.  No problem at all.  No error.
> >  >
> >  > I know I haven't provided much useful information yet. I wanted
> > to get an
> >  > initial response before I started providing those diagnostics. Is
> > there a
> >  > clear issue here that I'm not aware of?
> >  > --
> >
> > from where is kubectl coming from ?
> >
> > In cygwin I found only a kubectl.py in the ansible package
> >
> >
> > It's from here:
> >
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
> > .
>
> so it is NOT a cygwin program.
>
> If the warning is coming about curl, it is likely
> that using from cygwin you are using the cygwin curl
> and from CMD the windows one
>
>
> $ which -a curl
> /usr/bin/curl
> /cygdrive/c/WINDOWS/system32/curl
>
>
> $ /cygdrive/c/WINDOWS/system32/curl -V
> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
> Release-Date: 2017-11-14, security patched: 2019-11-05
> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
> smtps telnet
>   tftp
> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
>
> $ /usr/bin/curl -V
> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f zlib/1.2.11
> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
> Release-Date: 2019-09-11
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
> Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
> Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
> TrackMemory UnixSockets
>
>
> the support Forum https://discuss.kubernetes.io/
> is probably the most indicate place for guidance
>
> Regards
> Marco
>

I thought it was obvious that it was not working because it was calling the
Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.

And since I'm well aware of the k8s community, I already posted questions
about this in the appropriate place, before I posted here.

What I was hoping to get here was some indication or thoughts on why a
process using Windows curl doesn't have a problem, but does have a problem
when using Cygwin Curl. This isn't likely something that Cygwin curl is
doing "wrong", it's just that it's doing something different.

If it matters, the following is an elided version of the resulting curl
command:

curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0 (windows/amd64)
kubernetes/9e99141" -H "Authorization: Bearer ..." -H
"X-Stream-Protocol-Version: v4.channel.k8s.io" -H
"X-Stream-Protocol-Version: v3.channel.k8s.io" -H
"X-Stream-Protocol-Version: v2.channel.k8s.io" -H
"X-Stream-Protocol-Version: channel.k8s.io" 'https://
.../api/v1/namespaces/.../pods/.../exec?command=%2Fbin%2Fls=...=true=true=true'

I can't tell from the logging what request body it sent. It's possible it
didn't send any.
--
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

[ANNOUNCEMENT] gdb-9.2-1 (TEST)

[Jon Turney]

The following package has been updated in the Cygwin distribution:

* gdb-9.2-1

The GNU debugger allows you to debug programs written in C, C++, and 
other languages, by executing them in a controlled fashion and printing 
their data.


This is an update to a later upstream version:

https://sourceware.org/pipermail/gdb-announce/2020/000123.html

See the /usr/share/doc/gdb/NEWS file for a list of user-visible changes.
--
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

gdb-9.2-1 (TEST)

[Jon Turney]

The following package has been updated in the Cygwin distribution:

* gdb-9.2-1

The GNU debugger allows you to debug programs written in C, C++, and 
other languages, by executing them in a controlled fashion and printing 
their data.


This is an update to a later upstream version:

https://sourceware.org/pipermail/gdb-announce/2020/000123.html

See the /usr/share/doc/gdb/NEWS file for a list of user-visible changes.

[PATCH] cygport: check for patch files in DISTDIR

[Achim Gratz]

DISTDIR is currently not checked for patches, so change that:

https://repo.or.cz/cygport/rpm-style.git/commitdiff/ef4162c677af1a569b8f012863d26f8d1d154e32


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: cygwin x11 doesn't start after windows 10 upgrade

[Henry S. Thompson via Cygwin]

Steinar Bang writes:

[troubles with XWin]

Have a look at what Windows shows as the processes that are running.

I've had intermittent problems with XWin processes running without
actually showing any windows.  You can see process information either
with a special tool such as ProcExp or with the builtin Windows task
manager, via Control-Alt-Delete.

If you find XWin processes, let us know.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

--
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] cygport: process various checksum digests

[Achim Gratz]

I have several packges where upstream offers digests for the archives,
instead of the more useful signatures.  These come in two forms: either
properly formatted or just the plain hex digest string.  Teach cygport
to deal with these; while it's not as good as signatures, it still helps
verifying the download.

https://repo.or.cz/cygport/rpm-style.git/commitdiff/02ba3d27657a7e35bfbdb4f719c65f454473103f


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

[PATCH] cygport: allow for different package compression types and implement ZStandard decompression

[Achim Gratz]

Now that setup and calm know about Zstandard compression it's about time
we teach cygport the same.

https://repo.or.cz/cygport/rpm-style.git/commitdiff/303045744ba6159c6063786cf5b173d760f6298d

This patch keeps the current defaults in place, but allows one to set up
two environment variables to control how tar gets invoked during
packaging.  You could do that from either the cygport file or the
.cygport.conf file:

CYGPORT_TAR_CMD="env ZSTD_CLEVEL=19 tar -I zstd --group nobody:65534 --owner 
nobody:65534"
CYGPORT_TAR_EXT=".tar.zst"

While our packaged tar does not yet know about zst files the compressor
has top be named explicitly, eventually Eric will get around and release
a new version hopefully and then this can get automatic.  As
demonstrated above the facility can be used to do other useful things
besides changing the compression type and extension.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [PATCH] cygport: suppress spurious package dependencies

[Achim Gratz]

Achim Gratz writes:
>> What exactly are you trying to "fix" with this?
>
> The same thing as always: perl getting pulled in as a dependency for
> perl_base, which defeats the whole purpose of having a base package in
> the first place.  Again, the dependency extraction just doesn't quite
> work for things that have optional dependencies that are used if present
> and do no harm if not: cygport will always pull them in and makes them a
> hard requirement.
>
> There's an obvious copy bug in the patch, btw.

The corrected patch can be had from:
https://repo.or.cz/cygport/rpm-style.git/commitdiff/46a1534b523ada57855f5412f683c77a29dbed00


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: cygwin x11 doesn't start after windows 10 upgrade

[Steinar Bang]

> Jon Turney :

> Sorry to hear you are having problems. [1] lists the ways of starting
> the X server we think should work [2].

Ok. xlaunch is still on the list in [1] and it has worked fine for me
until these problems started.

It seems likely that this is something that happened in the recent Win10
upgrade.  But the problem is figuring out what, since there isn't much
in the way of error messages. :-)

> The simplest way to run the X server is using 'XWin' at a command line.

> Does that work?

Nope.

> I'm guessing probably not.  Does it hang? Or exit
> after doing nothing?

It exits after doing nothing.

> Does 'XWin -logverbose 3' produce any more information?

Unfortunately not.

Here it is:
sbang@ITEM-S63383:~$ XWin -logverbose 3
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.5.0
OS: CYGWIN_NT-10.0-18363 ITEM-S63383 3.1.5-340.x86_64 2020-06-01 08:59 UTC 
x86_64
OS: Windows 10  [Windows NT 10.0 build 18363] (Win64)
Package: version 1.20.5-3 built 2019-09-06

XWin was started with the following command line:

XWin -logverbose 3

OsVendorInit - Creating default screen 0
winInitializeScreens - 1
winInitializeScreen - 0
winValidateArgs - Returning.
(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
LoadPreferences: /cygdrive/d/Profiles/sbang/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winGetDisplay: DISPLAY=:0.0
winDetectSupportedEngines - RemoteSession: no
winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
winDetectSupportedEngines - Returning, supported engines 0005
sbang@ITEM-S63383:~$


Thanks!


- Steinar
--
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 x11 doesn't start after windows 10 upgrade

[Steinar Bang]

> Marco Atzeri via Cygwin :

> Hi Steinar,
> forgot to ask, there is stackdump  of Xwin ?

> usually the stack dump are under /usr/bin

>   ls /usr/bin | grep stack

> but they can also be on your home directory
> or in other places.

Nothing in /usr/bin but there is an lxterminal.exe.stackdump in my home
directory (I'm guessing that it isn't really helpful though. It probably
only crashed because there was no XWin to connect to).

I've attached the lxterminal stack trace to this message (this is from
one of the xlaunch attempts because lxterminal is what I start locally
with XWin).

> Re-looking at your Xwin.0.log
[snip!]
> on my log the next record is
>winSetEngine - Multi Window or Rootless => ShadowGDI

> so it seems something is going wrong there

> from "man Xwin" I see two possible options for troubleshooting
> engine detection faults
[snip!]
> on my system both options work, can you check on yours ?

>startxwin -- -engine 4

Here is the attempt:
sbang@ITEM-S63383:~$ startxwin -- -engine 4

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.5.0
OS: CYGWIN_NT-10.0-18363 ITEM-S63383 3.1.5-340.x86_64 2020-06-01 08:59 UTC 
x86_64
OS: Windows 10  [Windows NT 10.0 build 18363] (Win64)
Package: version 1.20.5-3 built 2019-09-06

XWin was started with the following command line:

/usr/bin/XWin :0 -multiwindow -engine 4 -auth
 /cygdrive/d/Profiles/sbang/.serverauth.747

(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
LoadPreferences: /cygdrive/d/Profiles/sbang/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winDetectSupportedEngines - RemoteSession: no
winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
winDetectSupportedEngines - Returning, supported engines 0005
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
sbang@ITEM-S63383:~$


Thanks!

Stack trace:
FrameFunctionArgs
000C428  0018005CADE (0018023E2ED, 0018021FC46, 000C428, 000B320)
000C428  001800463E9 (000, 000, 000, 003F8AF3FD0)
000C428  00180046422 (0018023E3A9, 000C2D8, 000C428, 000)
000C428  001800A97DF (000, 000, 000, 000)
000C428  001800A9A2D (000C440, 000, 000, 000)
000  001800AAC94 (000C440, 000, 000, 000)
End of stack trace
--
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: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[Marco Atzeri via Cygwin]

On 14.06.2020 08:12, David Karr wrote:



On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:

On 13.06.2020 20:53, David Karr via Cygwin wrote:
 > I've been using kubectl in Cygwin on Windows 10 for quite a while, to
 > communicate to our in-house k8s clusters. I often use "kubectl
exec" to
 > open a shell in a container or directly execute a shell command. 
This has

 > worked perfectly fine for a long time.
 >
 > A couple of days ago, I discovered that all of these attempts
were failing
 > with "Upgrade request required".  I hadn't upgraded kubectl or
Cygwin in
 > quite a while. I doubt our clusters had a k8s upgrade, but it's
entirely
 > possible.
 >
 > A colleague of mine has a very similar desktop configuration
(Windows 10,
 > Cygwin), and he's not seeing this symptom.
 >
 > I noticed that when I ran "kubectl exec" with max verbosity, it
shows the
 > resulting "curl" command that it runs. I tried that resulting
command, and
 > it results in the same response. I then tried updating my Cygwin
tools and
 > retesting, no change.
 >
 > I then took the entire resulting "kubectl exec" command line and
ran it in
 > a "cmd" shell.  No problem at all.  No error.
 >
 > I know I haven't provided much useful information yet. I wanted
to get an
 > initial response before I started providing those diagnostics. Is
there a
 > clear issue here that I'm not aware of?
 > --

from where is kubectl coming from ?

In cygwin I found only a kubectl.py in the ansible package


It's from here: 
https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows 
.


so it is NOT a cygwin program.

If the warning is coming about curl, it is likely
that using from cygwin you are using the cygwin curl
and from CMD the windows one


$ which -a curl
/usr/bin/curl
/cygdrive/c/WINDOWS/system32/curl


$ /cygdrive/c/WINDOWS/system32/curl -V
curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
Release-Date: 2017-11-14, security patched: 2019-11-05
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp 
smtps telnet

 tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL

$ /usr/bin/curl -V
curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f zlib/1.2.11 
brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4) 
libssh/0.8.7/openssl/zlib nghttp2/1.37.0

Release-Date: 2019-09-11
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps 
pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6 
Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP 
TrackMemory UnixSockets



the support Forum https://discuss.kubernetes.io/
is probably the most indicate place for guidance

Regards
Marco

--
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 x11 doesn't start after windows 10 upgrade

[Marco Atzeri via Cygwin]

On 11.06.2020 17:57, Steinar Bang wrote:

Platform: amd64, windows 10 10.0.18363 Build 18363,
   cygwin xorg-server 1.20.5-3, xlaunch 20160530-1

I start X11 by double clicking the following config.xlaunch:
  https://gist.github.com/steinarb/8687e2113c601e061da909e75a180f39

After the reboot caused by a windows 10 upgrade, launching X11 using
xlaunch have stopped working.

I have tried:
  1. Running xlaunch directly instead of double clicking config.xlaunch
  2. Running setup-86_64.exe to install all pending upgrades
  3. Running setup-86_64.exe to reinstall xlaunch
  4. Running setup-86_64.exe to reinstall xorg-server

But none of this has made any difference.

Does anyone have an idea what the problem might be?

Here's XWin.0.log from a startup attempt:
  https://gist.github.com/steinarb/dacfec5172fd547cbec7c87723163193

Thanks1


- Steinar



Hi Steinar,
forgot to ask, there is stackdump  of Xwin ?

usually the stack dump are under /usr/bin

  ls /usr/bin | grep stack

but they can also be on your home directory
or in other places.

Re-looking at your Xwin.0.log

XWin was started with the following command line:

XWin :0 -multiwindow -clipboard -wgl

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1920 h 1080
winInitializeScreenDefaults - native DPI x 120 y 120
[ 24028.656] (II) xorg.conf is not supported
[ 24028.656] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for 
more information

[ 24028.656] LoadPreferences: /cygdrive/d/Profiles/sbang/.XWinrc not found
[ 24028.656] LoadPreferences: Loading /etc/X11/system.XWinrc
[ 24028.656] LoadPreferences: Done parsing the configuration file...
[ 24028.671] winDetectSupportedEngines - RemoteSession: no
[ 24028.687] winDetectSupportedEngines - DirectDraw4 installed, allowing 
ShadowDDNL
[ 24028.687] winDetectSupportedEngines - Returning, supported engines 
0005


on my log the next record is
   winSetEngine - Multi Window or Rootless => ShadowGDI

so it seems something is going wrong there

from "man Xwin" I see two possible options for troubleshooting
engine detection faults

---
   -engine engine_type_id
   This option, which is intended for developers, overrides 
the  server's
   automatically  selected  drawing  engine type.  This 
parameter will be
   ignored if the specified drawing engine type is not 
supported  on  the

   current system.

   Default  behavior is to select the drawing engine with 
optimum perfor‐
   mance that supports the specified depth and window 
configuration.


   The engine type ids are:

   1   Shadow GDI

   4   Shadow DirectDraw Non-Locking



on my system both options work, can you check on yours ?

   startxwin -- -engine 4


--
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: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:

> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> > I've been using kubectl in Cygwin on Windows 10 for quite a while, to
> > communicate to our in-house k8s clusters. I often use "kubectl exec" to
> > open a shell in a container or directly execute a shell command.  This
> has
> > worked perfectly fine for a long time.
> >
> > A couple of days ago, I discovered that all of these attempts were
> failing
> > with "Upgrade request required".  I hadn't upgraded kubectl or Cygwin in
> > quite a while. I doubt our clusters had a k8s upgrade, but it's entirely
> > possible.
> >
> > A colleague of mine has a very similar desktop configuration (Windows 10,
> > Cygwin), and he's not seeing this symptom.
> >
> > I noticed that when I ran "kubectl exec" with max verbosity, it shows the
> > resulting "curl" command that it runs. I tried that resulting command,
> and
> > it results in the same response. I then tried updating my Cygwin tools
> and
> > retesting, no change.
> >
> > I then took the entire resulting "kubectl exec" command line and ran it
> in
> > a "cmd" shell.  No problem at all.  No error.
> >
> > I know I haven't provided much useful information yet. I wanted to get an
> > initial response before I started providing those diagnostics. Is there a
> > clear issue here that I'm not aware of?
> > --
>
> from where is kubectl coming from ?
>
> In cygwin I found only a kubectl.py in the ansible package
>

It's from here:
https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
.
--
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