The following was filed automatically by anaconda: anaconda 14.22 exception report Traceback (most recent call first): File "/usr/lib/python2.7/decimal.py", line 3712, in <module> val = globals()[globalname] File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 37, in <module> from decimal import Decimal File "/usr/lib/python2.7/site-packages/pyanaconda/gui.py", line 1241, in setScreen loaded = imp.load_module(moduleName, *found) File "/usr/lib/python2.7/site-packages/pyanaconda/gui.py", line 1191, in nextClicked self.setScreen () KeyError: 'ROUND_CEiLiNG'
Created attachment 490881 [details] Attached traceback automatically from anaconda.
Created attachment 490884 [details] Attached traceback automatically from anaconda.
Created attachment 490885 [details] Attached traceback automatically from anaconda.
Note to self: LANG appears to be tr_TR.UTF-8 Code in question seems to be here: 3709 # get rounding method function: 3710 rounding_functions = [name for name in Decimal.__dict__.keys() 3711 if name.startswith('_round_')] 3712 for name in rounding_functions: 3713 # name is like _round_half_even, goes to the global ROUND_HALF_EVEN value. 3714 globalname = name[1:].upper() 3715 val = globals()[globalname] 3716 Decimal._pick_rounding_function[val] = name 3717 3718 del name, val, globalname, rounding_functions from 2.7.1, although this has the "val = globals()[globalname]" at line 3715
rounding_functions: ['_round_ceiling', '_round_half_up', '_round_half_even', '_round_half_down', '_round_05up', '_round_floor', '_round_down', '_round_up'] name: _round_ceiling globalname: ROUND_CEiLiNG Looks like "upper()" is doing something unexpected by the decimal.py module within this locale.
How does Anaconda actually set the locale? I tried reproducing this using $ LANG=tr_TR.UTF-8 python -c 'print "round_ceiling".upper()' in the environment, but wasn't able to reproduce.
Here's a minimal recipe for reproducing the string conversion that triggers this: $ LC_ALL=tr_TR.UTF-8 python -c 'import locale; locale.setlocale(locale.LC_ALL, ""); print "round_ceiling".upper()' Here's a minimal reproducer for the "import" failure: $ LC_ALL=tr_TR.UTF-8 python -c 'import locale; locale.setlocale(locale.LC_ALL, ""); import decimal' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib64/python2.7/decimal.py", line 3715, in <module> val = globals()[globalname] KeyError: 'ROUND_CEiLiNG'
Or even shorter: python -c 'import locale; locale.setlocale(locale.LC_ALL, "tr_TR.UTF-8"); print "round_ceiling".upper()' This has actually already been reported before, as bug 251491 Similar bug reported here for IronPython: http://www.voidspace.org.uk/python/weblog/arch_d7_2007_11_03.shtml http://lists.ironpython.com/pipermail/users-ironpython.com/2007- October/005865.html Other instances: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/602561 https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/581207/comments/15
A nasty possible workaround: import decimal within the entrypoint to anaconda, before calling locale.setlocale()
Also mentioned here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489740 The interpretation of "upper" and "lower" for unicode is here: http://bugs.python.org/issue1528802
A robust fix for this for now may be to convert the str instances to unicode first, then call upper on them, then convert back to str. This would work since upper() for a unicode instance is locale-independent as per: http://bugs.python.org/issue1528802 (though there seems to have been some debate there).
Note to self: works with python 3, as the symbols are already unicode internally.
Reported upstream as http://bugs.python.org/issue11830
Fixed upstream in 2.7 branch. Fix committed/pushed to "master" for F16: * Tue Apr 12 2011 David Malcolm <dmalcolm> - 2.7.1-7 - fix "import decimal" in the Turkish locale (patch 131; rhbz#694928) Working on fixing config snafu on my machine so I can build it in Koji
Building python-2.7.1-7.fc16 into master: http://koji.fedoraproject.org/koji/taskinfo?taskID=2995747 I also committed/pushed to "f15"; building python-2.7.1-7.fc15 there as: http://koji.fedoraproject.org/koji/taskinfo?taskID=2995759
From my reading of this, any import of Anaconda's pyanaconda.iw.partition_gui module whilst in the Turkish locale will cause a failure of the installer. This code is referenced by gui "partition" : ("partition_gui", "PartitionWindow"), and it looks like doing so is mandatory for all installs. pyanaconda/storage/size.py also imports the "decimal" module. So it looks likely that this bug will block all installations in the Turkish locale. Added to "F15Blocker" and marked with "CommonBugs".
python-2.7.1-7.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/python-2.7.1-7.fc15
Tested for F15 Beta purposes: I confirm this bug exists in F15 Beta, but you only hit it if you go to the custom partitioning screen; if you don't use that screen (not using it is the click-straight-through case, btw) you dodge the bug. Proposing as nice-to-have for final (it doesn't quite hit blocker criteria, IMO), we will document for Beta. The fix will certainly get in for final anyway if it's submitted now.
Package python-2.7.1-7.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-2.7.1-7.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/python-2.7.1-7.fc15 then log in and leave karma (feedback).
python-2.7.1-7.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Discussed at the 2011-04-15 blocker bug review meeting (updating the bug in case it is re-opened). This causes problems in anaconda and possibly other packages but doesn't clearly hit any release criteria - accepted as F15 NTH.