[08:34] <seb128> hello there
[08:35] <baptistemm> salut seb128
[08:36] <pitti> good morning
[08:38] <pitti> hey bryce! hm, that's only a list of articles? anything particularly interesting?
[08:38] <pitti> seb128: thanks for running the benchmarks yesterday; so it was a 0.5 second savings for desktop part, or total?
[08:38] <seb128> both
[08:38] <pitti> seb128: (I had hoped for some nontrivial savings in the readahead part, too)
[08:38] <pitti> ok, thanks
[08:38] <seb128> it doesn't win anything obvious out of desktop I think
[08:38] <pitti> :-(
[08:39] <seb128> well I didn't look into details to the non desktop numbers
[08:39] <seb128> let me look at those again now
[08:41] <seb128> pitti, it's not easy to say numbers change a bit between boots
[08:42] <pitti> seb128: ok, no prob; if it's not really visible, it doesn't buy much then
[08:42] <seb128> it seems around 0.2 seconds win for boot and 0.5 seconds for login
[08:42] <pitti> well, I'm 80% there with it anyway, and it helps more on rotary, so I think I'll finish it anyway
[08:42] <seb128> well we need those 0.5 seconds anyway
[08:42] <chrisccoulson> good morning everyone
[08:42] <seb128> hey chrisccoulson
[08:43] <pitti> with gvariant we can hopefully make it a bit faster, too
[08:43] <pitti> hey chrisccoulson
[08:43] <seb128> pitti, what do you think about commenting out xsplash?
[08:43] <chrisccoulson> hey seb128, how are you?
[08:43] <chrisccoulson> hey pitti
[08:43] <seb128> pitti, it takes between .5 and 1 second
[08:43] <pitti> seb128: for testing, would be interesting; I hope we can make it much less CPU intense by changing the animation?
[08:43] <pitti> hey chrisccoulson
[08:44] <seb128> pitti, not, for reaching target, rickspencer suggested being aggressive until getting there and they adding things back
[08:44] <pitti> yay, David applied my last dk-disks patch
[08:44] <seb128> I would like to drop it now and say we don't re-add it until it's reasonable cpu wise
[08:44] <pitti> seb128: sounds fine
[08:44] <seb128> ok thanks
[08:45] <seb128> pitti, robert_ancell signed for looking at gnome-panel speed btw
[08:45] <seb128> just fyi so you guys don't dup work there
[08:46] <pitti> \o/
[08:46] <chrisccoulson> i tired experimenting with gconf last night, by making gconfd stat() all the xml files when it starts, rather than doing it when applications query the database
[08:46] <pitti> seb128: I just wanted to do the app menu caching; not dropping applets, etc.
[08:46] <chrisccoulson> but i didn't get it to work before i went to bed ;)
[08:47] <chrisccoulson> s/tired/tried
[08:47] <seb128> chrisccoulson, wouldn't it be simpler to have a cat of those in some xsession script or something?
[08:48] <seb128> chrisccoulson, if the goal is to cache infos
[08:48] <seb128> at least for testing
[08:48] <seb128> pitti, ok, good
[08:48] <pitti> shouldn't readahead already pick those up?
[08:48] <pitti> cat'ing seems unnecessary
[08:48] <chrisccoulson> seb128 - possibly. the issue is when applications query the database, gconfd builds its tree of values, which involves lots of stat() calls, and this blocks until that is all done
[08:49] <chrisccoulson> so i thought that gconfd could do that early rather than waiting for an application to ask for a value
[08:49] <seb128> good idea
[08:50] <chrisccoulson> i was hoping that it could do that whilst gnome-session and g-s-d are loading (which won't need gconf when i've finished with them)
[08:50] <chrisccoulson> so that when the panel loads, the gconf database will already be ready
[08:51] <chrisccoulson> i don't really know if it will work out yet though
[08:51] <pitti> does it help in any way to use a merged tree?
[08:52] <chrisccoulson> pitti - it probably would help a lot
[08:52] <seb128> we do that by default no?
[08:52] <chrisccoulson> is it easy to do that? (i'm still learning how gconf works)
[08:53] <chrisccoulson> seb128 - the per user database is a separate folder for each folder in the database (i think that's the opposite of a merged tree isnt it?)
[08:53] <seb128> right
[08:53] <seb128> but the user config is empty for our target
[08:53] <seb128> since the boot measure is on a stock install
[08:54] <chrisccoulson> are the defaults stored in a merged tree?
[08:54] <seb128> I would not bother optimizing this case
[08:54] <seb128> yes
[08:54] <seb128> only the user config are not
[08:54] <seb128> the reason being nfs locking issues
[08:54] <chrisccoulson> ah, ok
[08:55] <chrisccoulson> it still takes 500ms on the stock install though, even with the merged tree
[08:55] <chrisccoulson> but it seems that will get worse with the per-user config too
[08:55] <seb128> right
[08:55] <seb128> while I appreciate that I think we should not spend too much time on things that will be replaced next time
[09:03] <pitti> seb128: right, I just wondered, since switching to merged tree is a single change
[09:03] <pitti> but right, if we have an empty user tree, it shouldn't matter
[11:24] <pitti> Verarbeite Trigger für python-gmenu ...
[11:24] <pitti> Rebuilding /usr/share/applications/desktop.de_DE.UTF-8.cache...
[11:24]  * pitti hugs dpkg triggers
[11:27]  * seb128 hugs pitti
[11:28] <pitti> seb128: all working now; I forgot to construct a path to the .desktop file when reading the cache, that was the reason for menu entries not working
[11:28] <pitti> and cache is now handled automatically
[11:28]  * pitti uploads, let the bugs come all over me!
[11:30] <pitti> so the plan is now to drop those applets and disable xsplash for now, and see where we are?
[11:35] <seb128> pitti, yes, I did the gdm change some minutes ago
[11:36] <pitti> \o/
[11:36] <seb128> I will do the gnome-panel one this afternoon
[11:36] <pitti> you rock
[11:36] <seb128> thanks, you too!
[11:36] <seb128> once we have those I will do an official mark
[11:37] <seb128> then try again with gnome-session modified to start things together
[11:37] <seb128> just to see how that performs now
[11:37] <seb128> I will also do the compiz change to not depends on extra if Amaranth doesn't upload today
[11:37] <seb128> that wins another 0.5 second
[12:43] <mvo> Ng: hi, did you had trouble with asciidoc and not finding docbook-xsl.css too? I used -r /etc/asciidoc as a workaround, but that seems wrong that I have to do that explicitely - what do you think?
[12:45] <Ng> mvo: my memory is like an empty rock, so if I did have that problem I've apparently completely forgotten about it ;)
[12:45] <mvo> Ng: ok, no problem :)
[12:50] <Amaranth> seb128: I pushed the changes needed to remove plugins-extra to bzr, don't have time to build and upload right now
[12:51] <Amaranth> I guess we cleaned up active_plugins handling some time ago, wasn't as bad as I thought
[12:52] <seb128> Amaranth, will you do that today or should I do it?
[12:52] <seb128> it's just a depends to suggests change
[12:52] <seb128> no need to test build or anything
[12:52] <Amaranth> oh, I dropped it completely
[12:52] <seb128> that's good too
[12:52] <Amaranth> but I gotta go now, if you can wait 8 hours I can do it
[12:53] <seb128> as long as it's not depends or recommends
[12:53] <seb128> ok
[12:53] <seb128> I will wait for you to upload
[12:53] <seb128> thanks
[14:35] <seb128> hey rickspencer3
[14:36] <rickspencer3> hi seb128
[14:36] <seb128> how are you?
[14:38] <rickspencer3> doing well
[14:38] <rickspencer3> meetings galore this morning
[14:38] <pitti> good morning rickspencer3
[14:38] <rickspencer3> including covering our blueprints for lucid with sabdfl
[14:38] <rickspencer3> :o
[14:38] <rickspencer3> hi pitti
[14:38] <rickspencer3> seb128, pitti how is it going?
[14:39] <seb128> rickspencer3, good luck ;-)
[14:39] <seb128> rickspencer3, good, pitti rocked as usual and landed the menu caching changes
[14:39] <rickspencer3> chouette!
[14:40] <seb128> rickspencer3, I've also commented xsplash use from gdm btw
[14:40] <seb128> it wins us almost 1 second of login time
[14:41] <seb128> let me know if you are against it
[14:42] <rickspencer3> I not against anything that gets us to the 4 second budget at this stage
[14:42] <rickspencer3> so, good job
[14:42] <seb128> ok thanks ;-)
[14:42]  * seb128 wonders what is the publishing today
[14:42] <seb128> still no gnome-menus update
[14:43] <seb128> or what is the publisher doing rather
[14:48] <kenvandine> seb128, good and bad news on the indicator stuff... with the new indicators coming that will add more indicator services, but tedg is concerned about the startup time and will add some code to help profile it
[14:50] <seb128> kenvandine, current indicators use cpu for almost 1.5 seconds
[14:50] <seb128> which is over 25% budget for the whole login
[14:50] <kenvandine> tedg, ^^
[14:50] <kenvandine> not cool
[14:50] <seb128> really not no
[14:51] <seb128> I'm pondering dropping the applet from the default config just to reach the target as we did for xsplash
[14:51] <seb128> but I guess that would be controversial ;-)
[14:51] <seb128> we will need to put some pressure on improving those though or we will really have to consider that
[14:54] <kenvandine> are we planning to keep xsplash out?
[14:54]  * kenvandine thinks it defeats the whole purpose of having xsplash at all
[14:54] <seb128> well we said we would meet the target even if that means doing some compromises...
[14:54] <seb128> then we can discuss those choices
[14:54] <kenvandine> ok
[14:55] <seb128> we can't have everything
[14:55] <seb128> I expect xsplash could also be improved
[14:55] <seb128> the current animation use too much cpu
[14:55] <seb128> but Cody said he has ideas on how to improve that maybe
[14:56] <seb128> I think we will bring it back during the cycle but it will need to be less cpu intensive
[15:03] <chrisccoulson> seb128 - you have "gnome-session: investigate 1 second delay between start and activity:" assigned to you in https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed. we can close this one now can't we?
[15:03] <seb128> pitti, do you know if launchpad has issues?
[15:04] <seb128> pitti, gnome-menus is still not published there
[15:04] <seb128> chrisccoulson: that's gconf?
[15:04] <pitti> not that I know of
[15:04] <seb128> pitti, ignore me I'm using the french mirror
[15:04]  * seb128 switches to archive.ubuntu.com
[15:05] <pitti> :)
[15:05] <chrisccoulson> seb128 - i detailed all the findings on the spec :)
[15:05] <chrisccoulson> mostly gconf, but some dk-power too
[15:06] <kenvandine> seb128, i did see a merge proposal from bratsche for xsplash that pre-calculates the animation
[15:06] <kenvandine> last night
[15:06] <seb128> chrisccoulson: please add DONE on the whiteboard line then
[15:07] <seb128> kenvandine, oh nice, I need to try that
[15:07] <kenvandine> seb128,  https://code.launchpad.net/~bratsche/xsplash/precompute-throbber/+merge/15564
[15:08] <kenvandine> seb128, i bet he would love to see how it compares
[15:09] <bratsche> kenvandine, seb128: Yeah, I'm not sure how much that will help but it seemed worth a try.
[15:09] <kenvandine> hey bratsche!
[15:09] <bratsche> yo
[15:19] <seb128> bratsche, I will try and let you know how it goes
[15:26] <tedg> When I log in with a guest account and look at the CPU time taken by all indicators not a single one even registers:  ps -e -o user,time,cmd | grep /usr/lib/indicator | grep ^guest
[15:30] <seb128> tedg, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091203-1.png
[15:30] <seb128> tedg, look at the bottom for the chart
[15:30] <seb128> indicator-applet
[15:30] <tedg> seb128: It's async -- that doesn't mean that it's actually using that much time, it just uses time when it gets it.
[15:30] <seb128> it has almost full cpu use for 1.8 seconds
[15:31] <seb128> tedg, we are cpu bounded on this config
[15:31] <seb128> it's using cpu we need
[15:31] <tedg> seb128: But a line doesn't mean anything in boot chart.  That's not precise enough to prove anything useful.
[15:32] <seb128> what do you mean a line?
[15:32] <tedg> A blue line.
[15:32] <seb128> it means cpu activity
[15:33] <tedg> It means *some* CPU activity -- not CPU activity for the entire time.
[15:33] <tedg> If it ran one instruction in that watch time it'd show up as a line in bootchart.
[15:33] <seb128> well it's the only process doing a zillion line around
[15:34] <seb128> tedg, well, worded differently I just removed it and did a new chart
[15:34] <seb128> we win 0.8 seconds on boot without the applet
[15:35] <seb128> doing an another one now to see if the difference is constant
[15:35] <seb128> but I usually get 0.1 to 0.3 seconds variations
[15:36] <tedg> I'm not saying we're perfect, and that we can't be better, but I don't think we're using 1.5s of CPU time.
[15:36] <seb128> tedg, right, 0.9 seconds on this one
[15:36] <kenvandine> seb128, on my laptop i see far less cpu for the indicator but i see IO
[15:36] <seb128> well maybe not
[15:36] <seb128> but you cost 0.8 to 0.9 seconds on our 4 seconds budget
[15:36] <seb128> confirmed by several boots on the reference box now
[15:37] <seb128> I've no good explanation of *why*
[15:37] <tedg> Are we the only Bonobo based applet in the default config?
[15:37] <seb128> but that's what measures say
[15:37] <seb128> no
[15:37] <seb128> trash costs 0.3 seconds
[15:37] <seb128> for reference
[15:37] <tedg> So I'll blame Bonobo for 0.3 of our 0.8 ;)
[15:37] <seb128> fair enough
[15:38] <seb128> I'm wanting at least half of the 0.6 remaining back
[15:38] <seb128> or 0.5 remaining
[15:38] <seb128> you are the longer applet after the menus by far
[15:38] <seb128> 0.2 to 0.3 seconds is the cost for almost all the other ones
[15:38] <seb128> which I think it's basically bonobo ping pong + init
[15:39] <tedg> Okay, we'll look into it.  Right now, I'm not sure where it's going -- so it's hard to say where I'll get it back :)
[15:39] <seb128> is there any other data I can provide you?
[15:40] <seb128> the session is a stock one
[15:40] <tedg> I don't think so right now.  We'll get some logging in and setup, then I'll want those logs :)
[15:40] <seb128> ok
[15:40] <seb128> let me know when you need something there
[15:40] <seb128> I've the box used only for testing and I reboot it a lot ;-)
[15:41] <seb128> urg
[15:41] <seb128> pitti, you screwed menus ;-)
[15:41] <pitti> ?
[15:41] <seb128> pitti, I'm not preferences or admins menus
[15:42] <seb128> only the software-center in admin in fact
[15:42] <pitti> argh
[15:42] <seb128> and it's not at the bottom of applications anymore
[15:42]  * pitti sighs
[15:42] <seb128> I'm -> I've
[15:42] <seb128> do you get the issue too?
[15:42] <pitti> sorry
[15:42] <pitti> yes, seems I do
[15:43] <seb128> ok good
[15:43] <seb128> I'm not alone at least ;-)
[15:51] <pitti> seb128: seems to be my "break it" day; this morning my mailbox and IRC freaked out because I broke udev..
[15:55]  * seb128 hugs pitti, don't worry only those who do nothing break nothing
[15:56] <pitti> tseliot, rickspencer3: our call is on Rick's conf line?
[15:56] <rickspencer3> pitti, good idea
[15:56] <tseliot> I was about to ask the same question
[16:01] <pitti> I'm in, waiting
[16:01] <tseliot> me too
[16:01] <rickspencer3> jeez, I'm only 1 minute late
[16:08] <rickspencer3> tseliot, https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers
[16:20] <bryce> heya
[16:21] <rickspencer3> hi bryce
[16:22] <bryce> rickspencer3, sorry I thought the call was 8:30 not 8:00... still want me to call in?
[16:22] <rickspencer3> bryce, we just got off
[16:22] <rickspencer3> I'll send you your list of action items
[16:22] <bryce> ok
[16:22] <rickspencer3> bryce, we have you signed up to own pulse audio for lucid now

