Re: Find_fast_cwd : warning

[cygwinautoreply--- via Cygwin]

>Hello team,

>I am facing below warning many times when I am using 
>cygwin\lib\gcc\i686-pc-cygwin\4.8.3 ..please do me know what is the solution 
>for this issue


>1 [main] sh 18352 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.  
>Please report this problem to
>the public mailing list cygwin@cygwin.com

>Regards
>Jagadesh.A.S


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

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

[ASSI]

Holger, Vodafone writes:
> 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.

If the root-kit-like character of some of their components and the many
CVE in TrendMicro that essentially do the opposite of what the product
is promised to do hasn't already convinced your administrators to get
rid of it, you should exempt the Cygwin installation directory from all
their heuristics and "on-line" check and mitigation facilities.  How
exactly to do this varies, but in a corporate environment these are
usually not modifiable by the user.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
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

[Brian Inglis]

Apparently tmmon64.dll is a Trend Micro DLL that overwrites Windows dynamic
memory allocation entry points to monitor and track memory allocation.
It has been implicated by MS in a number of failures of MS software and system
crashes.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]


On 2020-06-15 06:17, Holger, Vodafone wrote:
> And I have checked on my system today, my strace output stop at the same 
> tmmon64.dll, so it is likely the reason for the error.
> 
> I have opened a service request with our IT and wait for their answer.
> 
> 
> 
>> Am 15.06.2020 um 00:21 schrieb 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
>>> 

Find_fast_cwd : warning

[Srikantaiah, Jagadesh via Cygwin]

Hello team,

I am facing below warning many times when I am using 
cygwin\lib\gcc\i686-pc-cygwin\4.8.3 ..please do me know what is the solution 
for this issue


1 [main] sh 18352 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.  
Please report this problem to
the public mailing list cygwin@cygwin.com

Regards
Jagadesh.A.S

--
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: [ITP] VirtualGL 2.6.3

[DRC via Cygwin-apps]

On a Windows machine running Cygwin:

