From antoine at nagafix.co.uk  Tue Jan  1 07:40:54 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Tue, 01 Jan 2013 14:40:54 +0700
Subject: [winswitch] [ANNOUNCE] xpra 0.7.6
Message-ID: <50E29306.1040806@nagafix.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

This release fixes a number of bugs. See release notes below.

The source:
https://xpra.org/src/
Binaries/repositories:
https://winswitch.org/downloads/
Direct binary downloads:
https://xpra.org/dists/

Cheers
Antoine

Release notes:
* fix tray options meant to be unusable until connected
* fix auto refresh delay
* fix missing first bell in error case
* fix potential DoS in client disconnection accounting
* fix network calls coming from wrong thread in error case
* fix unlikely locking issue and reduce lock hold time
* fix disconnect all connected clients cleanly
* fix clipboard flag handling
* fix Mac OSX path with spaces handling
* fix server minimum window dimensions with video encoders
* don't bother trying to auto-refresh in lossless modes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDikwYACgkQGK2zHPGK1rvglQCfRQTSpcQelu05O01yFLuNmfqr
5zYAnAxhyiQbJ9TAHmn0rujVS4x+A984
=cNBP
-----END PGP SIGNATURE-----


From ndbecker2 at gmail.com  Fri Jan  4 01:20:19 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 3 Jan 2013 20:20:19 -0500
Subject: [winswitch] trying out xpra/winswitch
Message-ID: <CAG3t+pGRbtLvNBKdeXYx+ZifiuU1p2t8m21FU-SHeDM_PcsXew@mail.gmail.com>

Trying out latest on Fedora 17.

