[01:39] <BalSak> 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] <fagan> BalSak: you would have to ask the upstream
[01:41] <fagan> So gnome
[01:41] <BalSak> I am, but the channel seems dead
[01:41] <fagan> Tomorrow is monday so ask sometime tomorrow and people should be there
[01:42] <crimsun> "patience is a virtue"
[01:42] <BalSak> ok. thansk
[01:42] <BalSak> NZ-time
[01:42] <BalSak> ...
[01:42] <BalSak> sux
[01:42] <fagan> It happens
[01:42] <fagan> but monday should be easier to get an answer
[01:42] <BalSak> sweet
[01:42] <BalSak> thanks
[01:43] <fagan> np
[07:32] <pitti> Good morning
[07:37] <pitti> asac: firefox source NEWed
[07:38] <baptistemm> good morning, and ahappy new week
[07:43] <didrocks> good morning
[07:45] <kermiac> hi pitti do you mind if i ask a quick question about an SRU for dapper? bug 484288
[07:46] <pitti> kermiac: just ask
[07:47] <kermiac> with dapper server being supported now & not the desktop, is it valid to install the gui on dapper server to test java
[07:48] <kermiac> or is there a better way to test java?
[07:49] <kermiac> 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] <pitti> kermiac: sure, it's fine to install the gui; it should still work
[07:53] <pitti> kermiac: testing that is greatly appreciated
[07:54] <kermiac> pitti: ty for the answer I just wanted to make sure that was a valid way to test :)
[08:34] <didrocks> 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] <pitti> bonjour didrocks
[08:34] <pitti> didrocks: I do have that
[08:34] <pitti> we don't need that for the gpg agent?
[08:35] <pitti> didrocks: incidentally, I'm just playing with seahorse to get rid of /etc/xdg/autostart/seahorse-daemon.desktop :)
[08:35] <didrocks> pitti: hehe, you're playing on the desktop, I'm on the Xsession :)
[08:35] <didrocks> pitti: seahorse and seahorse-plugins are the same source package, right?
[08:35] <pitti>  [ Loic Minier ]
[08:36] <pitti>    * searhorse.Xsession: don't start seahorse-agent if $GPG_AGENT_INFO is set.
[08:36] <pitti> didrocks: no, different ones
[08:36] <didrocks> oh right, it only suggests
[08:36] <pitti> didrocks: http://packages.debian.org/sid/i386/seahorse-plugins/filelist
[08:36] <pitti> didrocks: it's still there
[08:36] <didrocks> grep isn't good for parsing this carefully :)
[08:36] <pitti> and I think it ought to be
[08:37] <pitti> didrocks: we don't install -plugins by default
[08:37] <didrocks> ok, I'll then patch it here :)
[08:37] <didrocks> right
[08:37] <pitti> didrocks: is that only in svn or so?
[08:37] <didrocks> I was just thinking it will be in the same source package
[08:37] <didrocks> pitti: hum, what from svn?
[08:37] <pitti> didrocks: I don't see that the Xsession.d script was removed from Debian
[08:38]  * pitti invokes seb128
[08:38] <didrocks> pitti: in fact, I guess it was for the transition (it was remove from seahorse)
[08:38] <didrocks> removed*
[08:38] <didrocks> so, that's why I got puzzled
[08:38] <didrocks> everything's fine we still have that file from -plugins source package, sorry for the trouble :)
[08:39] <pitti> ok, I was confused
[08:39] <pitti> it seems it just shouldn't start if ther's another gpg agent running already
[08:40] <didrocks> pitti: but we have 90x11-common_ssh-agent too, right?
[08:40] <didrocks> oh sun! \o/ One week without seeing it
[08:40] <pitti> didrocks: right; that's ssh, while the 60seahorse is for gpg
[08:41] <didrocks> oh right, always confused with -plugins only having gpg stuff despite the description :)
[08:45] <pitti> didrocks: well, it also has the nautilus plugin (but that's also for gpg)
[08:47] <chrisccoulson> good morning everyone
[08:47] <didrocks> hey chrisccoulson o/
[08:47] <didrocks> I was talking about that sentence:
[08:47] <didrocks> " In addition it includes an agent for storing private passphrases,
[08:47] <didrocks>  as well as a GnuPG and OpenSSH key manager."
[08:47] <chrisccoulson> hey didrocks - how are you?
[08:47] <didrocks> chrisccoulson: fine thanks. Some sun this morning :) You?
[08:48] <chrisccoulson> it's quite miserable here (no sun) unfortunately
[08:48] <chrisccoulson> and i'm very tired this morning
[08:48] <chrisccoulson> but otherwise, not too bad thanks
[08:49] <didrocks> tired on Monday? Fortunately, you have the week to rest from your week-end :)
[08:50] <chrisccoulson> 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] <chrisccoulson> so i will need a few early nights this week ;)
[08:50] <didrocks> I think you deserve them :)
[08:50] <chrisccoulson> heh, thanks :)
[08:52] <pitti> hey chrisccoulson, good morning! thanks for gpm!
[08:52] <chrisccoulson> 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] <chrisccoulson> hey pitti, no worries :)
[08:52] <chrisccoulson> how are you?
[08:53] <pitti> I'm great! woke up with plans for startup speed in my head :)
[08:53] <hyperair> 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] <pitti> chrisccoulson: I'm a crash fix away from dropping the seahorse autostart .desktop
[08:53] <chrisccoulson> pitti - excellent. i was hoping to do some startup speed work this weekend, but it never materialised unfortunately
[08:53] <pitti> chrisccoulson: do we already have a breakdown how much time each g-s-d plugin needs?
[08:54] <pitti> I was going to add the profiling code that I have for wncksyncdaemon, and check out the timing
[08:54] <chrisccoulson> pitti - not that i've done, although i think it's been investigated in some depth before
[08:54] <didrocks> bbl, testing something
[08:54] <pitti> and see whether we can speed up/disable some of those for UNR at least
[08:54] <chrisccoulson> g-s-d already has some profiling code in it
[08:54] <chrisccoulson> but i've not figured out how to use it yet :)
[08:54] <pitti> that would be next on my list after fixing seahorse
[08:55] <pitti> 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] <chrisccoulson> 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] <pitti> at least no xrdb any more, that helped quite a bit already
[08:55] <chrisccoulson> hyperair - i had a thought about your gpm fix when i awoke this morning
[08:55] <pitti> seahorse-daemon needs quite a bit of CPU, so I hope dropping it will win another .5 s
[08:55] <chrisccoulson> the value of lid-is-closed that you read from DkpClient is also cached
[08:56] <chrisccoulson> hyperair - the cache in devkit-power-gobject is invalidated when it receives a signal from dk-power
[08:56] <chrisccoulson> but if you haven't returned to the main loop to process that event, then the cache is probably still invalid
[08:56] <chrisccoulson> s/invalid/wrong
[08:57] <chrisccoulson> so, i'm not sure it will fix it yet, which is why i asked if you could reproduce it
[08:57] <hyperair> chrisccoulson: seriously? devkit-power-gobject has its own cache?
[08:57] <seb128> good morning there
[08:57] <hyperair> chrisccoulson: good god. this is ridiculous.
[08:57] <chrisccoulson> hyperair - yeah, it does ;)
[08:57] <chrisccoulson> it's to cut down on dbus calls every time you want to read a property
[08:58] <hyperair> chrisccoulson: ............
[08:58] <chrisccoulson> 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] <hyperair> ah
[08:58] <hyperair> if that happens, then it should read from dk-power, right?
[08:58] <chrisccoulson> 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] <chrisccoulson> i wouldn't read directly from dk-power
[08:59] <hyperair> hmm?
[08:59] <hyperair> what do you mean wouldn't read directly?
[08:59] <chrisccoulson> i would probably make sure there are no events pending on the main loop before doing anything
[08:59] <hyperair> how do you check that?
[08:59] <chrisccoulson> so if the value has changed, then the cache is marked invalid before you do anything
[08:59] <hyperair> and it's likely that there are always events pending, isn't it?
[09:00] <hyperair> chrisccoulson: i don't suppose g_signal_connect_first would do the trick, would it?
[09:00] <chrisccoulson> 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] <hyperair> chrisccoulson: how about having all the components of g-p-m share the same devkit handle?
[09:00] <didrocks> morning seb128 :)
[09:00] <chrisccoulson> good morning seb128
[09:01] <pitti> bonjour seb128
[09:02] <chrisccoulson> pitti - this might be of interest for you: http://mces.blogspot.com/2008/10/improving-login-time-part-1-gnome.html
[09:02] <pitti> seb128: had a nice weekend?
[09:02] <chrisccoulson> there is a link to the tools needed to do the profiling, and g-s-d already has all the hooks in
[09:02] <chrisccoulson> it might be beneficial to do this with the newer version still
[09:03] <pitti> chrisccoulson: right, I know that blog post, but it seems a bit out of date to me
[09:03] <pitti> however, the profiling stuff is still interesting indeed
[09:03] <pitti> chrisccoulson: I'll use that for g-s-d
[09:03] <chrisccoulson> pitti - it is. i haven't got round to trying it yet, but it looks cool
[09:03] <hyperair> chrisccoulson: lemme try adding a chvt script and reproducing the issue.
[09:04] <chrisccoulson> hyperair - thanks
[09:04] <chrisccoulson> this is all a bit heavy for first thing on a monday morning - time to grab some coffee :)
[09:05] <seb128> lut didrocks, hey chrisccoulson pitti
[09:05] <seb128> pitti, too short but good, thanks
[09:05] <seb128> what about you?
[09:07] <seb128> didrocks, the une gnome-panel has still no clock applet there, known issue?
[09:07] <pitti> seb128: I'm great, thanks; woke up with startup speed  in my head :)
[09:07] <didrocks> 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] <seb128> pitti, good ;-) I didn't manage to not thing about it during weekend
[09:07] <pitti> 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] <seb128> didrocks, no, I did rm .gconf .local .config
[09:08] <seb128> pitti, ok
[09:08] <didrocks> seb128: hum, open a bug and I'll try on a clean config too, so
[09:08] <seb128> didrocks, I will try again before that
[09:08] <didrocks> seb128: thanks :)
[09:08] <seb128> didrocks, had a good wekend otherwise?
[09:09] <didrocks> seb128: nice one, yes, thanks :) went to the japanese restaurant we talked about during the sprint
[09:09] <didrocks> seb128: you?
[09:10] <seb128> didrocks, too short but good otherwise ;-)
[09:11] <chrisccoulson> pitti - do you know why it fails on the first go when seahorse-daemon is dbus activated?
[09:11] <pitti> chrisccoulson: it doesn't any more
[09:11] <chrisccoulson> ah, excellent
[09:11] <pitti> it consistently fails now and seahorse-daemon sigsegv :)
[09:12] <chrisccoulson> oh no :(
[09:12] <pitti> bug 512231
[09:12] <pitti> that's for seahorse-preferences
[09:12] <chrisccoulson> pitti - i can't view that
[09:12] <pitti> and for the nautilus plugin it's bug 512233
[09:12] <pitti> chrisccoulson: but that also fails to dbus-activate the daemon; I'll debug it now
[09:13] <pitti> chrisccoulson: "seahorse-daemon crashed with SIGSEGV in egg_set_desktop_file()  "
[09:13] <chrisccoulson> pitti - ah, because you removed the desktop file ;)
[09:14] <chrisccoulson> does it actually fail to activate completely from dbus (ie, not even start and then crash)?
[09:14] <pitti> chrisccoulson: the daemon starts, and segfaults
[09:14] <pitti> thus the UIs just get d-bus errors
[09:14] <pitti> it might very well be that these two bugs are in fact duplicates
[09:14] <pitti> I'll fix the crash first, and then check the nautilus plug in again
[09:14] <chrisccoulson> 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] <pitti> but I wanted to collect bug reports for all the observable regressions
[09:15] <pitti> chrisccoulson: sweet, will ask you about it then
[09:23] <didrocks> chrisccoulson: did you push 2.28.1-0ubuntu4 for seahorse-plugins in desktop team bzr branch? (it seems not)
[09:23] <chrisccoulson> didrocks - did i update it last?
[09:23] <chrisccoulson> (i cant remember) ;)
[09:23] <didrocks> chrisccoulson: it was on November :)
[09:24] <pitti> seahorse-plugins (2.28.1-0ubuntu4) karmic-proposed; urgency=low
[09:24] <pitti>  -- Chris Coulson<EMAIL_ADDRESS>Mon, 09 Nov 2009 22:34:57 +0000
[09:24] <chrisccoulson> didrocks - ah, that will be for the fix for the crash bug with a gazillion duplicates
[09:24] <chrisccoulson> i'm not sure if i pushed it to bzr or not (sorry if i didn't) :(
[09:25] <didrocks> chrisccoulson: you didn't copy it into the trunk. No pb, i'll do it for you :)
[09:25] <seb128> didrocks, what do you work on there?
[09:25] <chrisccoulson> didrocks - thanks
[09:25]  * chrisccoulson hugs didrocks
[09:25] <didrocks> seb128: the failsafe session thing
[09:25]  * didrocks hugs chrisccoulson
[09:26] <seb128> didrocks, you think it's a seahorse issue?
[09:26] <didrocks> seb128: not only a seahorse, you can have a look at bug #512235
[09:26]  * chrisccoulson thinks that seahorse-agent should be a proper session client rather than being launched from Xsession.d
[09:27] <seb128> ok
[09:28] <seb128> chrisccoulson, the issue would be for non GNOME users I guess
[09:28] <didrocks> seb128: btw, I'll need some sponsoring for xorg (just got an awful "already on repo" for seahorse one :))
[09:28] <chrisccoulson> seb128 - yeah, possibly
[09:28] <seb128> didrocks, ask #ubuntu-x or bryyce or tseliot
[09:29] <seb128> I'm not uploading xorg before checking with those guys before
[09:29] <didrocks> bryyce: tseliot: can you have a look at bug #512235, please?
[09:29] <didrocks> seb128: ok, make sense :)
[09:32] <bryyce> hi didrocks
[09:32] <didrocks> hey bryyce :)
[09:33] <bryyce> didrocks, would you like to propose a patch for 20x11-common_process-args?
[09:33] <didrocks> bryyce: normally, you attached a branch
[09:33] <didrocks> s/you/I
[09:33] <bryyce> aha, didn't see that
[09:34] <didrocks> bryyce: it's the +junk, didn't find a "xorg" product on LP
[09:34] <bryyce> we have xorg in git
[09:35] <didrocks> oh, that's why I couldn't find any xorg branch outside of lp:ubuntu/xorg
[09:35] <didrocks> bryyce: do you prefer a simple patch, a git one?
[09:35] <bryyce> a simple patch or a debdiff would be best
[09:36] <didrocks> one sec
[09:40] <bryyce> didrocks, http://bazaar.launchpad.net/~didrocks/%2Bjunk/fix-failsafe-session/revision/155?remember=153&compare_revid=153
[09:40] <didrocks> bryyce: should be attached now
[09:40] <bryyce> ok
[09:40] <didrocks> (debdiff)
[09:45] <bryyce> looks like I had a couple other failsafe changes (unrelated) in the hopper; I'll push all these out together
[09:46] <didrocks> bryyce: perfect, thanks :)
[09:46] <bryyce> didrocks, uploaded, and committed to git
[09:46] <didrocks> bryyce: should I open a bug on Debian, or you will push it there too?
[09:47] <pitti> chrisccoulson: ok, works fine now, so it's just a dupe of the crash
[09:48] <bryyce> 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] <didrocks> bryyce: oh sweet, I'll browse http://git.debian.org/?p=pkg-xorg;a=summary to find it :)
[09:53] <seb128> does edge timeout for other people too when trying to get buglists?
[09:54] <bryyce> seb128, yeah
[09:54] <seb128> or open bugs on a package which has quite some
[09:54] <bryyce> seb128, it's annoying me
[09:54] <seb128> ok
[09:54] <seb128> me too
[09:54] <seb128> did you mention it to the launchpad guys already?
[09:54] <bryyce> nope
[09:55] <seb128> ok, I ask on #launchpad if they know about it
[09:57] <chrisccoulson> seb128 - there's already a bug for that somewhere
[09:57] <seb128> chrisccoulson, right, #launchpad guys gave me the number, thanks
[09:57] <seb128> chrisccoulson, right, #launchpad guys gave me the number, thanks
[09:57] <seb128> ups
[09:57] <seb128> bah
[09:58] <chrisccoulson> heh
[09:59] <seb128> at least non-edge is working correctly
[09:59]  * pitti declares victory over seahorse
[10:00] <seb128> pitti, waouh!
[10:00] <seb128> my current charts are weird
[10:00] <pitti> sent two patches upstream now
[10:00] <pitti> seb128: in what way?
[10:00] <seb128> there is a one second gap with no cpu pick in login
[10:13] <seb128> didrocks, did you try for the clock applet if you get one?
[10:14] <didrocks> seb128: normally, I take the one from the gnome session (to get the same locations on the map)
[10:14] <seb128> ?
[10:14] <seb128> gnome-session has no clock applet
[10:15] <seb128> and which map are you talking about?
[10:15] <didrocks> seb128: not gnome-session, GNOME session (or desktop session, if you prefer)
[10:16] <didrocks> the map you get when clicking on the applet
[10:16] <didrocks> below the calendar
[10:16] <seb128> I'm getting confused
[10:16] <seb128> the issue there is that the stock config has no clock applet
[10:16] <seb128> like no hour on the gnome-panel bar
[10:17] <didrocks> 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] <seb128> I've one in the GNOME session though
[10:19] <seb128> and I've one in UNE after starting a GNOME session
[10:20] <seb128> so UNE relies on a GNOME session to be started once and do some config init
[10:20] <seb128> didrocks, thanks
[10:21] <didrocks> seb128: oh? that's bad :/
[10:21] <seb128> didrocks, well try to delete the gconf config and reboot with UNE
[10:21] <didrocks> 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] <didrocks> seb128: ok
[10:22] <seb128> I guess the issue is that gnome-panel doesn't manage to write keys
[10:22] <seb128> because of the mandatory use
[10:22] <didrocks> right, it's more than possible
[10:36] <seb128> ok, done with the weekend backlog
[10:36] <seb128> let's start work
[10:39] <chrisccoulson> seb128 - did you have many bugs to work through after the weekend?
[10:40] <seb128> bugs? not really, rather email
[10:40] <seb128> some 390 emails in my inbox, 387 being spam
[10:40] <seb128> some 300 bug emails
[10:40] <seb128> and reading changes lists in debian, ubuntu and some mailing lists
[10:50] <pitti> seb128: wow, you get so many false negatives in spam filtering?
[10:50] <pitti> what do you use?
[10:51] <seb128> none
[10:51] <seb128> I use the canonical imap server
[10:51] <pitti> oh, they don't scan spam and at least mark the mails?
[10:51] <seb128> I didn't turn on the spam filter option though, some people said it delays emails delivering by hours
[10:52] <pitti> well, like that it costs you some 15 mins each day, doesn't it?
[10:52] <seb128> no, I use bogofilter from evo on the inbox
[10:52] <seb128> which catches 95% of those
[10:53] <seb128> it just take a bit since it's not server side
[10:53] <seb128> so it has to download everything to filter
[10:53] <seb128> I was pondering just activating the spam filtering service
[10:53] <seb128> but I don't fancy hours of delay in delivering...
[10:55] <seb128> anyway
[10:56] <pitti> wow; seahorse bought us 0.7 seconds
[10:56] <seb128> ;-)
[10:56] <seb128> can I see your chart?
[10:56] <seb128> btw
[10:56] <seb128> http://mail.gnome.org/archives/gnome-keyring-list/2010-January/msg00007.html
[10:56] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3.png
[10:56] <seb128> does anybody has an opinion on that?
[10:57] <pitti> I still don't understand why gnome-session and ssh-agent now have a 0.5 second delay
[10:57] <pitti> gconf starts later than the ssh-agent thing
[10:57] <pitti> chrisccoulson: ^ any idea?
[10:57] <seb128> I'm not sure if we should upgrade
[10:58] <pitti> * No more support for hokey ACL prompts, which had almost no security
[10:58] <pitti>    value at all. This was being patched out by almost all distros.
[10:58] <pitti> YES! THANKS! YES!
[10:58] <chrisccoulson> pitti - were those not there before?
[10:58] <pitti> chrisccoulson: they were, but I thought they were due to seahorse-daemon and gconf
[10:58] <pitti> chrisccoulson: but we keep eliminating stuff from the critical path, so it's easier to see those now
[10:58] <seb128> bah
[10:58] <seb128> nm-applet takes 1 second cpu
[10:58] <seb128> that's ridiculous
[10:59] <pitti> seb128: that's after the "final" line, though
[10:59] <chrisccoulson> 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] <seb128> pitti, your mini has no internet?
[10:59] <pitti> seb128: it does, wpa2
[10:59] <pitti> it always asks me for my keyring password, and then connects
[10:59] <seb128> lucky you
[10:59] <pitti> the gnome-keyring-a* process takes quite some CPU
[10:59] <chrisccoulson> pitti - FYI, i did some work a while ago which i put here: http://people.ubuntu.com/~chrisccoulson/desktop-startup-speed/
[10:59] <pitti> seb128: you don't?
[10:59] <chrisccoulson> but those are out of date now
[11:00] <seb128> pitti, no
[11:00] <seb128> sec, I'm getting my charts online
[11:00] <pitti> 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] <pitti> I have one free CPU at that time
[11:01] <pitti> and the ssh-agent process is doing nothing
[11:01] <chrisccoulson> pitti - yeah, those bars are misleading. gnome-session starts after ssh-agent, but the chart seems to suggest otherwise
[11:01] <pitti> chrisccoulson: ok; so, if nobody has an idea, I'll bisect it down
[11:02] <pitti> chrisccoulson: but first I'll do the promised g-s-d plugin profiling
[11:02] <chrisccoulson> the labelling on the bars is messed up by all the fork'ing and execve'ing by things in Xsession.d
[11:02] <pitti> seb128: when I tried first on this box, it didn't even see my wpa2 essid
[11:02] <pitti> seb128: it helped to stop/restart wlan on my router
[11:02] <pitti> then it suddenly worked
[11:02] <pitti> and now it always works
[11:02] <pitti> seb128: it worked just fine on the sprint with the open wifi
[11:02] <pitti> so I didn't give much thought about it
[11:03] <pitti> 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] <pitti> seb128: WDYM in particular about the gnome-keyring update?
[11:05]  * pitti grumbles about PPA buildds constantly being mozilla-ed
[11:06] <seb128> pitti, http://people.canonical.com/~seb128/bootchart/seb-dellmini-lucid-20100125-3.png
[11:06] <seb128> pitti, the issue is not internet now working
[11:06] <seb128> it's the applet animation
[11:06] <seb128> I'm on wired ethernet there
[11:06] <pitti> seb128: oh, how come you don't have the 5 second usb_id delay?
[11:06] <seb128> and it takes 1 full second cpu
[11:07] <pitti> oh, -10 kernel
[11:07] <pitti> seb128: ergh
[11:07] <chrisccoulson> 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] <chrisccoulson> and i think dbus-launch does a similar thing too
[11:07] <pitti> chrisccoulson: aah, that'd explain it
[11:07] <seb128> pitti, gnome-keyring, seems quite some changes this cycle
[11:07] <pitti> chrisccoulson: so it's really just gnome-session
[11:07] <seb128> and
[11:08] <seb128> "Application or libraries that were speaking gnome-keyring's old
[11:08] <seb128>    binary internal protocol, are no longer supported.
[11:08] <seb128> "
[11:08] <chrisccoulson> pitti - it looks like ssh-agent takes 0.5s and gnome-session is another 0.5s
[11:08] <seb128> I need to ask upstream details about that
[11:08] <pitti> seb128: the "allow access to keyring" question is quite ridiculous, though; I'd love to see this go away for the lts
[11:08] <chrisccoulson> the 0.5s for gnome-session is consistent with the work i did for profiling it
[11:08] <seb128> right, we can turn that off in our current version
[11:09] <seb128> pitti, your chart also show a non optimal cpu use now
[11:09] <seb128> it drops for 2 seconds
[11:09] <pitti> 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] <seb128> I'm wondering what to do there
[11:09] <pitti> indeed
[11:10] <pitti> seb128: I think mutter does too much init in idle loop now
[11:10] <pitti> the free cpu corresponds to the hole in mutter
[11:10] <pitti> (i. e. the UNE next gen thing)
[11:10] <seb128> well it's not only it
[11:10] <seb128> there is quite some applets not done loading yet too
[11:11] <seb128> why don't they keep working there?
[11:13] <pitti> *nod*
[11:17] <pitti> seb128: oh, your nm-applet is actually before the red line
[11:17] <seb128> yes
[11:18] <seb128> I'm not sure why you don't have one
[11:18] <pitti> it spins way later
[11:18] <seb128> I guess that's because you don't autoconnect
[11:18] <pitti> when I log in, I just see the keyring password
[11:18] <pitti> well, it tries
[11:18] <seb128> well I'm on wired eth
[11:18] <seb128> so no password
[11:18] <pitti> but I didn't disable my keyring pwd
[11:18] <pitti> right
[11:18] <pitti> that needs to be fixed, too
[11:19]  * pitti adds WI
[11:19] <seb128> thanks
[11:19] <seb128> I think that was already on the karmic list of things to change?
[11:19] <pitti> not sure
[11:20] <seb128> asac, ^ do you know?
[11:20] <seb128> I'm previous sure having this animation too much cpu costy was discussed previous cycle
[11:20] <pitti> whoa
[11:20] <pitti> ssh-agent costs 0.5 seconds
[11:20] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3.png
[11:20] <pitti> vs.
[11:20] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3-no-ssh-agent.png
[11:21] <seb128> what is it doing during those 0.5s?
[11:21] <seb128> and why do we have a ssh-agent if we have gnome-keyring too?.
[11:22] <seb128> urg
[11:22] <pitti> oh, indeed
[11:22] <seb128> gnome-keyring agent uses over 1 second cpu
[11:22] <pitti> I thought it was necessary for seahorse stuff
[11:23] <seb128> I don't think it is no
[11:24] <pitti> it works just fine without
[11:24] <pitti> I'll check with Colin
[11:25] <pitti> seb128: do you know what sets $SSH_AUTH_SOCK?
[11:25] <seb128> gnome-keyring-agent
[11:25] <seb128> gnome-keyring-daemon
[11:25] <seb128> I mean
[11:25] <seb128> run it on a  command line
[11:26] <pitti> hm, wouldn't gnome-session need to do that somehow?
[11:26] <pitti> I mean, it needs to get into every process' env
[11:27] <seb128> gnome-keyring sets the gnome-session env over dbus
[11:28] <pitti> seb128: since we can't check for $SSH_AUTH_SOCK that early on, we could say "don't run ssh-agent if /etc/xdg/autostart/gnome-keyring-daemon.desktop exists'?
[11:29] <seb128> hum, no, that would break !GNOME
[11:29] <seb128> the autostart has OnlyShowIn=GNOME;
[11:29] <seb128> so ie xfce users would get none of those running
[11:29] <pitti> ah, so that and we run gnome?
[11:29] <seb128> you mean?
[11:29] <pitti> gnome is in $STARTUP
[11:30] <seb128> ah
[11:30] <pitti> seb128: I'd write it very permissive
[11:30] <pitti> i. e. only not start ssh-agent if we can be sure that we run gnome and we have the keyring autostart
[11:30] <seb128> it that works
[11:30] <pitti> we need to check with UNE
[11:30] <seb128> if
[11:30] <seb128> right
[11:30] <pitti> but I'll do that
[11:30] <pitti> and check with Colin, to be sure
[11:32] <seb128> you can look at the gnomerc Xsession.d script
[11:32] <seb128> you can look at the gnomerc Xsession.d script, it does something similar to detect GNOME
[11:32] <pitti> 'zactly
[11:32] <seb128> it looks to basestartup and see if gnome-session
[11:32] <seb128> +it's
[11:33] <didrocks> pitti: be careful, $STARTUP can be also gnome-session -f. You can check $GDMSESSION maybe
[11:33] <didrocks> or basestartup, right
[11:34] <seb128> BASESTARTUP=`basename "$STARTUP" | cut -d\  -f1`
[11:34] <seb128> didrocks, ^
[11:34] <pitti> didrocks: "gnome" as a substring should do, shouldn't it?
[11:34] <seb128> didrocks, that should work no?
[11:34] <didrocks> seb128: right, that should work :)
[11:34] <hyperair> chrisccoulson: you're right, the fix didn't quite work.
[11:34] <pitti> I don't want to call a zillion external programs for that
[11:35] <didrocks> unfortunate that debian won't take the xorg patch to support "gnome-session args"
[11:35] <seb128> why not?
[11:35] <didrocks> seb128: I got a very constructive answer: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566825
[11:35] <didrocks> using reportbug to report it)
[11:36] <seb128> right...
[11:36] <chrisccoulson> hyperair - thanks for testing it
[11:36] <hyperair> chrisccoulson: what needs to be done is the first patch, in another location as well.
[11:36] <didrocks> seb128: it's the 3rd time in one year, getting tired of this kind of answer
[11:37] <chrisccoulson> hmmm, that response really sucks
[11:37] <hyperair> didrocks: you communicate with all the wrong type of people =)
[11:38] <didrocks> hyperair: seems to be that, right :)
[11:38] <hyperair> didrocks: there was that other blog post where some debian developer was saying that it annoyed him to see @ubuntu.com email addresses in the changelog.
[11:38] <didrocks> I pointed Lucas Nussbaum to it, so that he can adapt the "ubuntu doesn't contribute to debian" speech :)
[11:39] <hyperair> heheh
[11:39] <didrocks> hyperair: right, I read the flameware few months ago
[11:39] <hyperair> flameware. i like that word. =p
[11:40] <didrocks> oupss ^^
[11:41] <hyperair> didrocks<EMAIL_ADDRESS><-- this says he doesn't do a thing for debian. i suspect a troll.
[11:42] <hyperair> or not
[11:42] <hyperair> he's a DD O_o
[11:42] <didrocks> hyperair: maybe a DD not contributing for a long time. Well, he closed the bug, I pointed lucas to it and we'll see next…
[11:43] <hyperair> didrocks<EMAIL_ADDRESS><-- this says he's pretty active.
[11:44] <hyperair> didrocks: i say just reopen the bug.
[11:44] <didrocks> hyperair: right, he's just flaming with the @ens-lyon mail, maybe :)
[11:44] <hyperair> perhaps.
[11:45] <didrocks> let's wait if he looks at my answer and if not, I'll speak with debian QA people before reopening it
[11:46] <hyperair> sure
[11:46] <seb128> didrocks, reopen saying it's an issue in debian too
[11:46] <seb128> the reply there is stupid
[11:48] <didrocks> seb128: ok, doing it now
[11:59] <geser> I usually strip the "ubuntu" suffix from the version when filing a bug with reportbug
[12:05] <didrocks> geser: well, ok, but that's just cheating and don't fix the underlying issue which is a social one :/
[12:05] <geser> true
[12:44] <pitti> didrocks, seb128: FYI, the $BASESTARTUP stuff in 55gnome-session_gnomerc just works by pure accident; in a later script, $STARTUP already has stuff like "dbus-launch" prepended, so it wouldn't work any more
[12:45] <seb128> oh
[12:46] <didrocks> oh bad. maybe the BASESTARTUP stuff should be recorded in /etc/X11/Xsession.d/20x11-common_process-args
[12:46] <pitti> meh, dash doesn't have anything for checking for a substring
[12:49] <pitti> ah, I think I know a trick
[12:50] <pitti> if [ "${STARTUP#*gnome-session}" != "$STARTUP" ]; then we_are_running_gnome
[12:56] <seb128> pitti, doesn't handle the case where it's x-session-manager though
[12:56] <pitti> seb128: sure, I added that as well
[12:56] <pitti> with teh same trick
[12:56] <pitti> now I need to check whether calling gconftool does bad things there
[12:56] <pitti> in terms of startup
[12:57] <pitti> it could just mean that it loads the daemon earlier, which could be fine
[12:57] <pitti> but destroy Chris' efforts of not blocking on it
[12:57] <seb128> it will probably put the 0.5 seconds gconf hit there
[12:57] <pitti> if it delays the startup too much, then we can just as well fix that damn ssh-agent
[12:57] <seb128> which chriscoulson tried to delay
[12:57] <pitti> (yay for having two things for the same thing)
[13:27] <seb128> didrocks, thanks for helping on updates
[13:27] <seb128> didrocks, could you announce on the channel what you start on though?
[13:27] <didrocks> seb128: no pb, I'm on nautilus now
[13:28] <seb128> I try to not read emails every 5 minutes during the day so I don't notice workflow bugs
[13:28] <seb128> ok, I was starting on it
[13:28] <seb128> and noticed your gvfs bug
[13:28] <didrocks> gvfs is waiting on new glib
[13:28] <seb128> that's why I figured I would mention it there ;-)
[13:28] <seb128> right, I did read comments about that now
[13:28] <didrocks> ok, I've finished nautilus one, but if you still want to work on it :)
[13:28] <seb128> no that's ok
[13:28] <seb128> it closes one open bug I think
[13:29] <didrocks> I generally check the bug which a release close at the end of the update (you followed the trunk?)
[13:30] <seb128> didrocks, (yes)
[13:31] <seb128> didrocks, bug #504185
[13:31] <seb128> didrocks, I think that one is fixed
[13:31] <seb128> didrocks, just to spare you the time looking through bugs
[13:31] <didrocks> seb128: thanks :)
[13:32] <seb128> you might want to check it's true ;-)
[13:32] <seb128> it just seems similar to the alignement issue fixed in git
[13:32] <didrocks> I'll check
[13:36] <baptistemm> I can check if you want, I'll currently building git
[13:36] <didrocks> that would be nice :)
[13:40] <didrocks> seb128: right, it fixes that one
[13:42] <baptistemm> the alignment issue seems to be fixed, but the bug upstream is not clease
[13:43] <baptistemm> closed
[13:47] <pitti> hmm
[13:47] <pitti> seb128: so, calling gconftool takes 0.4 seconds of CPU, and still causes gconfd to read everything again, apparently
[13:47] <pitti> that's even more overhead than ssh-agent itself
[13:48] <seb128> weird
[13:48] <seb128> I would just expect it to move the gconf database loading there
[13:48] <seb128> since that's the first call in the session
[13:49] <pitti> that's what I thought
[13:49] <pitti> or perhaps gconftool just generally is that expensive
[13:50] <chrisccoulson> where is gconftool being called?
[13:51] <chrisccoulson> the first gconf read from any client in the session causes gconfd to read and parse its XML files
[13:51] <pitti> chrisccoulson: I added it to /etc/X11/Xsession.d/90x11-common_ssh-agent
[13:51] <pitti> chrisccoulson: to check whether the user disabled ssh agent in g-keyring
[13:51] <chrisccoulson> i have a gconf patch though to make it read and parse them when it starts, rather than wait for a client
[13:51] <pitti> chrisccoulson: hm, ^ should that make a practical difference?
[13:52] <pitti> isn't gconfd spawned by the library once the first client connects?
[13:52] <chrisccoulson> pitti - ah, that's not good. one of the things i was trying to do is to delay reading from gconf for as long as possible
[13:52] <pitti> chrisccoulson: I know
[13:52] <pitti> chrisccoulson: it was just a test
[13:52] <chrisccoulson> gconfd is spawned by gnome-session if its not already running
[13:52] <chrisccoulson> or by a client if it's not already running
[13:52] <pitti> chrisccoulson: if it wasn't for that gconf key, we could efficiently suppress ssh-agent for GNOME session
[13:52] <pitti> s
[13:53] <pitti> chrisccoulson: but on the charts, the XML loading seems to happen right at the start of gconfd already
[13:53] <chrisccoulson> pitti - it will do if a client activated it and asked for a value
[13:53] <chrisccoulson> but when it is spawned by gnome-session, it doesn't do anything until a client tries to read a value
[13:54] <seb128> chrisccoulson, would it make sense to have a random Xsession script triggering the read?
[13:54] <pitti> I already had an Xsession.d script for taht
[13:55] <pitti> which called gconftool -g /invalid
[13:55] <seb128> well does it make next stage faster?
[13:55] <chrisccoulson> seb128 - we could do. the dbus environment has to be set up first though, otherwise you end up with 2 gconfd's in the session
[13:55] <pitti> it didn't really help, though
[13:55] <pitti> chrisccoulson: ah, I think that was the problem
[13:55] <chrisccoulson> and dbus currently isn't set up until after ssh-agent starts is it?
[13:55] <pitti> I think I started it too early
[13:55] <chrisccoulson> gconf needs dbus for clients to discover it
[13:55] <seb128> I would expect that we could do gconf work at the same time than xrandr etc are active
[13:55] <chrisccoulson> pitti - yeah, i fell in to that trap when i was experimenting with it before
[13:55] <seb128> oh, right
[13:56] <pitti> so, I think I'll rather look into ssh-agent itself
[13:56] <pitti> it shouldn't block everything for 0.5 seconds
[13:56] <chrisccoulson> yeah, 0.5 seconds is crazy
[14:01] <didrocks> seb128: apparently, I got a rejection for nautilus. This one is not on the desktop set
[14:01] <seb128> didrocks, ok, I can sponsor for you
[14:02] <pitti> are you guys planning to update glib?
[14:03] <pitti> if so, I'm currently testing whether -O3 makes any difference (for the markup parser -> gconf, etc.)
[14:03] <seb128> pitti, when there is an update yes
[14:03] <pitti> ok, so not "right now" then
[14:03] <seb128> no
[14:04] <desrt> seb, pitti; hi
[14:04] <seb128> hey desrt
[14:04] <didrocks> seb128: dget http://www.didrocks.fr/temp/nautilus_2.29.2-0ubuntu1.dsc
[14:04] <seb128> had a good weekend?
[14:04] <seb128> didrocks, thanks
[14:04] <didrocks> hey desrt
[14:04] <desrt> ya.  got a lot of work done :p
[14:04] <seb128> waouh!
[14:04] <desrt> didrocks: is this the nick you always use?
[14:05] <desrt> eh.  i have "real paid work" at work that i'm supposed to do
[14:05] <desrt> and i wasted a lot of the week doing GVariant work instead
[14:05] <didrocks> desrt: normally, yes :)
[14:05] <desrt> so i felt guilty and i had to catch up :)
[14:05] <desrt> didrocks: noted.  hi. :)
[14:05] <didrocks> desrt: (Didier, we met at last UDS)
[14:05] <desrt> yes.  i did /whois because i suspected that
[14:05] <didrocks> seb128: are you working on updating g-p-m?
[14:06] <seb128> didrocks, we already have 2.29?
[14:06] <chrisccoulson> there is a gpm update again?
[14:06] <desrt> is g-p-m fixed yet? :)
[14:06] <seb128> chrisccoulson, 2.28.3
[14:06] <chrisccoulson> seb128 - ah, we already have 2.29.1
[14:06] <didrocks> seb128: hum, no, only 2.28.3, sorry
[14:06] <chrisccoulson> desrt - whats wrong with g-p-m?
[14:06] <desrt> in karmic it causes my computer to suspend when waking up
[14:07] <pitti> . o O { speaking of which, the bootchart has two more gconftool-2 invocations; that needs to stop }
[14:07] <pitti> hey desrt
[14:07] <desrt> pitti: hi :)
[14:07] <chrisccoulson> desrt - hyperair is working on that issue, but we've found aother problem with the fix in karmic-proposed
[14:07] <desrt> cool
[14:07] <chrisccoulson> but it will be fixed :)
[14:07] <desrt> maybe i should be running -proposed
[14:08] <hyperair> i hear my name.
[14:08] <chrisccoulson> desrt - there is a fix already in karmic-proposed which may fix it for you
[14:08] <chrisccoulson> but there is still a corner case which affects some users
[14:08] <hyperair> chrisccoulson: no, it broke.
[14:08] <hyperair> chrisccoulson: my change broke whatever fix 1.1 did
[14:08] <chrisccoulson> hyperair - oh, i didn't realise that
[14:08] <chrisccoulson> hyperair - do you want me to take a look at it too?
[14:09] <hyperair> chrisccoulson: if you uploaded my most recent patch to both lucid and karmic, then both lucid and karmic are broken again
[14:09] <hyperair> in addition, gpm upstream.. hughsie committed my patch
[14:09] <hyperair> which broke whatever fixes the first patch made
[14:09] <chrisccoulson> ah, so we're back to square one then :(
[14:09] <hyperair> yes
[14:09] <hyperair> we are
[14:09] <chrisccoulson> pitti ^^
[14:09] <hyperair> because dkp-gobj has such bloody ridiculous behaviour >=(
[14:10] <hyperair> chrisccoulson: i can work on another hackish solution, but i'm not familiar enough with glib to implement a proper solution to this.
[14:10] <seb128> didrocks, did you forget to bzr push the changes?
[14:10] <chrisccoulson> hyperair - i'm at work at the moment, but feel free to ping me later if you need any assistance
[14:10] <hyperair> chrisccoulson: sure.
[14:11] <pitti> ah, too bad
[14:11] <hyperair> chrisccoulson: when do you end work?
[14:11] <didrocks> seb128: hum? debcheckout took upstream svn. I was thinking there were no branch so. Fixing that now
[14:11] <chrisccoulson> hyperair - about 17:00 UTC
[14:11] <hyperair> i see. +8 that would be.. 25.
[14:11] <hyperair> i'll be awake
[14:12] <seb128> didrocks, debian svn you mean there?
[14:12] <seb128> didrocks, ok thanks
[14:12] <didrocks> seb128: debcheckout definitely take debian svn. Maybe a patch would be needed in that case to prefer vcs-bzr one
[14:12] <seb128> or we should clean the debian vcs lines
[14:12] <seb128> I was not sure what to do about those
[14:13] <hyperair> chrisccoulson: do you think it would be a feasible idea upstream to make all parts of gpm use the same dkp client handle?
[14:13] <didrocks> you think so? it's an extra line on merges…
[14:13] <seb128> didrocks, I've no strong opinion either way
[14:13] <seb128> didrocks, one control line is not real work
[14:13] <seb128> didrocks, we add the bzr one anyway it's in the same diff chunck
[14:13] <chrisccoulson> hyperair - possibly. that might be a better way to do it
[14:14] <didrocks> seb128: sure, did you sponsor it already or I can remove it?
[14:14] <seb128> didrocks, sponsored
[14:14] <chrisccoulson> hyperair - most of the classes in g-p-m are already used as singletons anyway
[14:14] <hyperair> hmm
[14:14] <seb128> didrocks, there is a pending change from kees is bzr already anyway
[14:14] <seb128> didrocks, just queue changes there
[14:14] <hyperair> gobject is so confusing >_>
[14:14] <didrocks> seb128: ok, it'll be for next round so, with kees changes
[14:14] <seb128> didrocks, or get a -0ubuntu2 upload
[14:14] <hyperair> if gpm were written in C++ it'd be so much more straightforward
[14:14] <chrisccoulson> so having only one DkpClient instance might be a good idea
[14:15] <chrisccoulson> hyperair - i love gobject :D
[14:15] <hyperair> chrisccoulson: and i hate it. i'd rather go vala.
[14:15] <pitti> gobject from python or vala is indeed great :)
[14:15] <pitti> it's just a nuisance in C
[14:15] <chrisccoulson> heh
[14:15] <didrocks> seb128: where is kees change? bzr log -r -1 show me your last change (debian/patches/11_no_session_delay.patch)
[14:16] <seb128> didrocks, look to changelog?
[14:16] <pitti> perhaps we ought to introduce a general best practice to use bound branches
[14:16] <didrocks> seb128: oh right, seing it
[14:17] <pitti> so that we don't forget to push any more
[14:17] <seb128> didrocks, I didn't want to upload it with previous changes I did so I shuffled bzr around
[14:17] <seb128> pitti, is that "each commit is pushed online"?
[14:17] <pitti> right
[14:17] <didrocks> seb128: ok
[14:18] <hyperair> will upower/disks be entering lucid?
[14:18] <seb128> pitti, how does that work with offline work?
[14:18] <pitti> seb128: it fails, or you have to do bzr commit --local
[14:18] <seb128> pitti, like I'm packaging in the train when coming back from sprint
[14:19] <pitti> or you have to "bzr unbind" first
[14:19] <pitti> I'm not generally a huge fan of this mode either
[14:19] <pitti> it's just another option
[14:19] <pitti> I only use it for some projects where other people commit often
[14:19] <pitti> like the WI tracker
[14:20] <seb128> ok
[14:20] <seb128> will think about it
[14:20] <pitti> I think a good middle ground would be to push when you do "debcommit -r"
[14:20] <pitti> if that had a --push option, then we could set an alias
[14:21] <pitti> just thinking aloud, tho
[14:21] <seb128> I don't think it's too much of an issue right now
[14:22] <seb128> whatever model we pick we will always some have some glitches
[14:22] <seb128> pitti, are you on the devicekit mailing list?
[14:22] <pitti> yes, I am
[14:23]  * pitti tries to figure out whether a .1 second saving is just noise, or the result of glib with -O3
 hughsie, any news about https://bugs.freedesktop.org/show_bug.cgi?id=24329?
 seb128: can you ping me a mail to the devkit ml and i'll add it to my todo for this week pls?
