Bad beta setup exes?

[matthewpersico]

Describe the bug
All attempts to run Xpra_cmd.exe on my laptop from a beta setup.exe result in the error:

bad magic number in 'asyncio': b'\xa7\r\r\n'

To Reproduce
Steps to reproduce the behavior:

1. server command

 STARTED       ELAPSED          UID      PID     PPID TT       COMMAND
  Dec 23  16d21h52m40s        17245   270277        1 ?        /usr/lib/systemd/systemd --user
  Dec 23  16d21h52m40s        17245   270279   270277 ?         \_ (sd-pam)
  Jan 06   2d22h53m54s        17245  2941946   270277 ?         \_ /usr/bin/python3.11 /usr/bin/xpra start --attach=no --daemon=no --terminate-children=yes --exit-with-windows=yes
  Jan 06   2d22h53m53s        17245  2942028  2941946 ?         |   \_ /usr/libexec/Xorg-for-Xpra-S2941946 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/mpersico5/.Xauthority -logfile /run/user/17245/xpra/S2941946/Xorg.log -configdir /run/user/17245/xpra/S2941946/xorg.conf.d/2941946 -config /etc/xpra/xorg.conf -depth 24 -displayfd 4

2. client command

PS C:\Users\mpersico5\gits\xterm-launcher> & 'C:\Program Files\Xpra\Xpra_cmd.exe'

3. specific action to trigger the bug
   Just start the command.

System Information (please complete the following information):

• Server OS: Red Hat Enterprise Linux release 8.10 (Ootpa)
• Client OS: Windows 10 Enterprise, 22H2
• Xpra Server Version 6.1-r0
• Xpra Client Version 6.3-r37110 and 6.3-r37149 with the Light setup.exe files.

Additional context
I was trying these betas to deal with #4466. On a lark, I went and grabbed Xpra-Light-x86_64_6.3-r37110.zip, extracted the contents and ran directly from the extracted files. That works with no issues.

[totaam]

I can reproduce this issue.

The exe and zip files should contain identical files, the build script takes the same directory and runs zip and innosetup on it one after the other.

And unsurprisingly, apart from some config files which are installed in %COMMONAPPDATA%, the contents are the same.
Yet one works and the other one does not!

---

I was trying these betas to deal with #4466

There are no changes related to that ticket, I don't think that a newer version will behave any different wrt xsettings.

[totaam]

First I thought that some recent packaging changes caused this issue: 6b9a54f, 12af226, c03bd75, 50c112b but it turns out that the problem is more difficult than that.

I believe that it was caused by stray files in the installer directory (ie: C:\Program Files\Xpra), specifically a lib\certifi and lib\asyncio directories with python modules in them. These were from a different version of python, hence the bad magic number error.

I since then completely deleted the installation directory and re-installed, and then things worked as expected.
My guess is that this is due to some Xpra installer versions having asyncio in the lib\library.zip bundle and others do not. It did get moved around a bit last year as part of #4100 and #4050: 80b3ed0, dd3e8ff,

---

The two commits above attempt to prevent a re-occurrence of this problem:

• 5d465b8: by not moving asyncio and certifi to the library.zip (as it was in older versions), so new installations will overwrite these stray directories - this is not ideal and wastes a little bit of space, but better than telling users to remove files by hand
• 17113d0: trying harder to ensure the bytecode doesn't get written to the installation directory, as this could also cause similar problems

Unfortunately, since I deleted the problematic directories during my investigation, I am unable to confirm if these fixes are sufficient.

---

@matthewpersico please try 6.3-r37166 or later, hopefully you won't need to manually remove any stray directories.

[totaam]

Could also be caused by Windows Defender: #3639