1. Which way to configure Xorg?  Right now I'm trying xvfb with the dummy
driver:
xvfb=/usr/bin/Xorg-nosuid -dpi 96 -noreset -nolisten tcp +extension GLX
+extension RANDR +extension RENDER -logfile
${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf

This seems to look nice on emacs.  But I wonder if this is the "best"
option?  One thing is, it seems RANDR extension is reported as missing.
 For example, running xrandr --verbose from within emacs reports that.

2. winswitch works, but if I try to start a remote desktop session it works
with xpra, but not NX.  I believe it said something about ssh server not
forwarding?

3. In winswitch, if I try to start a different size desktop session, it
does not change size.  Probably related to RANDR missing?


From ndbecker2 at gmail.com  Fri Jan  4 01:30:28 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 3 Jan 2013 20:30:28 -0500
Subject: [winswitch] trying out xpra/winswitch
In-Reply-To: <CAG3t+pGRbtLvNBKdeXYx+ZifiuU1p2t8m21FU-SHeDM_PcsXew@mail.gmail.com>
References: <CAG3t+pGRbtLvNBKdeXYx+ZifiuU1p2t8m21FU-SHeDM_PcsXew@mail.gmail.com>
Message-ID: <CAG3t+pE4sk14O93bE2GYnbcYBD7W2kAgTepge5is_Zbr2Vd4-A@mail.gmail.com>

4. emacs started manually on remote using xpra looks much nicer than emacs
started via winswitch.  I could send screenshots.


On Thu, Jan 3, 2013 at 8:20 PM, Neal Becker <ndbecker2 at gmail.com> wrote:

> Trying out latest on Fedora 17.
>
> 1. Which way to configure Xorg?  Right now I'm trying xvfb with the dummy
> driver:
> xvfb=/usr/bin/Xorg-nosuid -dpi 96 -noreset -nolisten tcp +extension GLX
> +extension RANDR +extension RENDER -logfile
> ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf
>
> This seems to look nice on emacs.  But I wonder if this is the "best"
> option?  One thing is, it seems RANDR extension is reported as missing.
>  For example, running xrandr --verbose from within emacs reports that.
>
> 2. winswitch works, but if I try to start a remote desktop session it
> works with xpra, but not NX.  I believe it said something about ssh server
> not forwarding?
>
> 3. In winswitch, if I try to start a different size desktop session, it
> does not change size.  Probably related to RANDR missing?
>


From ndbecker2 at gmail.com  Fri Jan  4 12:47:05 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 4 Jan 2013 07:47:05 -0500
Subject: [winswitch] trying out xpra/winswitch
In-Reply-To: <CAG3t+pE4sk14O93bE2GYnbcYBD7W2kAgTepge5is_Zbr2Vd4-A@mail.gmail.com>
References: <CAG3t+pGRbtLvNBKdeXYx+ZifiuU1p2t8m21FU-SHeDM_PcsXew@mail.gmail.com>
 <CAG3t+pE4sk14O93bE2GYnbcYBD7W2kAgTepge5is_Zbr2Vd4-A@mail.gmail.com>
Message-ID: <CAG3t+pFw7y4JVwfP6Z35Vk08kvu_W0Rb0GCtHoPkQQyk_khy9A@mail.gmail.com>

I have some info about 4.  It seems if I use xpra directly, the server
started on the remote is using Xdummy driver, as per my xpra.conf.  But
when started by winswitch, it is not.  Any ideas?


On Thu, Jan 3, 2013 at 8:30 PM, Neal Becker <ndbecker2 at gmail.com> wrote:

> 4. emacs started manually on remote using xpra looks much nicer than emacs
> started via winswitch.  I could send screenshots.
>
>
> On Thu, Jan 3, 2013 at 8:20 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
>
>> Trying out latest on Fedora 17.
>>
>> 1. Which way to configure Xorg?  Right now I'm trying xvfb with the dummy
>> driver:
>> xvfb=/usr/bin/Xorg-nosuid -dpi 96 -noreset -nolisten tcp +extension GLX
>> +extension RANDR +extension RENDER -logfile
>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf
>>
>> This seems to look nice on emacs.  But I wonder if this is the "best"
>> option?  One thing is, it seems RANDR extension is reported as missing.
>>  For example, running xrandr --verbose from within emacs reports that.
>>
>> 2. winswitch works, but if I try to start a remote desktop session it
>> works with xpra, but not NX.  I believe it said something about ssh server
>> not forwarding?
>>
>> 3. In winswitch, if I try to start a different size desktop session, it
>> does not change size.  Probably related to RANDR missing?
>>
>
>


From ndbecker2 at gmail.com  Fri Jan  4 14:53:02 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 4 Jan 2013 09:53:02 -0500
Subject: [winswitch] xpra use case
Message-ID: <CAG3t+pFM3-E=7BFGmc1yYNOANovZn3yxfKH5By38fym22bR6ZA@mail.gmail.com>

I'm confused about xpra use.
In the example, in order to start the xterm I will need to ssh to the
remote machine.  If this ssh is disconnected, xterm dies.

My typical use would be start emacs on remote (via ssh).  Then disconnect
and connect to it later.

Does xpra support this use?

On the machine which will export the application (xterm in this example):

xpra start :100
DISPLAY=:100 xterm

For the simple case, we can then attach to this session from the same
machine with:

xpra attach :100

If connecting from a remote machine, you would use something like:

xpra attach ssh:serverhostname:100


From antoine at nagafix.co.uk  Sat Jan  5 11:18:05 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sat, 05 Jan 2013 18:18:05 +0700
Subject: [winswitch] xpra use case
In-Reply-To: <CAG3t+pFM3-E=7BFGmc1yYNOANovZn3yxfKH5By38fym22bR6ZA@mail.gmail.com>
References: <CAG3t+pFM3-E=7BFGmc1yYNOANovZn3yxfKH5By38fym22bR6ZA@mail.gmail.com>
Message-ID: <50E80BED.1080005@nagafix.co.uk>

On 01/04/2013 09:53 PM, Neal Becker wrote:
> I'm confused about xpra use.
> In the example, in order to start the xterm I will need to ssh to the
> remote machine.  If this ssh is disconnected, xterm dies.
Then you should learn about nohup, screen, etc or use the --start-child
switch.
The home page has been updated to include an example:
http://xpra.org/

> My typical use would be start emacs on remote (via ssh).  Then disconnect
> and connect to it later.
Note: there are plans to implement:
xpra start ssh:HOST:DISPLAY --start-child=XYZ
So you won't even need to ssh initially.
Probably not for 0.8 (due soon) - unless someone else can write the
code, but the next release after that.

> Does xpra support this use?
Yes.

> On the machine which will export the application (xterm in this example):
> 
> xpra start :100
> DISPLAY=:100 xterm
> 
> For the simple case, we can then attach to this session from the same
> machine with:
> 
> xpra attach :100
> 
> If connecting from a remote machine, you would use something like:
> 
> xpra attach ssh:serverhostname:100
That's all good.

Cheers
Antoine


From antoine at nagafix.co.uk  Sat Jan  5 11:27:05 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sat, 05 Jan 2013 18:27:05 +0700
Subject: [winswitch] trying out xpra/winswitch
In-Reply-To: <CAG3t+pFw7y4JVwfP6Z35Vk08kvu_W0Rb0GCtHoPkQQyk_khy9A@mail.gmail.com>
References: <CAG3t+pGRbtLvNBKdeXYx+ZifiuU1p2t8m21FU-SHeDM_PcsXew@mail.gmail.com>
 <CAG3t+pE4sk14O93bE2GYnbcYBD7W2kAgTepge5is_Zbr2Vd4-A@mail.gmail.com>
 <CAG3t+pFw7y4JVwfP6Z35Vk08kvu_W0Rb0GCtHoPkQQyk_khy9A@mail.gmail.com>
Message-ID: <50E80E09.5060205@nagafix.co.uk>

On 01/04/2013 07:47 PM, Neal Becker wrote:
> I have some info about 4.  It seems if I use xpra directly, the server
> started on the remote is using Xdummy driver, as per my xpra.conf.  But
> when started by winswitch, it is not.  Any ideas?
What versions have you got installed? What platform, distro, etc?
Old versions used to try to make xpra use Xdummy explicitly by
specifying the Xvfb command to use. But this is no longer the case, and
when winswitch launches xpra it will use the same configuration file as
when used from the command line?

> On Thu, Jan 3, 2013 at 8:30 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> 
>> 4. emacs started manually on remote using xpra looks much nicer than emacs
>> started via winswitch.  I could send screenshots.
Quality is encoding related, it is quite possible that winswitch uses a
different encoding by default. Try holding launching your commands via
the full "Start Application" dialog, or by holding the "Shift" key as
you select the application from the start menu, these dialogs allow you
to select the encoding quality.
Or just compare once launched in the xpra tray menu.

>> On Thu, Jan 3, 2013 at 8:20 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
>>
>>> Trying out latest on Fedora 17.
>>>
>>> 1. Which way to configure Xorg?  Right now I'm trying xvfb with the dummy
>>> driver:
>>> xvfb=/usr/bin/Xorg-nosuid -dpi 96 -noreset -nolisten tcp +extension GLX
>>> +extension RANDR +extension RENDER -logfile
>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf
/etc/xpra.conf
Should have examples for both Xvfb and Xdummy. What is enabled depends
on your distro. If Xdummy is not chosen, chances are that your distro is
too old to support it adequately.

>>> This seems to look nice on emacs.  But I wonder if this is the "best"
>>> option?  One thing is, it seems RANDR extension is reported as missing.
>>>  For example, running xrandr --verbose from within emacs reports that.
As per:
http://xpra.org/Xdummy.html
Xdummy is the way forward and there are a number of unfixable bugs when
using Xvfb without randr.

>>> 2. winswitch works, but if I try to start a remote desktop session it
>>> works with xpra, but not NX.  I believe it said something about ssh server
>>> not forwarding?
Details please. Platform, versions, etc. Log files?

>>> 3. In winswitch, if I try to start a different size desktop session, it
>>> does not change size.  Probably related to RANDR missing?
What protocol are you using for your desktop session? NX? VNC? Xpra?

Cheers
Antoine


>>>
>>
>>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 



From ndbecker2 at gmail.com  Sat Jan  5 21:44:49 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 5 Jan 2013 16:44:49 -0500
Subject: [winswitch] trying out xpra/winswitch
In-Reply-To: <50E80E09.5060205@nagafix.co.uk>
References: <CAG3t+pGRbtLvNBKdeXYx+ZifiuU1p2t8m21FU-SHeDM_PcsXew@mail.gmail.com>
 <CAG3t+pE4sk14O93bE2GYnbcYBD7W2kAgTepge5is_Zbr2Vd4-A@mail.gmail.com>
 <CAG3t+pFw7y4JVwfP6Z35Vk08kvu_W0Rb0GCtHoPkQQyk_khy9A@mail.gmail.com>
 <50E80E09.5060205@nagafix.co.uk>
Message-ID: <CAG3t+pE+PtkkaCp1gEOQm8DDhxMKXjZLaEOBCjzv=2NZFTx0_g@mail.gmail.com>

I'm baffled.  If I start emacs via xpra (using xdummy), it looks great.  If
I start via winswitch it doesn't.  It looks like it's set to a lower
resolution.

Both clients and servers are fedora f17 linux.

Within each of these emacs sessions, I ran xdpyinfo and xrandr.  Both
outputs show no difference.  I compared the two Xorg.:7.log, Xorg.:62.log,
and don't offhand see any significant diff (because of the timestamps,
comparing these files I just did visually).

I have no ideas how to debug this.  I'd like to use winswitch for the nice
features, but emacs under xpra looks beautiful while emacs under winswitch
looks bad.

I was wrong about my guess that winswitch was not using xdummy.  I see that
Xorg was started with the same command line in both cases.

Any ideas?


