Xpra: Ticket #1166: osx 0.16.4 has "log_both" error in hello packet

As a first note, to install the 0.16.4 r12370.pkg (from your /beta repo) I first had to throw all the .dmg applications I'd been collecting into the trash and empty the trash.

Once that was done, I was able to install, but trying to connect (to a 0.17.0 r12385 fedora 23 server) threw a hello packet error and triggered a connection loss:

2016-04-14 12:11:21,412 error in hello packet
Traceback (most recent call last):
  File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/client_base.py", line 618, in _process_hello
  File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 1599, in server_connection_established
    if XpraClientBase.server_connection_established(self):
  File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/client_base.py", line 645, in server_connection_established
  File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 1804, in parse_logging_capabilities
    if not self.log_both:
AttributeError: 'XpraClient' object has no attribute 'log_both'
2016-04-14 12:11:21,413 error processing hello packet from server: 'XpraClient' object has no attribute 'log_both'
2016-04-14 12:11:21,414 Connection lost

Fri, 15 Apr 2016 03:07:28 GMT - Antoine Martin: owner, priority changed

I cannot reproduce and I really don't see how that's possible. Please include the exact command lines and/or configuration files that you used.

The log_both attribute is initialized very early in the UI client class.

Fri, 15 Apr 2016 20:26:06 GMT - alas: owner changed

Interesting... I can't repro it either now?

Wait... spoke too soon.

0.16.4 r12370.pkg connects without a hitch with a 0.16.4 server (didn't note revision).

The above error, with the output, is triggered by connecting the 0.16.4.pkg to a 0.17.0 server.

Server is launched with a standard/habitual command of dbus-launch xpra --no-daemon --bind-tcp= --start-child=xterm --start-child=xterm --mdns=no start :13 --start-new-commands=yes.

Client is launched with ./xpra attach tcp:(stuff) -d launcher (without the debug flag, there's no traceback outputted).

To be thorough, I tested the 0.16.4 r12370 application as well... and found that it has the same issue as the .pkg.

Sat, 16 Apr 2016 02:30:03 GMT - Antoine Martin: owner, summary changed

Sorry about that, I am so focused on releasing 0.17 that I missed the fact that this ticket title is about 0.16.x

Should be fixed in r12389.

Mon, 18 Apr 2016 21:48:55 GMT - alas:

Hmm... tried again with 0.16.4 r12370.pkg against trunk r12432 fedora 23 server, and got the same error (as well as noticing that TRUNK is now 0.18).

I can only presume that the fix is in the client. I'll test again once I manage to get one built (and I'll also have to slap together a 0.17 tagged server build set up while I'm at it, to be thorough).

Tue, 19 Apr 2016 01:55:51 GMT - Antoine Martin:

The fix is in the client, as can be seen by following the link to r12389.

Thu, 21 Apr 2016 23:10:08 GMT - alas: status changed; resolution set

Tested with 0.16.4 r12444 against a 0.17.0 r12453 fedora 23 server. Connects without a hitch.

Just to satisfy a little OCD, tried against 0.18.0 r12453 fedora 23 server. Also connects without a hitch.


Sat, 23 Jan 2021 05:16:46 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1166