Bug 249994 - yum updating --> TypeError: list objects are unhashable
yum updating --> TypeError: list objects are unhashable
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
7
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-29 01:33 EDT by Russ
Modified: 2014-01-21 17:59 EST (History)
3 users (show)

See Also:
Fixed In Version: 3.2.7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-05 10:41:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russ 2007-07-29 01:33:55 EDT
+++ This bug was initially created as a clone of Bug #243662 +++

Description of problem:
while running pup, up2date or yum to update y softwares, it runs into trouble
with the following package : libgii
libgii-0.8.4-2
Looks like there's a problem with returning a list in python while resolving the
dependencies

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

How reproducible:
I think you need to have the packages that seem to cause the issue then try
update with either yum, up2date or pup (is pup the same as up2date ?)

Steps to Reproduce:
1. 
2.
3.
  
Actual results:
I can't update my system (unless i get rid of those packages but i'd rather keep'em)

Expected results:
I'd love to update my system, which was working well until now.

Additional info:
some packages i managed to trace in the dependencies :
libgii-0.8.4-2
libggi-2.0.1-6
svgalib4ggi-0.6-4
quake-svga-1.06-2

-- Additional comment from fx.pottier@free.fr on 2007-06-11 07:52 EST --
Created an attachment (id=156698)
file saved from the excetion occured window in Software updater


-- Additional comment from nerijus@users.sourceforge.net on 2007-06-12 15:44 EST --
I have the same problem but with yum and Fedora 7:

# yum update
...
Resolving Dependencies
--> Running transaction check
---> Package yumex.noarch 0:1.9.8-2.0.fc7 set to be updated
filelists.sqlite.bz2      100% |=========================| 456 kB    00:07     
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 135, in main
    (result, resultmsgs) = base.buildTransaction() 
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 549, in
buildTransaction
    (rescode, restring) = self.resolveDeps()
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 794, in resolveDeps
    deps = self._mytsCheck()
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 775, in _mytsCheck
    ret.extend(self._checkRemove(txmbr))
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 1029, in
_checkRemove
    for pkgtup in self.rpmdb.whatRequires(provname, None, None):
  File "/usr/lib/python2.5/site-packages/yum/rpmsack.py", line 422, in whatRequires
    pkgs = self.searchRequires(name)
  File "/usr/lib/python2.5/site-packages/yum/rpmsack.py", line 148, in
searchRequires
    return self.searchPrco(name, 'requires')
  File "/usr/lib/python2.5/site-packages/yum/rpmsack.py", line 127, in searchPrco
    if not result.has_key(po.pkgid):
TypeError: list objects are unhashable


-- Additional comment from nerijus@users.sourceforge.net on 2007-06-13 16:44 EST --
fx pottier, how have you found out which package is guilty? I uninstalled some
packages which yum update wanted to update (yumex, ...), and now it just dies as
above:
# yum update
...
Resolving Dependencies
--> Running transaction check
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
...

-- Additional comment from nerijus@users.sourceforge.net on 2007-06-13 17:01 EST --
OK, I found it out - it's gdb-6.6-15.fc7.i386.rpm. After I updated it manually,
yum update works.

-- Additional comment from fx.pottier@free.fr on 2007-06-15 09:20 EST --
good for you nerijus,
I'm not sure about the package libgii-0.8.4-2 is the one causing the issue but
the yum process dies there while testing the dependencies (or so it seems)

To manually update the package, did you simply download it and rpm -Uvh it ?

-- Additional comment from fx.pottier@free.fr on 2007-06-15 10:23 EST --
Since i had no other idea and didnt want to spend to much time on this
I removed the following pacakges and i found that svgalib4ggi was on wrong acrh
(i686 instead of i386) the problem might have come from there.
problem solved.
=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Removing:
 libggi                  i386       2.1.1-1          installed         1.5 M
 libgii                  i386       0.9.1-1          installed         497 k
 quake-svga              i386       1.06-2           installed         735 k
 quake2                  i386       3.20-glibc-6     installed          11 M
Removing for dependencies:
 svgalib4ggi             i686       0.6-4            installed          29 k

Transaction Summary
=============================================================================


-- Additional comment from nerijus@users.sourceforge.net on 2007-06-16 17:37 EST --
Yes, I simply downloaded gdb package from F7 updates and installed it with rpm
-Fvh. Then yum update started working. Strange.
Comment 1 Russ 2007-07-29 01:52:25 EDT
The bug as described above is also present in F7. It is NOT, however, a yum
problem with a specific package, as described above.