On Sat, Jan 5, 2013 at 6:27 AM, Antoine Martin <antoine at nagafix.co.uk>wrote:

> On 01/04/2013 07:47 PM, Neal Becker wrote:
> > I have some info about 4.  It seems if I use xpra directly, the server
> > started on the remote is using Xdummy driver, as per my xpra.conf.  But
> > when started by winswitch, it is not.  Any ideas?
> What versions have you got installed? What platform, distro, etc?
> Old versions used to try to make xpra use Xdummy explicitly by
> specifying the Xvfb command to use. But this is no longer the case, and
> when winswitch launches xpra it will use the same configuration file as
> when used from the command line?
>
> > On Thu, Jan 3, 2013 at 8:30 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> >
> >> 4. emacs started manually on remote using xpra looks much nicer than
> emacs
> >> started via winswitch.  I could send screenshots.
> Quality is encoding related, it is quite possible that winswitch uses a
> different encoding by default. Try holding launching your commands via
> the full "Start Application" dialog, or by holding the "Shift" key as
> you select the application from the start menu, these dialogs allow you
> to select the encoding quality.
> Or just compare once launched in the xpra tray menu.
>
> >> On Thu, Jan 3, 2013 at 8:20 PM, Neal Becker <ndbecker2 at gmail.com>
> wrote:
> >>
> >>> Trying out latest on Fedora 17.
> >>>
> >>> 1. Which way to configure Xorg?  Right now I'm trying xvfb with the
> dummy
> >>> driver:
> >>> xvfb=/usr/bin/Xorg-nosuid -dpi 96 -noreset -nolisten tcp +extension GLX
> >>> +extension RANDR +extension RENDER -logfile
> >>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf
> /etc/xpra.conf
> Should have examples for both Xvfb and Xdummy. What is enabled depends
> on your distro. If Xdummy is not chosen, chances are that your distro is
> too old to support it adequately.
>
> >>> This seems to look nice on emacs.  But I wonder if this is the "best"
> >>> option?  One thing is, it seems RANDR extension is reported as missing.
> >>>  For example, running xrandr --verbose from within emacs reports that.
> As per:
> http://xpra.org/Xdummy.html
> Xdummy is the way forward and there are a number of unfixable bugs when
> using Xvfb without randr.
>
> >>> 2. winswitch works, but if I try to start a remote desktop session it
> >>> works with xpra, but not NX.  I believe it said something about ssh
> server
> >>> not forwarding?
> Details please. Platform, versions, etc. Log files?
>
> >>> 3. In winswitch, if I try to start a different size desktop session, it
> >>> does not change size.  Probably related to RANDR missing?
> What protocol are you using for your desktop session? NX? VNC? Xpra?
>
> Cheers
> Antoine
>
>
> >>>
> >>
> >>
> > _______________________________________________
> > shifter-users mailing list
> > shifter-users at lists.devloop.org.uk
> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >
>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>


From ndbecker2 at gmail.com  Sat Jan  5 21:45:37 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 5 Jan 2013 16:45:37 -0500
Subject: [winswitch] trying out xpra/winswitch
In-Reply-To: <CAG3t+pE+PtkkaCp1gEOQm8DDhxMKXjZLaEOBCjzv=2NZFTx0_g@mail.gmail.com>
References: <CAG3t+pGRbtLvNBKdeXYx+ZifiuU1p2t8m21FU-SHeDM_PcsXew@mail.gmail.com>
 <CAG3t+pE4sk14O93bE2GYnbcYBD7W2kAgTepge5is_Zbr2Vd4-A@mail.gmail.com>
 <CAG3t+pFw7y4JVwfP6Z35Vk08kvu_W0Rb0GCtHoPkQQyk_khy9A@mail.gmail.com>
 <50E80E09.5060205@nagafix.co.uk>
 <CAG3t+pE+PtkkaCp1gEOQm8DDhxMKXjZLaEOBCjzv=2NZFTx0_g@mail.gmail.com>
Message-ID: <CAG3t+pEc8kzPN8BoBrcL6Cbe3+PhP_fYVdYtXZXqmvzP6bRLTA@mail.gmail.com>

Oh, xpra and winswitch are the latest versions (available via yum)


On Sat, Jan 5, 2013 at 4:44 PM, Neal Becker <ndbecker2 at gmail.com> wrote:

> I'm baffled.  If I start emacs via xpra (using xdummy), it looks great.
>  If I start via winswitch it doesn't.  It looks like it's set to a lower
> resolution.
>
> Both clients and servers are fedora f17 linux.
>
> Within each of these emacs sessions, I ran xdpyinfo and xrandr.  Both
> outputs show no difference.  I compared the two Xorg.:7.log, Xorg.:62.log,
> and don't offhand see any significant diff (because of the timestamps,
> comparing these files I just did visually).
>
> I have no ideas how to debug this.  I'd like to use winswitch for the nice
> features, but emacs under xpra looks beautiful while emacs under winswitch
> looks bad.
>
> I was wrong about my guess that winswitch was not using xdummy.  I see
> that Xorg was started with the same command line in both cases.
>
> Any ideas?
>
>
> On Sat, Jan 5, 2013 at 6:27 AM, Antoine Martin <antoine at nagafix.co.uk>wrote:
>
>> On 01/04/2013 07:47 PM, Neal Becker wrote:
>> > I have some info about 4.  It seems if I use xpra directly, the server
>> > started on the remote is using Xdummy driver, as per my xpra.conf.  But
>> > when started by winswitch, it is not.  Any ideas?
>> What versions have you got installed? What platform, distro, etc?
>> Old versions used to try to make xpra use Xdummy explicitly by
>> specifying the Xvfb command to use. But this is no longer the case, and
>> when winswitch launches xpra it will use the same configuration file as
>> when used from the command line?
>>
>> > On Thu, Jan 3, 2013 at 8:30 PM, Neal Becker <ndbecker2 at gmail.com>
>> wrote:
>> >
>> >> 4. emacs started manually on remote using xpra looks much nicer than
>> emacs
>> >> started via winswitch.  I could send screenshots.
>> Quality is encoding related, it is quite possible that winswitch uses a
>> different encoding by default. Try holding launching your commands via
>> the full "Start Application" dialog, or by holding the "Shift" key as
>> you select the application from the start menu, these dialogs allow you
>> to select the encoding quality.
>> Or just compare once launched in the xpra tray menu.
>>
>> >> On Thu, Jan 3, 2013 at 8:20 PM, Neal Becker <ndbecker2 at gmail.com>
>> wrote:
>> >>
>> >>> Trying out latest on Fedora 17.
>> >>>
>> >>> 1. Which way to configure Xorg?  Right now I'm trying xvfb with the
>> dummy
>> >>> driver:
>> >>> xvfb=/usr/bin/Xorg-nosuid -dpi 96 -noreset -nolisten tcp +extension
>> GLX
>> >>> +extension RANDR +extension RENDER -logfile
>> >>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf
>> /etc/xpra.conf
>> Should have examples for both Xvfb and Xdummy. What is enabled depends
>> on your distro. If Xdummy is not chosen, chances are that your distro is
>> too old to support it adequately.
>>
>> >>> This seems to look nice on emacs.  But I wonder if this is the "best"
>> >>> option?  One thing is, it seems RANDR extension is reported as
>> missing.
>> >>>  For example, running xrandr --verbose from within emacs reports that.
>> As per:
>> http://xpra.org/Xdummy.html
>> Xdummy is the way forward and there are a number of unfixable bugs when
>> using Xvfb without randr.
>>
>> >>> 2. winswitch works, but if I try to start a remote desktop session it
>> >>> works with xpra, but not NX.  I believe it said something about ssh
>> server
>> >>> not forwarding?
>> Details please. Platform, versions, etc. Log files?
>>
>> >>> 3. In winswitch, if I try to start a different size desktop session,
>> it
>> >>> does not change size.  Probably related to RANDR missing?
>> What protocol are you using for your desktop session? NX? VNC? Xpra?
>>
>> Cheers
>> Antoine
>>
>>
>> >>>
>> >>
>> >>
>> > _______________________________________________
>> > shifter-users mailing list
>> > shifter-users at lists.devloop.org.uk
>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>> >
>>
>> _______________________________________________
>> shifter-users mailing list
>> shifter-users at lists.devloop.org.uk
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>
>
>


