Version-Release number of selected component: blueman-1.23-5.fc18 Additional info: cmdline: /usr/bin/python /bin/blueman-applet executable: /bin/blueman-applet kernel: 3.9.2-200.fc18.i686 uid: 1000 ureports_counter: 1 Truncated backtrace: Gconf.py:76:x:GError: No se pudo contactar con el servidor de configuración: Error de D-Bus: No se puede guardar un valor en la clave «/apps/blueman/AppletPlugin», ya que el servidor de configuraciones no tiene ninguna base de datos en modo de escritura. Hay dos causas comunes para este problema: 1) su ruta de configuración /etc/gconf/2/path no contiene ninguna base de datos o no ha sido encontrada; ó 2) de alguna manera se han creado erróneamente dos procesos gconfd; ó 3) el sistema está mal configurado y el bloqueo de NFS no funciona en su carpeta raíz; ó 4) la máquina NFS cliente dejó de funcionar y no notificó correctamente al servidor al reiniciarse que se deberían eliminar los bloqueos de archivo. Si tiene dos procesos gconfd (o tenía dos en el momento en el que el segundo fue lanzado), cierre, termine todas las copias de gconfd, y vuelva a ingresar, esto puede solucionar el problema. Si tiene bloqueos antiguos, elimine ~/.gconf*/*lock. Quizá el problema está en que intento usar GConf desde dos máquinas al mismo tiempo, y ORBit todavía tiene la configuración predeterminada que previene las conexiones remotas de CORBA - defina "ORBIIOPIPv4=1" en /etc/orbitrc. Como siempre, compruebe las bitácoras user.* para obtener más detalles sobre los problemas encontrados por gconfd. Solo puede haber un gconfd por carpeta raíz, y debe tener un archivo de bloqueo en ~/.gconfd y también archivos de bloqueo en los sitios de almacenamiento locales como ~/.gconf Traceback (most recent call last): File "/bin/blueman-applet", line 125, in <module> BluemanApplet() File "/bin/blueman-applet", line 67, in __init__ self.Plugins = PersistentPluginManager(AppletPlugin, blueman.plugins.applet, self) File "/usr/lib/python2.7/site-packages/blueman/main/PluginManager.py", line 256, in __init__ setattr(self.__config.props, self.plugin_class.__name__, []) File "/usr/lib/python2.7/site-packages/blueman/plugins/ConfigPlugin.py", line 37, in __setattr__ self.__dict__["Config"]().set(key, value) File "/usr/lib/python2.7/site-packages/blueman/plugins/config/Gconf.py", line 81, in set func(BLUEMAN_PATH + self.section + "/" + key, value) File "/usr/lib/python2.7/site-packages/blueman/plugins/config/Gconf.py", line 76, in x self.client.set_list(key, gconf.VALUE_STRING, val) GError: No se pudo contactar con el servidor de configuración: Error de D-Bus: No se puede guardar un valor en la clave «/apps/blueman/AppletPlugin», ya que el servidor de configuraciones no tiene ninguna base de datos en modo de escritura. Hay dos causas comunes para este problema: 1) su ruta de configuración /etc/gconf/2/path no contiene ninguna base de datos o no ha sido encontrada; ó 2) de alguna manera se han creado erróneamente dos procesos gconfd; ó 3) el sistema está mal configurado y el bloqueo de NFS no funciona en su carpeta raíz; ó 4) la máquina NFS cliente dejó de funcionar y no notificó correctamente al servidor al reiniciarse que se deberían eliminar los bloqueos de archivo. Si tiene dos procesos gconfd (o tenía dos en el momento en el que el segundo fue lanzado), cierre, termine todas las copias de gconfd, y vuelva a ingresar, esto puede solucionar el problema. Si tiene bloqueos antiguos, elimine ~/.gconf*/*lock. Quizá el problema está en que intento usar GConf desde dos máquinas al mismo tiempo, y ORBit todavía tiene la configuración predeterminada que previene las conexiones remotas de CORBA - defina "ORBIIOPIPv4=1" en /etc/orbitrc. Como siempre, compruebe las bitácoras user.* para obtener más detalles sobre los problemas encontrados por gconfd. Solo puede haber un gconfd por carpeta raíz, y debe tener un archivo de bloqueo en ~/.gconfd y también archivos de bloqueo en los sitios de almacenamiento locales como ~/.gconf Local variables in innermost frame: self: <Gconf object at 0x88c25a4 (blueman+plugins+ConfigPlugin+ConfigPlugin at 0x86b9360)> key: '/apps/blueman/AppletPlugin' val: []
Created attachment 749434 [details] File: backtrace
Created attachment 749435 [details] File: core_backtrace
Created attachment 749436 [details] File: environ
It happens every time I boot (the error message is in English). It started yesterday, perhaps after an update. But the blueman package is not new and not newly installed. Install Date: Mon 14 Jan 2013 07:43:59 PM EST Group : Applications/System Size : 2537697 License : GPLv3+ Signature : RSA/SHA256, Fri 28 Dec 2012 02:04:38 PM EST, Key ID ff01125cde7f38bd Source RPM : blueman-1.23-5.fc18.src.rpm I have no bluetooth receivers on my system. I'm running an up-to-date Fedora 18 x86_64.
Here's some additional information. I'm using LXDE desktop. It is configured to run gconf in Preferences->Desktop Session Settings. Indeed, gconfd is running $ ps x |grep -i gconfd 1176 ? S 0:00 /usr/libexec/gconfd-2 I installed and ran gconf-editor. It turns out I have /apps but not /apps/blueman. When I select any key in gconf-editor, I see a warning "This key is not writable". If I try to change any value, I get the same message (on the terminal where gconf-editor was launched) as blueman produces. Let me quote it in English to make this bug easier to find. GConf Error: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/gconf-editor/recents', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
I'm quite sure the real problem is that my gconf database is not writable. I don't have that problem on my other systems. I checked the above recommendations, but I don't see anything wrong. It turns out I have a directory /.gconf/apps/blueman with the file %gconf.xml that has an entry for AppletPlugin. <?xml version="1.0"?> <gconf> <entry name="AppletPlugin" mtime="1339032936" type="list" ltype="string"> <li type="string"> <stringvalue>!PulseAudio</stringvalue> </li> </entry> </gconf> The file is writable. However, gconf-editor doesn't see /apps/blueman in the database. Moving away ~/.gconf and killing gconfd-2 makes no difference.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 18'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.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.