The actual problem seems to occur when yum, using python, parses the
dependencies and encounters a package which contains some type of package
description text, ect. which python cannot handle, thus crashing yum.

In doing a google search of the problem, I have found that this problem, while
not prevalent, has been a well documented bug in yum. Further research indicated
that the problem arises from improper python coding which prevents python from
properly parsing the offending text.

A quick fix to mitigate the problem would be to create a database of offending
packages which cause the bug, and determine the common text or formatting of the
package description, ect. which causes yum to crash. The offending packages
could then be easily changed to prevent yum from crashing.

A permanent fix will be to fix the yum/python problem with handling the
offending packages.
Comment 3 Seth Vidal 2007-07-29 02:10:43 EDT
what version of yum is this? 3.2.1?

If so could you try 3.2.2 which is in fedora 7 updates-testing?

Thanks
Comment 4 Russ 2007-07-31 01:18:07 EDT
(In reply to comment #3)
> what version of yum is this? 3.2.1?
> 
> If so could you try 3.2.2 which is in fedora 7 updates-testing?
> 
> Thanks
> 

yum-3.2.1-1.fc7

Will try 3.2.2 now...
Comment 5 Russ 2007-07-31 02:02:08 EDT
with 3.2.2:

yum update GraphicsMagick compat-openldap libcdio openldap openldap-devel
policycoreutils
Loading "fastestmirror" plugin
Setting up Update Process
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package libcdio.i386 0:0.78.2-2.fc7 set to be updated
---> Package GraphicsMagick.i386 0:1.1.8-2.fc7 set to be updated
---> Package openldap-devel.i386 0:2.3.34-3.fc7 set to be updated
---> Package compat-openldap.i386 0:2.3.34_2.2.29-3.fc7 set to be updated
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 135, in main
    (result, resultmsgs) = base.buildTransaction()
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 540, in
buildTransaction
    (rescode, restring) = self.resolveDeps()
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 821, in resolveDeps
    deps = self._mytsCheck()
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 791, in _mytsCheck
    thisneeds = self._checkInstall(txmbr)
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 965, in
_checkInstall
    dep = self._provideToPkg(req)
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 714, in
_provideToPkg
    for pkgtup in self.rpmdb.whatProvides(r, f, v):
  File "/usr/lib/python2.5/site-packages/yum/rpmsack.py", line 386, in whatProvides
    pkgs = self.searchProvides(name)
  File "/usr/lib/python2.5/site-packages/yum/rpmsack.py", line 145, in
searchProvides
    return self.searchPrco(name, 'provides')
  File "/usr/lib/python2.5/site-packages/yum/rpmsack.py", line 127, in searchPrco
    if not result.has_key(po.pkgid):
TypeError: list objects are unhashable

Comments:
As in other bug reports with the problem, when yum tries to resolve dependencies
is where problems begin. Therefore a more complex update, such as this, is what
tends to cause problems. In this particular instance the package
compat-openldap.i386 0:2.3.34_2.2.29-3.fc7 is (one of) the package(s) that cause
yum to crash. It seems that the fact that package had two additional
dependencies, which causes the problem. Once that package and its dependencies
wre updated via rpm yum then crashed on checkpolicy-2.0.3-1.fc7.i386, which was
a dependency of policycoreutils. After that yum updated the others with no problems.

I can think of at least 15-20 packages so far from the Fedora repositories which
needed manual update using rpm. Once the problematic package has been installed
yum will continue normally with the remaining packages until it completes the
update or until it encounters another package which causes it to crash.
 
Comment 6 Jeremy Katz 2007-09-13 14:48:29 EDT
Does this still happen with yum 3.2.5?
Comment 7 Nerijus Baliūnas 2007-09-16 18:48:43 EDT
With latest yum 3.2.4-2.fc7 from Fedora updates I can no longer update or
install anything:
# yum install agg-devel
--> Running transaction check
---> Package agg-devel.i386 0:2.5-1 set to be updated
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 143, in main
    (result, resultmsgs) = base.buildTransaction() 
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 565, in
buildTransaction
    (rescode, restring) = self.resolveDeps()
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 718, in resolveDeps
    for po, dep in self._checkFileRequires():
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 889, in
_checkFileRequires
    dep = self.rpmdb.getProvides(name, flag, evr)
  File "/usr/lib/python2.5/site-packages/yum/rpmsack.py", line 393, in getProvides
    morepkgs = self.searchFiles(name)
  File "/usr/lib/python2.5/site-packages/yum/rpmsack.py", line 111, in searchFiles
    if not result.has_key(pkg.pkgid):
TypeError: list objects are unhashable

Downgrading to 3.2.2-1.fc7 helps, but this version sometimes cannot update too.
Comment 8 Steven Pritchard 2007-10-03 18:48:49 EDT
I'm getting this error with 3.2.5-1.fc7.
Comment 9 Steven Pritchard 2007-10-04 11:12:13 EDT
A git checkout from today works fine.
Comment 10 Russ 2007-11-02 19:04:20 EDT
A recent update to  yum-3.2.7-1.fc7 and rpm-4.4.2.2-2.fc7 has apparently
resolved the yum issue previously reported by me. So far we have not experienced
any further issues during several yum updates with our systems in text mode.

Using Kyum, however, results in the following error:
*** Traceback (most recent call last):
***   File "/usr/bin/yum", line 29, in <module>
***     yummain.main(sys.argv[1:])
***   File "/usr/share/yum-cli/yummain.py", line 105, in main
***     result, resultmsgs = base.doCommands()
***   File "/usr/share/yum-cli/cli.py", line 282, in doCommands
***     return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd,
self.extcmds)
***   File "/usr/share/yum-cli/yumcommands.py", line 171, in doCommand
***     rup = base.listPkgs(ypl.updates, 'Updated Packages', basecmd)
***   File "/usr/share/yum-cli/output.py", line 129, in listPkgs
***     self.infoOutput(pkg)
***   File "/usr/share/yum-cli/output.py", line 100, in infoOutput
***     print _("Description:\n%s") % enc(pkg.description)
***   File "/usr/share/yum-cli/output.py", line 84, in enc
***     if len(s) > 0:
*** TypeError: object of type 'NoneType' has no len()
Process exited normally with code 1.