From ndbecker2 at gmail.com  Sat Jan  5 21:52:28 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 5 Jan 2013 16:52:28 -0500
Subject: [winswitch] mixing xpra and winswitch
Message-ID: <CAG3t+pHwhKfZjSNtNo1O1BtS-cHSqid8xMkZ_tv5-xOz3MD+TQ@mail.gmail.com>

Can I mix using xpra on client side with using winswitch?

After starting winswitch, I can't seem to run xpra.  I got:

xpra attach ssh:10.4.1.3:7
xpra client version 0.7.6
2013-01-05 16:50:29,138 failed to locate the dbus notification service
2013-01-05 16:50:29,715 password is required by the server
2013-01-05 16:50:29,717 Connection lost
Exception in thread read_loop (most likely raised during interpreter
shutdown):
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 551, in __bootstrap_inner
  File "/usr/lib64/python2.7/threading.py", line 504, in run
  File "/usr/lib/python2.7/site-packages/xpra/protocol.py", line 330, in
_read_thread_loop
<type 'exceptions.TypeError'>: 'NoneType' object is not callable


From antoine at nagafix.co.uk  Sun Jan  6 05:12:25 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sun, 06 Jan 2013 12:12:25 +0700
Subject: [winswitch] mixing xpra and winswitch
In-Reply-To: <CAG3t+pHwhKfZjSNtNo1O1BtS-cHSqid8xMkZ_tv5-xOz3MD+TQ@mail.gmail.com>
References: <CAG3t+pHwhKfZjSNtNo1O1BtS-cHSqid8xMkZ_tv5-xOz3MD+TQ@mail.gmail.com>
Message-ID: <50E907B9.3070402@nagafix.co.uk>

On 01/06/2013 04:52 AM, Neal Becker wrote:
> Can I mix using xpra on client side with using winswitch?
Depends what you mean by "mix".

> After starting winswitch, I can't seem to run xpra.  I got:
winswitch will capture your existing xpra sessions, make them available
via TCP and regular sockets, and password protect them.
You can disable this behaviour in (self explanatory):
.winswitch/server/protocols/xpra.conf

The error below is because you need the password.
> 2013-01-05 16:50:29,715 password is required by the server
(and the stacktrace is an unrelated python shutdown issue)

Antoine

> 
> xpra attach ssh:10.4.1.3:7
> xpra client version 0.7.6
> 2013-01-05 16:50:29,138 failed to locate the dbus notification service
> 2013-01-05 16:50:29,715 password is required by the server
> 2013-01-05 16:50:29,717 Connection lost
> Exception in thread read_loop (most likely raised during interpreter
> shutdown):
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/threading.py", line 551, in __bootstrap_inner
>   File "/usr/lib64/python2.7/threading.py", line 504, in run
>   File "/usr/lib/python2.7/site-packages/xpra/protocol.py", line 330, in
> _read_thread_loop
> <type 'exceptions.TypeError'>: 'NoneType' object is not callable
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 



From antoine at nagafix.co.uk  Sun Jan  6 05:17:45 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sun, 06 Jan 2013 12:17:45 +0700
Subject: [winswitch] trying out xpra/winswitch
In-Reply-To: <CAG3t+pE+PtkkaCp1gEOQm8DDhxMKXjZLaEOBCjzv=2NZFTx0_g@mail.gmail.com>
References: <CAG3t+pGRbtLvNBKdeXYx+ZifiuU1p2t8m21FU-SHeDM_PcsXew@mail.gmail.com>
 <CAG3t+pE4sk14O93bE2GYnbcYBD7W2kAgTepge5is_Zbr2Vd4-A@mail.gmail.com>
 <CAG3t+pFw7y4JVwfP6Z35Vk08kvu_W0Rb0GCtHoPkQQyk_khy9A@mail.gmail.com>
 <50E80E09.5060205@nagafix.co.uk>
 <CAG3t+pE+PtkkaCp1gEOQm8DDhxMKXjZLaEOBCjzv=2NZFTx0_g@mail.gmail.com>
Message-ID: <50E908F9.8050008@nagafix.co.uk>

On 01/06/2013 04:44 AM, Neal Becker wrote:
> I'm baffled.  If I start emacs via xpra (using xdummy), it looks great.
>  If I start via winswitch it doesn't.  It looks like it's set to a lower
> resolution.
You have not answered the question about encoding and quality settings,
what are they set to?
Please also post server and client xpra commands to compare.

Note that winswitch will create the ssh tunnel itself using  the
built-in Twisted-conch instead of ssh, it may be less efficient and
cause xpra to lower quality to adapt to the more limited bandwidth.
(Although I have not seen this in testing before)
Please also specify your link quality, and the amount of traffic going
through the winswitch ssh tunnel.

If you are on a LAN, what you should really do is drop ssh completely
for xpra and use plain tcp sockets with passwords. You may need to
tweak/disable some firewall rules to achieve this.

> Both clients and servers are fedora f17 linux.
> 
> Within each of these emacs sessions, I ran xdpyinfo and xrandr.  Both
> outputs show no difference.  I compared the two Xorg.:7.log,
> Xorg.:62.log, and don't offhand see any significant diff (because of the
> timestamps, comparing these files I just did visually).
> 
> I have no ideas how to debug this.  I'd like to use winswitch for the
> nice features, but emacs under xpra looks beautiful while emacs under
> winswitch looks bad.
That is quite odd since even with a drop in quality, the auto-refresh
delay should kick in and give you a pixel perfect picture after about
one second.

