Description

FindPage cannot be opened at all.

• Note: when reproducing it, !Findpage COULD be displayed. But the AdvancedSearch macro fails, only an error message is rendered at its place. But the rest of the FindPage is visible as usual. -- ThomasWaldmann 2012-05-27 18:28:54

Wiki will fail with the following message in the log:

ERROR 2010-06-08 18:30:00,990 MoinMoin.macro:132 Macro AdvancedSearch (page: 'FindPage') raised an exception:
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/MoinMoin/macro/__init__.py", line 122, in execute
    return execute(self, args)
  File "/usr/lib/python2.6/site-packages/MoinMoin/macro/AdvancedSearch.py", line 189, in execute
    return advanced_ui(macro)
  File "/usr/lib/python2.6/site-packages/MoinMoin/macro/AdvancedSearch.py", line 141, in advanced_ui
    (_('File Type'), unicode(mt_select), ''),
  File "/usr/lib/python2.6/site-packages/MoinMoin/widget/html.py", line 131, in __unicode__
    co = unicode(c)
  File "/usr/lib/python2.6/site-packages/MoinMoin/widget/html.py", line 131, in __unicode__
    co = unicode(c)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 3: ordinal not in range(128)

Steps to reproduce

1. Try to access FindPage.

Component selection

I checked the code a little bit and found out that /etc/mime.types in Fedora 13 cannot get parsed.

This is because there is "cubic" sign (g3) on one of the mime types.

application/vnd.geocube+xml                     g3 g³

This is line 355 of Fedora 13's /etc/mime.types

Details

Workaround

Delete g³ from /etc/mime.types (or any other non-ascii entry).

Discussion

uncleremus, 2012-05-25: Here is another patch that might be in the "right place". Tested on my Fedora system (F16).

• Thanks to uncleremus for the patch, I used it as inspiration, but did a slightly improved change, see link below. -- ThomasWaldmann 2012-05-27 19:04:18

I'ld suggest considering that "to-the-power-of-3" utf-8 char in /etc/mime.types to be the bug, until otherwise proven that mime.types has to be considered a file with utf-8 contents. There's no single encode/decode operation in python's mimetypes.py stdlib module, so to me it rather looks like that file has to be ascii. Also, using non-ascii filename extensions looks like a pretty bad idea considering the different encodings used on different systems/platforms. Thus, please file a bug to fedora, I'm closing this one until more evidence has been shown. -- ThomasWaldmann 2012-05-26 16:42:59

Note: I sent an email to the person who registered that mimetype and provided the non-ascii extension within that registration to either show specs allowing that or remove the non-ascii extension. Let's see what happens. -- ThomasWaldmann 2012-05-26 17:19:29

Update: got a reply:

Francois Pirsch told that

• As this geocube project is abandoned, I totally forgot about iana.org and didn't update my contact info.
  I asked them to remove completely this entry, or at least remove the "superscript three" file extension. It's in their hands now.

  He didn't know any specification of the encoding either, so this part of the issue remains unclear.

While answering his email, I also had a look at python 3.3: stdlib mimetypes.py there uses "utf-8" decoding for the mime.types file (not sure where THEY got it from or whether it was just a wild guess). Python 2.x does not do that, though, so this won't help us.

So I guess (although it is not a moin bug) we need a workaround to avoid the crash on all platforms / pythons that have troubles with that non-ascii mime.types content.

See also: http://bugs.python.org/issue13025 (the "fix" is in python 3.x)

Plan

• Priority:
• Assigned to:
• Status:
  • /etc/mime.types file issue (please file a bug to whoever is responsible for that file, requesting removal of that non-ascii stuff)
  • not a moin issue. but needing a workaround in moin to avoid the crash

  • workaround added: http://hg.moinmo.in/moin/1.9/rev/5b92be3da023

CategoryMoinMoinNoBug