The above error seems to be a localized issue with Kyum, since text mode
Yum updates work fine. We will report above the problem as a Kyum only issue.

Thanks!!! 

We are happy the issue is no longer currently a problem for us and hopeful the
issue has been permanently resolved.
Comment 11 Jochen Schmitt 2007-11-04 14:36:26 EST
Sorry, please look on the following output of yum-3.2.7-1:

$ yum -y info updates
Loading "kernel-module" plugin
Loading "fastestmirror" plugin
Loading "skip-broken" plugin
Loading "fedorakmod" plugin
Loading "priorities" plugin
Loading "allowdowngrade" plugin
Loading "tsflags" plugin
Loading "changelog" plugin
Loading "protectbase" plugin
Loading "downloadonly" plugin
Loading mirror speeds from cached hostfile
0 packages excluded due to repository priority protections
0 packages excluded due to repository protections
Updated Packages
Name   : cups-devel
Arch   : x86_64
Epoch  : 1
Version: 1.2.12
Release: 6.fc7
Size   : 68 k
Repo   : updates
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 105, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 282, in doCommands
    return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd,
self.extcmds)
  File "/usr/share/yum-cli/yumcommands.py", line 171, in doCommand
    rup = base.listPkgs(ypl.updates, 'Updated Packages', basecmd)
  File "/usr/share/yum-cli/output.py", line 129, in listPkgs
    self.infoOutput(pkg)
  File "/usr/share/yum-cli/output.py", line 99, in infoOutput
    print _("Summary: %s") % enc(pkg.summary)
  File "/usr/share/yum-cli/output.py", line 86, in enc
    t = gettext.dgettext(d, s)
  File "/usr/lib64/python2.5/gettext.py", line 530, in dgettext
    codeset=_localecodesets.get(domain))
  File "/usr/lib64/python2.5/gettext.py", line 478, in translation
    t = _translations.setdefault(key, class_(open(mofile, 'rb')))
  File "/usr/lib64/python2.5/gettext.py", line 180, in __init__
    self._parse(fp)
  File "/usr/lib64/python2.5/gettext.py", line 313, in _parse
    v = v.split(';')
AttributeError: 'list' object has no attribute 'split'

The environment variable LANG was set to 'de_DE.utf8'. So you see, that this is
a yum issue.

Best Regards:

Jochen Schmitt
Comment 12 Jeremy Katz 2007-11-05 10:41:13 EST
For different tracebacks, please file different bugs.  FWIW, the list splitting
thing in python's gettext module is bug 252136  

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