Cheers
Antoine


> I was wrong about my guess that winswitch was not using xdummy.  I see
> that Xorg was started with the same command line in both cases.
> 
> Any ideas?
> 
> 
> On Sat, Jan 5, 2013 at 6:27 AM, Antoine Martin <antoine at nagafix.co.uk
> <mailto:antoine at nagafix.co.uk>> wrote:
> 
>     On 01/04/2013 07:47 PM, Neal Becker wrote:
>     > I have some info about 4.  It seems if I use xpra directly, the server
>     > started on the remote is using Xdummy driver, as per my xpra.conf.
>      But
>     > when started by winswitch, it is not.  Any ideas?
>     What versions have you got installed? What platform, distro, etc?
>     Old versions used to try to make xpra use Xdummy explicitly by
>     specifying the Xvfb command to use. But this is no longer the case, and
>     when winswitch launches xpra it will use the same configuration file as
>     when used from the command line?
> 
>     > On Thu, Jan 3, 2013 at 8:30 PM, Neal Becker <ndbecker2 at gmail.com
>     <mailto:ndbecker2 at gmail.com>> wrote:
>     >
>     >> 4. emacs started manually on remote using xpra looks much nicer
>     than emacs
>     >> started via winswitch.  I could send screenshots.
>     Quality is encoding related, it is quite possible that winswitch uses a
>     different encoding by default. Try holding launching your commands via
>     the full "Start Application" dialog, or by holding the "Shift" key as
>     you select the application from the start menu, these dialogs allow you
>     to select the encoding quality.
>     Or just compare once launched in the xpra tray menu.
> 
>     >> On Thu, Jan 3, 2013 at 8:20 PM, Neal Becker <ndbecker2 at gmail.com
>     <mailto:ndbecker2 at gmail.com>> wrote:
>     >>
>     >>> Trying out latest on Fedora 17.
>     >>>
>     >>> 1. Which way to configure Xorg?  Right now I'm trying xvfb with
>     the dummy
>     >>> driver:
>     >>> xvfb=/usr/bin/Xorg-nosuid -dpi 96 -noreset -nolisten tcp
>     +extension GLX
>     >>> +extension RANDR +extension RENDER -logfile
>     >>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf
>     /etc/xpra.conf
>     Should have examples for both Xvfb and Xdummy. What is enabled depends
>     on your distro. If Xdummy is not chosen, chances are that your distro is
>     too old to support it adequately.
> 
>     >>> This seems to look nice on emacs.  But I wonder if this is the
>     "best"
>     >>> option?  One thing is, it seems RANDR extension is reported as
>     missing.
>     >>>  For example, running xrandr --verbose from within emacs reports
>     that.
>     As per:
>     http://xpra.org/Xdummy.html
>     Xdummy is the way forward and there are a number of unfixable bugs when
>     using Xvfb without randr.
> 
>     >>> 2. winswitch works, but if I try to start a remote desktop
>     session it
>     >>> works with xpra, but not NX.  I believe it said something about
>     ssh server
>     >>> not forwarding?
>     Details please. Platform, versions, etc. Log files?
> 
>     >>> 3. In winswitch, if I try to start a different size desktop
>     session, it
>     >>> does not change size.  Probably related to RANDR missing?
>     What protocol are you using for your desktop session? NX? VNC? Xpra?
> 
>     Cheers
>     Antoine
> 
> 
>     >>>
>     >>
>     >>
>     > _______________________________________________
>     > shifter-users mailing list
>     > shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     >
> 
>     _______________________________________________
>     shifter-users mailing list
>     shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 
> 



From antoine at nagafix.co.uk  Tue Jan 15 16:20:02 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Tue, 15 Jan 2013 23:20:02 +0700
Subject: [winswitch] [ANNOUNCE] xpra 0.7.8
Message-ID: <50F581B2.3070201@nagafix.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

This release fixes a number of bugs. See release notes below.
Those wondering where 0.7.7 went, it had been tagged and was being
tested and then I forgot to actually push it out.

There is also a new 0.8.0 build, which is pretty much a release
candidate at this point, so please give it a whirl if you can.

The source:
https://xpra.org/src/
Binaries/repositories:
https://winswitch.org/downloads/
Direct binary downloads:
https://xpra.org/dists/
Beta downloads:
https://xpra.org/beta/

Cheers
Antoine

Release notes for 0.7.7 + 0.7.8:
* fix quality menu
* fix for clients not using rencoder (ie: Java, Android..)
* fix pixel queue size accounting
* fix xsettings integer parsing
* fix 'quality' command line option availibility check
* workaround Ubuntu's global menus
* better compatibility with old servers: don't send new xsettings format
* avoid logging for normal "clipboard is disabled" case
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlD1gbIACgkQGK2zHPGK1rvdvwCeIvS7Tvpi4mTnjaZ/TeEWwahD
824An1VBP0OYx9td/UldJmFaGz16yFFu
=0sSg
-----END PGP SIGNATURE-----


From ndbecker2 at gmail.com  Sat Jan 26 19:24:14 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 26 Jan 2013 14:24:14 -0500
Subject: [winswitch] still dpi
Message-ID: <CAG3t+pHoz2NJmgSZfe7CgZFEWkfN2ib-Dg2eWcgPzvv0eyDUrA@mail.gmail.com>

I see if I use NX for a remote desktop (kde), I must use
force font dpi=115

What I seem to need in xpra, is a way to do this (for apps - not for remote
desktop).

If I only knew what exactly setting force font dpi=115 in
~/.kde/share/config/ kcmfonts

actually did...


From ndbecker2 at gmail.com  Sat Jan 26 19:32:41 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 26 Jan 2013 14:32:41 -0500
Subject: [winswitch] xpra desktop
Message-ID: <CAG3t+pFgenno3LzMHOzt1T-FSU-PLP+yKNk6gwZFi_QWk3FuBA@mail.gmail.com>

I notice that selecting
start desktop session

session type: xpra

Gives a window that is not resizable.  Starting a vnc session is resizable.

Is this intentional?


From ndbecker2 at gmail.com  Sat Jan 26 19:36:09 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 26 Jan 2013 14:36:09 -0500
Subject: [winswitch] key mapping annoyance
Message-ID: <CAG3t+pHz2aORxBsQRDNx+Gp2fUhdpLeUAAAvtiyaUkbgsWf8BA@mail.gmail.com>

I have set both CTRL and CAPS LOCK as CTRL, using key layouts under kde.

I'm very pleased that xpra/winswitch usually doesn't screw this up - but
I've seen several times that after playing with xpra/winswitch the key
mapping of CAPS LOCK on my _local_ keyboard/display has been switched.


