Re: A workaround against Emacs crash when displaying images

2019-03-07 Thread Katsumi Yamaoka
On Fri, 08 Mar 2019 08:36:24 +0900, Katsumi Yamaoka wrote: > I tried the 2019-03-06 snapshot and, oh!, I verified Emacs got > not to crash for displaying images without such a spell. > It seems Emacs revived as for me as it was before Cygwin 3. I'm sorry that was a hasty conclusion. Emacs

Re: pulseaudio.exe never have a sound

2019-03-07 Thread Bobone
Corinna Vinschen-2 wrote > Is anybody here interested in removing these limitations? One problem is > that Cygwin only recogizes a single audio device, the current default > device. It would be cool if somebody with a bit of knowledge in Windows > audio could update Cygwin's /dev/dsp code a bit.

Re: A workaround against Emacs crash when displaying images

2019-03-07 Thread Katsumi Yamaoka
On Thu, 07 Mar 2019 15:55:29 +, Ken Brown wrote: > On 3/6/2019 7:20 PM, Katsumi Yamaoka wrote: >> export MAGICK_THREAD_LIMIT=1 > Is this a new issue with cygwin-3.0.x? If so, it might be related > to the memory leak that was recently discovered (and fixed in the > latest snapshot): >

RE: emacs-X11 memory leak?

2019-03-07 Thread Rockefeller, Harry
>>> -Original Message- >>> From: cygwin-ow...@cygwin.com On Behalf Of >>> Ken Brown >>> Sent: Thursday, March 07, 2019 9:09 AM To: cygwin@cygwin.com Subject: Re: emacs-X11 memory leak? >> On 3/7/2019 9:53 AM, Rockefeller, Harry wrote: > CYGWIN_NT-6.1 HARRYR-PC

Re: Emacs seems to be dragging down other processes?

2019-03-07 Thread Ken Brown
On 3/7/2019 3:39 PM, David Karr wrote: > I've recently been having general performance problems on my Win7 laptop, > mostly realized by very slow switches to workspaces (Dexpot). I've been > watching processes using high cpu, and I'm trying to watch for processes > with high i/o, but I'm not as

Emacs seems to be dragging down other processes?

