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 process_package_queue rc, msg = self.yumexbase.processPkgs( pkgs, doAll ) File "/usr/lib/python2.4/site-packages/yumex/yumexBase.py", line 614, in processPkgs return self.buildTransaction() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 402, in buildTransaction 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
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 TYPE_INTERFASE plugin. 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: http://lists.atrpms.net/pipermail/atrpms-devel/2006-July/001185.html 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 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".
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 best.
*** Bug 211575 has been marked as a duplicate of this bug. ***