On Mon, Oct 23, 2006 at 12:54:20PM +0200, Stephan A Suerken wrote: > > Ah, much to my surprise, I am able to reproduce this problem when > > remote-displaying from a machine running unstable. Or from etch -- but in > > both cases only when trying to display it remotely.
> I get it that you are sure that, when experiencing this bug, s.th. > like "xclock" works while uae does not under the same conditions? Yes. (My control client here was 'xterm'.) > I have just successfully tested remote displaying using "ssh -X" (on > both, an amd64 and a i386 etch) -- which also uses the ~/.Xauthority > file afaik. > What exactly do I have to do to reproduce this? No idea... It's trivially reproducible for me running ssh -X from i386/etch to amd64/sid, or even running ssh -X localhost on i386/etch. An strace shows uae attempting to make two successive connections to the X server. In the first instance, it correctly opens ~/.Xauthority and authenticates successfully. In the second instance (after joystick/sound detection), it looks at .uaerc/.Xauthority, which of course doesn't exist, and fails to connect as a result. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