2019-03-07 Thread David Karr
I've recently been having general performance problems on my Win7 laptop, mostly realized by very slow switches to workspaces (Dexpot). I've been watching processes using high cpu, and I'm trying to watch for processes with high i/o, but I'm not as certain how to find those (I'm using Process

Re: emacs-X11 memory leak?

2019-03-07 Thread Ken Brown
On 3/7/2019 3:00 PM, Rockefeller, Harry wrote: > >>> -Original Message- >>> From: cygwin-ow...@cygwin.com On Behalf Of >>> Ken Brown >>> Sent: Thursday, March 07, 2019 9:09 AM >>> To: cygwin@cygwin.com >>> Subject: Re: emacs-X11 memory leak? > >>> On 3/7/2019 9:53 AM, Rockefeller, Harry

RE: emacs-X11 memory leak?

2019-03-07 Thread Rockefeller, Harry
>>-Original Message- >>From: cygwin-ow...@cygwin.com On Behalf Of >>Ken Brown >>Sent: Thursday, March 07, 2019 9:09 AM >>To: cygwin@cygwin.com >>Subject: Re: emacs-X11 memory leak? >>On 3/7/2019 9:53 AM, Rockefeller, Harry wrote: >>> CYGWIN_NT-6.1 HARRYR-PC 3.0.1(0.338/5/3) 2019-02-20

Re: Fresh OS, fresh cygwin install, unable to resolve "couldn't allocate heap, Win32 error 487" error

2019-03-07 Thread Bill Bierman
Reverting to Cygwin 2.10.0 solved the problem for me. On Wed, Mar 6, 2019 at 8:31 AM Achim Gratz wrote: > > Bill Bierman writes: > >> I am currently receiving this error when attempting to compile libgmp: > > What's wrong with the libgmp that ships with Cygwin? > > >> *** fatal error in

Re: A workaround against Emacs crash when displaying images

2019-03-07 Thread Ken Brown
On 3/6/2019 7:20 PM, Katsumi Yamaoka wrote: > Hi, > > I found a workaround for Emacs from crashing that always happens > when displaying images in an html article using Gnus. That is: > > export MAGICK_THREAD_LIMIT=1 > > According to the Google search someone said the crash arises due > to a

RE: emacs-X11 memory leak?

2019-03-07 Thread Rockefeller, Harry
>-Original Message- >From: cygwin-ow...@cygwin.com On Behalf Of Ken Brown >Sent: Thursday, March 07, 2019 9:09 AM >To: cygwin@cygwin.com >Subject: Re: emacs-X11 memory leak? >On 3/7/2019 9:53 AM, Rockefeller, Harry wrote: >> CYGWIN_NT-6.1 HARRYR-PC 3.0.1(0.338/5/3) 2019-02-20 10:19

Re: Logging-in using ssh elevates the user privilege.

2019-03-07 Thread Andrey Repin
Greetings, Takashi Yano! >> This also causes gnu screen to freeze. > GNU screen freeze without much of an effort under Cygwin. > Try detaching from running screen and then running screen -ls. Past discussion http://sourceware.org/ml/cygwin/2017-05/msg00448.html

Re: emacs-X11 memory leak?

2019-03-07 Thread Ken Brown
On 3/7/2019 9:53 AM, Rockefeller, Harry wrote: > CYGWIN_NT-6.1 HARRYR-PC 3.0.1(0.338/5/3) 2019-02-20 10:19 x86_64 Cygwin > GNU Emacs 26.1 (build 1, x86_64-unknown-cygwin, GTK+ Version 3.22.28) of > 2018-05-28 > > I got egg on my face with my last post to Cygwin. So, no, I'm not claiming > there

emacs-X11 memory leak?

2019-03-07 Thread Rockefeller, Harry
CYGWIN_NT-6.1 HARRYR-PC 3.0.1(0.338/5/3) 2019-02-20 10:19 x86_64 Cygwin GNU Emacs 26.1 (build 1, x86_64-unknown-cygwin, GTK+ Version 3.22.28) of 2018-05-28 I got egg on my face with my last post to Cygwin. So, no, I'm not claiming there is a memory leak, but rather how to test what's going on.

Re: sshd problem on WS2008R2 64bit

2019-03-07 Thread Brian Inglis
On 2019-03-07 01:53, Corinna Vinschen wrote: > On Mar 6 23:15, Brian Inglis wrote: >> On 2019-03-06 13:59, Corinna Vinschen wrote: >>> I'm reasonably sure there won't be any fix for these systems for at >>> least two reasons: >>> - All affected systems are EOLed or in the last year of their

Re: Annoying error messages from setup

2019-03-07 Thread Ken Brown
On 3/6/2019 7:02 PM, Enrique Perez-Terron wrote: > For some time (several months), the setup program always finishes with the > following message: > >> Package: _/cygwin-doc >> cygwin-doc.sh exit code 3 >> Package: z/Perpetual >> zp_texlive_finish.dash exit code 20 > The output from

Re: Logging-in using ssh elevates the user privilege.

2019-03-07 Thread Takashi Yano
Sorry, the message bellow accidentally lost the references. On Thu, 7 Mar 2019 20:14:39 +0900 Takashi Yano wrote: > On Wed, 06 Mar 2019 19:33:17 +0100 Achim Gratz wrote: > > This has been the case for as long as I use ssh logins and is by design. > > You can drop privileges after logon (see

Re: Logging-in using ssh elevates the user privilege.

2019-03-07 Thread Andrey Repin
Greetings, Takashi Yano! > This also causes gnu screen to freeze. GNU screen freeze without much of an effort under Cygwin. Try detaching from running screen and then running screen -ls. > To reproduce this: > (1) Start screen in mintty window. > (2) Detatch from the screen (Ctrl-A d). > (3)

Re: Logging-in using ssh elevates the user privilege.

2019-03-07 Thread Takashi Yano
On Wed, 06 Mar 2019 19:33:17 +0100 Achim Gratz wrote: > This has been the case for as long as I use ssh logins and is by design. > You can drop privileges after logon (see cygdrop), but not aquire new > ones. > > So if that's changed behaviour for you, then your ssh logins didn't > actually work

Re: Logging-in using ssh elevates the user privilege.

2019-03-07 Thread Takashi Yano
Hi Corinna, On Wed, 6 Mar 2019 17:17:31 +0100 Corinna Vinschen wrote: > > This is by design, and this is no new behaviour. As soon as an admin > > account logs in, seteuid uses the elevated token. Cygwin is doing that > > since 2015. > > Actually, since 2010. > > > After all, from an ssh

Updated: Perl distributions

2019-03-07 Thread Achim Gratz
The following Perl distributions have been updated to their latest version on CPAN, respectively: x86/x86_64 -- perl-Cpanel-JSON-XS-4.09-1 perl-Data-UUID-1.224-1 perl-JSON-XS-4.02-0 perl-Proc-ProcessTable-0.56-1 perl-Socket-2.029-1 perl-XML-LibXML-2.0134-1 noarch --

[ANNOUNCEMENT] Updated: Perl distributions

2019-03-07 Thread Achim Gratz
The following Perl distributions have been updated to their latest version on CPAN, respectively: x86/x86_64 -- perl-Cpanel-JSON-XS-4.09-1 perl-Data-UUID-1.224-1 perl-JSON-XS-4.02-0 perl-Proc-ProcessTable-0.56-1 perl-Socket-2.029-1 perl-XML-LibXML-2.0134-1 noarch --

Re: sshd problem on WS2008R2 64bit

2019-03-07 Thread Corinna Vinschen
On Mar 6 23:15, Brian Inglis wrote: > On 2019-03-06 13:59, Corinna Vinschen wrote: > > I'm reasonably sure there won't be any fix for these systems for at > > least two reasons: > > - All affected systems are EOLed or in the last year of their Extended > > Support Cycle, all ending on