From ndbecker2 at gmail.com  Sat Jan 26 20:40:53 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 26 Jan 2013 15:40:53 -0500
Subject: [winswitch] still dpi
In-Reply-To: <CAG3t+pHoz2NJmgSZfe7CgZFEWkfN2ib-Dg2eWcgPzvv0eyDUrA@mail.gmail.com>
References: <CAG3t+pHoz2NJmgSZfe7CgZFEWkfN2ib-Dg2eWcgPzvv0eyDUrA@mail.gmail.com>
Message-ID: <CAG3t+pGzcraq7rm7PA9Y=7DpcxjeB6BL7aWpmE4CxvkVnxdPpA@mail.gmail.com>

OK, if I start a remote app (terminal) , and then do:

xrdb -merge < ~/.Xresources

it appears my dpi is fixed.

It appears that winswitch is setting dpi too late.  The first app I start
(e.g., konsole, emacs), shows fonts too small, but if I then start emacs as
a subprocess (from that konsole or emacs), the new one is obeying the
setting of Xft.dpi.

I played with setting dpi in /etc/xpra/xpra.conf, but it seems to have no
effect.




On Sat, Jan 26, 2013 at 2:24 PM, Neal Becker <ndbecker2 at gmail.com> wrote:

> I see if I use NX for a remote desktop (kde), I must use
> force font dpi=115
>
> What I seem to need in xpra, is a way to do this (for apps - not for
> remote desktop).
>
> If I only knew what exactly setting force font dpi=115 in
> ~/.kde/share/config/ kcmfonts
>
> actually did...
>
>


From antoine at nagafix.co.uk  Sun Jan 27 05:37:49 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sun, 27 Jan 2013 12:37:49 +0700
Subject: [winswitch] still dpi
In-Reply-To: <CAG3t+pGzcraq7rm7PA9Y=7DpcxjeB6BL7aWpmE4CxvkVnxdPpA@mail.gmail.com>
References: <CAG3t+pHoz2NJmgSZfe7CgZFEWkfN2ib-Dg2eWcgPzvv0eyDUrA@mail.gmail.com>
 <CAG3t+pGzcraq7rm7PA9Y=7DpcxjeB6BL7aWpmE4CxvkVnxdPpA@mail.gmail.com>
Message-ID: <5104BD2D.3030000@nagafix.co.uk>

On 01/27/2013 03:40 AM, Neal Becker wrote:
> OK, if I start a remote app (terminal) , and then do:
> 
> xrdb -merge < ~/.Xresources
> 
> it appears my dpi is fixed.
> 
> It appears that winswitch is setting dpi too late.  The first app I start
> (e.g., konsole, emacs), shows fonts too small, but if I then start emacs as
> a subprocess (from that konsole or emacs), the new one is obeying the
> setting of Xft.dpi.
Sound like the default dpi is not set until your client connects.

> I played with setting dpi in /etc/xpra/xpra.conf, but it seems to have no
> effect.
Please be more specific, what did you change, versions, etc

Antoine

> 
> 
> 
> 
> On Sat, Jan 26, 2013 at 2:24 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> 
>> I see if I use NX for a remote desktop (kde), I must use
>> force font dpi=115
>>
>> What I seem to need in xpra, is a way to do this (for apps - not for
>> remote desktop).
>>
>> If I only knew what exactly setting force font dpi=115 in
>> ~/.kde/share/config/ kcmfonts
>>
>> actually did...
>>
>>


From antoine at nagafix.co.uk  Sun Jan 27 05:38:11 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sun, 27 Jan 2013 12:38:11 +0700
Subject: [winswitch] key mapping annoyance
In-Reply-To: <CAG3t+pHz2aORxBsQRDNx+Gp2fUhdpLeUAAAvtiyaUkbgsWf8BA@mail.gmail.com>
References: <CAG3t+pHz2aORxBsQRDNx+Gp2fUhdpLeUAAAvtiyaUkbgsWf8BA@mail.gmail.com>
Message-ID: <5104BD43.50607@nagafix.co.uk>

On 01/27/2013 02:36 AM, Neal Becker wrote:
> I have set both CTRL and CAPS LOCK as CTRL, using key layouts under kde.
> 
> I'm very pleased that xpra/winswitch usually doesn't screw this up - but
> I've seen several times that after playing with xpra/winswitch the key
> mapping of CAPS LOCK on my _local_ keyboard/display has been switched.
I find that very hard to believe, as there is no code in winswitch or
xpra to modify your local keyboard configuration (client side), only to
read it..

Antoine


From antoine at nagafix.co.uk  Sun Jan 27 05:38:17 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sun, 27 Jan 2013 12:38:17 +0700
Subject: [winswitch] xpra desktop
In-Reply-To: <CAG3t+pFgenno3LzMHOzt1T-FSU-PLP+yKNk6gwZFi_QWk3FuBA@mail.gmail.com>
References: <CAG3t+pFgenno3LzMHOzt1T-FSU-PLP+yKNk6gwZFi_QWk3FuBA@mail.gmail.com>
Message-ID: <5104BD49.1070808@nagafix.co.uk>

On 01/27/2013 02:32 AM, Neal Becker wrote:
> I notice that selecting
> start desktop session
> 
> session type: xpra
> 
> Gives a window that is not resizable.  Starting a vnc session is resizable.
> 
> Is this intentional?
Yes. What would you expect the resizing to do?

Antoine


From ndbecker2 at gmail.com  Sun Jan 27 12:05:12 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 27 Jan 2013 07:05:12 -0500
Subject: [winswitch] still dpi
In-Reply-To: <5104BD2D.3030000@nagafix.co.uk>
References: <CAG3t+pHoz2NJmgSZfe7CgZFEWkfN2ib-Dg2eWcgPzvv0eyDUrA@mail.gmail.com>
 <CAG3t+pGzcraq7rm7PA9Y=7DpcxjeB6BL7aWpmE4CxvkVnxdPpA@mail.gmail.com>
 <5104BD2D.3030000@nagafix.co.uk>
Message-ID: <CAG3t+pHpTzV1ASjOdv6W8K4kNboPK+Y3iVYKdvtKY3T1Sziuzg@mail.gmail.com>

winswitch-0.12.18-2.x86_64
xpra-0.7.8-1.fc18.x86_64

on the _server_, I have in /etc/xpra/xpra.conf:

# Default DPI:

dpi = 115



On Sun, Jan 27, 2013 at 12:37 AM, Antoine Martin <antoine at nagafix.co.uk>wrote:

