Description of problem: Clicking on the "Generate" button next to the password field for a new entry causes a traceback window to be shown: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/revelation/ui.py", line 1057, in <lambda> self.button = Button(_('Generate'), lambda w: self.generate()) File "/usr/lib64/python2.7/site-packages/revelation/ui.py", line 1066, in generate password = util.generate_password(self.config.get("passwordgen/length"),self.config.get("passwordgen/punctuation")) File "/usr/lib64/python2.7/site-packages/revelation/config.py", line 129, in get raise ConfigError ConfigError Version-Release number of selected component (if applicable): revelation-0.4.14-1.fc17.x86_64 How reproducible: 100%
This is probably another symptom of stale gconf interacting badly with the updated schema. Can you see if you blow away the revelation directory .gconf/apps/revelation And restart your login session, does the issue go away for you? I could use some help identifying a packaging snippet that can prevent users from running into this sort of stale gconf weirdness. Am I doing something wrong in the new package with regard to gconf handling? The sporadic gconf stuff is the reason why I haven't pushed it out of testing. I can't reliably produce the situation, once I clear it on a system, dropping back to the old package and retesting the upgrade doesn't give me the same result. Now it could be a problem in the old package not handling postun correctly or something. But hell if I know how to fix it in the new package to prevent this from happening to people. -jef
(In reply to comment #1) > Can you see if you blow away the revelation directory .gconf/apps/revelation > And restart your login session, does the issue go away for you? Yes, it does. Sorry I can't help with the gconf packaging issue.
Ok, so I ran into this when upgrading to Fedora 18. I had a lot going on when I saw this workaround/fix, so I didn't want to log out, so I did this instead: $ gconftool-2 --recursive-unset /apps/revelation Then I started up revelation and had no problem. So here's a crazy thought: put a wrapper script around the real /usr/bin/revelation that checks for gconf keys specific to the old schema, and if present then do the recursive unset. Otherwise, leave it alone. In either case, call the real program. Better still, if you know what key needs to be added/removed, you could do that instead of breaking the user's settings, but I would think "works" is better than "doesn't work". :D It's ugly, but gets you out of this hole.
Same issue in Fedora 18. The "gconftool-2 --recursive-unset /apps/revelation" fixes it perfectly (of course, with the loss of all settings).
So based on the traceback, I checked the contents of "~/.gconf/apps/revelation/passwordgen/%gconf.xml" before and after "gconftool-2 --recursive-unset /apps/revelation". Before (with the issue): <gconf><entry name="length" mtime="1346715670" schema="/schemas/apps/revelation/passwordgen/length" type="int" value="32"/></gconf> After (without the issue): <gconf><entry name="punctuation" mtime="1360638194" schema="/schemas/apps/revelation/passwordgen/punctuation"/><entry name="length" mtime="1360638194" schema="/schemas/apps/revelation/passwordgen/length"/></gconf> If settings are changed in the GUI, these may later acquire specific values: <gconf><entry name="punctuation" mtime="1360638354" schema="/schemas/apps/revelation/passwordgen/punctuation" type="bool" value="true"/><entry name="length" mtime="1360638354" schema="/schemas/apps/revelation/passwordgen/length"/></gconf> So it appears that the entry was simply missing. I'm not too familiar with gconf, but I think this might be prevented by installing the schemas in the postinstall script to provide default values, with something similar to: export GCONF_CONFIG_SOURCE="xml::/etc/gconf/gconf.xml.defaults" gconftool-2 --makefile-install-rule /etc/gconf/schemas/revelation.schemas Any thoughts?
Tried out the old "broken" config on another user account, and did not receive an error. I believe this is due to the schema installation mentioned above. In one line: GCONF_CONFIG_SOURCE="xml::/etc/gconf/gconf.xml.defaults" gconftool-2 --makefile-install-rule /etc/gconf/schemas/revelation.schemas Can anyone with a still-broken setup try that command as root and report your results?
(In reply to redhatbugzilla from comment #6) > > In one line: > > GCONF_CONFIG_SOURCE="xml::/etc/gconf/gconf.xml.defaults" gconftool-2 > --makefile-install-rule /etc/gconf/schemas/revelation.schemas > > Can anyone with a still-broken setup try that command as root and report > your results? This fix doesn't work on my PC. My ~/.gconf/apps/revelation/passwordgen/%gconf.xml file is still untouched(!?)
The "gconftool-2 --recursive-unset /apps/revelation" fixes my revelation too. Here is my diff before and after fixation and reconfiguration. diff ~/backups/.gconf/apps/revelation/passwordgen/%gconf.xml ~/.gconf/apps/revelation/passwordgen/%gconf.xml 3c3 < <entry name="length" mtime="1323078463" schema="/schemas/apps/revelation/passwordgen/length" type="int" value="16"/> --- > <entry name="length" mtime="1369371979" type="int" value="16"/>
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I don't think this has been fixed yet, and I think it's still present (though I've worked around it for myself), but I don't have sufficient permissions to change the version.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.