Red Hat Bugzilla – Bug 203501
Yumex reports problem - TypeError: unsubscriptable object
Last modified: 2014-01-21 17:54:56 EST
Description of problem:
Yumex reports the following error after updates are selected, and downloaded.
Version-Release number of selected component (if applicable):
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
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
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 == 'update':
TypeError: unsubscriptable object
Local variables in innermost frame:
conduit: <yum.plugins.DepsolvePluginConduit instance at 0xafd9810c>
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.
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.
Taking over this bug.
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. ??
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
The fix I'm going to perfom is to check whether command is a list, and if not
treat it like "yum update".
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
*** Bug 211575 has been marked as a duplicate of this bug. ***