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>
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)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4379: ordinal not in range(128)
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
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?
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?
The bugs in #1589 are due to an ASCII locale, but they are quite rare. I'm fine with leaving it for 0.13.1, but if we get a few reports of failures, then we can cut an early patch release.
Ah, I had missed that this is py3-specific. Much less pressure, then.
OK, let's ride it out and see how it goes. Also note that it's py3-only, further decreasing the impact surface (which is the intersection of old-school Unix configuration with Python 3)
Remove umlauts so py3 installations on LANG=C systems succeed.
backported to 0.13.1 from ba2907d
Backport PR #2063: Remove umlauts so py3 installations on LANG=C syst…
build with LC_ALL=C.UTF-8 to avoid a unicode issue in setupbase.py
git-svn-id: svn://anonscm.debian.org/python-modules/packages/ipython/trunk@22384 771dd761-d7fa-0310-a302-f036d1c1ebb6