I suggest you actually try installing it; 3.1/3.2 will both fail due to the author name being non ascii (but the code expecting it to be). Didn't look further, but the fact it can't install makes me suspect it needs loving in the py3k front.
Traceback (most recent call last): File "setup.py", line 99, in <module> 'test': TestCommand File "/usr/lib64/python3.2/distutils/core.py", line 148, in setup dist.run_commands() File "/usr/lib64/python3.2/distutils/dist.py", line 917, in run_commands self.run_command(cmd) File "/usr/lib64/python3.2/distutils/dist.py", line 936, in run_command cmd_obj.run() File "/usr/lib64/python3.2/distutils/command/install.py", line 581, in run self.run_command(cmd_name) File "/usr/lib64/python3.2/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/usr/lib64/python3.2/distutils/dist.py", line 936, in run_command cmd_obj.run() File "/usr/lib64/python3.2/distutils/command/install_egg_info.py", line 44, in run self.distribution.metadata.write_pkg_file(f) File "/usr/lib64/python3.2/distutils/dist.py", line 1031, in write_pkg_file file.write('Author: %s\n' % self.get_contact() ) UnicodeEncodeError: 'ascii' codec can't encode character '\u0142' in position 13: ordinal not in range(128)
Python version(s)?
(In reply to comment #2) > Python version(s)? Per the subject... " gentopm doesn't actually support >=py3k"; in conjunction w/ your iuse, I'd haphazard that the versions involved were 3.1 and 3.2. But what do I know...
What is going on here? What is gentopm and why all the hostility?
(In reply to comment #3) > (In reply to comment #2) > > Python version(s)? > > Per the subject... > " gentopm doesn't actually support >=py3k"; in conjunction w/ your iuse, I'd > haphazard that the versions involved were 3.1 and 3.2. > > But what do I know... I was asking for *exact* Python versions. The unicode issues should be fixed in current Python3 versions in the tree, unless I'm missing something.
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > > > Python version(s)? > > > > Per the subject... > > " gentopm doesn't actually support >=py3k"; in conjunction w/ your iuse, I'd > > haphazard that the versions involved were 3.1 and 3.2. > > > > But what do I know... > > I was asking for *exact* Python versions. The unicode issues should be fixed > in current Python3 versions in the tree, unless I'm missing something. 3.2 confirmed; if it's fixed in the -r1's, adjust your deps.
bleh, pardon, half awake- meant 3.2.2. Either way, if there is a fix (and this is caused by the bundled distutils/setuptools), the eclasses need their deps tightened to the unaffected versions. I have a hard time believing that if this is as you say, your package is the only one affected- non-ascii names aren't uncommon.
(In reply to comment #7) > bleh, pardon, half awake- meant 3.2.2. Either way, if there is a fix (and > this is caused by the bundled distutils/setuptools), the eclasses need their > deps tightened to the unaffected versions. Python team, what do you think about this? > I have a hard time believing that if this is as you say, your package is the > only one affected- non-ascii names aren't uncommon. This is not a very common issue. It affects only a few packages which have (and use) such names, and only users who have a locale not supporting those characters.
(In reply to comment #8) > (In reply to comment #7) > > bleh, pardon, half awake- meant 3.2.2. Either way, if there is a fix (and > > this is caused by the bundled distutils/setuptools), the eclasses need their > > deps tightened to the unaffected versions. > > Python team, what do you think about this? This was fixed in 3.2.3 if I recall correctly. I think tightening deps in the eclass for an issue that affects a small number of packages is silly. It would requre a lot of work to restructure the way dependencies are generated. Just upgrade your python to the latest stable version already.
On second thought, It might not be super-difficult to do in the new eclasses. I just don't want to muck with python.eclass.
Nothing for devrel to do here
I think something like this will do the job once gentoopm is migrated to distutils-r1. We could potentially break out every individual python slot that way if necessary. --- python-r1.eclass 14 Oct 2012 10:51:28 -0000 1.1 +++ python-r1.eclass 15 Oct 2012 14:58:10 -0000 @@ -106,6 +106,8 @@ for i in "${PYTHON_COMPAT[@]}"; do local d case ${i} in + python3_2) + d='>=dev-lang/python-3.2.3';; python*) d='dev-lang/python';; jython*)
(In reply to comment #12) > I think something like this will do the job once gentoopm is migrated to > distutils-r1. > > We could potentially break out every individual python slot that way if > necessary. > > --- python-r1.eclass 14 Oct 2012 10:51:28 -0000 1.1 > +++ python-r1.eclass 15 Oct 2012 14:58:10 -0000 > @@ -106,6 +106,8 @@ > for i in "${PYTHON_COMPAT[@]}"; do > local d > case ${i} in > + python3_2) > + d='>=dev-lang/python-3.2.3';; > python*) > d='dev-lang/python';; > jython*) I don't think it's really necessary right now. We could get back to it later, especially when -r1 Python ebuilds go stable.
