Bug 694928

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.