[16:23] <bryce> teasing the X guy before he's had coffee, eh?
[16:23] <bryce> brave brave man
[16:23] <tseliot> hehe
[16:23] <pitti> argh argh
[16:23] <pitti> *pitti has quit (X server segfault)
[16:23] <seb128> pitti, what else did you break?
[16:23] <seb128> oh, only xorg
[16:23] <bryce> pitti, o_O
[16:23] <pitti> j/k
[16:24] <seb128> ;-)
[16:24] <pitti> seb128: my current breakage is the WI tracker, again
[16:24] <pitti> that, then menus
[16:24] <pitti> seems like a whack-a-bug day today :/
[16:24] <seb128> I would argue that menus are higher importance than some tracker ;-)
[16:24]  * seb128 runs away from rickspencer3
[16:25] <pitti> yay, my launchpadlib branch was merged
[16:48] <jcastro> seb128, I noticed gwibber isn't on the app indicator list, is that on purpose or an oversight?
[16:49] <hugolp> hi, I am trying to use empathy for 9.10 from the launchpad ppa but there is some incompatibility with the packages
[16:49] <seb128> jcastro, where did you get your gwibber from? I guess it's a kenvandine question
[16:49] <seb128> jcastro, it's up to the software to ship the launcher
[16:49] <hugolp> in order to install empathy-common wich is needed for empathy is asking me to desinstall ubuntu-desktop
[16:49] <jcastro> seb128, no I mean on the list of apps to port to the app indicator
[16:49] <jcastro> it works fine in real life.
[16:49] <seb128> hugolp, known issue, kenvandine said he would look at it
[16:49] <mpt> mvo, glatzor: If someone inserts a CD containing .deb packages, how can you tell whether it's a CD for a previous Ubuntu version, the current version, a future version, or another Debian-based OS entirely?
[16:50] <seb128> jcastro, oh ok, I though you said it was not in the message indicator launchers
[16:50] <hugolp> seb128: ok
[16:50] <seb128> jcastro, it's probably an oversight
[16:50] <jcastro> ok I will add it
[16:50] <kenvandine> jcastro, why would it be on the list?
[16:50] <seb128> it has a notification area icon?
[16:50] <kenvandine> it already uses the indicator
[16:50] <mvo> mpt: there is a .diskinfo/ dir for official ones, but we do not really have great standards for addon cds
[16:50] <kenvandine> optional
[16:51] <mvo> mpt: the closest was/is the g-a-i addon cd
[16:51] <jcastro> yeah but it's going into main right?
[16:51] <kenvandine> yes
[16:51] <seb128> well don't we want to patch that optional codepath?
[16:51] <mvo> mpt: but that should be fomalized and it also will not work with s-c anymore because the way the meta-data is handled changed
[16:51] <jcastro> kenvandine, I am talking about the thing ted is working on
[16:51] <kenvandine> seb128, true
[16:51] <seb128> what if there is no message indicator applet installed
[16:51] <kenvandine> jcastro, add it :)
[16:51] <jcastro> everything that uses the tray will need to be ported
[16:51] <kenvandine> just so if people try to enable it, it will do the right thing :)
[16:52] <mpt> mvo, what is "the g-a-i addon cd"?
[16:52] <seb128> jcastro, I think kenvandine's was arguing that it doesn't use the tray since it uses the messaging indicator
[16:52] <mvo> mpt: it sounds to me like we want a) addon and b) new releases, but they look like two different use cases
[16:52] <kenvandine> seb128, yeah... by default it shouldn't use it
[16:52] <kenvandine> but you can turn that on
[16:52] <jcastro> seb128, I'll add it to the list so when we get there we at least look at it
[16:52]  * jcastro will play it safe
[16:52] <kenvandine> so if you do i guess we want to change the behavior a bit
[16:53] <seb128> jcastro, right
[16:53] <seb128> we need 3 cases now
[16:53] <mpt> mvo, proper handling of the CD is a v3/v4 thing. Right now I'm just concerned with giving the CD item a sensible label in the navigation pane.
[16:53] <seb128> using message indicator, or application indicator or notification area
[16:56] <mvo> mpt: have you looked at how software-properties does it? is that representation good enough? the .diskinfo stuff is pretty much what we currently have
[16:57] <mpt> mvo, unfortunately I'm not in the office and don't have any CDs handy :-)
[16:59] <mvo> cat /cdrom/.disk/info
[16:59] <mvo> Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.1)
[17:02] <seb128> pitti, bug #491937 is yours
[17:02] <seb128> pitti, I've assigned it to you I hope it's ok
[17:02] <pitti> seb128: thanks! sure it is
[17:09] <glatzor> mvo, I am now nearly done with the API review of aptdaemon
[17:10] <glatzor> mvo, So I make a stable fork of the branch lp:aptdaemon/0.1.x
[17:10] <mvo> glatzor: great!
[17:10] <mvo> glatzor: btw, see #packagekit, apparently some string matiching is not ideal
[17:11] <pitti> bryce: please use "bryceharrington" for WI assignees (your LP name)
[17:12] <bryce> pitti, bleah
[17:13] <chrisccoulson> awesome, it's nearly friday already :)
[17:13] <seb128> chrisccoulson: ;-)
[17:15] <chrisccoulson> 2.5 day weeks are great :)
[17:15] <chrisccoulson> especially when 2 of those are spent on a course
[17:18] <ccheney> ugh i think evolution just ate an email i tried to send :(
[17:18] <ccheney> hmm no, just sticking it in the wrong folder, very odd
[17:25] <mpt> mvo, perfect, thanks
[17:25] <seb128> chrisccoulson: hehe
[17:34] <chrisccoulson> seb128 - i just did some more gconf tests here. you're right, the per-user tree isn't taking a lot of time - it is reading /var/lib/gconf/defaults/%gconf-tree.xml which takes all that time
[17:35] <chrisccoulson> it's 2.6MB :-/
[17:36] <pitti> rickspencer3: check this out: http://piware.de/workitems/desktop/lucid-alpha2/report.html
[17:36] <pitti> rickspencer3: (scroll down)
[17:36] <pitti> courtesy by cjwatson
[17:49] <pitti> chrisccoulson: does it call gettext on any of those?
[17:49] <pitti> chrisccoulson: i. e. when you strace it, any mo files involved?
[17:49] <pitti> it shouldn't ideally
[17:49] <chrisccoulson> pitti - it doesn't look like it
[17:50] <chrisccoulson> it just needs to read the whole file to build the tree
[17:50] <pitti> AFAIR, when I wrote those bits, gettext() should only be called on demand
[17:50] <pitti> ok
[17:50] <pitti> that sucks
[17:50] <chrisccoulson> it does :(
[17:51] <chrisccoulson> i'm not going to give up just yet though
[17:51] <pitti> it also means that it keeps the stuff in memory, all the time, "just in cas"
[17:51] <pitti> e
[17:51] <pitti> but as seb128 says, gconf's days are counted anyway
[17:52] <chrisccoulson> yeah, but we've still got to put up with it for one more cycle
[17:52] <chrisccoulson> and it's currently quite a time waster
[17:52] <pitti> *nod*
[17:52] <chrisccoulson> anyway, dinner time for me now :)
[17:52] <pitti> likewise :)
[17:53] <pitti> is it important to be XML?
[17:53] <pitti> could it be any faster with a simple two-column text file?
[17:54] <kenvandine> pitti, cool... work items included in the report, awesome!
[17:54] <pitti> chrisccoulson: also, where does this file actually store the default values?
[17:54] <pitti> kenvandine: thanks to cjwatson :)
[17:54] <pitti>                                 <dir name="crop">
[17:54] <pitti>                                         <entry name="aspect_ratio_height" mtime="1257778535" schema="/schemas/apps/gthumb/dialogs/crop/aspect_ratio_height"/>
[17:54] <pitti> is it just me, or is ther just about zero information here?
[17:55] <pitti> chrisccoulson: it might be worth investigating what happens if all the entries which don't have a <default>/<*value> tag will just get dropped
[17:55] <pitti> seb128: ^ could that work?
[17:56] <pitti> the first value is 8% into the file
[17:57] <pitti> chrisccoulson: good catch anyway!
[17:59] <kenvandine> parsing xml is slow :/
[18:02] <seb128> pitti, not sure if gconf needs a mapping of existant keys or not
[18:02] <seb128> would be worth playing with in any case
[19:39] <mpt> glatzor or mvo: I just added a third-party repository and the "Comment" field in Software Sources was populated automatically. Where does that text come from in the repository?
[19:40] <mpt> Is that from /.disk/info too?
[19:44] <mpt> or is it from the Release file?
[19:47] <mpt> hm, looks like Release file Label is what I want
[20:13] <pitti> rickspencer3_, didrocks: any chance to finish drafting of  desktop-lucid-quickly{,-templates} soon (deadline is today)? at least add WIs?
[20:14] <rickspencer3_> pitti, SURE
[20:14] <rickspencer3_> sorry, I can get to it maybe tomorrow or this weekend
[20:14] <pitti> the WIs are probably a bit more urgent
[20:37] <mvo> pitti: hi, is the update-gnome-menus-cache your new work?
[20:37] <pitti> mvo: I know, I know, it's broken; looking at it now ;)
[20:37] <pitti> mvo: yes, from today
[20:37] <mvo> pitti: it seems to be crashing during hardy->lucid because gmenu can not be imported (the old pysupport thing)
[20:38] <pitti> oh noes
[20:38] <pitti> mvo: curious, though; does it actually fail the package?
[20:38] <mvo> well, just add a try: except: and a trigger, that should be fine
[20:38] <pitti>         update-gnome-menus-cache /usr/share/applications > "$cache.dpkg-new" || rm -f "$cache.dpkg-new"
[20:38] <mvo> no, ist just a crash file
[20:38] <pitti> ah
[20:38] <pitti> because for reasons like that I wrote it like above
[20:38] <mvo> but the upgrader-tester is picky about crash files generated during the upgrades
[20:39] <pitti> if it ever fails, it removes the cache to not leave inconsistent data around
[20:39] <pitti> and not fail the package postinst
[20:39] <mvo> right, its not breaking aanything, its just crashing :)
[20:39] <mvo> (which is great btw)
[20:39] <pitti> mvo: what's the particular exception?
[20:39] <pitti> mvo: just an ImportError?
[20:40] <pitti> mvo: I don't generally like hiding those, but for  this kind of script a mere stderr message is fine
[20:40] <mvo> yes, just that
[20:40] <mvo> I can give you the crash file, but its really just a import error for gmenu
[20:41] <pitti> nevermind
[20:41] <pitti> mvo: btw
[20:41] <pitti> mvo: it's AWESOME that you discover stuff like that only a few hours after it's introduced
[20:42]  * pitti hugs mvo
[20:42] <pitti> mvo: fixed in http://bazaar.launchpad.net/~ubuntu-desktop/gnome-menus/ubuntu/revision/28
[20:42] <mvo> thanks pitti!
[20:43]  * mvo hugs pitti
[20:43]  * pitti goes back to fixing the thing to not mess up your menus
[20:44] <pitti> Riddell: is bug 484802  already fixed in lucid by chance?
[20:47] <pitti> mvo: btw, we support dapper->lucid upgrades?
[20:47] <pitti> mvo: I'm afraid me and other people have dropped a *lot* of upgrade quirks from edgy/feisty/gutsy/hardy
[20:48] <pitti> so far I assumed that we only support dapper->hardy->lucid
[20:48] <seb128> oh, same here
[20:48] <pitti> mvo: oh, nevermind; you said hardy->lucid
[20:48] <seb128> I cleaned all the pre-hardy hacks...
[20:49] <pitti> where the heck did I read "dapper"?
[20:49] <Tm_T> pitti: from your box running dapper?
[20:49] <pitti> the only thing I have left from dapper is a chroot..
[20:49] <mvo> yeah, no dapper->lucid, that would be ... woah
[20:50] <pitti> *phew* :)
[20:50] <mvo> the only thing I have left is memories :)
[20:50] <pitti> "dragon! duck! dragon! duck! STFU!"
[20:50]  * mvo is not entirely correct, he got a test-kvm machine that one day should test dapper->hardy->lucid
[20:51] <pitti> "my other computer is a 3 GB image file" :)
[20:51]  * pitti hugs kvm
[20:51] <mvo> heh :)
[20:53] <didrocks> pitti, rickspencer3_ : trying to finish WI (I only have a local draft) on Quickly for tomorrow afternoon (very busy week). I'll ping you for ack when it's done. Sorry for the delay
[20:53] <pitti> didrocks: no problem at all, was just a gentle reminder :)
[20:53] <pitti> sorry if I act like you were already employed
[20:54] <didrocks> pitti: no pb, reminding is always good (even if gtg has all those for me ;))
[20:55] <chrisccoulson> pitti - the XML file is parsed in 4k blocks at the moment
[20:55] <chrisccoulson> do you think that is optimal for a SSD?
[20:55] <chrisccoulson> (i honestly don't know)
[20:55] <pitti> chrisccoulson: it shouldn't matter really
[20:55] <pitti> ureadahead does all of that
[20:55] <chrisccoulson> yeah, i wasn't sure really
[20:55] <pitti> it's the CPU processing that hurts
[20:56] <pitti> chrisccoulson: it looks like we could cut this file at least by half by throwing out all the noise
[20:56] <pitti> needs to be tested, of course
[20:56] <pitti> but if that file doesn't provide any default, then it shold be possible to just omit it entirely
[20:57] <pitti> we need to check that it still looks sensible in gconf-editor, though
[20:57] <pitti> that might need the full thing
[20:57] <chrisccoulson> pitti - removing all the formatting might help a bit
[20:57] <chrisccoulson> it's full of tabs and white space
[20:57] <pitti> chrisccoulson: I actually meant removing all the keys withoout a default/value
[20:57] <pitti> I don't think that the tabs/white space matter a lot
[20:58] <pitti> but it has to parse this thing into a huge internal treee
[21:02] <chrisccoulson> pitti - did you find keys that don't have a default value?
[21:04] <chrisccoulson> do those keys not reference the schema (which has the default value)?
[21:05] <pitti> chrisccoulson: most just reference a schema
[21:05] <pitti> but when I look at this:
[21:05] <pitti>         <dir name="apps">
[21:05] <pitti>                 <dir name="gthumb">
[21:05] <pitti>                         <dir name="dialogs">
[21:05] <pitti>                                 <dir name="crop">
[21:05] <pitti>                                         <entry name="aspect_ratio_height" mtime="1257778535" schema="/schemas/apps/gthumb/dialogs/crop/aspect_ratio_height"/>
[21:06] <pitti> wouldn't it be prudent to assume that the schema for a key a/b/c/name is /schemas/a/b/c/name ?
[21:06] <chrisccoulson> quite possibly
[21:07] <pitti> many keys there actually have a default value, description, etc.
[21:08] <pitti> ArneGoetje: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-font-selection mentions "ian-farrel", but I can't find a person with this name on LP; it's not a valid LP name
[21:12] <bryce> pitti, heya quick question
[21:13] <bryce> pitti, we've got a bunch of X packages needing sync'd before we can pull in xserver 1.7
[21:13] <bryce> pitti, see http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
[21:13] <pitti> oooh
[21:13] <pitti> bryce: want me to sync them now?
[21:13] <bryce> pitti, eventually these would get pulled in automatically via debian testing, but if we're going to make 1.7 by a1 we kinda need them sync'd soonish
[21:13] <bryce> please, that would totally rock
[21:13] <pitti> by all means
[21:15] <pitti> bryce: ah, you actually filed bugs?
[21:15] <bryce> pitti, yes
[21:15] <bryce> (isn't that the normal process?)
[21:16] <bryce> pitti, note that some of the syncs are from unstable, some are from experimental
[21:16] <pitti> bryce: it is, don't worry
[21:20] <rickspencer3_> pitti, seb128 ...
[21:20] <pitti> ok, here then
[21:20] <rickspencer3_> so sabdfl was totally adamant that our plan about removing the bottom panel and trash applet and show desktop ...
[21:21] <pitti> rickspencer3_: OOI, what about metacity?
[21:21] <rickspencer3_> was not something that we could do
[21:21] <rickspencer3_> he was quiet on that, so I think we're okay for now
[21:22] <rickspencer3_> but the panel changes, I would ask that we pull those back if possible
[21:22] <seb128> hum
[21:22] <seb128> we will never reach that target if we have no flexibility...
[21:22] <seb128> but alright
[21:22] <rickspencer3_> we just need to talk about it more
[21:22] <seb128> with who?
[21:22] <seb128> we had team consensus during the meeting
[21:23] <rickspencer3_> right, but not sabdfl
[21:23] <rickspencer3_> he was quite adamant
[21:23] <seb128> to a specific point?
[21:23] <rickspencer3_> he rarely is directive with me, so when he is, I feel that we owe him the courtesy of following his wishes
[21:23] <pitti> well, can't have the cake and eat it too..
[21:23] <rickspencer3_> according to my notes ..
[21:24] <rickspencer3_> removing the bottom panel, the trash, and "show desktop
[21:24] <rickspencer3_> we need to have replacements for these before we can propose removing them
[21:24] <pitti> but well, he's right by definition, so let's revert it tomorrow
[21:24] <pitti> I'd still like to see a bootchart of this, to see how much it gains us
[21:24] <seb128> :-(
[21:24] <rickspencer3_> or get his buy in first
[21:24] <seb128> how do we go to get his buy?
[21:24] <rickspencer3_> seb128, he is right to challenge us on this
[21:24] <pitti> we can remove the two starters?
[21:24] <seb128> where is the best discussion medium for that?
[21:24] <rickspencer3_> pitti, yes
[21:24] <rickspencer3_> seb128, I'm not sure, let me think about it
[21:24] <seb128> ok
[21:25] <seb128> do we want to let it for the night just to get quick feedback and measure boot impact?
[21:25] <rickspencer3_> I need to have some lunch, you guys are working too late
[21:25] <seb128> or should we revert right now?
[21:26] <rickspencer3_> seb128, please revert now, then we'll put together a profiling plan tomorrow or Monday
[21:26] <seb128> I'm just back from sport and dinner don't worry
[21:26] <seb128> enjoy your lunch
[21:26] <rickspencer3_> okay
[21:26] <seb128> ok :-(
[21:26] <rickspencer3_> seb128, don't be bummed, we'll figure it out
[21:26] <seb128> (slightly annoyed to have waste efforts on that when I don't finish to do what I want to do)
[21:26] <rickspencer3_> it's just a small challenge to us, we've faced much worse before
[21:26] <rickspencer3_> sorry seb128 :(
[21:26] <seb128> rickspencer3_, don't worry that's my problem, I'm just a bit grumpy to have spent time for nothing
[21:27] <rickspencer3_> well, look at it that you will reuse the work
[21:27] <seb128> rickspencer3_, not yout fault
[21:27] <rickspencer3_> we just have to figure out how to do it right
[21:27] <rickspencer3_> "right" means doesn't freak out key stake holders
[21:27] <seb128> I will let you deal with that
[21:28] <seb128> I think we followed standard open procedure on this one
[21:28] <seb128> discussion in public meeting, summary sent on lists, etc
[21:28] <seb128> but right
[21:28] <seb128> let's undo for now and figure that later
[21:28] <rickspencer3_> seb128, thank you
[21:28] <pitti> seb128: you can keep the starters dropped at least..
[21:28] <seb128> it's not making a significant speed difference anyway
[21:28] <rickspencer3_> oh?
[21:28] <seb128> pitti, right now I prefer to just undo the upload that spend extra time to get that wrong
[21:29] <rickspencer3_> seb128, are you saying that the changes don't seem to have much impact?
[21:29] <pitti> seb128: agreed
[21:29] <seb128> rickspencer3_, well, ie 0.5seconds
[21:29] <rickspencer3_> bummer
[21:29] <seb128> but we need to add those 0.5s to reach target
[21:29] <rickspencer3_> of course 20 .5 second changes = 10 seconds
[21:29] <seb128> exactly
[21:29] <rickspencer3_> okay, let's not give up on this, just view it as something we need to think about a bit more
[21:29] <seb128> ok
[21:29]  * Amaranth waves
[21:29] <rickspencer3_> hi Amaranth :)
[21:30] <seb128> if you can get specific concerns
[21:30] <rickspencer3_> seb128, yeah, I do
[21:30] <seb128> dropping the trash applet is the best win there
[21:30] <seb128> it avoids doing trash backend init etc
[21:30] <rickspencer3_> hmmm
[21:30] <rickspencer3_> okay, let's think about how to make the applet load faster
[21:30] <rickspencer3_> like can it do the init on first use?
[21:30]  * rickspencer3_ really has to leave
[21:30] <rickspencer3_> thanks seb128
[21:30] <seb128> not if you want to display correct full or empty icon
[21:30] <rickspencer3_> you are truly the bestest
[21:31] <seb128> rickspencer3_, enjoy lunch!
[21:31]  * kenvandine hugs seb128
[21:31] <seb128> see you tomorrow!
[21:31]  * seb128 hugs kenvandine too
[21:31] <seb128> rickspencer3_, you rock too, thanks ;-)
[21:31]  * rickspencer3_ notes that we could cache the correct icon at shutdown
[21:31] <rickspencer3_> by the way, before I go ...
[21:31] <seb128> rickspencer3_, let's talk about that later
[21:31] <rickspencer3_> the review went very very well
[21:31] <seb128> cool
[21:31] <seb128> you will tell me tomorrow
[21:32] <rickspencer3_> bye bye
[21:32] <seb128> see you
[21:37] <Amaranth> so my boot times have suddenly gotten very impressive
[21:37] <Amaranth> I think it's because my max IO is now 94MB/s
[21:38] <geser> what did you have to do to get it?
[21:38] <Amaranth> buy a new HD :)
[21:39] <seb128> Amaranth, nice ;-)
[21:42] <Amaranth> now I just need to figure out how to get KMS turned off again...
[21:42] <seb128> why?
[21:43] <Amaranth> no brightness control
[21:43] <pitti> i915.modeset=0
[21:43] <Amaranth> in grub?
[21:44] <Amaranth> I was trying i915 modeset=0 in initramfs-tools modules file
[21:45] <pitti> hm, I'd just set it in grub
[21:52] <Riddell> pitti: bug 484802 is fixed in lucid yes
[21:52] <Riddell> I've updatd the bug status
[21:52] <pitti> Riddell: great, thank you!
[21:59] <seb128> hey rob
[21:59] <seb128> hey robert_ancell
[21:59] <robert_ancell> seb128, hey
[21:59] <pitti> bryce: I synced most of them now; LP goes down in 2 mins, so I need to do the rest tomorrow morning
[21:59] <pitti> hey robert_ancell
[21:59] <seb128> robert_ancell, the gnome-games rename upstream don't seem a really good idea...
[22:00] <pitti> bryce: btw, the fastest way for archive admins is an IRC ping "please sync from experimental: foo bar baz  (no commas, etc.)
[22:00] <robert_ancell> ?
[22:00] <robert_ancell> seb128, you mean debian doesn't like the package split?
[22:00] <bryce> pitti, ok thanks
[22:00] <Amaranth> hmm, if I split compiz-plugins into individual plugin packages each one needs to Provides/Replaces the last uploaded compiz-plugins package, right?
[22:01] <seb128> robert_ancell, no, I just noticed your commit about gnometris being renamed to an unclear name
[22:01] <Amaranth> crap I'll have to wait until launchpad comes back to do a compiz upload to remove plugins-extra
[22:01] <seb128> robert_ancell, it's a shame to have a tetris game without tetris in the name ;-)
[22:02] <seb128> Amaranth, yes
[22:02] <seb128> Amaranth, yes
[22:02] <Amaranth> alright
[22:02] <seb128> Amaranth, how do you want to split those now?
[22:02] <robert_ancell> seb128, oh the quadrapassel and fell-swoop names?  I think they're awful too
[22:02] <seb128> robert_ancell, right
[22:02] <kenvandine> what was it renamed too?
[22:02] <seb128> who decided on that?
[22:02] <Amaranth> so I'm thinking after splitting compiz-plugins and compiz-fusion-plugins-main I'll make the compiz source package generate a compiz-plugins metapackage that depends on the ones we want installed by default
[22:03] <kenvandine> sad it can't just be named tetris :/
[22:03] <robert_ancell> I'm not sure who decided on them
[22:03] <Amaranth> and each plugin will depend on the plugins it needs (based on checking depends in the xml files)
[22:03] <robert_ancell> kenvandine, gnometris->quadrapassel same-gnome->swell-foop
[22:03] <Amaranth> after that I get to start figuring out how to stop using the XML files completely
[22:03] <kenvandine> that sucks :/
[22:04] <Amaranth> and I really wish I could statically link some plugins into the compiz binary but I dunno if that'd actually help
[22:05] <kenvandine> seb128, i had prepared the gtk upload based on what was in bzr... then realized 2.19.1 was uploaded to lucid and not merged into bzr :/
[22:05] <kenvandine> seb128, so i did that and pushed the branch (without my patches)
[22:05] <kenvandine> and now prepared it against 2.19.1
[22:05] <seb128> ok
[22:05] <kenvandine> doing a test build now, assuming my laptop doesn't overheat again
[22:05] <seb128> kenvandine, that's because 2.19 is a direct sync from Debian
[22:06] <kenvandine> yeah
[22:06] <kenvandine> i should have checked :/
[22:06] <pitti> seb128: ok, I fixed the capplets/admin menu
[22:06] <pitti> seb128: the only thing that's left broken is app-center
[22:06] <seb128> pitti, you rock
[22:06] <pitti> it's still in the admin menu
[22:06] <pitti> seems I need to figure out the magic that makes it appear in the Apps menu in the first place..
[22:07] <seb128> pitti, look at the bottom of applications.menu
[22:08] <seb128> pitti, in /etc/xdg/menus
[22:08] <pitti> right, I saw that
[22:08] <pitti> I mean code-wise, and how the caching breaks it
[22:08] <seb128> ok
[22:08] <pitti> seb128: don't worry, I'll figure it out
[22:08] <Amaranth> oh goody, someone else gets to experience the joys of the xdg menu spec
[22:09] <pitti> bryce: ok, it's still alive, synced all bug bug 491051
[22:09] <pitti> s/bug bug/but bug/
[22:09] <pitti> ah, that's another one which says "unstable" and means "experimental"
[22:10]  * pitti syncs
[22:11] <bryce> ah
[22:11] <pitti> yay, all in
[22:11]  * pitti watches the buildds squeak, crank, and sweat
[22:13] <bryce> pitti, were all of the experimental syncs mis-titled?
[22:13] <pitti> bryce: no, just 4
[22:14] <bryce> hrm weird
[22:14] <bryce> since I used a script to do it, I would have expected them all to be right, or all wrong
[22:14] <pitti> oh, https://edge.launchpad.net/builders is full of "building private source" which might explain the delay in shutting down LP :)
[22:15] <pitti> bryce: the changelog in teh description said "experimental", bug the bug title said "unstable"
[22:15] <pitti> (see #491051)
[22:16] <pitti> oh, hmm
[22:16] <pitti> bryce: I now actually synced x11proto-input 2.0-1
[22:16] <pitti> while the title said "1.5.0-2"
[22:16] <bryce> 2.0-1 is more correct
[22:16] <pitti> okay, *phew*
[22:16] <pitti> the description says 2.0, too
[22:16] <pitti> bryce: btw, does that mean "xinput 2 protocol"?
[22:17] <bryce> we already have 1.5.0-2
[22:17] <bryce> pitti, that's correct
[22:17] <pitti> right, that's why the unstable sync failed
[22:17] <bryce> pitti, XI2 is the major new feature that xserver 1.7 brings
[22:17] <pitti> bryce: does that further mean that we can now use key codes >= 256?
[22:17] <bryce> ah, not sure on that point
[22:18] <bryce> the 256 limit is due to a X11 protocol limitation IIRC
[22:18] <pitti> like KEY_ZOOM, KEY_NEXT, KEY_ADDRESSBOOK, and the like
[22:18] <pitti> right, ISTR that xi2 was to rectify that
[22:18] <bryce> not sure if XI2 provides a way around that limitation.  maybe...
[22:18] <bryce> I"ll ask
[22:19] <pitti> we'll see
[22:19] <pitti> don't worry for now
[22:19]  * pitti was just curious
[22:19] <Amaranth> I'm pretty sure it does
[22:19] <tjaalton> I think it would need XKB2 too
[22:19] <Amaranth> keycodes are 32 bit in XI2
[22:19] <tjaalton> right
[22:20] <Amaranth> yeah, you'd need xkb2 so it knew how to deal with it
[22:20] <pitti> http://bugs.freedesktop.org/show_bug.cgi?id=11227#c26
[22:20] <pitti> tjaalton: the bug mentions that, yes
[22:22] <tjaalton> pitti: yep, I've read that bug a couple of times :)
[22:28]  * pitti tries something new and goes to bed before midnight
[22:28] <pitti> good night everyone!
[22:28] <seb128> 'night pitti
[22:28]  * seb128 tries something new and work on friday this week ;-)
[22:31] <seb128> robert_ancell, btw I think you asked about introspection the other day, I've sorted most of it today I think
[22:37] <robert_ancell> seb128, so gnome-games now installs?
[22:38] <seb128> robert_ancell, not yet, things are still building
[22:48] <Amaranth> does gobject-introspection still pull in most of a GNOME build environment?
[23:05] <rickspencer3> robert_ancell, good morning
[23:07] <robert_ancell> rickspencer3, hey
[23:08]  * rickspencer3 is reading back scroll
[23:09] <rickspencer3> lots happened in the 1.5 hours I was gone@
[23:09] <rickspencer3> robert_ancell, we were supposed to have a call but I blew you off :(
[23:09] <robert_ancell> rickspencer3, np
[23:10] <rickspencer3> call now?
[23:10] <robert_ancell> sure
[23:59] <rickspencer3> pitti, added workitems to quickly blueprints