Repository: ipython/ipython

Issue:
setup fails for python3 with LANG=C
since Jörgen was added do release.py python3 fails due to the umlaut on systems with LANG=C

```
$ LANG=C python3.2 setup.py build
Traceback (most recent call last):
  File "setup.py", line 61, in <module>
    from setupbase import target_update
  File "/tmp/ipython-ipython-da134db/setupbase.py", line 74, in <module>
    execfile(pjoin('IPython','core','release.py'), globals())
  File "/tmp/ipython-ipython-da134db/setupbase.py", line 55, in execfile
    exec(compile(open(fname).read(), fname, "exec"), globs, locs)
  File "/usr/lib/python3.2/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4379: ordinal not in range(128)
```



Discussion:
Does a python2 build succeed?

its an py3 only code path in setupbase.py:55
py2 works fine

ouch... this is a bad one, b/c LANG=C is pretty common...

pypi shows zero downloads on all, so I'm tempted to just retag 0.13 fixing only ö -> o in that file and nothing else.  thoughts?

please don't I already uploaded the tag to debian

ok

how serious is this one for debian?

not bad I just set the build to LC_ALL=C.UTF-8
is LANG=C really so common?

honestly I don know in the wild.  Maybe not as much anymore... Windows certainly doesn set LANG by default.  let me check an osx box...

would debian accept a 0.13.1 in a month or so with any small fixes we accumulate?

as only python3 is affected and not everyone uses LANG=C I would suggest waiting a bit and bundling it in an early bugfix release
its likely a couple of bugs will get discovered soon now that a stable release is out

same thing :)

the buildbots are all solid and we did run all tests manually on mac, windows and linux at the very end, so I'm not _too_ worried.  we just didn't have this particular configuration

yup, osx also sets LANG by default to a UTF-8 locale.

so let's leave this one be, it looks like it will mostly only be a problem for odd combinations of very old unix setups and people wanting to run on python3.  That's an unusual setup, so it probably won't matter much.

I'll tag it for a backport to 0.13.1, does that sound OK?

sounds good.
As long as the fixes in a potential 0.13.1 aren't to invasive it can still be added to Debian.
Fixing this in it would be fine.

OK, I've made a backport 0.13.1 label.  We can start using that to tag potential backport issues for a 0.13.1 branch, which we'll make soon.  You can give us feedback on what's a good idea and what's too much for Debian.

I'd like to try to keep 0.13.1 debian-compatible, and we can always cut a more aggressive 0.13.2 with more invasive fixes afterwards that could be OK for ubuntu/EPD/etc.

Does that sound like a good policy for you guys?


Resolving patch:
diff --git a/IPython/core/release.py b/IPython/core/release.py
--- a/IPython/core/release.py
+++ b/IPython/core/release.py
@@ -114,7 +114,7 @@
            'Brian'    : ('Brian E Granger', 'ellisonbg@gmail.com'),
            'Min'      : ('Min Ragan-Kelley', 'benjaminrk@gmail.com'),
            'Thomas'   : ('Thomas A. Kluyver', 'takowl@gmail.com'),
-           'Jörgen'   : ('Jörgen Stenarson', 'jorgen.stenarson@bostream.nu'),
+           'Jorgen'   : ('Jorgen Stenarson', 'jorgen.stenarson@bostream.nu'),
            'Matthias' : ('Matthias Bussonnier', 'bussonniermatthias@gmail.com'),
            }
 


Test patch: