2018-05-28 15:39:27,405 Xpra gtk2 client version 2.3-r19246 64-bit
2018-05-28 15:39:27,409 running on Microsoft Windows 10
2018-05-28 15:39:28,913 Warning: failed to import opencv:
<Unicode console stdout>.write: UnicodeDecodeError('utf8', '2018-05-28 15:39:28,913 DLL load failed: ??p??a ???t??a p??et??\xb5as?a? \xb5?a? \xdf?\xdf???????? d??a\xb5???? s??des?? (DLL) ap?t??e.\n', 64, 65, 'invalid start byte')
Traceback (most recent call last):
File "C:/msys64/mingw64/lib/python2.7/logging/__init__.py", line 891, in emit
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb5 in position 64: invalid start byte
Logged from file log.py, line 132
2018-05-28 15:39:28,913 webcam forwarding is disabled
I have tried various ways to go around that, but I cannot seem to find something special.
I think at some point I manage to "decode" the text, but I cannot seem to remember the used codepage. (I will update if I manage to)
Text is in Greek (suggested codepage for chcp is 1253)
Recommended chcp for UTF-8 is 65001 (although internet says it's broken anyway)
This exception comes from opencv, not xpra itself. I have just checked and xpra handles unicode exception messages just fine.
So I will probably close this ticket as wontfix unless someone else fixes it. We'll have to wait for #1231 to replace opencv with something better. ie something that doesn't break with such regularity - see r17571 and many other fixes like it..
I didn't manage to decode the file. Is it possible that the output is already mangled?
I'll add some 2c, but I am fine with your opinion regardless. I have some example text in the mentioned encoding (see attached file).
It could be possible to "fix this" by adding cmd /V /C "set LANG=C && gpg -k --check-trustdb" (check on the attached file again).
Maybe this workaround is specific to gpg itself however?
(forgot to mention: in Notepad2 http://www.flos-freeware.ch/notepad2.html, working encoding is OEM (737) / Greek (DOS-737)
I didn't manage to decode the file. Is it possible that the output is already mangled?
Yes, it's very likely.
It could be possible to "fix this" by adding
cmd /V /C "set LANG=C && gpg -k --check-trustdb"
Using LANG=C is cheating, you're using the default locale.
Replying to Antoine Martin:
It could be possible to "fix this" by adding
cmd /V /C "set LANG=C && gpg -k --check-trustdb"Using
LANG=Cis cheating, you're using the default locale.
Probably I am cheating. However, if that one-line workaround "saves" you some time until you switch from OpenCV once and for all, I am not sure if it would be too harmful.
Obviously, your call :D
Please try a build r19535 or later from https://xpra.org/beta/windows.
Unfortunately, trick does not work :/ Apologies for the work.
r19543 will set LC_ALL=C rather than LANG=C - updated builds to come later.
You can already check if that is going to work by setting it before running xpra.
If that still doesn't help, then I will close this ticket as "wontfix".
Oups! ... Maybe should've thought that earlier :/
However; this doesn't work. I literally did:
set LC_ALL=C set LANG=C xpra attach [...]
Does not parse it.
Since you went through the trouble to push a new commit, I'll test the build when it comes. However, not too optimistic about it :/
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1856