[01:39] hi guys. the #gnome channel seems dead. does anyone know it the multiseat functionality what was present in 2.20, and removed in 2.28, will be re-introduced in later versions? [01:41] BalSak: you would have to ask the upstream [01:41] So gnome [01:41] I am, but the channel seems dead [01:41] Tomorrow is monday so ask sometime tomorrow and people should be there [01:42] "patience is a virtue" [01:42] ok. thansk [01:42] NZ-time [01:42] ... [01:42] sux [01:42] It happens [01:42] but monday should be easier to get an answer [01:42] sweet [01:42] thanks [01:43] np [07:32] Good morning [07:37] asac: firefox source NEWed [07:38] good morning, and ahappy new week [07:43] good morning [07:45] hi pitti do you mind if i ask a quick question about an SRU for dapper? bug 484288 [07:45] Launchpad bug 484288 in sun-java5 "update to 1.5.0-22" [Undecided,Fix committed] https://launchpad.net/bugs/484288 [07:46] kermiac: just ask [07:47] with dapper server being supported now & not the desktop, is it valid to install the gui on dapper server to test java [07:48] or is there a better way to test java? [07:49] for hardy i just tried a couple of dozen online java games & verified it as working using the test on the java website & it seems ok [07:53] kermiac: sure, it's fine to install the gui; it should still work [07:53] kermiac: testing that is greatly appreciated [07:54] pitti: ty for the answer I just wanted to make sure that was a valid way to test :) [08:34] pitti: do you have an /etc/X11/Xsession.d/60seahorse-plugins file? debian removed it, but as we renamed it from 60seahorse-plugins to 60seahorse, it wasn't removed [08:34] bonjour didrocks [08:34] didrocks: I do have that [08:34] we don't need that for the gpg agent? [08:35] didrocks: incidentally, I'm just playing with seahorse to get rid of /etc/xdg/autostart/seahorse-daemon.desktop :) [08:35] pitti: hehe, you're playing on the desktop, I'm on the Xsession :) [08:35] pitti: seahorse and seahorse-plugins are the same source package, right? [08:35] [ Loic Minier ] [08:36] * searhorse.Xsession: don't start seahorse-agent if $GPG_AGENT_INFO is set. [08:36] didrocks: no, different ones [08:36] oh right, it only suggests [08:36] didrocks: http://packages.debian.org/sid/i386/seahorse-plugins/filelist [08:36] didrocks: it's still there [08:36] grep isn't good for parsing this carefully :) [08:36] and I think it ought to be [08:37] didrocks: we don't install -plugins by default [08:37] ok, I'll then patch it here :) [08:37] right [08:37] didrocks: is that only in svn or so? [08:37] I was just thinking it will be in the same source package [08:37] pitti: hum, what from svn? [08:37] didrocks: I don't see that the Xsession.d script was removed from Debian [08:38] * pitti invokes seb128 [08:38] pitti: in fact, I guess it was for the transition (it was remove from seahorse) [08:38] removed* [08:38] so, that's why I got puzzled [08:38] everything's fine we still have that file from -plugins source package, sorry for the trouble :) [08:39] ok, I was confused [08:39] it seems it just shouldn't start if ther's another gpg agent running already [08:40] pitti: but we have 90x11-common_ssh-agent too, right? [08:40] oh sun! \o/ One week without seeing it [08:40] didrocks: right; that's ssh, while the 60seahorse is for gpg [08:41] oh right, always confused with -plugins only having gpg stuff despite the description :) [08:45] didrocks: well, it also has the nautilus plugin (but that's also for gpg) [08:47] good morning everyone [08:47] hey chrisccoulson o/ [08:47] I was talking about that sentence: [08:47] " In addition it includes an agent for storing private passphrases, [08:47] as well as a GnuPG and OpenSSH key manager." [08:47] hey didrocks - how are you? [08:47] chrisccoulson: fine thanks. Some sun this morning :) You? [08:48] it's quite miserable here (no sun) unfortunately [08:48] and i'm very tired this morning [08:48] but otherwise, not too bad thanks [08:49] tired on Monday? Fortunately, you have the week to rest from your week-end :) [08:50] didrocks - yeah, we had a long day on saturday (i spent about 7.5 hours driving), and then i got to bed late this morning too [08:50] so i will need a few early nights this week ;) [08:50] I think you deserve them :) [08:50] heh, thanks :) [08:52] hey chrisccoulson, good morning! thanks for gpm! [08:52] hey hyperair - do you know if your second g-p-m patch fixes that other reporters double-suspend issue (ie, could you recreate it without the change)? [08:52] hey pitti, no worries :) [08:52] how are you? [08:53] I'm great! woke up with plans for startup speed in my head :) [08:53] chrisccoulson: i couldn't recreate it without the change, but i'm quite sure of what the problem is, due to the order of the stuff that appeared in the log. [08:53] chrisccoulson: I'm a crash fix away from dropping the seahorse autostart .desktop [08:53] pitti - excellent. i was hoping to do some startup speed work this weekend, but it never materialised unfortunately [08:53] chrisccoulson: do we already have a breakdown how much time each g-s-d plugin needs? [08:54] I was going to add the profiling code that I have for wncksyncdaemon, and check out the timing [08:54] pitti - not that i've done, although i think it's been investigated in some depth before [08:54] bbl, testing something [08:54] and see whether we can speed up/disable some of those for UNR at least [08:54] g-s-d already has some profiling code in it [08:54] but i've not figured out how to use it yet :) [08:54] that would be next on my list after fixing seahorse [08:55] chrisccoulson: ok; you already signed up for the xrandr one, so I guess I'll let you do that plugin first, and I can have a look at the other ones [08:55] pitti - that would be useful. we already know how long the xrandr plugin takes, and it would be interesting to know how long xsettings takes too [08:55] at least no xrdb any more, that helped quite a bit already [08:55] hyperair - i had a thought about your gpm fix when i awoke this morning [08:55] seahorse-daemon needs quite a bit of CPU, so I hope dropping it will win another .5 s [08:55] the value of lid-is-closed that you read from DkpClient is also cached [08:56] hyperair - the cache in devkit-power-gobject is invalidated when it receives a signal from dk-power [08:56] but if you haven't returned to the main loop to process that event, then the cache is probably still invalid [08:56] s/invalid/wrong [08:57] so, i'm not sure it will fix it yet, which is why i asked if you could reproduce it [08:57] chrisccoulson: seriously? devkit-power-gobject has its own cache? [08:57] good morning there [08:57] chrisccoulson: good god. this is ridiculous. [08:57] hyperair - yeah, it does ;) [08:57] it's to cut down on dbus calls every time you want to read a property [08:58] chrisccoulson: ............ [08:58] but the cache should be automatically invalidated when a property changes, so that it gets read from dk-power on the next read [08:58] ah [08:58] if that happens, then it should read from dk-power, right? [08:58] hyperair - don't worry just yet though, your patch might still fix it. but, if it doesn't, then we need to think of something else [08:58] i wouldn't read directly from dk-power [08:59] hmm? [08:59] what do you mean wouldn't read directly? [08:59] i would probably make sure there are no events pending on the main loop before doing anything [08:59] how do you check that? [08:59] so if the value has changed, then the cache is marked invalid before you do anything [08:59] and it's likely that there are always events pending, isn't it? [09:00] chrisccoulson: i don't suppose g_signal_connect_first would do the trick, would it? [09:00] you can use g_main_context_pending / g_main_context_iterating etc, or perhaps you could defer some work with g_idle_add (to ensure that you return to the main loop before doing anything else) [09:00] chrisccoulson: how about having all the components of g-p-m share the same devkit handle? [09:00] morning seb128 :) [09:00] good morning seb128 [09:01] bonjour seb128 [09:02] pitti - this might be of interest for you: http://mces.blogspot.com/2008/10/improving-login-time-part-1-gnome.html [09:02] seb128: had a nice weekend? [09:02] there is a link to the tools needed to do the profiling, and g-s-d already has all the hooks in [09:02] it might be beneficial to do this with the newer version still [09:03] chrisccoulson: right, I know that blog post, but it seems a bit out of date to me [09:03] however, the profiling stuff is still interesting indeed [09:03] chrisccoulson: I'll use that for g-s-d [09:03] pitti - it is. i haven't got round to trying it yet, but it looks cool [09:03] chrisccoulson: lemme try adding a chvt script and reproducing the issue. [09:04] hyperair - thanks [09:04] this is all a bit heavy for first thing on a monday morning - time to grab some coffee :) [09:05] lut didrocks, hey chrisccoulson pitti [09:05] pitti, too short but good, thanks [09:05] what about you? [09:07] didrocks, the une gnome-panel has still no clock applet there, known issue? [09:07] seb128: I'm great, thanks; woke up with startup speed in my head :) [09:07] seb128: hum, even with Friday's update? No, I have mine there. Do you have something in your .local tweaking it? (it just as default) [09:07] pitti, good ;-) I didn't manage to not thing about it during weekend [09:07] seb128: FYI, I tested seahorse without the autostart .desktop file, and found two bugs which need to be fixed (linked to the spec now); but for the main use case (ssh/gpg agents) it's working great [09:07] didrocks, no, I did rm .gconf .local .config [09:08] pitti, ok [09:08] seb128: hum, open a bug and I'll try on a clean config too, so [09:08] didrocks, I will try again before that [09:08] seb128: thanks :) [09:08] didrocks, had a good wekend otherwise? [09:09] seb128: nice one, yes, thanks :) went to the japanese restaurant we talked about during the sprint [09:09] seb128: you? [09:10] didrocks, too short but good otherwise ;-) [09:11] pitti - do you know why it fails on the first go when seahorse-daemon is dbus activated? [09:11] chrisccoulson: it doesn't any more [09:11] ah, excellent [09:11] it consistently fails now and seahorse-daemon sigsegv :) [09:12] oh no :( [09:12] bug 512231 [09:12] Bug 512231 on http://launchpad.net/bugs/512231 is private [09:12] that's for seahorse-preferences [09:12] pitti - i can't view that [09:12] and for the nautilus plugin it's bug 512233 [09:12] Launchpad bug 512233 in seahorse-plugins "nautilus extension does not find GPG keys with seahorse-daemon being d-bus activated" [Undecided,New] https://launchpad.net/bugs/512233 [09:12] chrisccoulson: but that also fails to dbus-activate the daemon; I'll debug it now [09:13] chrisccoulson: "seahorse-daemon crashed with SIGSEGV in egg_set_desktop_file() " [09:13] pitti - ah, because you removed the desktop file ;) [09:14] does it actually fail to activate completely from dbus (ie, not even start and then crash)? [09:14] chrisccoulson: the daemon starts, and segfaults [09:14] thus the UIs just get d-bus errors [09:14] it might very well be that these two bugs are in fact duplicates [09:14] I'll fix the crash first, and then check the nautilus plug in again [09:14] pitti - ah, ok. if you fix the crash and still get a dbus error on the first go, then i've spotted something which might cause that [09:15] but I wanted to collect bug reports for all the observable regressions [09:15] chrisccoulson: sweet, will ask you about it then [09:23] chrisccoulson: did you push 2.28.1-0ubuntu4 for seahorse-plugins in desktop team bzr branch? (it seems not) [09:23] didrocks - did i update it last? [09:23] (i cant remember) ;) [09:23] chrisccoulson: it was on November :) [09:24] seahorse-plugins (2.28.1-0ubuntu4) karmic-proposed; urgency=low [09:24] -- Chris Coulson Mon, 09 Nov 2009 22:34:57 +0000 [09:24] didrocks - ah, that will be for the fix for the crash bug with a gazillion duplicates [09:24] i'm not sure if i pushed it to bzr or not (sorry if i didn't) :( [09:25] chrisccoulson: you didn't copy it into the trunk. No pb, i'll do it for you :) [09:25] didrocks, what do you work on there? [09:25] didrocks - thanks [09:25] * chrisccoulson hugs didrocks [09:25] seb128: the failsafe session thing [09:25] * didrocks hugs chrisccoulson [09:26] didrocks, you think it's a seahorse issue? [09:26] seb128: not only a seahorse, you can have a look at bug #512235 [09:26] Launchpad bug 512235 in seahorse-plugins "Fix gnome failsafe support in lucid (supporting session with arguments" [Undecided,Fix committed] https://launchpad.net/bugs/512235 [09:26] * chrisccoulson thinks that seahorse-agent should be a proper session client rather than being launched from Xsession.d [09:27] ok [09:28] chrisccoulson, the issue would be for non GNOME users I guess [09:28] seb128: btw, I'll need some sponsoring for xorg (just got an awful "already on repo" for seahorse one :)) [09:28] seb128 - yeah, possibly [09:28] didrocks, ask #ubuntu-x or bryyce or tseliot [09:29] I'm not uploading xorg before checking with those guys before [09:29] bryyce: tseliot: can you have a look at bug #512235, please? [09:29] Launchpad bug 512235 in seahorse-plugins "Fix gnome failsafe support in lucid (supporting session with arguments" [Undecided,Fix committed] https://launchpad.net/bugs/512235 [09:29] seb128: ok, make sense :) [09:32] hi didrocks [09:32] hey bryyce :) [09:33] didrocks, would you like to propose a patch for 20x11-common_process-args? [09:33] bryyce: normally, you attached a branch [09:33] s/you/I [09:33] aha, didn't see that [09:34] bryyce: it's the +junk, didn't find a "xorg" product on LP [09:34] we have xorg in git [09:35] oh, that's why I couldn't find any xorg branch outside of lp:ubuntu/xorg [09:35] bryyce: do you prefer a simple patch, a git one? [09:35] a simple patch or a debdiff would be best [09:36] one sec [09:40] didrocks, http://bazaar.launchpad.net/~didrocks/%2Bjunk/fix-failsafe-session/revision/155?remember=153&compare_revid=153 [09:40] bryyce: should be attached now [09:40] ok [09:40] (debdiff) [09:45] looks like I had a couple other failsafe changes (unrelated) in the hopper; I'll push all these out together [09:46] bryyce: perfect, thanks :) [09:46] didrocks, uploaded, and committed to git [09:46] bryyce: should I open a bug on Debian, or you will push it there too? [09:47] chrisccoulson: ok, works fine now, so it's just a dupe of the crash [09:48] didrocks, we use debian's git repo so they can see the changes we put through and pick off interesting ones. However, they could miss it so it would be a good idea to file a bug on it. [09:51] bryyce: oh sweet, I'll browse http://git.debian.org/?p=pkg-xorg;a=summary to find it :) [09:53] does edge timeout for other people too when trying to get buglists? [09:54] seb128, yeah [09:54] or open bugs on a package which has quite some [09:54] seb128, it's annoying me [09:54] ok [09:54] me too [09:54] did you mention it to the launchpad guys already? [09:54] nope [09:55] ok, I ask on #launchpad if they know about it [09:57] seb128 - there's already a bug for that somewhere [09:57] chrisccoulson, right, #launchpad guys gave me the number, thanks [09:57] chrisccoulson, right, #launchpad guys gave me the number, thanks [09:57] ups [09:57] bah [09:58] heh [09:59] at least non-edge is working correctly [09:59] * pitti declares victory over seahorse [10:00] pitti, waouh! [10:00] my current charts are weird [10:00] sent two patches upstream now [10:00] seb128: in what way? [10:00] there is a one second gap with no cpu pick in login [10:13] didrocks, did you try for the clock applet if you get one? [10:14] seb128: normally, I take the one from the gnome session (to get the same locations on the map) [10:14] ? [10:14] gnome-session has no clock applet [10:15] and which map are you talking about? [10:15] seb128: not gnome-session, GNOME session (or desktop session, if you prefer) [10:16] the map you get when clicking on the applet [10:16] below the calendar [10:16] I'm getting confused [10:16] the issue there is that the stock config has no clock applet [10:16] like no hour on the gnome-panel bar [10:17] right, and normally, I'm taking the one from the desktop session (the same applet id) to have the same city and location in the clock applet for the 2 sessions [10:19] I've one in the GNOME session though [10:19] and I've one in UNE after starting a GNOME session [10:20] so UNE relies on a GNOME session to be started once and do some config init [10:20] didrocks, thanks [10:21] seb128: oh? that's bad :/ [10:21] didrocks, well try to delete the gconf config and reboot with UNE [10:21] seb128: I don't know how to share the location so. I have to what what config init it's doing to achieve the same in UNE session [10:21] seb128: ok [10:22] I guess the issue is that gnome-panel doesn't manage to write keys [10:22] because of the mandatory use [10:22] right, it's more than possible [10:36] ok, done with the weekend backlog [10:36] let's start work [10:39] seb128 - did you have many bugs to work through after the weekend? [10:40] bugs? not really, rather email [10:40] some 390 emails in my inbox, 387 being spam [10:40] some 300 bug emails [10:40] and reading changes lists in debian, ubuntu and some mailing lists [10:50] seb128: wow, you get so many false negatives in spam filtering? [10:50] what do you use? [10:51] none [10:51] I use the canonical imap server [10:51] oh, they don't scan spam and at least mark the mails? [10:51] I didn't turn on the spam filter option though, some people said it delays emails delivering by hours [10:52] well, like that it costs you some 15 mins each day, doesn't it? [10:52] no, I use bogofilter from evo on the inbox [10:52] which catches 95% of those [10:53] it just take a bit since it's not server side [10:53] so it has to download everything to filter [10:53] I was pondering just activating the spam filtering service [10:53] but I don't fancy hours of delay in delivering... [10:55] anyway [10:56] wow; seahorse bought us 0.7 seconds [10:56] ;-) [10:56] can I see your chart? [10:56] btw [10:56] http://mail.gnome.org/archives/gnome-keyring-list/2010-January/msg00007.html [10:56] http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3.png [10:56] does anybody has an opinion on that? [10:57] I still don't understand why gnome-session and ssh-agent now have a 0.5 second delay [10:57] gconf starts later than the ssh-agent thing [10:57] chrisccoulson: ^ any idea? [10:57] I'm not sure if we should upgrade [10:58] * No more support for hokey ACL prompts, which had almost no security [10:58] value at all. This was being patched out by almost all distros. [10:58] YES! THANKS! YES! [10:58] pitti - were those not there before? [10:58] chrisccoulson: they were, but I thought they were due to seahorse-daemon and gconf [10:58] chrisccoulson: but we keep eliminating stuff from the critical path, so it's easier to see those now [10:58] bah [10:58] nm-applet takes 1 second cpu [10:58] that's ridiculous [10:59] seb128: that's after the "final" line, though [10:59] pitti - gnome-session still blocks on gconf. i have some packages which probably help that, but i need to update them with all the latest changes before you try them [10:59] pitti, your mini has no internet? [10:59] seb128: it does, wpa2 [10:59] it always asks me for my keyring password, and then connects [10:59] lucky you [10:59] the gnome-keyring-a* process takes quite some CPU [10:59] pitti - FYI, i did some work a while ago which i put here: http://people.ubuntu.com/~chrisccoulson/desktop-startup-speed/ [10:59] seb128: you don't? [10:59] but those are out of date now [11:00] pitti, no [11:00] sec, I'm getting my charts online [11:00] chrisccoulson: I just seem to remember that you said "ssh-agent is not what you think it is", and wondered whether I"m missing something [11:00] I have one free CPU at that time [11:01] and the ssh-agent process is doing nothing [11:01] pitti - yeah, those bars are misleading. gnome-session starts after ssh-agent, but the chart seems to suggest otherwise [11:01] chrisccoulson: ok; so, if nobody has an idea, I'll bisect it down [11:02] chrisccoulson: but first I'll do the promised g-s-d plugin profiling [11:02] the labelling on the bars is messed up by all the fork'ing and execve'ing by things in Xsession.d [11:02] seb128: when I tried first on this box, it didn't even see my wpa2 essid [11:02] seb128: it helped to stop/restart wlan on my router [11:02] then it suddenly worked [11:02] and now it always works [11:02] seb128: it worked just fine on the sprint with the open wifi [11:02] so I didn't give much thought about it [11:03] chrisccoulson: right, but if I remove the xsession.d stuff step by step it should allow me to see what is what, and which bit introduces the latency [11:04] seb128: WDYM in particular about the gnome-keyring update? [11:05] * pitti grumbles about PPA buildds constantly being mozilla-ed [11:06] pitti, http://people.canonical.com/~seb128/bootchart/seb-dellmini-lucid-20100125-3.png [11:06] pitti, the issue is not internet now working [11:06] it's the applet animation [11:06] I'm on wired ethernet there [11:06] seb128: oh, how come you don't have the 5 second usb_id delay? [11:06] and it takes 1 full second cpu [11:07] oh, -10 kernel [11:07] seb128: ergh [11:07] pitti - i'm fairly certain that the gnome-session process on your bootchart actually starts it's life as ssh-agent. i had a look at the ssh-agent code, and it fork's, and then the parent exec's gnome-session, whilst the child continues as ssh-agent [11:07] and i think dbus-launch does a similar thing too [11:07] chrisccoulson: aah, that'd explain it [11:07] pitti, gnome-keyring, seems quite some changes this cycle [11:07] chrisccoulson: so it's really just gnome-session [11:07] and [11:08] "Application or libraries that were speaking gnome-keyring's old [11:08] binary internal protocol, are no longer supported. [11:08] " [11:08] pitti - it looks like ssh-agent takes 0.5s and gnome-session is another 0.5s [11:08] I need to ask upstream details about that [11:08] seb128: the "allow access to keyring" question is quite ridiculous, though; I'd love to see this go away for the lts [11:08] the 0.5s for gnome-session is consistent with the work i did for profiling it [11:08] right, we can turn that off in our current version [11:09] pitti, your chart also show a non optimal cpu use now [11:09] it drops for 2 seconds [11:09] chrisccoulson: ok; it should be much quicker to generate a socket and export an env var; it could do all the costly stuff after fork [11:09] I'm wondering what to do there [11:09] indeed [11:10] seb128: I think mutter does too much init in idle loop now [11:10] the free cpu corresponds to the hole in mutter [11:10] (i. e. the UNE next gen thing) [11:10] well it's not only it [11:10] there is quite some applets not done loading yet too [11:11] why don't they keep working there? [11:13] *nod* [11:17] seb128: oh, your nm-applet is actually before the red line [11:17] yes [11:18] I'm not sure why you don't have one [11:18] it spins way later [11:18] I guess that's because you don't autoconnect [11:18] when I log in, I just see the keyring password [11:18] well, it tries [11:18] well I'm on wired eth [11:18] so no password [11:18] but I didn't disable my keyring pwd [11:18] right [11:18] that needs to be fixed, too [11:19] * pitti adds WI [11:19] thanks [11:19] I think that was already on the karmic list of things to change? [11:19] not sure [11:20] asac, ^ do you know? [11:20] I'm previous sure having this animation too much cpu costy was discussed previous cycle [11:20] whoa [11:20] ssh-agent costs 0.5 seconds [11:20] http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3.png [11:20] vs. [11:20] http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3-no-ssh-agent.png [11:21] what is it doing during those 0.5s? [11:21] and why do we have a ssh-agent if we have gnome-keyring too?. [11:22] urg [11:22] oh, indeed [11:22] gnome-keyring agent uses over 1 second cpu [11:22] I thought it was necessary for seahorse stuff [11:23] I don't think it is no [11:24] it works just fine without [11:24] I'll check with Colin [11:25]