Public bug reported:
Binary package hint: gconf
I am connecting from a Jaunty computer to another computer running
Jaunty, using ssh X11 forwarding.
When I try to open any application such as gedit, I get the following
error over and over again:
GConf Error: Failed to contact configuration
Yes it is reproducible.
I'm not sure if I have found exactly when it happens, but its basically happens
i'd say 90% of the time. I've restarted the server many times, and one time it
worked and I was able to bring up gedit, and basically every other app without
issue.
I'm not really sure
I looked into this more and did some research. There was a file in
~/.dbus/session-bus that was owned by root. I changed the ownership
to me and the error went away, and the program popped up. Below is what
I did:
ke...@mediabox:~$ gedit
GConf Error: Failed to contact configuration server;
Whether or not this is a bug with gconf, I would still consider this a
bug. Something is changing/setting the permissions of those files,
which inhibits basic functionality.
I don't think that a basic user should have to know that they need to
change the permissions back to their own in the
I just encountered the same issue, as described above.
But this time, I right after did:
xrandr -s 1680x1050
and it immediately changed the screen resolution successfully
--
changing screen resolution doesn't always work
https://bugs.launchpad.net/bugs/347944
You received this bug notification
Public bug reported:
Binary package hint: gnome-control-center
I have a Dell Laptop using the fglrx driver. Its native resolution is
1920 x 1200. Often I will connect it to an external monitor. The
external monitor has a lower resolution (1680 x 1050).
When I try to change the resolution to
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/24308439/Dependencies.txt
** Attachment added: ProcMaps.txt
http://launchpadlibrarian.net/24308441/ProcMaps.txt
** Attachment added: ProcStatus.txt
http://launchpadlibrarian.net/24308442/ProcStatus.txt
--
changing
@mazerj
Instead of removing ~/.dbus try changing the ownership of that directory
(and sub directories/files) to your self:
$ sudo chown -R username:username ~/.dbus/
When you removed the directory, it might have been regenerated with some as
root for some reason (which might help with
OTR is required by our company, and though I would love to use Empathy,
this is a show stopper for me.
--
empathy needs to support OTR encryption
https://bugs.launchpad.net/bugs/296867
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to