[Raspian][v0.7.0] LookupError: unknown encoding: utf-8 #194
Comments
If you mean wsdd is very cool. Thanks. If not than credits goes to the package maintainer. 😉
I doubt that this is an wsdd error. Try to run this in the Python REPL: print('abc'.encode('utf-8'))If that does not work, I would say your Python installation is broken or the is system missing iconv (or similar stuff). |
|
of course wsdd is cool, but what's best that having it just one apt-get install away? :) this is the output of the command you asked me: i didn't touch my python installation that I remember, it's the default raspberry one. |
|
I've just notice that the service is run by wsdd user as per service file attached (from debian bookworm) but the user is missing on my system: I've noticed this beccause if I manually run wsdd as my user I don't have this issue and I can see my host in windows. but adding the user wsdd doesn't solve it either: |
It does not matter. The unit file makes use of the
Ok, so your system appears to work. That's great. What could be the reason is the usage of chroot in the unit file. You can try to remove that command line argument in the unit file. Issue a
Well, that has nothing to do with a missing/present user, doesn't it. |
|
it seems to work now, thanks :) |
|
Ok. It's very likely that some information stored in a file is missing at runtime due to chroot'ing into an empty directory. Seems to be a fundamental flaw, but needs some further investigation. |
|
Please let me know if I can help anyhow. |
|
FWIW I just installed However, I note that the service requires I wonder if the Raspberry Pi OS kernel doesn't have that capability? I'd be surprised if it didn't but who knows? To check if your kernel supports that, try this: (If you don't have that command, install the If it doesn't return any output then your kernel doesn't have that capability and I recommend reporting a bug to Raspberry Pi OS. If your kernel does have that capability, then I suggest checking that the package is coming from Debian (I suspect it is but good to check): If your output looks the same (or at least very similar - except the To report to Debian, install the FWIW I note that there are currently no existing Debian bugs related to |
|
@Fabioamd87 There has been a similar issue quite a while a ago which I am able to reproduce. However, I tried to produce a MWE for this particular issue here: import os
import xml.etree.ElementTree as ET
os.chroot("/var/empty")
xml = ET.Element('item', {'key': u'😉'})
retval = b'<?xml version="1.0" encoding="utf-8">'
print(retval + ET.tostring(xml, encoding='utf-8'))(let's call that thing the wsdd MWE) This resembles what is done in the context of the exception reported in the OP. Lines 426 to 427 in c9cffc5 However, the MWE works for me with Python 3.9 to 3.12 on Gentoos (sorry, don't have a Raspian installation at hand) and on OpenBSD with 3.9 when chrooting into What I noticed with the MWE from the Python bugtracker is that indeed the Python interpreter fails to open an encoding-related file between chrooting and bailing out the exception. Here's the strace I can work around the issue in bugtracker MWE if I do an additional urlopen before chrooting which forces a load of the encoding data that appears to be re-used lateron. Nevertheless, I wonder why the exception does not happen with the wsdd MWE for me. @Fabioamd87 can you give the "wsdd MWE" from a above a try on your RasPi and chroot (you need root privileges for this) |
fabio@rpi:~ $ capsh --print | grep -i CAP_SYS_CHROOT fabio@rpi:~ $ apt policy wsdd fabio@rpi:~ $ wsdd MWE |
@Fabioamd87 Sorry, that's not what I meant. Please do the following:
import os
import xml.etree.ElementTree as ET
os.chroot("/var/empty")
xml = ET.Element('item', {'key': u'😉'})
retval = b'<?xml version="1.0" encoding="utf-8">'
print(retval + ET.tostring(xml, encoding='utf-8'))
|
|
@Fabioamd87 - everything looks pretty reasonable there. Your kernel clearly fulfills the requirement and the package is coming from Debian repos (which TBH I'm not surprised about). I wonder if there is some issue with your locale? FWIW I tried to reproduce the issue by removing UTF-8 encoding on a system and even that works for me?! Very weird... @christgau - FWIW on a Debian based system (unless the |
|
Hello, this issue has been open for a while now. I found than when I set a non-UTF-8 locale on a new system the LookupError will occur. Changing the locale to a UTF-8 locale and rebooting fixes the issue. Hope that helps. |
|
This worked for me as well. Updated the locale to UTF-8 and restarted the service. Now working properly!
|
|
Thanks for that feedback. I haven't checked it, but maybe it's a good idea to put into the unit file and add a requirement for an UTF-8 locale in the README. Would be interesting to know of any UTF-8 locale works (I hope/guess). |
Hello, I've realized that wsdd is in Raspberry Pi OS bookworm, and this is very cool!
Unfortunately when I start the service trough systemd, I get this error:
I probably know how to fix this, but is there any solution that doesn't imply to touch the "original" code of the package?
thanks!
The text was updated successfully, but these errors were encountered: