Bug 203501 - Yumex reports problem - TypeError: unsubscriptable object
Summary: Yumex reports problem - TypeError: unsubscriptable object
Alias: None
Product: Fedora
Classification: Fedora
Component: yumex   
(Show other bugs)
Version: 5
Hardware: i386 Linux
Target Milestone: ---
Assignee: Axel Thimm
QA Contact: Fedora Extras Quality Assurance
: 211575 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2006-08-22 03:35 UTC by Ron Siven
Modified: 2014-01-21 22:54 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-24 09:55:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ron Siven 2006-08-22 03:35:32 UTC
Description of problem:
Yumex reports the following error after updates are selected, and downloaded.

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

How reproducible:
Happens every time

Steps to Reproduce:
1. Open yumex
2. select packages to update
3. Click add to queue
4. go to queue
5. click process queue
6. wait...
Actual results:
Component: yumex
Version: 1.0.2
Summary: TBd751b3d9 kmdl.py:91:postresolve_hook:TypeError: unsubscriptable object

Traceback (most recent call last):
  File "/usr/share/yumex/yumexmain.py", line 128, in on_queueProcess_clicked
    if self.action.process_package_queue( pkgs, doAll):
  File "/usr/lib/python2.4/site-packages/yumex/yumexBase.py", line 1046, in
    rc, msg = self.yumexbase.processPkgs( pkgs, doAll )
  File "/usr/lib/python2.4/site-packages/yumex/yumexBase.py", line 614, in
    return self.buildTransaction()
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 402, in
    self.plugins.run('postresolve', rescode=rescode, restring=restring)
  File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 164, in run
    func(conduitcls(self, self.base, conf, **kwargs))
  File "/usr/lib/yum-plugins/kmdl.py", line 91, in postresolve_hook
    if commands[0] == 'update':
TypeError: unsubscriptable object

Local variables in innermost frame:
conduit: <yum.plugins.DepsolvePluginConduit instance at 0xafd9810c>
commands: None
opts: None

Comment 1 Tim Lauridsen 2006-08-23 07:16:03 UTC
The problem is in the kmdl plugin, it will only work with commandline yum, not
yum api applications like yumex, pup and pirut.
Yumex only uses TYPE_CORE plugins, i think this plugin should have been a

I will write a mail to Axel Thimm, maybe he will fix it.

Comment 2 Axel Thimm 2006-08-23 07:38:11 UTC
Thanks for pointing that out. It looks like the getCmdLine part of the conduit
is not available within yumex, aka yum api. So how can one tell whether yumex
issued an update or a simple install command?

The trivial fix is to prefix the check on command in the kmdl with a type check
on it, but then any yumex operation would be dealt with like an update operation.

Comment 3 Axel Thimm 2006-08-23 07:51:56 UTC
Taking over this bug.

Comment 4 Tim Lauridsen 2006-08-23 12:09:58 UTC
I had at look on the code in:


I dont understand i what situation he old_kernels are usefull.

If there is a kernel in the TsInfo, then you need to add the kmdl modules there
match the kernel in TsInfo into the Transaction Set. (new_kernels does that)

I dont see why the currently installed kernels should be processed. ??

Comment 5 Axel Thimm 2006-08-23 14:33:53 UTC
Usually when a new kernel package is released there is a delay of 0.5-2 days
until the matching kernel module packages come up. Therefore there are high
chances that the kernel has already been installed w/o the kmdls.

The idea is that if yum is called as "yum update" the plugin checks these
kernels, too. If yum is called as yum install firefox, then old kernels are
ignored, as the user would be surpised to see kmdls in the transaction for a
firefox install.

The fix I'm going to perfom is to check whether command is a list, and if not
treat it like "yum update".

Comment 6 Axel Thimm 2006-08-24 09:55:39 UTC
I've added the check and tested yumex against the new plugin. It works and I
assume pup/pirut and any other yum-api consumer will also work. I already
uploaded a new plugin at ATrpms.

I'm not sure how to close this, as this is fixed, but has nothing directly to do
with yumex. I think technically correct NOTABUG would be matching (it's not a
bug of yumex after all), but it would sound as if the original report's content
hadn't been acknowledged. I'm using UPSTREAM, which is also not proper, but at
least indicates that the bug fix happened, and happened external to this entry.
Anyway, if you think there is a better resolution, please change as you consider

Comment 7 Tim Lauridsen 2006-10-29 15:42:31 UTC
*** Bug 211575 has been marked as a duplicate of this bug. ***

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