Summary: | gentopm doesn't actually support >=py3k | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Brian Harring (RETIRED) <ferringb> |
Component: | New packages | Assignee: | Michał Górny <mgorny> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | bkohler, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Brian Harring (RETIRED)
2012-10-14 21:56:32 UTC
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. |