Opened 16 years ago
Closed 16 years ago
#7325 closed defect (duplicate)
Decode Error of 'ascii' codec: ordinal not in range
Reported by: | jplass | Owned by: | Christian Boos |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | rendering | Version: | 0.11rc2 |
Severity: | normal | Keywords: | unicode verify |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Hello,
the following is a traceback of my recent trac installation. The error occurs when opening the "Roadmap" or the "New Ticket" view on a fresh trac install (empty database):
Traceback (most recent call last): File "c:\xxx\trac\template2\python25\lib\site-packages\trac-0.11rc2-py2.5.egg\trac\web\api.py", line 339, in send_error 'text/html') File "c:\xxx\trac\template2\python25\lib\site-packages\trac-0.11rc2-py2.5.egg\trac\web\chrome.py", line 726, in render_template stream.render(method, doctype=doctype, out=buffer) File "build\bdist.win32\egg\genshi\core.py", line 179, in render return encode(generator, method=method, encoding=encoding, out=out) File "build\bdist.win32\egg\genshi\output.py", line 61, in encode for chunk in iterator: File "build\bdist.win32\egg\genshi\output.py", line 311, in __call__ for kind, data, pos in stream: File "build\bdist.win32\egg\genshi\output.py", line 753, in __call__ for kind, data, pos in stream: File "build\bdist.win32\egg\genshi\output.py", line 592, in __call__ for kind, data, pos in stream: File "build\bdist.win32\egg\genshi\output.py", line 707, in __call__ text = mjoin(textbuf, escape_quotes=False) UnicodeDecodeError: 'ascii' codec can't decode byte 0xfc in position 1695: ordinal not in range(128)
This happens for:
Trac 0.11rc1 and rc2 Genshi 0.5 and 0.4.4 Pygments 0.10
The installation is on windows XP. I tried both, native windows and installation via cygwin - same result. If you need more info I'll be happy to provide it, just state what you need or how I can assist to "trac" this down. Also I'm not sure if this isn't really a Genshi problem, so if you prefer to see this report in the Genshi context please tell me.
Johannes
Attachments (0)
Change History (7)
follow-up: 2 comment:1 by , 16 years ago
comment:2 by , 16 years ago
Replying to jonas:
What database are you using?
I'm using sqlite3, freshly downloaded from the homepage. Webserver is tracd, python is 2.5.2.
follow-up: 5 comment:3 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The bug was caused by using a german umlaut in a user's fullname.
comment:4 by , 16 years ago
Keywords: | needinfo added |
---|---|
Milestone: | 0.11.1 → 0.11.2 |
Resolution: | wontfix |
Status: | closed → reopened |
Hang on a second… Trac should really support full names being non-ascii.
Could you provide a bit more insight into where that name originated? Is the name entered through 'Preferences' as part of storing session, or provided by whatever authentication mechanism you use? What do you use for user management/authentication?
There are some older tickets related to non-ascii for login, but haven't seen that the full name should be a problem - unless you use LDAP which I think uses some login→name mechanism.
Regardless, it is not a wontfix
. It may well be a duplicate
, or possibly some new issue we need to look into.
comment:5 by , 16 years ago
Keywords: | unicode verify added; needinfo removed |
---|---|
Milestone: | 0.11-retriage → 0.11.3 |
Replying to jplass:
The bug was caused by using a german umlaut in a user's fullname.
Need to verify this.
comment:6 by , 16 years ago
Also, were you using any plugin (th:AccountManagerPlugin, or the LDAP plugin or Apache's autnz_ldap module)?
Possibly related: #6318 (suggests authnz_ldap being involved), #7287.
comment:7 by , 16 years ago
Milestone: | 0.11.3 |
---|---|
Resolution: | → duplicate |
Status: | reopened → closed |
Well, actually #6318 has a backtrace. I'm pretty sure it's the same issue. Closing this one as duplicate.
What database are you using?