Bug 460631
Summary: | python-setuptools 0.63c8 version bump | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Matt Baker <m> | ||||
Component: | python-setuptools | Assignee: | Bohuslav "Slavek" Kabrda <bkabrda> | ||||
Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE <qe-baseos-auto> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 5.3 | CC: | a.badger, cww, lmacken, opensource, rbu, thomas | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | noarch | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 0.63c8 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-10-16 09:28:12 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Matt Baker
2008-08-29 08:41:10 UTC
Python-setuptools is now provided in RHEL proper (as of release RHEL-5.2) and thus I cannot provide any further updates to this package in EPEL. *** Bug 490062 has been marked as a duplicate of this bug. *** We can reassign this to RHEL's python-setuptools maintainer. To summarize the two bugs: setuptools is now at 0.6c9, and some newer Python tools (such as python-sphinx 0.5.1) requires this latest version. RHEL is stuck on 0.6c5: http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/python-setuptools-0.6c5-2.el5.src.rpm (In reply to comment #1) > Python-setuptools is now provided in RHEL proper (as of release RHEL-5.2) and > thus I cannot provide any further updates to this package in EPEL. We should probably clear EPEL's EL-5 branch and put a dead.package file. The only reason I filed the bug is that I looked at the CVS and it appeared to still be maintained. This probably should be discussed more in the EPEL list, but it's a bit.. bizarre that, theoretically, EPEL could push a newer version of python-setuptools for RHEL 4 (since it's not in RHEL proper for that version) than the available version in RHEL 5. Tiny bit of a side note but for sphinx, we can probably just get rid of the following lines from setup.py:: import ez_setup ez_setup.use_setuptools() setuptools upstream has a bit of a problem understanding how to play well with others and the ez_setup script is one symptom of that. In our environment (building rpms) we never need the bootstrap functionality provided by ez_setup. As long as any real setuptools dependencies are specified in the setup.py's requires section everything will work fine. Ah. Toshio, could you test the Sphinx solution? I need to fix my VirtualBox set-up for Rawhide, until then, I have no access to RHEL/CentOS. Success: http://koji.fedoraproject.org/koji/taskinfo?taskID=1241950 I've also checked in the patch and updated spec. This is safe, though unnecessary to push to Fedora releases as well. Let me know if you want me to build this for real. *** Bug 498068 has been marked as a duplicate of this bug. *** *** Bug 498724 has been marked as a duplicate of this bug. *** Also in opposite to the fomer EPEL python-setuptools, the RHEL python-setuptools does not provide python-setuptools-devel. WRT python-setuptools-devel, note that currently, no RHEL/EPEL packages provide python-setuptools-devel. As Till mentions, the EPEL package did for a brief time. In Fedora, F-11 and 12 have python-setuptools-devel. In F-13 onwards we will not (Bug in python that was the reason we had the python-setuptools-devel package has been fixed). I recently took over developer responsibility for this package within RHEL. I'm sorry that this bug hasn't been resolved yet. Within RHEL we're somewhat paranoid about rebasing packages to newer upstream versions, preferring to take targetted patches for specific issues. For that reason, in order to make the case for a rebase to my manager, it's useful to know what the issues are with the package as is. As I understand from Matt's report in comment #0 and Michel's summary in comment #3, the issues are: (a) non-monotonicity from EPEL4 -> EL5: EPEL4 has 0.6c9, but EL5 has only 0.6c5 (b) python-sphinx-0.5.1 needed setuptools 0.6c9 (c) rh bug 498724 (http://bugs.python.org/setuptools/issue4 ): NameError: global name 'log' is not defined in 'log.warn("unrecognized .svn/entries format in %s", dirname)' which seems to be an issue with Subversion 1.5 Are there any other changes needed? Reading comment #7, it appears that Toshio resolved (b). We could backport a targetted fix for the "svn entries" bug ( see http://bugs.python.org/issue2770 ), but there may be a case for rebasing the package, to cover (a) above. Having said that, the diff between the two upstream tarballs is non-trivial; I hope to work through this and analyze risk shortly: EasyInstall.txt | 172 ++++++++++++++++++++++---------- PKG-INFO | 29 +++-- README.txt | 25 +++- ez_setup.py | 103 +++++++++++++------ launcher.c | 12 +- pkg_resources.py | 109 +++++++++++++++++--- pkg_resources.txt | 16 ++ release.sh | 7 - setup.py | 4 setuptools.egg-info/PKG-INFO | 29 +++-- setuptools.egg-info/SOURCES.txt | 4 setuptools.txt | 93 ++++++++++++++++- setuptools/__init__.py | 34 +++--- setuptools/cli.exe |binary setuptools/command/bdist_egg.py | 53 ++++++++- setuptools/command/bdist_rpm.py | 2 setuptools/command/bdist_wininst.py | 5 setuptools/command/build_ext.py | 8 - setuptools/command/develop.py | 63 +++++++++-- setuptools/command/easy_install.py | 168 +++++++++++++++---------------- setuptools/command/egg_info.py | 42 +++---- setuptools/command/install.py | 12 +- setuptools/command/install_egg_info.py | 62 +++++------ setuptools/command/install_scripts.py | 10 - setuptools/command/sdist.py | 4 setuptools/command/test.py | 65 +++++++++--- setuptools/command/upload.py | 7 - setuptools/depends.py | 12 +- setuptools/dist.py | 22 ++-- setuptools/gui.exe |binary setuptools/package_index.py | 105 +++++++++++++------ setuptools/tests/__init__.py | 14 -- setuptools/tests/test_packageindex.py |only setuptools/tests/test_resources.py | 78 ++++++++++---- setuptools/tests/win_script_wrapper.txt | 50 +++++++-- version.dat | 2 wikiup.cfg |only 37 files changed, 998 insertions(+), 423 deletions(-) Sorry again for not having resolved this (In reply to comment #12) > (b) python-sphinx-0.5.1 needed setuptools 0.6c9 > > Reading comment #7, it appears that Toshio resolved (b). Correct. seutptools upstream creates setup.py scripts that imports an ez_setup.py module that it creates. ez_setup, in turn, depends on the version of setuptools it was created with or later even though any same major version (or even different major versions in many common cases) will work. ez_setup's primary purpose is to download a setuptools module onto the computer where the module is being built. Since we provide a setuptools module and we do not allow downloads within the buildsystem it's almost always okay to simply get rid of the ez_setup import or, if submitting to upstream, making it conditional on not finding setuptools. (In reply to comment #12) > (a) non-monotonicity from EPEL4 -> EL5: EPEL4 has 0.6c9, but EL5 has only > 0.6c5 This is also true for EPEL5 -> EL5, because EPEL5 used to have 0.6c7, before python-setuptools was included in EL5 and removed from EPEL5. (In reply to comment #11) > WRT python-setuptools-devel, note that currently, no RHEL/EPEL packages provide > python-setuptools-devel. As Till mentions, the EPEL package did for a brief > time. On systems where the package was not downgraded manually, it still does. > In Fedora, F-11 and 12 have python-setuptools-devel. In F-13 onwards we will > not (Bug in python that was the reason we had the python-setuptools-devel > package has been fixed). So maybe it is not worth to re-add this Provides to the EL package then, because in a year there won't be any difference between Fedora and EL wrt. to this dependency anymore. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. dmalcolm: Seems like this can be closed? As Matt pointed out in comment #0: > We specifically need it to prevent svn version incompatibility as described in > this bug http://bugs.python.org/setuptools/issue4 With EL 5.6, subversion was upgraded to 1.6, which makes this bug a real problem. If a package dependency is fulfilled by a subversion checkout, you get this backtrace: python setup.py egg_info running egg_info writing requirements to Trac.egg-info/requires.txt writing Trac.egg-info/PKG-INFO writing top-level names to Trac.egg-info/top_level.txt writing dependency_links to Trac.egg-info/dependency_links.txt writing entry points to Trac.egg-info/entry_points.txt Traceback (most recent call last): File "setup.py", line 66, in ? entry_points = """ File "/usr/lib64/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib64/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib64/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/site-packages/setuptools/command/egg_info.py", line 171, in run self.find_sources() File "/usr/lib/python2.4/site-packages/setuptools/command/egg_info.py", line 252, in find_sources mm.run() File "/usr/lib/python2.4/site-packages/setuptools/command/egg_info.py", line 306, in run self.add_defaults() File "/usr/lib/python2.4/site-packages/setuptools/command/egg_info.py", line 333, in add_defaults rcfiles = list(walk_revctrl()) File "/usr/lib/python2.4/site-packages/setuptools/command/sdist.py", line 45, in walk_revctrl for item in ep.load()(dirname): File "/usr/lib/python2.4/site-packages/setuptools/command/sdist.py", line 52, in _default_revctrl for path in finder(dirname,path): File "/usr/lib/python2.4/site-packages/setuptools/command/sdist.py", line 98, in entries_finder log.warn("unrecognized .svn/entries format in %s", dirname) NameError: global name 'log' is not defined This is with subversion 1.6.11-7.el5 and 0.6c5-2.el5. (In reply to comment #19) > This is with subversion 1.6.11-7.el5 and 0.6c5-2.el5. ... setuptools 0.6c5-2.el5 This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. Created attachment 511402 [details] src.rpm with patch to support Subversion 1.6 Just to share work done locally: I built a src.rpm which contains a patch from http://bugs.python.org/setuptools/issue64, adapted to the setuptools version shipped by EL5. It works for me so it might be interesting to others as well. As Red Hat Enterprise Linux 5 has now entered Production Phase 2, this bug has been re-evaluated with the conclusion that a fix would not be appropriate at this time. Consequently this bug is being closed. Please contact your Red Hat representative if a review is required. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux. Closing as per comment 23. |