Bug 138987 - AttributeError: HTTPResponse instance has no attribute 'code'
Summary: AttributeError: HTTPResponse instance has no attribute 'code'
Status: CLOSED DUPLICATE of bug 138535
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-12 12:11 UTC by Ivan Gyurdiev
Modified: 2014-01-21 22:50 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2006-02-21 19:06:58 UTC

Attachments (Terms of Use)

Description Ivan Gyurdiev 2004-11-12 12:11:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0

Description of problem:
Yum update:

Traceback (most recent call last):
  File "/usr/bin/yum", line 8, in ?
  File "/usr/share/yum-cli/yummain.py", line 51, in main
  File "/usr/share/yum-cli/cli.py", line 133, in getOptionsConfig
    self.conf = yumconf(configfile = yumconffile, root=root)
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 227, in
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 299, in
    doRepoSection(self, repoconf, section)
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 313, in
    mirrorurls = getMirrorList(mirrorlist)
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 390, in
    fo = urlresolver.urlopen(url)
  File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line
427, in urlopen
    return default_grabber.urlopen(url, **kwargs)
  File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line
555, in urlopen
    return self._retry(opts, retryfunc, url)
  File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line
527, in _retry
    return apply(func, (opts,) + args, {})
  File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line
554, in retryfunc
    return URLGrabberFileObject(url, filename=None, opts=opts)
  File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line
703, in __init__
  File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line
747, in _do_open
    fo, hdr = self._make_request(req, opener)
  File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line
823, in _make_request
    fo = opener.open(req)
  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: HTTPResponse instance has no attribute 'code'

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. See summary.

Additional info:

Comment 1 James Laska 2004-11-12 12:44:21 UTC
This is a bug in python-2.4 urllib2

$ rpm -qf /usr/lib/python2.4/urllib2.py

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

Comment 2 James Laska 2004-11-12 13:06:40 UTC
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)

Comment 3 alexandre dulaunoy 2004-11-14 15:38:26 UTC
Same issue (on urllib2.py) and seems related to the latest update of
the Python libraries. 

Comment 4 Wade Mealing 2004-11-16 10:23:56 UTC
Any movement on this bug ? is there a workaround anyone has found ?

Comment 5 Mihai Ibanescu 2004-11-16 13:11:24 UTC
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 ***

Comment 6 Christopher M. Smith 2004-11-18 12:49:58 UTC
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):                                   
"/usr/lib/python2.4/threading.py", line 442, in __bootstrap  
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           
_opener.open(url, data)                                              
"/usr/lib/python2.4/urllib2.py", line 364, in
                                     response = meth(req, response)
File "/usr/lib/python2.4/urllib2.py", line 468, in http_response
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.


Comment 7 Red Hat Bugzilla 2006-02-21 19:06:58 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.