> On 01/27/2013 03:40 AM, Neal Becker wrote:
> > OK, if I start a remote app (terminal) , and then do:
> >
> > xrdb -merge < ~/.Xresources
> >
> > it appears my dpi is fixed.
> >
> > It appears that winswitch is setting dpi too late.  The first app I start
> > (e.g., konsole, emacs), shows fonts too small, but if I then start emacs
> as
> > a subprocess (from that konsole or emacs), the new one is obeying the
> > setting of Xft.dpi.
> Sound like the default dpi is not set until your client connects.
>
> > I played with setting dpi in /etc/xpra/xpra.conf, but it seems to have no
> > effect.
> Please be more specific, what did you change, versions, etc
>
> Antoine
>
> >
> >
> >
> >
> > On Sat, Jan 26, 2013 at 2:24 PM, Neal Becker <ndbecker2 at gmail.com>
> wrote:
> >
> >> I see if I use NX for a remote desktop (kde), I must use
> >> force font dpi=115
> >>
> >> What I seem to need in xpra, is a way to do this (for apps - not for
> >> remote desktop).
> >>
> >> If I only knew what exactly setting force font dpi=115 in
> >> ~/.kde/share/config/ kcmfonts
> >>
> >> actually did...
> >>
> >>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>


From ndbecker2 at gmail.com  Wed Jan 30 00:37:38 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 29 Jan 2013 19:37:38 -0500
Subject: [winswitch] traceback when attempting 'stop server'
Message-ID: <CAG3t+pG0GnJBPbUMiC4k2bTnNi1Ys2iBR9Ynuk__1iB7PB6QXw@mail.gmail.com>

pplet.py:751:do_stop_server:AttributeError: ServerLineConnection instance
has no attribute 'stop_server'

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/winswitch/ui/dialog_util.py", line
119, in <lambda>
    dialog.connect('response', lambda dialog, response_id:
ask_response_callback(dialog, response_id))
  File "/usr/lib/python2.7/site-packages/winswitch/ui/dialog_util.py", line
105, in ask_response_callback
    ok_callback()
  File "/usr/lib/python2.7/site-packages/winswitch/client/applet.py", line
746, in <lambda>
    None, lambda: self.do_stop_server(server))
  File "/usr/lib/python2.7/site-packages/winswitch/client/applet.py", line
751, in do_stop_server
    client.stop_server("User request")
AttributeError: ServerLineConnection instance has no attribute 'stop_server'

Local variables in innermost frame:
self: <winswitch.client.applet.WinSwitchApplet instance at 0x7f3e46939a70>
client: <winswitch.client.server_line_connection.ServerLineConnection
instance at 0x2239998>
server: <winswitch.objects.server_config.ServerConfig instance at 0x2242e60>


From antoine at nagafix.co.uk  Wed Jan 30 07:13:07 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Wed, 30 Jan 2013 14:13:07 +0700
Subject: [winswitch] traceback when attempting 'stop server'
In-Reply-To: <CAG3t+pG0GnJBPbUMiC4k2bTnNi1Ys2iBR9Ynuk__1iB7PB6QXw@mail.gmail.com>
References: <CAG3t+pG0GnJBPbUMiC4k2bTnNi1Ys2iBR9Ynuk__1iB7PB6QXw@mail.gmail.com>
Message-ID: <5108C803.2070301@nagafix.co.uk>

On 01/30/2013 07:37 AM, Neal Becker wrote:
> pplet.py:751:do_stop_server:AttributeError: ServerLineConnection instance
> has no attribute 'stop_server'
I believe this is fixed in:
https://winswitch.org/trac/changeset/5136

Thanks
Antoine

PS: please use the bug tracker for bugs
> 
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/winswitch/ui/dialog_util.py", line
> 119, in <lambda>
>     dialog.connect('response', lambda dialog, response_id:
> ask_response_callback(dialog, response_id))
>   File "/usr/lib/python2.7/site-packages/winswitch/ui/dialog_util.py", line
> 105, in ask_response_callback
>     ok_callback()
>   File "/usr/lib/python2.7/site-packages/winswitch/client/applet.py", line
> 746, in <lambda>
>     None, lambda: self.do_stop_server(server))
>   File "/usr/lib/python2.7/site-packages/winswitch/client/applet.py", line
> 751, in do_stop_server
>     client.stop_server("User request")
> AttributeError: ServerLineConnection instance has no attribute 'stop_server'
> 
> Local variables in innermost frame:
> self: <winswitch.client.applet.WinSwitchApplet instance at 0x7f3e46939a70>
> client: <winswitch.client.server_line_connection.ServerLineConnection
> instance at 0x2239998>
> server: <winswitch.objects.server_config.ServerConfig instance at 0x2242e60>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 



From me at cgf.cx  Wed Jan 30 18:00:39 2013
From: me at cgf.cx (Christopher Faylor)
Date: Wed, 30 Jan 2013 13:00:39 -0500
Subject: [winswitch] Problems connecting between Fedora -> gentoo/OpenSUSE
Message-ID: <20130130180039.GA4757@ednor.casa.cgf.cx>

I have recently upgraded all of my systems to xpra 0.7.8 and am
experiencing problems when attempting to connect from a Fedora 16 system
using ssh to my host OpenSUSE 12.2 system (I built 0.7.8 myself for this
system).

I have a Gentoo system running 0.7.8 which connects without difficulty.

The error in the server logs when I attempt to connect is:

2013-01-30 10:10:59,570 connection lost: invalid packet: size requested is 808464432 (maximum allowed is 32768 - packet header: '00010263l5:hellod20:__prerelease'), dropping this connection!

"808464432" is, in hex, "0x30303030".

I've tried using a direct TCP connection with similar results.

In case it matters, the Gentoo and OpenSUSE systems are on a local
network while the Fedora system is going over the internet.

If I downgrade the OpenSUSE version to 0.3.6-1, I can connect from
Fedora but not from Gentoo.

I'd appreciate any hints on how to resolve this problem.

cgf


From antoine at nagafix.co.uk  Wed Jan 30 20:39:34 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Thu, 31 Jan 2013 03:39:34 +0700
Subject: [winswitch] [ANNOUNCE] xpra 0.8.0
Message-ID: <51098506.7070804@nagafix.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

This major release took much longer than planned, but it was worth it.
There are many new features and enhancements.
Here are some highlights (full release notes at the end of this email):
* much better performance, lower latency, less jittery video
* much better video quality by default, better automatic refresh
* SSH support on MS Windows
* delta compression for lossless modes
* improved diagnostics screens and commands
* sound forwarding support
* system tray forwarding
* support for shadowing existing X11 displays
Some of these items will be improved further in the next release.

The source:
https://xpra.org/src/
Binaries/repositories:
https://winswitch.org/downloads/
Direct binary downloads:
https://xpra.org/dists/

Cheers
Antoine

PS: unfortunately, the Mac OSX build failed testing and will be posted
later.

Full releases notes:
* fix modal windows support
* fix default mouse cursor: now uses the client's default cursor
* fix "double-apple" in menu on OSX
* fix short lived windows: avoid doing unnecessary work, avoid
re-registering handlers
* fix limit the number of raw packets per client to prevent DoS via
memory exhaustion
* fix authentication: ensure salt is per connection
* fix for ubuntu global application menus
* fix proxy handling of deadly signals
* fix pixel queue size calculations used for performance tuning decisions
* fix ^C exit on MS Windows: ensure we do cleanup the system tray on exit
* edge resistance for colourspace conversion level changes to prevent
yoyo effect
* more aggressive picture quality tuning
* better CPU utilization
* new command line options and tray menu to trade latency for bandwidth
* x264 disable unecessary I-frames and avoid IDR frames
* performance and latency optimizations in critical sections
* avoid server loops: prevent the client from connecting to itself
* group windows according to the remote application they belong to
* sound forwarding (initial code, high latency)
* faster and more reliable client and server exit (from signal or
otherwise)
* SSH support on MS Windows
* "xpra shadow" mode to clone an existing X11 display (compositors not
supported yet)
* support for delta pixels mode (most useful for shadow mode)
* avoid warnings and X11 errors with the screenshot command
* better mouse cursor support: send cursors by name so their size
matches the client's settings
* mitigate bandwidth eating cursor change storms: introduce simple
cursor update batching
* support system tray icon forwarding (limited)
* preserve window workspace
* AES packet encryption for TCP mode (without key secure exchange for now)
* launcher entry box for username in SSH mode
* launcher improvements: highlight the password field if needed,
prevent warnings, etc
* better window manager specification compatibility (for broken
applications or toolkits)
* use lossless encoders more aggressively when possible
* new x264 tuning options: profiles to use and thresholds
* better detection of dead server sockets: retry and remove them if needed
* improved session information dialog and graphs
* more detailed hierarchical per-window details via "xpra info"
* send window icons in dedicated compressed packet (smaller new-window
packets, faster)
* detect overly large main packets
* partial/initial Java/AWT keyboard support
* py2exe, ebuild and distutils improvements: faster and cleaner
builds, discarding unwanted modules
* OSX and MS Windows build updates: newer py2app, gtk-mac-bundler,
pywin32 and support libraries
* OSX command line path fix
* updated libx264 and libav on OSX
* updated Cython to 0.17.4 for all binary builds
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEJhQYACgkQGK2zHPGK1rv8kwCaA4a19iMk6xOvcRFAXaW/fKAx
0doAnRAT0oYS3FhAiGhLbd+BkAo/U71u
=bVk1
-----END PGP SIGNATURE-----


From antoine at nagafix.co.uk  Wed Jan 30 20:45:12 2013
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Thu, 31 Jan 2013 03:45:12 +0700
Subject: [winswitch] Problems connecting between Fedora ->
	gentoo/OpenSUSE
In-Reply-To: <20130130180039.GA4757@ednor.casa.cgf.cx>
References: <20130130180039.GA4757@ednor.casa.cgf.cx>
Message-ID: <51098658.8090104@nagafix.co.uk>

On 01/31/2013 01:00 AM, Christopher Faylor wrote:
> I have recently upgraded all of my systems to xpra 0.7.8 and am
> experiencing problems when attempting to connect from a Fedora 16 system
> using ssh to my host OpenSUSE 12.2 system (I built 0.7.8 myself for this
> system).
> 
> I have a Gentoo system running 0.7.8 which connects without difficulty.
> 
> The error in the server logs when I attempt to connect is:
> 
> 2013-01-30 10:10:59,570 connection lost: invalid packet: size requested is 808464432 (maximum allowed is 32768 - packet header: '00010263l5:hellod20:__prerelease'), dropping this connection!
It looks like the client (Fedora 16?) is sending an invalid packet.
I would have expected the packet to be rejected before the size check,
but maybe you just got (un)lucky.

> "808464432" is, in hex, "0x30303030".
> 
> I've tried using a direct TCP connection with similar results.
> 
> In case it matters, the Gentoo and OpenSUSE systems are on a local
> network while the Fedora system is going over the internet.
> 
> If I downgrade the OpenSUSE version to 0.3.6-1, I can connect from
> Fedora but not from Gentoo.
Are you sure they are all the same versions, sounds like they are not.

> I'd appreciate any hints on how to resolve this problem.
First, v0.3 is unsupported and broken/insecure. Worst thing is that this
is 0.3.6, so it's not even the latest from the old (and no longer
supported) v0.3 branch. Do not use.

Second, it looks to me like your Fedora box is not running 0.7.8, maybe
some older version too.

So, the simple answer is: run supported versions and everything should
work fine, until then, I can't help you, sorry.

Antoine


> 
> cgf
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 



From me.xpra at cgf.cx  Wed Jan 30 22:33:07 2013
From: me.xpra at cgf.cx (Christopher Faylor)
Date: Wed, 30 Jan 2013 17:33:07 -0500
Subject: [winswitch] Problems connecting between Fedora ->
 gentoo/OpenSUSE
In-Reply-To: <51098658.8090104@nagafix.co.uk>
References: <20130130180039.GA4757@ednor.casa.cgf.cx>
 <51098658.8090104@nagafix.co.uk>
Message-ID: <20130130223307.GA6021@ednor.casa.cgf.cx>

On Thu, Jan 31, 2013 at 03:45:12AM +0700, Antoine Martin wrote:
>On 01/31/2013 01:00 AM, Christopher Faylor wrote:
>> "808464432" is, in hex, "0x30303030".
>> 
>> I've tried using a direct TCP connection with similar results.
>> 
>> In case it matters, the Gentoo and OpenSUSE systems are on a local
>> network while the Fedora system is going over the internet.
>> 
>> If I downgrade the OpenSUSE version to 0.3.6-1, I can connect from
>> Fedora but not from Gentoo.
>Are you sure they are all the same versions, sounds like they are not.
>
>> I'd appreciate any hints on how to resolve this problem.
>First, v0.3 is unsupported and broken/insecure. Worst thing is that this
>is 0.3.6, so it's not even the latest from the old (and no longer
>supported) v0.3 branch. Do not use.

Sorry.  I should have made it clear that the reason I tried 0.3.6 was
because I was stepping back to see which version worked.

>Second, it looks to me like your Fedora box is not running 0.7.8, maybe
>some older version too.
>
>So, the simple answer is: run supported versions and everything should
>work fine, until then, I can't help you, sorry.

That was the hint I needed.  RPM did report 0.7.8 (I triple checked) but
apparently I had somehow had old stuff sitting around.  I found
xpra-related libraries sitting around in python locations.  Once I nuked
those, a reinstallation worked (I'm now on 0.8.0).

So, obviously I must have installed 0.3.something in some nonstandard
way and screwed up my system.

Thanks for the help.  Much appreciated.

cgf