- Enable and start the cygserver service (needed in order to enable the
MIT-SHM extension in Cygwin/X.)
[https://cygwin.com/cygwin-ug-net/using-cygserver.html]
- Install (if necessary) and start the Cygwin/X server (/usr/bin/startxwin).
- Install (if necessary) OpenSSH.
- Launch XTerm using the X applications menu.
- /usr/bin/vglconnect -s {some-Linux-host}

NOTE:
As to whether the VirtualGL package should depend on Cygwin/X and
OpenSSH, technically the vglconnect script and vglclient application,
despite running in a Cygwin environment, could still be used with an
external X server and SSH implementation not provided by Cygwin.  Thus,
it's my opinion that the VirtualGL package should not depend on Cygwin/X
and the Cygwin-provided OpenSSH package.  However, I am open to being
convinced otherwise, particularly if there is an established precedent.

On the Linux host:

- Install the appropriate libjpeg-turbo official binary package,
depending on your flavor of Linux.
[https://sourceforge.net/projects/libjpeg-turbo/files/2.0.4]
- Install (if necessary) the X11 and OpenGL development kits (libX11,
libXext, libXtst, libGL, and libGLU.)
- Install (if necessary) CMake.
- wget
https://sourceforge.net/projects/virtualgl/files/2.6.3/VirtualGL-2.6.3.tar.gz
- tar xf VirtualGL-2.6.3.tar.gz
- cd VirtualGL-2.6.3
- mkdir build
- cd build
- cmake ..
- make vgltransut
- bin/vgltransut {some-BMP-or-PPM-file}


On 6/13/20 2:11 AM, Marco Atzeri via Cygwin-apps wrote:
> On 12.06.2020 22:53, DRC via Cygwin-apps wrote:
>> I intend to package the client for VirtualGL, a toolkit that adds
>> server-side GPU-accelerated OpenGL rendering capabilities to existing
>> remote X or X proxy environments.
>>
>> VirtualGL is currently provided by various Linux distributions and
>> FreeBSD:
>> https://pkgs.org/download/virtualgl
>> https://rpmfind.net/linux/rpm2html/search.php?query=VirtualGL
>>
>> It is licensed under the wxWidgets Library License v3.1:
>> https://opensource.org/licenses/WXwindows
>>
>> Archive containing proposed package files:
>> https://turbovnc.org/downloads/VirtualGL-cygwin.tar.bz2
>>
>> DRC
>>
> 
> builds fine, how to test it ?
> 
> Regards
> Marco

mintty emacs-nox pseudorandom color dimming

[Paul Ausbeck via Cygwin]

Dear Sirs:

After recently updating my cygwin installation, emacs-nox now pseudorandomly 
dims some characters after the cursor passes through a character's position. I 
don't think the problem lies with emacs-nox, but rather with mintty. I say this 
as the color dimming happens when one is using local emacs-nox within a mintty 
or using remote emacs-nox after sshing within a mintty.

After I first discovered the dimming problem I noticed a separate problem with 
the backspace key in ssh sessions. I then noticed that there was yet another 
more recent mintty update, so I thought that I'd try that. After applying that 
update, the backspace problem resolved itself. However, the character dimming 
problem remains.

Regards,

Paul Ausbeck
--
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: [ITP] python36-wx 4.0.7.post2

[Achim Gratz]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> Turns out just running "rebaseall" worked for me. I don't get any
> fork-related warnings/errors any more.

No it doesn't, it's a mere coincidence that it worked in your case.  You
shouldn't manually run rebaseall on Cygwin at all in fact, setup
perpetual postinstall actions take care of maintaing the rebase map.
If you ever have reason to believe that the rebase map needs a complete
rebuild, run "rebase-trigger full" and then run setup again.

Fitting newly built DLL into the rebase map is correctly done by an
ephemeral rebase like the script Marco has shown you does.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: RCS?

[Bill Coffin]

Sorry to jump the gun, I found cpp, too.

-Bill

On 6/15/2020 10:10 AM, Bill Coffin wrote:
It turned out to be easier than that.  I just re-ran the installer and 
added the RCS package.  Works fine!  I also found "make" easily 
enough.  But which package contains cpp (the C preprocessor, not the 
C++ thing).


Thanks,
  Bill

On 6/14/2020 5:23 PM, Eliot Moss wrote:
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




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

[Bill Coffin]

It turned out to be easier than that.  I just re-ran the installer and 
added the RCS package.  Works fine!  I also found "make" easily enough.  
But which package contains cpp (the C preprocessor, not the C++ thing).


Thanks,
  Bill

On 6/14/2020 5:23 PM, Eliot Moss wrote:

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


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

change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1

[Josh Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Cygwin community,

I'm a developer on the Apache VCL project which is a private cloud management 
platform.  We've used Cygwin for many years to allow VCL management systems to 
ssh in to Windows nodes to manage them.  We're very grateful for the Cygwin 
project and how helpful it has been to us for many years.  :)

We recently noticed a change in double quote (") handling that is causing a 
command we issue to fail.  The command is:

cmd.exe /c "mkdir \"C:/Cygwin/home/root/VCL\""

In 3.1.4-1 and previous versions, the command works as expected.

In 3.1.5-1, it returns this error:

The filename, directory name, or volume label syntax is incorrect.

The command is being issued to a bash shell that is opened over ssh.  I really 
don't know why it was decided to use cmd.exe to launch mkdir instead of just 
using mkdir through bash, but that's how the VCL code currently is.  The 
command is in a utility function that can be passed various paths to create.  
In the case listed above, the escaped quotes wouldn't be needed.  However, if 
the path passed in contained any spaces, the quotes become necessary.

I chatted with jturney and avih on IRC about this (thanks jturney and avih!).  
jturney pointed out using echo instead of mkdir also illustrated the problem.

in 3.1.4:

$ cmd.exe /c "echo \"C:/Cygwin/home/root/VCL\""
"C:/Cygwin/home/root/VCL"

in 3.1.5:

$ cmd.exe /c "echo \"C:/Cygwin/home/root/VCL\""
\"C:/Cygwin/home/root/VCL\"

And, this can be simplified even more to just

3.1.4:
$ cmd.exe /c "echo \""
"

3.1.5:
$ cmd.exe /c "echo \""
\"

avih brought up a valid point that it may now be quoting the quotes since they 
are part of the argument list.  However, I can't come up with the proper 
escaping of things to use mkdir to create a directory with a space in it with 
the new behavior.

jturney asked if I would email this list about the issue.

Thanks for any help!

Josh Thompson
- -- 
- ---
Josh Thompson
VCL Developer
North Carolina State University

my GPG/PGP key can be found on pool.sks-keyservers.net

All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQRMIdRtWXideTZDK31X8tBw1209AwUCXuegCAAKCRBX8tBw1209
A09tAJ0f2c3/9LaHdYxbprt6IRem8i90ogCfeUNV0SQJFKfIMo8klnr+EiX+oNE=
=Dzm0
-END PGP SIGNATURE-



--
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 12:32 PM David Karr wrote:

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

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

[Holger, Vodafone]

And it look like a problem from at least 2018:

https://sourceware.org/legacy-ml/cygwin/2018-07/msg00278.html 



> Am 15.06.2020 um 14:17 schrieb Holger, Vodafone :
> 
> And I have checked on my system today, my strace output stop at the same 
> tmmon64.dll, so it is likely the reason for the error.
> 
> I have opened a service request with our IT and wait for their answer.
> 
> 
> 
>> Am 15.06.2020 um 00:21 schrieb 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 

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

[Holger, Vodafone]

And I have checked on my system today, my strace output stop at the same 
tmmon64.dll, so it is likely the reason for the error.

I have opened a service request with our IT and wait for their answer.



> Am 15.06.2020 um 00:21 schrieb 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 

Strong guarantees for your web page visibility

[dest...@alltopbanner.com]

Hi Cygwin,

I'm Destiny

There is the bigest reason to get the first page visibility for your website.
For this purpose only, our newest technique is to demonstrate a specific example
of how to optimize a web page beneficially. This can be achieved simply by
applying the concept of our technology.

We will analyze your website and keywords and give you traffic estimates for
keywords that you want to lock

To see it in action:
1. Go to our website and try the online demo.
2. Fill online quote form on our website and put your website 
cygwin com details.


Regards,
Destiny Hutchinson
--
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: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 11/06/2020 17:41, Marco Atzeri via Cygwin-apps wrote:
> the 32bit has less memory space so it take a bit of file swapping when
> the data are large

Ah okay.

> run demo in build dir ?
>
> 1) remove any excessive libraries from your cygwin 32 bit install.
> Recently for a similar reason I removed all libboost except the
> last one, a good of previous version like libicuXX and similar
> that accumulated in the years.
>
> 2) rebase the built dll's without storing permanently the addresses.
>   Attached the script I am using for the scope
>
>
Turns out just running "rebaseall" worked for me. I don't get any
fork-related warnings/errors any more.

I'm running the demo from
https://extras.wxpython.org/wxPython4/extras/4.0.7.post2/ in a separate
directory with the packages I built installed.

Do I need to rebuild this for the new Python release? If not I think
this is all working now. Does it seem good to you?

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature