Description of problem: Shows error announcement Exception Occurred, unhandled exception and crashes Output: [Yum] 0 packages excluded due to repository protections [Yum] Reading version lock configuration Error in routine: BackgroundRunner Error Type: yum.plugins.PluginYumExit Error Value: Unable to read version lock configuration: [Errno 5] OSError: [Errno 2] No such file or directory: "/etc/yum/pluginconf.d/versionlock.list" Summary: TB03120a34 yumexmain.py:1045:_runBackground:PluginYumExit:Unable to read version lock configuration: ... Traceback: File "/usr/share/yumex/yumexmain.py",line 1108,in ? mainApp = YumexMainApplication() File ...the same line 541, in_init_ self.setup_yum() ...line 992, in setup_yum Version-Release number of selected component (if applicable): yumex Version 1.2.2 How reproducible: Every time Steps to Reproduce: 1. Start Yum extender (and clear cache ?) 2. Edit preferences, check versionlock plugin on 3. exit 4. Start Yum extender with versionlock plugin on 5. Check Load Yum Metadata on Actual results: Closes Yum Extender Expected results: Should keep loading metadata, and / start ask questions for defining settings for versionlock plugin. Solution proposal: Plugin install should make an initial file to /etc/yum/pluginconf.d/versionlock.list probably should ask which ones to protect. I am trying to protect at least kernel / xen kernel versions, because of this kind of problems: E-mail from xen-users.com > I've just attempted several times to install Fedora Linux domU's on a Fedora > > 6 [32-bit xen kernel 2.6.20-1.2944], and it keeps crashing at various points > > when trying to format domU's virtual disk. I've tried allocating 1 vcpu and > > 2 vcpus, and it still keeps crashing dom0. The machine has a total of two > > hyperthreaded 3.2ghz Xeon cpus, and 3GB of RAM. > > > > Anybody had similar problems with Xen VM's on a HP DL360G3? > > Fedora kernel-xen-2.6.20 versions are broken. Downgrade to 2.6.19 and it will work fine. -- Pasi Additional info:
Created attachment 152817 [details] dump from yumextender bug when using versionlock plugin
The versionlock plugin is designed to break if the file dont exist. The author want it to work that way. The plugin is not enabled by default, when installed, so when you install it you have to enable it in the conf file and create the /etc/yum/plugin.conf.d/versionlock.list file to make it work.
(In reply to comment #2) > The versionlock plugin is designed to break if the file dont exist. > The author want it to work that way. > The plugin is not enabled by default, when installed, so when you install it you > have to enable it in the conf file and create the > /etc/yum/plugin.conf.d/versionlock.list file to make it work. >
Then there is still a bug, because it don´t break cleanly, but prompt a bug report and crashes the main application. An additional if clause is required to the code. And it would help, if there would be a documentation of the syntax of the versionlock.list -file. It seems, that a directory listing redirected to the file will work (first copy the .rpm-files, that you want to lock to a same initially empty directory and cd there and from command prompt ls > /etc/yum/plugin.conf.d/versionlock.list ). Can you confirm this. Instead of a propmt of bug-report, there should popup a prompt with this information and suggestion of disabling the versionlock plugin otherwise. And an OK should then shut down the main application. By the way, I think it would be worthwhile to perfect yumex and plugins and sometime put them on the main distribution.
Panu, do you have any comments
The problem is just that Yumex isn't prepared to handle PluginYumExit exception, which plugins can legitimately raise to signal they want the main program to exit. The same problem exists in Pirut at least in FC6 version. versionlock plugin "leaking" the inner OSError exception text into its error message (possibly obscuring the issue) could be considered a bug I guess :)
Panu, it's been a while on this bug. What would you like to have done to fix it, if anything at all?
Ok, so I changed versionlock upstream so that it'll be enabled by default after install (which is what all the other plugins do). So to fix that I made it come with a default versionlock.list file that is empty. So while the above still happens if you rm the versionlock.list file, I'll happily blame the user for that :).