[14:23] <seb128> pitti, ^ could you quickly drop an email about that on the bug? you are the one who sent the bug upstream too ;-)
[14:24] <seb128> it will avoid me to look for the email address, subscribe, etc
[14:24] <pitti> seb128: can do, or ping him on IRC
[14:24]  * pitti keeps tab as a reminder
[14:24] <seb128> pitti, what I copied is the reply I just got with an IRC ping
[14:24] <pitti> ah, ok
[14:24] <pitti> yep, will do
[14:24] <seb128> thanks
[14:27] <seb128> arrrrg
[14:27] <seb128> didrocks, !!!!
[14:27] <desrt> talk like a french pirate day?
[14:27] <didrocks> seb128: what?
[14:27] <seb128> didrocks, we stay on evo 2.28 for lucid
[14:27] <seb128> didrocks, we stay on evo 2.28 for lucid...
[14:27] <seb128> didrocks, no gtkhtml 3.29
[14:27] <seb128> bah
[14:27] <didrocks> seb128: I didn't upload evo?
[14:27] <seb128> you did gtkhtml
[14:27] <didrocks> oh gtkhtml is only related to evo?
[14:28] <seb128> which is part of the evo stack
[14:28] <seb128> could you please start pinged there when you do updates?
[14:28] <didrocks> seb128: yes, it was before you notified me about this (this morning)
[14:28] <seb128> ok
[14:28] <didrocks> so, reverting with an epoch?
[14:29] <seb128> that one is annoying now
[14:29] <seb128> I hate epochs
[14:29] <seb128> especially when it means never syncing with debian again
[14:29] <seb128> didrocks, how much did you try if it works in 2.28?
[14:29] <pitti> don't do an epoch, please
[14:29] <pitti> 2.29+really2.28
[14:29] <didrocks> sorry, I wasn't thinking it was so related to evo, just an external library used. I took care about not touching evo upgrade
[14:30] <seb128> that's ok
[14:30] <seb128> but usually when we didn't do any of the 2.29 updates there is a reason
[14:30] <seb128> so ask there
[14:31] <didrocks> ok, sorry :(
[14:31] <seb128> how much did you test it?
[14:31] <seb128> do you use evo as an email client?
[14:31] <didrocks> seb128: I restarted evolution IIRC
[14:31] <didrocks> not sure to have stopped the daemon
[14:31] <seb128> I'm wondering if we could use the new gtkhtml and evo 2.28
[14:31] <seb128> let me ask upstream
[14:32] <didrocks> maybe pitti's trick about 2.28+really2.28 is better?
[14:33] <seb128> right, I was going for that in any case
[14:33] <seb128> as said no epoch
[14:34] <didrocks> ok, I do it right now
[14:34] <seb128> but I'm checking with upstream if 2.29 can work with evo 2.28
[14:34] <seb128> and if they would recommend mixing versions
[14:34] <seb128> didrocks, not don't
[14:34] <didrocks> ok
[14:34] <seb128> please stop touching this one for now ;-)
[14:34] <didrocks> noted down, sorry again :(
[14:34] <seb128> that's ok
[14:34] <seb128> happens to everybody
[14:34] <seb128> but that serves as a lessons for everybody
[14:34] <seb128> we better communicate on IRC
[14:35] <seb128> rather than randomly upload ;-)
[14:35] <seb128> it's part my fault, it's not filtered out on version
[14:35] <seb128> which I'm not sure why
[14:35] <seb128> I did filter evo*
[14:35] <seb128> and gtkhtml too
[14:35] <seb128> but that didn't work on the gtkhtml version
[14:40] <seb128> didrocks, the git log suggests it should work fine on lucid
[14:40] <seb128> let's see how it behaves
[14:40] <didrocks> seb128: I have restarted the daemon and can't open evolution now
[14:40] <seb128> :-(
[14:40] <seb128> what error do you get?
[14:41] <seb128> what daemon btw?
[14:41] <didrocks> file not found
[14:41] <seb128> which file?
[14:42] <didrocks> evolution –force-shutdown
[14:42] <didrocks> ok, the evolution package is in conflict now. Don't know what happened
[14:42] <didrocks> in any case, revert seems to be needed
[14:44] <seb128> let me try to upgrade there first
[14:44] <seb128> I would like to understand why
[14:44] <didrocks> seb128: you will have a conflict
[14:44] <didrocks> seb128: I used dpkg -i first
[14:44] <didrocks> then, had an issue because of shlibs << 2.29
[14:44] <seb128> conflict between what and what?
[14:44] <didrocks> so I fixed it
[14:46] <didrocks> seb128: libgtkhtml-editor0 and libgtkhtml3.14-19
[14:46] <didrocks> seb128: I update the shlibs and then, maybe evolution has been removed when executing apt-get install -f without noticing it on my side
[14:47] <seb128> right
[14:47] <seb128> in any case we need to fix evolution now
[14:47] <seb128> can you try to rebuild with your new gtkhtml
[14:47] <seb128> and see how it works once reinstalled?
[14:48] <seb128> gtkhtml shlib was >> 2.28 << 2.29
[14:48] <seb128> which is pretty stupid thing to do and coming from debian
[14:48] <didrocks> ok, let me try to rebuild evolution
[14:48] <seb128> drop the << part of the gtkhtml shlibs
[14:48] <seb128> and rebuild evo
[14:48] <seb128> thanks
[14:48] <seb128> I'm waiting for a reply from upstream too
[14:49] <seb128> right, evolution got removed now on my une install
[14:55] <seb128> didrocks, ok, evolution need an upload now in any case
[14:55] <seb128> didrocks, do you want to do it or should I?
[14:55] <seb128> didrocks, just to pick the new shlibs
[14:55] <seb128> it's required in any case since 2.29.is.2.28 would still be > 2.29
[14:55] <didrocks> seb128: don't you prefer I test it first locally?
[14:55] <didrocks> oh right
[14:55] <seb128> no
[14:55] <seb128> that's just to pick the shlib fix
[14:55] <didrocks> I can do it if you prefer
[14:56] <seb128> as you want
[14:56] <seb128> I've the checkout and everything
[14:56] <seb128> let me do it there
[14:56] <didrocks> ok
[14:56] <didrocks> I'm testing locally with the new lib version now
[14:57] <seb128> hanks
[14:57] <seb128> thanks
[14:58] <chrisccoulson> pitti - did you figure out if your 0.1 second saving with -O3 is real?
[14:58] <pitti> chrisccoulson: no; I'm afraid savings of that magnitude are below bootchart's noise level
[14:59]  * seb128 thinks charts change too much to get 0.1s out of noise
[14:59] <chrisccoulson> ah, that's a shame
[14:59] <pitti> chrisccoulson: I'd need to instrument gconfd to print microsecond timestamps
[14:59] <chrisccoulson> i suppose you'd need to run it a few hundred times to get something that's statistically relevant ;)
[14:59] <pitti> I won't waste time on that fornow
[15:00] <pitti> I'll profile g-s-d plugins now, and check out that ssh-agent thing
[15:00] <hyperair> chrisccoulson: http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/commit/?id=b8a200eb481a42adf26d639dbdc2224a6c99f841 <-- this needs to get into karmic and lucid. then my second patch will do the trick.
[15:00] <pitti> there's much more beef there
[15:00] <hyperair> chrisccoulson: but i should really test build to make sure nothing else goes wrong this time
[15:00] <chrisccoulson> hyperair - yeah, i was just about to ping hughsie and ask if DkpClient should be a singleton to avoid these issues
[15:01] <chrisccoulson> so, it seems like he beat me to it ;)
[15:01] <hyperair> chrisccoulson: i poked him about it ;-)
[15:01] <chrisccoulson> hyperair - ah, thanks :)
[15:01] <hyperair> chrisccoulson: np. i was actually lying in wait for him for quite a while already, but he always seemed to do his work while not being on irc.
[15:01] <chrisccoulson> ^^pitti - did you see that too?
[15:02] <pitti> I just saw the patch
[15:02] <pitti> I think it's ok to try in karmic-proposed, since except g-p-m not much else is using dk-p yet
[15:02] <davmor2> asac: I'm doing some testing on hardy.4 FF doesn't seem able to track down the plugin for flash.  I went to the vimeo site as I know it has flash and FF's plugin finder gets triggered.
[15:03] <chrisccoulson> pitti - thanks. are you ok to upload that?
[15:04] <pitti> I'm happy to sponsor something, yes
[15:04] <pitti> if someone could throw the patch URL to the bug, as a reminder for me?
[15:04] <pitti> (or just upload it)
[15:05] <chrisccoulson> pitti - i don't think i can upload dk-power
[15:05] <pitti> chrisccoulson: you can
[15:06] <pitti> at least as long as KDE/XFCE aren't using it yet, I figure
[15:08] <chrisccoulson> pitti - oh, ok. i'll give that a try in a bit
[15:09] <seb128> didrocks, ok, upstream says there has been incompatible changes
[15:09] <didrocks> seb128: ok, the build is not finished yet, but if upstream says that…
[15:10] <seb128> didrocks, so take the version which was in lucid before you upload
[15:10] <seb128> and update the changelog using a version 3.29.6.is.3.28.something
[15:11] <seb128> set the shlib back to what it was for >>
[15:11] <seb128> and change the << to 3.29.7
[15:11] <seb128> or 3.30
[15:11] <seb128> or drop it
[15:11] <seb128> and upload
[15:11] <didrocks> ok, doing it right now
[15:11] <seb128> thanks
[15:11] <didrocks> sorry again
[15:11] <seb128> no problem
[15:11] <seb128> happens to everybody
[15:22] <hyperair> pitti: i noticed the Maintainer for devkit-power isn't set to ubuntu developers <ubuntu-devel-discuss .. blah blah. should i leave it be? (my DEBEMAIL is an @ubuntu.com, so dpkg-buildpackage refuses to let me through without changing it)
[15:22] <pitti> hyperair: feel free to; I co-maintain it with Michael Biebl in Debian git, so I didn't change it
[15:22] <hyperair> i see.
[15:23]  * pitti was lazy and used DEBEMAIL= debuild -S for SRUs
[15:23] <hyperair> heh
[15:23] <hyperair> i see.
[15:24] <rickspencer3> good morning all
[15:25] <rickspencer3> ArneGoetje, asac, bryyce, kenvandine, pitti, seb128, chrisccoulson, Nafai, etclll 0/
[15:25] <hyperair> it hasn't reached morning yet here..
[15:25] <seb128> hey rickspencer3
[15:25] <seb128> rickspencer3, how are you?
[15:25] <kenvandine> hey rickspencer3
[15:26] <ArneGoetje> rickspencer3: hi
[15:26] <rickspencer3> I'm a bit crispy this morning, tbh ;)
[15:26] <chrisccoulson> hey rickspencer3, how are you?
[15:27] <rickspencer3> had to finally register my nick this morning to get into some of my channels :/
[15:27] <chrisccoulson> yeah, i think there were a few issues over the weekend with the channels getting spammed
[15:27] <didrocks> hey rickspencer3
[15:27] <rickspencer3> good afternoon didrocks
[15:28] <rickspencer3> looks like a lot of action on blueprints over the last couple of days
[15:28] <rickspencer3> maybe I should take Fridays off more often
[15:28] <seb128> heh
[15:29] <pitti> http://people.canonical.com/~pitti/bootcharts/gnome-settings-daemon-20100125.png
[15:29] <pitti> hey rickspencer3, good morning
[15:30] <seb128> pitti, so xrandr and xrdb takes time
[15:30] <seb128> which we knew
[15:30] <seb128> nothing really slow otherwise
[15:31] <pitti> drawing the background is almost a second
[15:31] <seb128> that's on une right?
[15:31] <seb128> ie when nautilus doesn't do it
[15:31] <seb128> that's similar to the time I was getting with nautilus
[15:31] <pitti> xkl_engine_start_listen takes long, too
[15:31] <seb128> I had a 0.8 seconds win without a background
[15:31] <pitti> seb128: right, UNE
[15:32] <seb128> pitti, right, xkl is in an idle loop though
[15:32] <seb128> no?
[15:32] <chrisccoulson> pitti - xkl_engine_start_listen happens after the next phase has started
[15:32] <chrisccoulson> yeah
[15:32] <chrisccoulson> seb128 beat me to it ;)
[15:33] <chrisccoulson> the bits which block the session end at "gnome_settings_manager_start: end"
[15:33] <seb128> 0.58 seconds start
[15:33] <seb128> that's actually quite good
[15:34] <chrisccoulson> but that xrandr delay is sized perfectly to slot in the gconf XML defaults parsing in parallel :)
[15:34] <chrisccoulson> i don't think both activities fight for CPU activity there
[15:34] <pitti> chrisccoulson: in other words, your patch should help now?
[15:34] <chrisccoulson> pitti - yeah, it should. i just need to get my packages up to date
[15:34] <pitti> since we eliminated the other bits in the chain?
[15:34] <didrocks> seb128: I got a FTBFS on gtkhtml (http://paste.ubuntu.com/362663/). I should patch to use something like gtk_widget_is_toplevel() instead of GTK_WIDGET_TOPLEVEL, right?
[15:35] <seb128> didrocks, yes
[15:36] <seb128> didrocks, see http://git.gnome.org/browse/gtkhtml/commit/?id=265e4da7d533ab32243f4e63c5c35c12de5d62b2
[15:36] <seb128> didrocks, I guess you can apply that one directlyhttp://git.gnome.org/browse/gtkhtml/commit/?id=265e4da7d533ab32243f4e63c5c35c12de5d62b2
[15:36] <didrocks> seb128: I will try, thanks
[15:37] <seb128> didrocks, you're welcome
[15:37] <seb128> stupid question but is there any init function required to use GList and GString?
[15:37] <seb128> I'm used to work on gtk apps and do gtk_init
[15:38] <seb128> but if that's purely a glib app without any event handling, just strings work
[15:40] <seb128> bratsche, desrt: ^
[15:41] <chrisccoulson> seb128 - i don't think you need to call anything to use them
[15:41] <seb128> I don't think either but I'm checking ;-)
[15:41] <seb128> chrisccoulson, thanks
[15:42] <bratsche> Yeah, I don't think so.
[15:44] <seb128> bratsche, thanks
[16:29] <pitti> *boggle*
[16:29] <pitti> after purging pulseaudio, boot time reduced from 16.1 to 14.7
[16:29] <seb128> urg
[16:30] <pitti> pulse itself doesn't actually take a noticeable amount of CPU on the charts
[16:30] <pitti> I wonder whether that's just due to not playing the login sounds, etc.
[16:30] <rickspencer3> pitti, seems easy to test?
[16:31] <seb128> pitti, I did cut the xdg-user-dirs-gtk-update from 1 seconds to 0.3 seconds there
[16:31] <pitti> seb128: wow! just now?
[16:31] <seb128> that's not really busy time though
[16:31] <seb128> pitti, yes, it was doing gtk init every time but only needs it when there is a change and a dialog to show
[16:31] <pitti> rickspencer3: I'll try disabling the sound theme and profile again
[16:32] <seb128> the gtk init leads to load of loading
[16:32] <seb128> themes, etc
[16:32] <pitti> nm-applet is still crazy, though
[16:32]  * pitti eyes the new NM maintainer
[16:32] <seb128> right
[16:32] <seb128> lol
[16:32] <pitti> I didn't have any network right now
[16:33] <pitti> (older kernel -> no bcm wl)
[16:33] <seb128> do we officially have one now?
[16:33] <pitti> and it took > 1 s
[16:33] <seb128> similar to my chart then
[16:33] <seb128> it's the spinning animation...
[16:33] <seb128> we could animate less
[16:33] <pitti> but I didn't even see an animation
[16:33] <pitti> there is no network to connect to
[16:34] <seb128> weird
[16:34] <seb128> the 1 second there is the icon spinning for pretty sure
[16:34] <seb128> it does that while waiting for dhcp reply
[16:35] <pitti> anyway, for general motivation: that's the state of the art (with old kernel which doesn't have the boot time regression): http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-oldkernel.png
[16:35] <pitti> 16.1 seconds
[16:35] <pitti> that's pretty awesome already
[16:35] <seb128> is that with pulse?
[16:35] <pitti> yes, with pulse
[16:35] <seb128> bah
[16:35] <seb128> that gap in cpu use annoys me
[16:35] <pitti> seb128: as I said, 14.7 without pulse
[16:36] <pitti> seb128: check out http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-oldkernel-nopulseaudio.png
[16:36] <seb128> it means that for some reason things are waiting
[16:36] <seb128> and I don't know why
[16:36] <kklimonda> pitti, and the final target is what - 10 or 15 seconds?
[16:36] <pitti> for some reason the gap is almost gone there
[16:36] <pitti> kklimonda: 12 I think
[16:36] <seb128> so we have desktop around 7 seconds now
[16:36] <pitti> the mutter plugin still needs a lot of work
[16:36] <rickspencer3> 10 seconds
[16:37]  * rickspencer3 whip cracking noises
[16:37] <kklimonda> btw, now that there is the new merge process involving lots of bzr magic how to merge packages that have branches in ~ubuntu-desktop ?
[16:37] <seb128> rickspencer3, you said 12 seconds some days ago?
[16:37] <rickspencer3> :)
[16:37] <desrt> seb128: you will notice something interesting later today or tomorrow
[16:37] <seb128> heh!
[16:37] <rickspencer3> seb128, sabdfl mentioned 12 seconds on one call
[16:37] <rickspencer3> but I don't know why he changed it from 10 to 12
[16:37] <seb128> desrt, like desrt * rb4c0b10658bb glib/glib/tests/ (.gitignore Makefile.am gvarianttype.c): add testcase for GVariantType
[16:37] <seb128> ?
[16:37] <desrt> seb128: you're too fast :(
[16:37] <rickspencer3> so we should continute to shoot for 10 until I hear a good reason why the goal changed
[16:37] <seb128> desrt, ;-)
[16:37] <desrt> i assumed you only read changelogs while packaging :p
[16:37]  * seb128 hugs desrt
[16:37] <pitti> rickspencer3: ack
[16:38] <seb128> rickspencer3, we do yes
[16:38] <desrt> (release is coming this afternoon)
[16:38] <pitti> gvariant hitting glib now?
[16:38]  * pitti hugs desrt, great work!
[16:38] <desrt> pitti: parts already have
[16:38] <desrt> pitti: other parts in the next week or two
[16:38] <desrt> the merge is actively in progress at this point, though
[16:38]  * pitti sees http://git.gnome.org/browse/glib/log/
[16:39] <desrt> the type system was the part that matthias had the most concerns about, so hopefully the rest goes easier :)
[16:40] <seb128> the plumber boot is 1 second over target too right now
[16:40] <seb128> it means if they get what they want we are down to 13.7s
[16:40] <seb128> without pulseaudio
[16:40]  * desrt has a solution!
[16:41] <desrt> change pulseaudio into system daemon mode
[16:41] <desrt> that way it goes under plumbing budget :)
[16:41] <seb128> lol
[16:41] <desrt> no.  but seriously.  that would actually be kinda nice for when you have audio streaming setup
[16:41] <desrt> it annoys me that i have to login to [arbitrary user account] in order to be able to stream to my shared speakers
[16:42] <desrt> should just work
[16:42] <seb128> is there any reason to not want to do that?
[16:43] <desrt> i don't know.
[16:43] <pitti> all users would share the same daemon
[16:43] <desrt> but is that bad?
[16:43] <pitti> so it could be a security concern
[16:43] <pitti> but anyway, Lennart strongly recommends using per-user
[16:43] <desrt> ah.  good to know.
[16:43] <pitti> so as distro packagers we better follow that
[16:44] <desrt> is his concern the security one?
[16:44] <pitti> it's easy to enable, of course; it has an init script and all that
[16:44] <pitti> desrt: I'm not sure
[16:44] <pitti> could also be weird race conditions and what not
[16:44] <pitti> in particular, you would loose the automatic ACLs on sound devices
[16:44] <desrt> true.
[16:44] <pitti> i. e. all users could accesss the sound card at the same time, even the inactive sessions
[16:44] <pitti> or ssh ones
[16:44] <pitti> but as I said, that's just my braindump
[16:44] <desrt> sounds like good enough reasons to me
[16:46] <seb128> pitti, note that without pulseaudio you have things not starting in the session
[16:46] <seb128> pitti, like the mixer notification icon
[16:46] <seb128> pitti, and the g-s-d volume key handler probably exit too
[16:46] <pitti> seb128: right; I very much susped those secondary effects
[16:46] <pitti> seb128: my secret hope is that disabling the sound theme by default makes it faster
[16:46] <pitti> and these are just a nuisance in public environments anyway
[16:47] <pitti> which is a good excuse for a netbook!
[16:47] <seb128> did you try that?
[16:47] <pitti> seb128: I'm at it
[16:47] <seb128> hum
[16:47] <seb128> so g-s-d is buggy when it comes to displaying a solid color background
[17:11] <seb128> rickspencer3, do you remember what crashed exactly when we tried empathy video call a week ago? was that segfault? did you send it to launchpad?
[17:11] <rickspencer3> seb128, I don't remember
[17:11] <rickspencer3> I don't think there was a crash
[17:11] <rickspencer3> sorry
[17:11] <seb128> ok, no problem
[17:11] <seb128> we might try again tomorrow ;-)
[17:12] <rickspencer3> sounds good
[17:17] <seb128> I'm looking at the empathy update
[17:17] <seb128> didrocks, ^
[17:17] <pitti> ok, no win on disabling the sound theme
[17:17] <didrocks> ok :)
[17:18] <didrocks> pitti: your ears get some win there :)
[17:18] <fagan> Hmmm is that a known issue that the sound notifications slow emapthy down a little
[17:18] <fagan> Mine freezes for like a second when the sound is about to play
[17:18] <pitti> so I just added a WI for nm-applet
[17:19] <rickspencer3> pitti, work items are going up!
[17:19]  * rickspencer3 chiver
[17:19] <rickspencer3> shiver, even
[17:20] <pitti> I know, I keep adding them for startup-speed :)
[17:20] <pitti> but at the same time half of them got fixed, too
[17:20] <fagan> rickspencer3: well mine will be done by the end of the day I think :)
[17:20] <rickspencer3> fagan, yeah!
[17:20] <pitti> or even more
[17:21] <rickspencer3> pitti, well, if we're doing that work (and by "we" I mean "you" ;) ) it may was well be accounted for
[17:21] <rickspencer3> :)
[17:21] <rickspencer3> so thanks for keeping the work items up to date, it's good for folks in the community and what not to see what's going on too
[17:21] <pitti> nevertheless, 'nuff boot speed stuff for today; dinner, and then some sponsoring, and some sport
[17:21] <seb128> I should add the things I do too
[17:21] <seb128> like the xdg-user-dirs change
[17:22] <rickspencer3> seb128, yeah, that would be good
[17:23] <pitti> seb128: please do; I used to add the time that it saves when flipping to done
[17:37] <didrocks> pitti: simple-scan is already in main. Apparently, no MIR to do on it (and one less WI ;))
[17:37] <fagan> has it been seeded?
[17:38]  * fagan hates xsane
[17:39] <didrocks> fagan: I think so, it's on ubuntu-desktop task at least
[17:59] <pitti> didrocks: I did the MIR some days ago, lool approved, I changed the seeds
[17:59] <pitti> didrocks: hm, I only changed the ubuntu-desktop seed, though, not UNE
[17:59] <pitti> fagan: yes
[18:00] <pitti> u-meta needs a rebuild now
[18:00] <pitti> ... doing
[18:00] <didrocks> pitti: ok, I've removed the WI as I thought it was invalid
[18:00] <didrocks> pitti: I'm adding it to the UNE seed so
[18:00] <pitti> didrocks: it was duplicated with the document-scanning spec; thanks
[18:00] <pitti> didrocks: oh, can you commit ther?
[18:01] <didrocks> pitti: I don't remember if I was able to commit just the seed (not the meta-package)
[18:02] <seb128> kenvandine, hey
[18:02] <seb128> chrisccoulson, wb
[18:03] <chrisccoulson> hey seb128, how are you?
[18:03] <seb128> chrisccoulson, good! you?
[18:03] <seb128> getting ready for sport, I've to leave in some minute
[18:03] <chrisccoulson> yeah, i'm good thanks. just arrived back from work :)
[18:03] <seb128> will be back after that though
[18:08] <didrocks> pitti: it was already there. We did it apparently during the sprint (same for gwibber). I'm doing the gwibber MIR now
[18:09] <seb128> getting gwibber promoted?
[18:11] <didrocks> seb128: for UNE default app, yes
[18:11] <seb128> ok
[18:11] <seb128> I've to go now, sport time
[18:11] <seb128> didrocks, kenvandine: I didn't manage to start on the empathy upgrade
[18:11] <seb128> if one of you want to work on if feel free
[18:12] <didrocks> seb128: ok, taking it
[18:12] <seb128> I will have a look when coming back from sport in 2 hours otheriwse
[18:12] <didrocks> kenvandine: ^
[18:12] <seb128> didrocks, thanks!
[18:12] <didrocks> y/w :)
[18:12] <seb128> see you later
[18:20] <pitti> bye everyone
[18:29] <didrocks> bye bye pitti
[18:31] <kenvandine> didrocks, cool... there are major changes coming to gwibber this week
[18:31] <kenvandine> i need to run to an appointment though, can we talk about it tomorrow/
[18:31] <kenvandine> ?
[18:46]  * kenvandine runs out for 2 back to back doctor's appointments, be back in about 2 hours
[18:56] <didrocks> kenvandine: sure
[18:58] <mclasen> pitti: around ?
[19:05] <Nafai>  yay for ubuntu developer week.  Help get me a good head start for starting next week
[19:06] <chrisccoulson> mclasen - i think pitti is finished for the evening now
[19:31] <bryyce> chrisccoulson, hey a week or so ago you asked me about http://bugs.freedesktop.org/show_bug.cgi?id=25855 - did you get a chance to file an SRU for that?
[19:32] <chrisccoulson> hey bryyce - not yet, i've not had any spare time to follow it up yet
[19:32] <chrisccoulson> the patch had some review comments on xorg-devel. i need to check the status of that really
[19:33] <bryyce> chrisccoulson, ok, good idea.
[19:34] <bryyce> chrisccoulson, I'll keep it on my todo list to check back with you about it
[19:34] <chrisccoulson> bryyce - thanks. i'll hopefully get a chance to look at that in the next couple of days or so
[19:34] <bryyce> sounds great
[19:53] <hyperair> chrisccoulson: http://paste.ubuntu.com/362823/
[19:56] <chrisccoulson> hyperair - thanks. does that seem to resolve the issue?>
[19:56] <hyperair> chrisccoulson: yes.
[19:57] <hyperair> chrisccoulson: but before you upload it..
[19:57] <hyperair> chrisccoulson: i think it'd be better to have the users test it out of a PPA first
[19:57] <chrisccoulson> hyperair - yeah, that sounds ok
[19:57] <hyperair> i've already made two crap uploads, i don't want to make a third crap one.
[19:58] <hyperair> chrisccoulson: also, there's this patch for devkit-power-gobject that i thought was necessary at first, but doesn't seem to be necessary after all
[19:58] <hyperair> it makes dkpclient a singleton
[20:15] <fagan> rickspencer3 or didrocks are either of you free to do a merge to get my quickly docs :)
[20:16] <didrocks> fagan: not right now, but open a merge request :)
[20:17] <fagan> Cool, its not perfect but it works and its all docbook
[20:17] <huats> didrocks, gtksourceview is for me !
[20:18] <didrocks> huats: ok, was going to take it there, but if you want it, take it :)
[20:18] <huats> great !
[20:18] <huats> thanks
[20:20] <huats> didrocks, I am about to start it but with the little baby not sure to end it tonight.... I'll finish it by tomorrow anyway
[20:21] <didrocks> huats: ok :)
[20:23] <didrocks> hum, we are in sync for epiphany-webkit. Let's keep like that
[20:23] <fagan> didrocks: just one small question how do you want me to open yelp?
[20:24] <fagan> to open yelp in bash its yelp <file>
[20:24] <didrocks> fagan: so, yelp file, using subprocess module :)
[20:25] <didrocks> fagan: maybe #quickly is better for that
[20:25] <fagan> Ok :)
[20:26] <didrocks> fagan: you can't join?
[20:26] <fagan> Just got there didrocks :)
[20:34] <didrocks> working on mousetweaks
[21:10] <didrocks> hey seb128, how was your sport evening?
[21:10] <didrocks> taking gedit
[21:10] <seb128> didrocks, good thanks
[21:10] <seb128> just had dinner
[21:11] <seb128> what about you?
[21:11] <didrocks> seb128: some updates finally coming :)
[21:11] <didrocks> seb128: I didn't touch to glib on purpose. I think you wanted to do it
[21:12] <seb128> yes I will do it thanks
[21:12] <didrocks> finishing gedit and then, taking a break. Didn't stop more than 30 min from this morning
[21:12] <seb128> urg
[21:12] <didrocks> (but I don't have the feeling to have done so much work, unfortunately :/)
[21:12] <seb128> you should stop yes
[21:13] <seb128> you did quite some updates
[21:13] <seb128> you can let the accessibility ones to TheMuso btw
[21:13] <didrocks> that's why I just finish an easy one: gedit
[21:13] <seb128> he usually do those since he knows better how to do testing
[21:13] <seb128> ie mousetweak
[21:13] <didrocks> ok, will do for next time. I was waiting for you to come back for glib in fact :)
[21:13] <didrocks> ah, and huats is working on gtksourceview
[21:14] <didrocks> between two baby cries :)
[21:15] <didrocks> for mousetweak, I rebooted the session and try some accessibility key. But sure, I can't test it as much as TheMuso does
[21:16] <seb128> didrocks, ok, excellent work
[21:16] <didrocks> thanks :)
[21:21] <seb128> doing some testing, be back later
[21:21] <seb128> bbl
[21:27] <azteech> anyone know if there is a ubuntu-branded version out for firefox 3.5/3.6, 64-bit 9.04?
[21:27] <azteech> know there is one out for 9.10 .. but am running 9.04
[21:27] <ccheney> azteech: #ubuntu-mozillateam might know
[21:28] <ccheney> azteech: aiui if not yet there will be one eventually, i don't know the current status
[21:28] <azteech> ccheney, thanks .. :)
[22:41] <chrisccoulson> has anyone got any experience running the intel gma4500 graphics chipset that seems to come as standard in dell laptops at the moment?
[22:49] <seb128> chrisccoulson, bryyce probably has an idea about how it's working
[22:49] <chrisccoulson> seb128 - thanks
[22:49] <chrisccoulson> i'm laptop shopping and i have no idea what to buy :(
[22:49] <seb128> not easy indeed
[22:50] <seb128> distro team people mostly have lenovo or dell laptops nowadays
[22:50] <seb128> distro team people mostly have lenovo or dell laptops nowadays
[22:50] <seb128> ups
[22:50] <seb128> I'm happy with my latitude one
[22:50] <seb128> I've not looked recently a newer models though
[22:50] <chrisccoulson> seb128 - yeah, i'm looking at the dells at the moment
[22:51] <seb128> I recommend intel hardware where you can and ssd disk
[22:51] <seb128> my laptop is all intel and everything works out of the box
[22:51] <chrisccoulson> yeah, i'll try and stick to intel hardware
[22:51] <seb128> no wifi chipset issue, no video binary driver breakages
[22:52] <seb128> it's probably not as fast for 3d that other cards but for what I do...
[22:52] <bryyce> chrisccoulson, most of the intel graphics stuff is reasonably well tested
[22:52] <chrisccoulson> seb128 / bryyce - thanks :)
[23:34] <jcastro> chrisccoulson: I have a 4500 in my thinkpad, it's solid.
[23:54] <chrisccoulson> jcastro - thanks :)