=== onestone_ is now known as onestone === calc_ is now known as calc [08:12] hello [08:13] pitti: hey, did you look at why the retracers have a lock or should I do that? [08:13] * seb128 is reading his emails [08:13] moin seb128 [08:13] seb128: I didn't get any lock mail today? [08:13] I got two yesterday, but I fixed that [08:14] (they are actually *working* now, yohoo) [08:14] I mean the mails [08:14] (retracers, too) [08:14] pitti: I got 3 watchdog emails during the night [08:15] weird that you didn't receive those [08:17] pitti: btw do you plan to do srus today? there is a gtk+ and a gedit update waiting for you since friday ;-) [08:20] seb128: already doing [08:20] pitti: you rock! [08:20] eww indeed, three lock files [08:20] seb128: could you have a look, please? [08:20] pitti: will do that [08:21] ah, synced mail again, there it is === kagou is now known as naingrincheux === naingrincheux is now known as kagou [08:39] seb128: is bug 287611 really SRU worthy? it doesn't even have a crash report, or a test case, or anythihng [08:39] Launchpad bug 287611 in gtk+2.0 "implicit pointer conversion will cause SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/287611 [08:40] pitti: that was an implicit declaration so I figured I would do the line change in the sru while I was doing an upload [08:41] pitti: could be causing crashes on some architectures so why not, I would not have uploaded only for that though [08:41] seb128: ah, it's adding that missing #include only? okay [08:41] pitti: right [08:43] seb128: I added tasks to bug 305226, are both fixed in jaunty? [08:43] Launchpad bug 305226 in gtk+2.0 "GtkExpander reports incorrect "name" to accessibility tools" [Low,Triaged] https://launchpad.net/bugs/305226 [08:45] pitti: no, fixed on my disk but the 2.15 update has some issues so I will only upload the next tarball [08:45] which should be in the next days, new GNOME scheduled for next week [08:46] ah,it's in that; alright [09:06] ok [09:06] so I did some bootcharting for session login speed yesterday [09:06] * seb128 looks at mvo [09:06] * seb128 looks at pitti [09:06] * seb128 looks at vuntz [09:06] I blame you guys for session slowness ;-) [09:07] I managed to cut 15 seconds in my session start btw [09:07] mvo: so compiz doesn't register correctly to the session which makes gnome-session sit there and wait for timeout for several seconds [09:07] seb128: what is it doing incorrectly? [09:08] pitti: jockey is hitting disk quite a lot apparently, you know about it I guess? [09:08] mvo: dunno but .xsession-errors has WARNING: Application 'compiz.desktop' failed to register before timeout [09:08] * mvo mubbles something about baroque complexity when registering with the session [09:09] mvo: and bootchart shows it's working for a few second and then doing nothing [09:09] mvo: could be true, vuntz probably have details on how to register correctly if you need those ;-) [09:09] I've to admit I don't know what the clients are supposed to do [09:09] but compiz and seahorse timeout [09:09] ok [09:09] which creates a lot of sitting there and waiting [09:09] I opened a seahorse upstream bug [09:10] and I'm pinging you about compiz ;-) [09:10] seb128: do you know of anything that is equivalent of gdm signal ? [09:10] the compiz upstream might know about that? [09:10] seb128: I want to tell gdm to reboot when I logout [09:10] seb128: I will deal with it after the gdm problem ;) [09:10] mvo: use the dbus api? [09:10] the old gdm speaks that? [09:10] that is excellent [09:10] no [09:10] gnome-session speaks that [09:10] and it uses ck directly nowadays [09:10] no gdm [09:11] that's the complains we get about gnome-session in intrepid [09:11] so g-s logs out and ck knows to reboot instead of returning to gdm? [09:11] it just call reboot or shutdown and doesn't bother about closing the session correctly [09:11] haha [09:11] sounds not quite like what i want then :) [09:11] that's rather ck call reboot [09:11] well, I think that's what you want [09:11] that's what users get when using reboot in gnome-session [09:11] I want session closing first and then reboot .) [09:12] we should fix gnome-session [09:12] right, which is what gnome-session should be doing in any reboot case [09:12] I would rather invest effort making gnome-session do the right thing than workaround to not use it [09:12] since we get the issue when user use the session dialogs [09:13] seb128: right [09:14] seb128: hrm, hrm, the dbus api will be fine for gnome but xfce will stop working (or any other window manager on top of gdm) [09:15] that is really not ideal, I like the current way better in this regard [09:15] hum right [09:15] standardization! [09:15] seb128: but thanks a lot for your help, I will see what I can do [09:16] seb128: and then checkout what compiz is doing, I want to talk to upstream anyway [09:16] mvo: thanks [09:19] just to confirm, gdm-new as man gdm is jaunty+1 ? [09:19] then I can savely switch to dbus because anyone will use it :) [09:20] s/man/main/ [09:20] mvo: right, that's the plan, not in jaunty yet anyway for sure [09:20] ok, thanks! [09:21] mvo: depends on good it will work and the new browser thing for jaunty+1 [09:21] morning everyone [09:22] lut huats [09:22] hello seb128 [09:23] pitti: I got those errors in .xsession-errors [09:23] "ERROR:dbus.proxies:Introspect error on :1.49:/DeviceDriver: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.48" (uid=1000 pid=7010 comm="/usr/bin/python /usr/bin/jockey-gtk --check 60 ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination=":1.49" (uid=0 pid=10551 comm="/usr/bin/pyt [09:23] hon /usr/share/jockey/jockey-backend -"))" [09:24] seb128: 15 seconds! wow [09:24] seb128: yes, I'm aware of my share in jockey; I'll fix that next week [09:24] pitti: is that bug #318745 or should I open a new one? [09:24] Launchpad bug 318745 in jockey "D-Bus Policy needs checking" [Undecided,New] https://launchpad.net/bugs/318745 [09:24] seb128: that's a curious one [09:24] pitti: do you want a bug for it? [09:24] seb128: yes, it needs to get introspection allowed [09:25] seb128: (sorry, got stuck in SRU stuff) [09:25] pitti: well, as said for login seahorse and compiz trigger timeouts because they don't register correctly that's a good part of the issue [09:26] seb128: I'll fix 318745 ASAP, that's the .xsession-errors issue [09:26] pitti: I also copied over my .gconf directory to limit fragmentation which won some 3 seconds, uninstalled tracker which won some other seconds [09:26] pitti: ok thanks [09:26] 15 seconds *dream* takes 77 for me ATM [09:26] I disabled jockey for a test, that bought me 3 [09:26] a lot less than I expected [09:26] 77 is my grub to desktop loaded time on my laptop now [09:27] but I figure if you disable the print applet as well, then you'd get rid of python, and it gets a lot faster [09:27] seb128: do you use an initramfs? [09:27] dunno [09:27] I disabled mine, and grub to gdm is some 40 secs now [09:27] I use whatever jaunty do [09:27] it's still enabled by default [09:27] you have to switch the root= argument from uuid to /dev/sdawhatever [09:27] then you can ditch it (most probably for your laptop) [09:28] jaunty kernel has lots of former modules built in now [09:28] gnome-session starts around 27 seconds on my bootchart [09:29] your laptop has a slow disk [09:29] the main offenders now in session startup on my current chart are 2 python process and jockey [09:29] right [09:29] gnome-panel is doing quite a lot of ios too [09:29] but even with hot cache it takes 28 seconds, shouldn't access the disk much then [09:30] but I don't think we will do anything to this one this cycle [09:30] seb128: is that after fixing the 5-second timeouts? [09:30] pitti: grep timeout .xsession-errors [09:30] x-session-manager[3316]: WARNING: Application 'seahorse-daemon.desktop' failed to register before timeout [09:30] evolution-alarm-notify-Message: Setting timeout for 55602 1233270000 1233214398 [09:30] alarevolution-alarm-notify-Message: Setting timeout for 32179 1233246600 1233214421 [09:30] pitti: 77 seconds grub to desktop is after uninstalling seahorse for testing, I still have compiz [09:31] right, 77 sec is with compiz for me as well [09:31] but I'm running metacity ATM [09:31] my 77 is grub to desktop [09:31] so if compiz has another timeout, this grep didn't catch it [09:31] right it has [09:32] maybe the composite crash is fixed now; I'll reboot in a bit to boot new kernel, will try it out then [09:57] seb128: yep, compiz works again I now get [09:57] x-session-manager[3328]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout [09:57] as well [09:57] ok [09:58] seb128: do you know why g-s is so insistant on serializing startup? [09:58] pitti: the new gnome-session was designed this way [09:58] starting first gnome-settings-daemon [09:58] then compiz [09:59] then nautilus and gnome-panel [09:59] then everything else [09:59] or roughly something around those lines [09:59] the idea is to have a quick desktop loading [10:00] quick by waiting? :-) [10:00] and not too much flickering [10:00] so you get themes, fonts, etc set first [10:00] then start the basic components [10:00] then everything else [10:00] well if none of the basic component is buggy that works fine [10:00] we just have to make sure g-s-d, seahorse, gnome-panel, nautilus, compiz are not buggy [10:00] then everything else can be started [10:07] okay [10:07] seb128: btw, any luck with the retracers? or shall I look into it? [10:08] pitti: there was no error in the logs that's weird, I delete the log and that seems to be working [10:08] log -> lock [10:09] seb128: anything in /var/mail/ubuntu-archive? [10:09] seb128: btw, if you delete a lock, you should check "ps ux" whether anything is running [10:09] pitti: launchpad error, they took it down for upgrade yesterday though [10:09] pitti: so it could be due to that [10:09] aaah [10:09] I'm fairly sure it's that [10:10] all failed at roughly the same time [10:10] good thing that this is nondestructive now [10:10] pitti: right for checking that no instance is running [10:10] (retagging and all that) [10:20] gnome-session registering ... [10:26] seb128: https://code.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/+merge/3208 [10:29] this is the link to the C part: http://bazaar.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/annotate/34?file_id=111_add_dontzap_chec-20090128144105-hq323ola4d9u7qpn-1 [10:34] tseliot: I read your request yesterday but I prefer to let mvo comment, I didn't have to use policykit yet and I don't know enough about it to review those changes quickly === asac_ is now known as asac [10:35] seb128: ok, basically I'm reusing the policykit stuff in screen-resolution-extra which now deals with both the virtual resolution and dontzap [10:36] seb128: The only relevant changes are in the UI i.e. in the C patch [10:40] tseliot: ok, I'll have a look to that later if mvo is not quicker [10:40] ok, thanks [10:41] I can have a look too, just doing some compiz stuff [10:49] seb128: didrocks just told me that he will spend his day off to improve his mario kart skills instead of packaging... do you think it is serious ? [10:50] huats: isn't he trying to become a motu? [10:50] ;-) [10:50] seb128: ;) [10:50] (in fact he is home because he is ill...) [10:51] oh ok so in this case he can [13:09] seb128: I have quite frankly no idea why gnome-session is unhappy, from what I can see it does the proper things. I will go and ask upstream about it [13:11] mvo: ok [13:11] vuntz: there? does compiz register correctly to the session on opensuse? did you distro patch something? [13:12] seb128: don't know, you should ask rodrigo, I guess [13:12] vuntz: do you have a website where I can see the patches you have for each source? [13:14] seb128: yes, but it requires you to create an account :/ [13:14] vuntz: so I get spammed with suse advertissements? no thanks ;-) [13:14] nah, no spam [13:15] vuntz: there is something in the account page which says that you accept to get mails from suse or novell [13:15] really? [13:15] heh [13:15] that's bad [13:15] or that it's possible that you get mails after subscribing [13:15] that's for a bugzilla account dunno if that's the same there [13:16] well, it's the same thing [13:16] if you have an account for any opensuse thing, then you have an account for everything [13:17] no I didn't due to this email thing [13:17] seb128: http://tmp.vuntz.net/opensuse-packages/srcpackage.py [13:17] vuntz: https://secure-www.novell.com/selfreg/jsp/createAccount.jsp [13:17] " By completing this form, I am giving Novell and/or Novell's partners permission to contact me regarding Novell products and services." [13:17] seb128: you can at least see a list of patches for the packages maintained by the gnome team there [13:18] vuntz: thanks [13:18] seb128: I should probably take more time to finish what I wanted to do and publish the patches too [13:18] hm, compiz is not among them [13:19] indeed [13:19] yes, we have a few patches, but not sure we patch anything related to the session [13:19] * rodrigo looks [13:19] no, seems we don't [13:20] ok, I try latest git now [13:22] vuntz: how do I get the patches from your vuntz.net summary? [13:22] vuntz: ie http://tmp.vuntz.net/opensuse-packages/srcpackage.py?srcpackage=gnome-session [13:22] 4: gnome-session-gnome-wm-compiz-manager.patch [13:24] you ping me :-) There's nothing more on this website [13:24] let me upload it [13:24] thanks [13:24] vuntz: ping :) 4: gnome-session-gnome-wm-compiz-manager.patch please [13:25] and 6: gnome-session-compiz-as-default-wm.patch :) [13:25] http://tmp.vuntz.net/opensuse-packages/patches/ [13:25] thanks [13:25] * mvo hugs vuntz [13:25] http://tmp.vuntz.net/opensuse-packages/patches/gnome-session-wm-switch.patch [13:25] ahah! [13:27] not sure that impacts session registration though [13:27] yeah :/ [13:40] seb128: hi :) please sync banshee-extension-mirage 0.4.0+r81-1 from debian/experimental :) [13:54] mvo: do you guys have compiz-manager too? [13:54] * vuntz is wondering whether gnome-session-gnome-wm-compiz-manager.patch should be committed upstream [13:57] vuntz: yes [13:57] vuntz: and you use 0.7.8 ? [13:57] eh, no [13:57] you use the nomad branch from davidr [14:17] mvo, seb128: just added links to http://tmp.vuntz.net/opensuse-packages/srcpackage.py?srcpackage=gnome-session [14:18] (and others) [14:18] the mime type is wrong, but at least you can download stuff [14:18] vuntz: thanks! [14:22] thanks vuntz [14:26] vuntz: the change on http://bugzilla.gnome.org/show_bug.cgi?id=544700 seems to make sense no? [14:26] is there something I can call to run a .desktop file, e. g. in /etc/xdg/autostart/ ? [14:26] Gnome bug 544700 in Panel "[PATCH] Treat expandable applets as fully expanded when finding free spot" [Normal,Unconfirmed] [14:28] ah, nevermind, I can open it in nautilus [14:31] seb128: the idea makes sense, I think. Need to look at it closer [14:59] vuntz: do you know how session registration works in gnome-session? [14:59] vuntz: could you look at gnome bug #569636 [14:59] Gnome bug 569636 in Daemon "doesn't register correctly to the session" [Normal,New] http://bugzilla.gnome.org/show_bug.cgi?id=569636 [15:25] asac: did you want some extra informations about this xulrunner crash on closing? [15:26] asac: I get apport triggering a zilliion times a day due to it in jaunty [15:27] "ignore crashes of this version" FTW [15:29] pitti: right, still would be better to get xulrunner fixed this cycle, this bug is there since hardy [15:33] seb128: right, just for getting it out of your eyes once you reported it [15:34] right [15:34] seb128: btw, I committed a change to jockey trunk to not start it every time any more (just the first time, i. e. if you don't have /var/cache/jockey/check) [15:34] the annoying part is rather the hang while apport is catching the crash which means you can't reopen it immediatly [15:34] pitti: what do you call first time? [15:34] pitti: what happens if hardware change? [15:34] seb128: if it was never called before [15:35] seb128: you lose, and have to start it manually [15:35] ok [15:35] I still need to find a solution for this [15:35] I guess that's a good trade [15:35] but it should be more dynamic, and not tied to session startup [15:35] I need a kind of "hardware checksum" which is quick to calculate [15:35] lspci | md5sum or something [15:36] I was going to write that ;-) [15:36] * pitti puts that into a bug report, for the future [15:36] if the lspci output change slightly between linux versions that's no issue you just get jockey running for the next login [15:38] bug 322776 [15:38] Launchpad bug 322776 in jockey "start jockey at session start if hardware changed" [Undecided,New] https://launchpad.net/bugs/322776 [15:39] seb128: with a new kernel it makes sense to check anyway [15:45] seb128: does it go away when disabling a11y ? [15:46] asac: no, I don't have that enable [15:46] that's still this shutdown issue, I got you a valgrind about it some times ago I think [15:48] seb128: well. we have a new shutdown issue in firefox ... thats why i am asking. [15:48] if you see it a zillion times i would think that its rather that one [15:49] then the one you reported month ago [15:51] asac: [15:52] #5 0xb633f69c in nsBaseAppShell::OnProcessNextEvent (this=0xa937d20, [15:52] thr=0x9f3aba8, mayWait=0, recursionDepth=0) at nsBaseAppShell.cpp:288 [15:52] that's where it crash [15:52] #6 0xb63ebd86 in nsThread::ProcessNextEvent (this=0x9f3aba8, mayWait=0, [15:52] result=0xbf9ff8b8) at nsThread.cpp:497 [15:52] etc [15:52] looks similar to the one I'm having since hardy [15:52] yes [15:53] anyway if you need debug informations, valgrind log, whatever [15:53] let me know ;-) === pedro__ is now known as pedro_ [16:11] seb128: i will get a build on top of a modern xul branch up somewhere ... maybe its gone as there have been substantial fixes on memory management for 1.9.2 and 1.9.1 [16:11] ok [16:11] the backtrace and the valgrind log didnt have much valid info. [16:22] seb128, mvo: very crude hack: http://tmp.vuntz.net/opensuse-packages/browse.py [16:23] vuntz: seems to work ;-) [16:24] vuntz: btw did you read my seahorse gnome-session question before? [16:24] seb128: do you have anything pending for gnome-control-center? [16:24] if not, I will upload the changes from tseliot now [16:24] mvo: no [16:24] mvo: wait [16:24] * mvo freezes [16:25] just looking if there is something obvious you can fix while you upload ;-) [16:25] seb128: nope, I was working on that [16:25] vuntz: do you read it in the backlog? I restarted my irc client since [16:25] mvo: you can upload ;-) [16:27] seb128: replied on the bug [16:34] vuntz: thanks [17:38] vuntz: is seahorse special cased in gnome-session? [17:39] it's started early I'm not sure why [17:39] seb128: no, it's not [17:39] it is [17:40] oh you mean not special cased [17:40] ah [17:41] that's because it's using initialisation in it's desktop, shouldn't it be application? [17:41] it's started before gnome-panel and nautilus right now [17:43] ok, I've to go, bbl [17:43] really going this time bbl [20:27] asac: ping [21:03] hey bryce, does bug 314263 only occur for you when you try and open a URL with sudo (like in the duplicate of it)? [21:03] Launchpad bug 314263 in gvfs "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Triaged] https://launchpad.net/bugs/314263 [21:03] chrisccoulson: never tried it with sudo [21:04] ah, so it's a slightly different situation [21:04] the duplicate occurs for people calling gnome-open with sudo, as apport-gtk does [21:04] and i can recreate that [21:04] i was going to have a look 2nite and see if i can do some debugging [21:05] i dont know the code that well so i cant promise anything! [23:16] rickspencer3: pong