Summary: | gnome-base/gnome-panel-2.32.1 hangs on startup due old .gconf/desktop/gnome/interfaces/%gconf.xml | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Torsten Kurbad <torsten> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | fkhp101 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | https://bugzilla.gnome.org/show_bug.cgi?id=626377#c6 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 339225, 352218 | ||
Attachments: |
.xsession-errors
.gconf/desktop/gnome/interfaces/%gconf.xml |
Description
Torsten Kurbad
2011-01-12 14:28:58 UTC
What applets are you using? Do you have quick-longe applet? Have you tried on a new created user account? Please provide ~/.xsession-errors file just after reproducing the problem libbonobo 2.32 is masked for a reason, see bug #348290, do not try to use it. Please note that your cflags are too aggressive and are not supported by gnome upstream nor by gentoo gnome team. Most notably -mfpmath=see is known to break various components of the linux desktop in hard to debug ways. Please note that you are setting more than one ACCEPT_KEYWORDS. It is ok if it is the same arch, however setting amd64 and x86 is not only wrong but could cause unpredictable problems. (In reply to comment #2) > libbonobo 2.32 is masked for a reason, see bug #348290, do not try to use it. Yes, I saw that. Nevertheless, I considered it useful to try to approach the problem that way. In my experience, Gnome can be very picky about the actual dependencies and their versions. > Please note that your cflags are too aggressive and are not supported by gnome > upstream nor by gentoo gnome team. Most notably -mfpmath=see is known to break > various components of the linux desktop in hard to debug ways. Hmm, I'm using these CFLAGS for almost 3 years now and never ran into problems because of compiler optimization. Would it be possible to narrow down these "various components" a bit, so I don't have to do an emerge -e world just as a blind shot? > Please note that you are setting more than one ACCEPT_KEYWORDS. It is ok if it > is the same arch, however setting amd64 and x86 is not only wrong but could > cause unpredictable problems. Noted. This is just a remainder of times when there hasn't been a flash-player or java-vm for amd64. I removed x86 and ~x86 from my ACCEPT_KEYWORDS now. However, emerge -evp world tells me there's nothing actually needing those any longer. (In reply to comment #1) > What applets are you using? Do you have quick-longe applet? Have you tried on a > new created user account? Please provide ~/.xsession-errors file just after > reproducing the problem I'm just using things like netstatus-applet. I read the bug reports on the quick-lounge applet, but I don't think that applies here. .xsession-errors states (with bonobo): (gnome-panel:5848):GLib-GObject-WARNING **: cannot register existing type `PanelApplet' (gnome-panel:5848): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed and without bonobo: (gnome-panel:24193): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x1594980 (gnome-panel:24193): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x1594980 Btw., I also read bug report #348240, since I have nvidia twinview running. However, since the panel comes up with USE="-bonobo", I assume this bug doesn't apply either. (In reply to comment #4) [...] > > Please note that your cflags are too aggressive and are not supported by gnome > > upstream nor by gentoo gnome team. Most notably -mfpmath=see is known to break > > various components of the linux desktop in hard to debug ways. > > Hmm, I'm using these CFLAGS for almost 3 years now and never ran into problems > because of compiler optimization. > > Would it be possible to narrow down these "various components" a bit, so I > don't have to do an emerge -e world just as a blind shot? I encountered these compiler optimization problems on at least x86 and I just wanted to make sure you understand it could be one of these and it could be hard to debug. You might just have been lucky because older compilers were less aggressive over optimizations are some of our ebuilds like gtk+ are filtering dangerous cflags. > > Please note that you are setting more than one ACCEPT_KEYWORDS. It is ok if it > > is the same arch, however setting amd64 and x86 is not only wrong but could > > cause unpredictable problems. > > Noted. This is just a remainder of times when there hasn't been a flash-player > or java-vm for amd64. I removed x86 and ~x86 from my ACCEPT_KEYWORDS now. You can use portage.keywords for that. Anyway, now that this is cleared, do you have a dual-head setup ? I see that you have the nvidia USE flag, you might be seeing bug #348240 or one of its variations. oh and could you attach full .xsession-errors too ? > Anyway, now that this is cleared, do you have a dual-head setup ? I see that
> you have the nvidia USE flag, you might be seeing bug #348240 or one of its
> variations.
ok seeing your other comment, never mind this question.
(In reply to comment #7) > > Anyway, now that this is cleared, do you have a dual-head setup ? I see that > > you have the nvidia USE flag, you might be seeing bug #348240 or one of its > > variations. Sorry for getting back that late. The machine I'm having problems with is my main production system, thus I had to make do without bonobo applets for the last two days to get my work done... I'll try two other things after recompiling gnome-panel with USE="bonobo" and report back: 1. Disconnecting 2nd monitor to see, if #348240 applies 2. Attaching a full .xsession-errors Regards, Torsten Created attachment 259806 [details] .xsession-errors (In reply to comment #8) > 1. Disconnecting 2nd monitor to see, if #348240 applies No effect. Panel doesn't come up, even if TwinView is completely disabled with only one display physically connected. > 2. Attaching a full .xsession-errors See attachment. Btw., gnome-panel doesn't actually crash. If I do a ps aux | grep gnome-panel I see a panel process running like so: tkurbad 3343 0.2 0.7 362476 31248 ? Sl 13:46 0:00 gnome-panel Anyway, the panel doesn't show up... Any clues left? Best regards, Torsten Did you try on a new created user account with "fresh" config files? (In reply to comment #10) > Did you try on a new created user account with "fresh" config files? Not, not as of yet. But what I did in the very first place was to remove the folder "panel" from .gconf/apps to have it created freshly. That at least didn't help. I'll try with a "fresh" user and report back. Regards, Torsten As to the whiteboard: I found that bug report, too, and tried the outlined fix, but to no avail. Anyway, strace gnome-panel --replace showed the same output for me as in that bug report, i.e. ending in FUTEX_WAIT_PRIVATE after the Glib-CRITICAL... (In reply to comment #11) > I'll try with a "fresh" user and report back. Okay, fresh user works. Now, how do I narrow down the problem? I tried copying (and chown'ing) over .gconf/apps/panel from the new user, but that didn't do the trick. One thing looks suspicious, though: The new user got everything with _screen0 appended, while my "old" user gets some freshly created _screen1's, too, in .gconf/apps/panel/toplevel. These are the ones that produce warnings in .xsession-errors. Any clue on how to get rid of screen1 for the moment without access to the panel? Regards, Torsten (In reply to comment #13) > (In reply to comment #11) > > I'll try with a "fresh" user and report back. > > Okay, fresh user works. Now, how do I narrow down the problem? > You should now start copying directories and files from "broken" home to "working" one and test when it breaks again in new home. Then, go to subdirectories and so... I suffered a similar problem time ago as explained in: https://bugzilla.gnome.org/show_bug.cgi?id=626377#c6 Please remember that, when "copying/removing/moving" gconf related files, you probably need to logout and verify gconfd is not running (In reply to comment #14) > You should now start copying directories and files from "broken" home to > "working" one and test when it breaks again in new home. Then, go to > subdirectories and so... Fixed! I just did it a bit "the other way round": 1. Made a backup of .gconf, .config and .local in my own homedir, than deleted the defective one 2. Logged out, back in and back out to get a fresh Gnome config 3. Sequentially copied over all non-suspicious application settings, icons, etc. from the backup of the broken config, eventually logging out and back in to check the working state. 4. Copied only the contents of the panel's old objects folder to the new location, leaving out all applets, etc. 5. Adapted .gconf/apps/panel/general/%gconf.xml to reflect all objects now in the configuration 6. Recreated .gconf/desktop/gnome/interfaces/%gconf.xml from scratch not to be hit by the probably related Gnome bug. Et voila, panel's back! Now I only have to re-add the few applets I had running and I'm done. Nonetheless, this is the third or fourth time I hit such a bumpy road on Gnome-updates. I already shiver in fear of 3.0... :-% I don't know, if this bug should be considered fixed. Maybe, some kind of general Gnome upgrade guide in the documentation section of the website would be in order? Regards, Torsten (In reply to comment #15) > 6. Recreated .gconf/desktop/gnome/interfaces/%gconf.xml from scratch not to be > hit by the probably related Gnome bug. > Was this also caused by problems with old .gconf/desktop/gnome/interfaces/%gconf.xml ? Do you have a copy of wrong file? Created attachment 259881 [details] .gconf/desktop/gnome/interfaces/%gconf.xml (In reply to comment #16) > Was this also caused by problems with old > .gconf/desktop/gnome/interfaces/%gconf.xml ? Do you have a copy of wrong file? Honestly, I don't know for sure. I just didn't try again with the old file. But it looks suspiciously similar to the one in the upstream bug report, so I attached it anyway. (In reply to comment #17) > > Was this also caused by problems with old > > .gconf/desktop/gnome/interfaces/%gconf.xml ? Do you have a copy of wrong file? Got same problem and no, that file is not involved (at least in my situation). Problem encountered with nvidia and single screen. solved removing the .gconf/apps/panel/ directory. Ok, a bit rude but i think that losing the actual panel configuration is not so bad and in 30 sec my panel is back like before. (In reply to comment #18) > (In reply to comment #17) > > > Was this also caused by problems with old > > > .gconf/desktop/gnome/interfaces/%gconf.xml ? Do you have a copy of wrong file? > > Got same problem and no, that file is not involved (at least in my situation). > Problem encountered with nvidia and single screen. > solved removing the .gconf/apps/panel/ directory. Ok, a bit rude but i think > that losing the actual panel configuration is not so bad and in 30 sec my panel > is back like before. > Next time please preserve a copy of old files to allow us to find what is the exact problem in exact file. Thanks (Adding this as a blocker for 2.32 tracker to remember to add a ewarn note pointing to .gconf/desktop/gnome/interfaces/%gconf.xml since, at least, Torsten and me got the same problem) I'm suspecting that the nvidia driver changed the way it exposes its monitor layout or that something in the stack is getting it right in 2.32 when it wasn't in earlier releases. I think running something like gconf --recursive-unset /apps/panel would make it work equally well. However, if someone had a copy of the broken setup, it would be nice if we could run some tests together to have something less brutal. Anyway, no ewarn necessary, just write up a migration guide as usual and prepare a news item and we'll be good. *** Bug 348148 has been marked as a duplicate of this bug. *** OK, we will use bug 352218 to cover upgrade guide, this can be closed now since we know it's a configuration problem and upgrade guide will report how to solve it. |