--
gnome-settings-daemon crash opening any window: BadWindow X error under Xvnc
https://bugs.launchpad.net/bugs/199245
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
Not sure what else I can do to help, or what else is needed to move bug from
incomplete status. Hoping this is a good start.
FWIW Xvnc under Hardy is abysmally slow and klunky compared to Gutsy. I
have no idea why the performance is so awful here. I can see the individual
GTK widgets being
gdb backtrace attached.
** Attachment added: gdb-gnome-settings-daemon.txt
http://launchpadlibrarian.net/12520587/gdb-gnome-settings-daemon.txt
--
gnome-settings-daemon crash opening any window: BadWindow X error under Xvnc
https://bugs.launchpad.net/bugs/199245
You received this bug
Sorry, that was a red herring. I figured out how to disable the gnome-
settings-daemon plugins by moving the *plugin files from /usr/lib/gnome-
settings-daemon-2.0, but removing those plugins had no effect on the
login procedure. Still just greeted with a blank screen, *or* sometimes
a lone
Found it. Please mark this bug invalid. The problem lies in the
Xming win32 X server, which for some reason can connect to Gutsy via
XDMCP, but not to Hardy. When I use XDMCP from a real Linux box, I can
log in normally.
Not sure why it doesn't work with Hardy but I can't worry about it.
--
Some info, which I think points to the problem. I used XDMCP to start a
Failsafe Terminal session. (Both libgconf and gnome-keyring-daemon
still start up even with failsafe terminal, which I didn't realize used
any gnome services. Strange).
From the xterm window in the lower right, I type
My IT guys insist they're not blocking anything on our local network.
--
Gnome login hangs every time using XDMCP
https://bugs.launchpad.net/bugs/188132
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
I've also tried renaming the gnome-keyring-daemon, and now on a login
attempt I get the orange background and absolutely no processes in the
terminal from this user according to 'ps'. So it's pretty safe to
assume that gnome-keyring-daemon is not the culprit. Still no clue what
the culprit is,
Strange. I've done a few tests and here's some additional info. I
tried a few other paths to see if the problem lay somewhere other than
XDMCP but the problem does seem related to XDMCP logins only.
1) I've updated to the latest hardy packages as of 12-Feb-2008.
2) Local logins still work
You're correct; I don't know that the bug is in gnome-keyring for
certain. What I do know is that the gnome login process hangs at gnome-
keyring-daemon.
Is there a way I can test a gnome login without the keyring daemon, to
eliminate that as the culprit? I'm happy to provide any other info you
Public bug reported:
Binary package hint: gnome-keyring
System:
Fresh install of Hardy Heron desktop CD (i386), 1-Feb-2008. System: 1GB Ram,
Intel Core 2 Duo, 2.0Ghz. Gnome login desktop works fine from local console.
Steps to reproduce bug:
1) System - Admin - Login Window:
-
Also affects gutsy, just tested on a clean gutsy with all updates
installed (same hardware).
--
Gnome login hangs every time using XDMCP
https://bugs.launchpad.net/bugs/188132
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug contact for
** Attachment added: Got the error dialog!
http://librarian.launchpad.net/3006043/error.jpg
--
Gparted should return 1 Cancel when its operation fails
https://launchpad.net/bugs/46961
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
I can finally report some good news. Now every time I try (using the
latest CD), I get the attached error dialog. The dialog is blank and
doesn't have any GUI buttons, but if I close it from the title bar,
ubiquity takes me back to the manual partition screen *and* my hard disk
isn't hosed.
Public bug reported:
Gparted should return 1 Cancel from the apply command when one of
its operations fails.
Specifically, I have tried to resize an NTFS partition through ubiquity
(which embeds gparted for manual partitioning), and when this operation
fails, gparted does not emit a cancel/error
Cool, downloading the latest CD now, and will try it in the a.m. Thanks
a ton for your diligence on trying to fix this before release... but, I
don't think gparted has been emitting error codes in most of my tests so
I don't know if the latest patch will help.
Not to be alarmist... ;-) but I'm
Hmmm while that may be true on a slow network, this UI bug is still a bug --
the user is given no indication why the behavior would be different. My
network must be better than yours, I burn ISO's from shared drives all the time
on Windows (successfully) ;-)
Now that I look into it more, I
Public bug reported:
Affects: nautilus-cd-burner (Ubuntu)
Severity: Normal
Priority: (none set)
Status: Unconfirmed
Description:
Binary package hint: nautilus-cd-burner
Nautilus-cd-burner doesn't seem to work with SMB shares.
ISO image files on Nautilus network shares
18 matches
Mail list logo
