Bug 138987
Summary: | AttributeError: HTTPResponse instance has no attribute 'code' | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ivan Gyurdiev <ivg231> |
Component: | yum | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | adulau-rh, csmith, jlaska, katzj, mihai.ibanescu, wmealing |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-21 19:06:58 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: |
Description
Ivan Gyurdiev
2004-11-12 12:11:12 UTC
This is a bug in python-2.4 urllib2 $ rpm -qf /usr/lib/python2.4/urllib2.py python-2.4-0.b2.3 I'm not sure what the response structure is supposed to look like but there is no data member 'code'. It appears this role is now filled by the 'status' member. Applying the following patch resolves the issue for me. --- /usr/lib/python2.4/urllib2.py 2004-11-12 07:46:18.012832416 -0500 +++ /tmp/urllib2.py 2004-11-12 07:46:14.715333712 -0500 @@ -465,7 +465,7 @@ handler_order = 1000 # after all other processing def http_response(self, request, response): - code, msg, hdrs = response.code, response.msg, response.info() + code, msg, hdrs = response.status, response.msg, response.info() if code not in (200, 206): response = self.parent.error( $ yum update Setting up Update Process Setting up Repo: development repomd.xml 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files MD Read : ########### 814/3560 ... hmm, closer inspection shows that the response object can be of different types. The above patch then causes a failure later down the line when a different type is referenced (addinfourl). The later failure occurs after pulling down repositories, and attempting to gather the first rpm package. I'm not very familiar with the underlying structures to determine whether or not the caller is at fault. (changing back to yum) Same issue (on urllib2.py) and seems related to the latest update of the Python libraries. Any movement on this bug ? is there a workaround anyone has found ? Can someone please try to reproduce this outside of yum? If this is a bug in python we'd better have it reported upstream while it's still in beta. I am currently swamped and cannot try to isolate it. *** This bug has been marked as a duplicate of 138535 *** This bug manifests itself as well in the latest version of the Bittorrent client (version 3.4.2). (http://www.bittorrent.com): error(s): Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs file BitTorrent-3.4.2/BitTorrent/Rerequester.py", line 84, in rerequest h = urlopen(url) File "/usr/lib/python2.4/urllib2.py", line 130, in urlopen return _opener.open(url, data) File "/usr/lib/python2.4/urllib2.py", line 364, in open--------------------------------------- response = meth(req, response) File "/usr/lib/python2.4/urllib2.py", line 468, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: addinfourldecompress instance has no attribute 'code' Obviously there is more going on here than simply the urllib call, but it does show that this can be reproduced outside of yum. CMS Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |