=== robbiew is now known as robbiew-afk === asac_ is now known as asac === bjf is now known as bjf-afk [08:34] hello there [08:35] salut seb128 [08:36] good morning [08:38] hey bryce! hm, that's only a list of articles? anything particularly interesting? [08:38] seb128: thanks for running the benchmarks yesterday; so it was a 0.5 second savings for desktop part, or total? [08:38] both [08:38] seb128: (I had hoped for some nontrivial savings in the readahead part, too) [08:38] ok, thanks [08:38] it doesn't win anything obvious out of desktop I think [08:38] :-( [08:39] well I didn't look into details to the non desktop numbers [08:39] let me look at those again now [08:41] pitti, it's not easy to say numbers change a bit between boots [08:42] seb128: ok, no prob; if it's not really visible, it doesn't buy much then [08:42] it seems around 0.2 seconds win for boot and 0.5 seconds for login [08:42] well, I'm 80% there with it anyway, and it helps more on rotary, so I think I'll finish it anyway [08:42] well we need those 0.5 seconds anyway [08:42] good morning everyone [08:42] hey chrisccoulson [08:43] with gvariant we can hopefully make it a bit faster, too [08:43] hey chrisccoulson [08:43] pitti, what do you think about commenting out xsplash? [08:43] hey seb128, how are you? [08:43] hey pitti [08:43] pitti, it takes between .5 and 1 second [08:43] seb128: for testing, would be interesting; I hope we can make it much less CPU intense by changing the animation? [08:43] hey chrisccoulson [08:44] pitti, not, for reaching target, rickspencer suggested being aggressive until getting there and they adding things back [08:44] yay, David applied my last dk-disks patch [08:44] I would like to drop it now and say we don't re-add it until it's reasonable cpu wise [08:44] seb128: sounds fine [08:44] ok thanks [08:45] pitti, robert_ancell signed for looking at gnome-panel speed btw [08:45] just fyi so you guys don't dup work there [08:46] \o/ [08:46] 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] seb128: I just wanted to do the app menu caching; not dropping applets, etc. [08:46] but i didn't get it to work before i went to bed ;) [08:47] s/tired/tried [08:47] chrisccoulson, wouldn't it be simpler to have a cat of those in some xsession script or something? [08:48] chrisccoulson, if the goal is to cache infos [08:48] at least for testing [08:48] pitti, ok, good [08:48] shouldn't readahead already pick those up? [08:48] cat'ing seems unnecessary [08:48] 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] so i thought that gconfd could do that early rather than waiting for an application to ask for a value [08:49] good idea [08:50] 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] so that when the panel loads, the gconf database will already be ready [08:51] i don't really know if it will work out yet though [08:51] does it help in any way to use a merged tree? [08:52] pitti - it probably would help a lot [08:52] we do that by default no? [08:52] is it easy to do that? (i'm still learning how gconf works) [08:53] 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] right [08:53] but the user config is empty for our target [08:53] since the boot measure is on a stock install [08:54] are the defaults stored in a merged tree? [08:54] I would not bother optimizing this case [08:54] yes [08:54] only the user config are not [08:54] the reason being nfs locking issues [08:54] ah, ok [08:55] it still takes 500ms on the stock install though, even with the merged tree [08:55] but it seems that will get worse with the per-user config too [08:55] right [08:55] while I appreciate that I think we should not spend too much time on things that will be replaced next time [09:03] seb128: right, I just wondered, since switching to merged tree is a single change [09:03] but right, if we have an empty user tree, it shouldn't matter [11:24] Verarbeite Trigger für python-gmenu ... [11:24] Rebuilding /usr/share/applications/desktop.de_DE.UTF-8.cache... [11:24] * pitti hugs dpkg triggers [11:27] * seb128 hugs pitti [11:28] 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] and cache is now handled automatically [11:28] * pitti uploads, let the bugs come all over me! [11:30] so the plan is now to drop those applets and disable xsplash for now, and see where we are? [11:35] pitti, yes, I did the gdm change some minutes ago [11:36] \o/ [11:36] I will do the gnome-panel one this afternoon [11:36] you rock [11:36] thanks, you too! [11:36] once we have those I will do an official mark [11:37] then try again with gnome-session modified to start things together [11:37] just to see how that performs now [11:37] I will also do the compiz change to not depends on extra if Amaranth doesn't upload today [11:37] that wins another 0.5 second === MacSlow is now known as MacSlow|lunch [12:43] 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] mvo: my memory is like an empty rock, so if I did have that problem I've apparently completely forgotten about it ;) [12:45] Ng: ok, no problem :) [12:50] seb128: I pushed the changes needed to remove plugins-extra to bzr, don't have time to build and upload right now [12:51] I guess we cleaned up active_plugins handling some time ago, wasn't as bad as I thought [12:52] Amaranth, will you do that today or should I do it? [12:52] it's just a depends to suggests change [12:52] no need to test build or anything [12:52] oh, I dropped it completely [12:52] that's good too [12:52] but I gotta go now, if you can wait 8 hours I can do it [12:53] as long as it's not depends or recommends [12:53] ok [12:53] I will wait for you to upload [12:53] thanks === MacSlow|lunch is now known as MacSlow === robbiew-afk is now known as robbiew [14:35] hey rickspencer3 [14:36] hi seb128 [14:36] how are you? [14:38] doing well [14:38] meetings galore this morning [14:38] good morning rickspencer3 [14:38] including covering our blueprints for lucid with sabdfl [14:38] :o [14:38] hi pitti [14:38] seb128, pitti how is it going? [14:39] rickspencer3, good luck ;-) [14:39] rickspencer3, good, pitti rocked as usual and landed the menu caching changes [14:39] chouette! [14:40] rickspencer3, I've also commented xsplash use from gdm btw [14:40] it wins us almost 1 second of login time [14:41] let me know if you are against it [14:42] I not against anything that gets us to the 4 second budget at this stage [14:42] so, good job [14:42] ok thanks ;-) [14:42] * seb128 wonders what is the publishing today [14:42] still no gnome-menus update [14:43] or what is the publisher doing rather [14:48] 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] kenvandine, current indicators use cpu for almost 1.5 seconds [14:50] which is over 25% budget for the whole login [14:50] tedg, ^^ [14:50] not cool [14:50] really not no [14:51] I'm pondering dropping the applet from the default config just to reach the target as we did for xsplash [14:51] but I guess that would be controversial ;-) [14:51] we will need to put some pressure on improving those though or we will really have to consider that [14:54] are we planning to keep xsplash out? [14:54] * kenvandine thinks it defeats the whole purpose of having xsplash at all [14:54] well we said we would meet the target even if that means doing some compromises... [14:54] then we can discuss those choices [14:54] ok [14:55] we can't have everything [14:55] I expect xsplash could also be improved [14:55] the current animation use too much cpu [14:55] but Cody said he has ideas on how to improve that maybe [14:56] I think we will bring it back during the cycle but it will need to be less cpu intensive [15:03] 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] pitti, do you know if launchpad has issues? [15:04] pitti, gnome-menus is still not published there [15:04] chrisccoulson: that's gconf? [15:04] not that I know of [15:04] pitti, ignore me I'm using the french mirror [15:04] * seb128 switches to archive.ubuntu.com [15:05] :) [15:05] seb128 - i detailed all the findings on the spec :) [15:05] mostly gconf, but some dk-power too [15:06] seb128, i did see a merge proposal from bratsche for xsplash that pre-calculates the animation [15:06] last night [15:06] chrisccoulson: please add DONE on the whiteboard line then [15:07] kenvandine, oh nice, I need to try that [15:07] seb128, https://code.launchpad.net/~bratsche/xsplash/precompute-throbber/+merge/15564 [15:08] seb128, i bet he would love to see how it compares [15:09] kenvandine, seb128: Yeah, I'm not sure how much that will help but it seemed worth a try. [15:09] hey bratsche! [15:09] yo [15:19] bratsche, I will try and let you know how it goes [15:26] 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] tedg, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091203-1.png [15:30] tedg, look at the bottom for the chart [15:30] indicator-applet [15:30] 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] it has almost full cpu use for 1.8 seconds [15:31] tedg, we are cpu bounded on this config [15:31] it's using cpu we need [15:31] seb128: But a line doesn't mean anything in boot chart. That's not precise enough to prove anything useful. [15:32] what do you mean a line? [15:32] A blue line. [15:32] it means cpu activity [15:33] It means *some* CPU activity -- not CPU activity for the entire time. [15:33] If it ran one instruction in that watch time it'd show up as a line in bootchart. [15:33] well it's the only process doing a zillion line around [15:34] tedg, well, worded differently I just removed it and did a new chart [15:34] we win 0.8 seconds on boot without the applet [15:35] doing an another one now to see if the difference is constant [15:35] but I usually get 0.1 to 0.3 seconds variations [15:36] 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] tedg, right, 0.9 seconds on this one [15:36] seb128, on my laptop i see far less cpu for the indicator but i see IO [15:36] well maybe not [15:36] but you cost 0.8 to 0.9 seconds on our 4 seconds budget [15:36] confirmed by several boots on the reference box now [15:37] I've no good explanation of *why* [15:37] Are we the only Bonobo based applet in the default config? [15:37] but that's what measures say [15:37] no [15:37] trash costs 0.3 seconds [15:37] for reference [15:37] So I'll blame Bonobo for 0.3 of our 0.8 ;) [15:37] fair enough [15:38] I'm wanting at least half of the 0.6 remaining back [15:38] or 0.5 remaining [15:38] you are the longer applet after the menus by far [15:38] 0.2 to 0.3 seconds is the cost for almost all the other ones [15:38] which I think it's basically bonobo ping pong + init [15:39] 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] is there any other data I can provide you? [15:40] the session is a stock one [15:40] I don't think so right now. We'll get some logging in and setup, then I'll want those logs :) [15:40] ok [15:40] let me know when you need something there [15:40] I've the box used only for testing and I reboot it a lot ;-) [15:41] urg [15:41] pitti, you screwed menus ;-) [15:41] ? [15:41] pitti, I'm not preferences or admins menus [15:42] only the software-center in admin in fact [15:42] argh [15:42] and it's not at the bottom of applications anymore [15:42] * pitti sighs [15:42] I'm -> I've [15:42] do you get the issue too? [15:42] sorry [15:42] yes, seems I do [15:43] ok good [15:43] I'm not alone at least ;-) === bjf-afk is now known as bjf [15:51] seb128: seems to be my "break it" day; this morning my mailbox and IRC freaked out because I broke udev.. === hggdh_ is now known as hggdh [15:55] * seb128 hugs pitti, don't worry only those who do nothing break nothing [15:56] tseliot, rickspencer3: our call is on Rick's conf line? [15:56] pitti, good idea [15:56] I was about to ask the same question [16:01] I'm in, waiting [16:01] me too [16:01] jeez, I'm only 1 minute late [16:08] tseliot, https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers [16:20] heya [16:21] hi bryce [16:22] rickspencer3, sorry I thought the call was 8:30 not 8:00... still want me to call in? [16:22] bryce, we just got off [16:22] I'll send you your list of action items [16:22] ok [16:22] bryce, we have you signed up to own pulse audio for lucid now [16:22] [16:23] teasing the X guy before he's had coffee, eh? [16:23] brave brave man [16:23] hehe [16:23] argh argh [16:23] *pitti has quit (X server segfault) [16:23] pitti, what else did you break? [16:23] oh, only xorg [16:23] pitti, o_O [16:23] j/k [16:24] ;-) [16:24] seb128: my current breakage is the WI tracker, again [16:24] that, then menus [16:24] seems like a whack-a-bug day today :/ [16:24] I would argue that menus are higher importance than some tracker ;-) [16:24] * seb128 runs away from rickspencer3 [16:25] yay, my launchpadlib branch was merged [16:48] seb128, I noticed gwibber isn't on the app indicator list, is that on purpose or an oversight? [16:49] hi, I am trying to use empathy for 9.10 from the launchpad ppa but there is some incompatibility with the packages [16:49] jcastro, where did you get your gwibber from? I guess it's a kenvandine question [16:49] jcastro, it's up to the software to ship the launcher [16:49] in order to install empathy-common wich is needed for empathy is asking me to desinstall ubuntu-desktop [16:49] seb128, no I mean on the list of apps to port to the app indicator [16:49] it works fine in real life. [16:49] hugolp, known issue, kenvandine said he would look at it [16:49] 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] jcastro, oh ok, I though you said it was not in the message indicator launchers [16:50] seb128: ok [16:50] jcastro, it's probably an oversight [16:50] ok I will add it [16:50] jcastro, why would it be on the list? [16:50] it has a notification area icon? [16:50] it already uses the indicator [16:50] mpt: there is a .diskinfo/ dir for official ones, but we do not really have great standards for addon cds [16:50] optional [16:51] mpt: the closest was/is the g-a-i addon cd [16:51] yeah but it's going into main right? [16:51] yes [16:51] well don't we want to patch that optional codepath? [16:51] 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] kenvandine, I am talking about the thing ted is working on [16:51] seb128, true [16:51] what if there is no message indicator applet installed [16:51] jcastro, add it :) [16:51] everything that uses the tray will need to be ported [16:51] just so if people try to enable it, it will do the right thing :) [16:52] mvo, what is "the g-a-i addon cd"? [16:52] jcastro, I think kenvandine's was arguing that it doesn't use the tray since it uses the messaging indicator [16:52] mpt: it sounds to me like we want a) addon and b) new releases, but they look like two different use cases [16:52] seb128, yeah... by default it shouldn't use it [16:52] but you can turn that on [16:52] 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] so if you do i guess we want to change the behavior a bit [16:53] jcastro, right [16:53] we need 3 cases now [16:53] 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] using message indicator, or application indicator or notification area [16:56] 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] mvo, unfortunately I'm not in the office and don't have any CDs handy :-) [16:59] cat /cdrom/.disk/info [16:59] Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.1) [17:02] pitti, bug #491937 is yours [17:02] Launchpad bug 491937 in gnome-menus ""system" pulldown empty" [Undecided,Confirmed] https://launchpad.net/bugs/491937 [17:02] pitti, I've assigned it to you I hope it's ok [17:02] seb128: thanks! sure it is [17:09] mvo, I am now nearly done with the API review of aptdaemon [17:10] mvo, So I make a stable fork of the branch lp:aptdaemon/0.1.x [17:10] glatzor: great! [17:10] glatzor: btw, see #packagekit, apparently some string matiching is not ideal [17:11] bryce: please use "bryceharrington" for WI assignees (your LP name) [17:12] pitti, bleah [17:13] awesome, it's nearly friday already :) [17:13] chrisccoulson: ;-) [17:15] 2.5 day weeks are great :) [17:15] especially when 2 of those are spent on a course [17:18] ugh i think evolution just ate an email i tried to send :( [17:18] hmm no, just sticking it in the wrong folder, very odd [17:25] mvo, perfect, thanks [17:25] chrisccoulson: hehe [17:34] 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] it's 2.6MB :-/ [17:36] rickspencer3: check this out: http://piware.de/workitems/desktop/lucid-alpha2/report.html [17:36] rickspencer3: (scroll down) [17:36] courtesy by cjwatson [17:49] chrisccoulson: does it call gettext on any of those? [17:49] chrisccoulson: i. e. when you strace it, any mo files involved? [17:49] it shouldn't ideally [17:49] pitti - it doesn't look like it [17:50] it just needs to read the whole file to build the tree [17:50] AFAIR, when I wrote those bits, gettext() should only be called on demand [17:50] ok [17:50] that sucks [17:50] it does :( [17:51] i'm not going to give up just yet though [17:51] it also means that it keeps the stuff in memory, all the time, "just in cas" [17:51] e [17:51] but as seb128 says, gconf's days are counted anyway [17:52] yeah, but we've still got to put up with it for one more cycle [17:52] and it's currently quite a time waster [17:52] *nod* [17:52] anyway, dinner time for me now :) [17:52] likewise :) [17:53] is it important to be XML? [17:53] could it be any faster with a simple two-column text file? [17:54] pitti, cool... work items included in the report, awesome! [17:54] chrisccoulson: also, where does this file actually store the default values? [17:54] kenvandine: thanks to cjwatson :) [17:54] [17:54] [17:54] is it just me, or is ther just about zero information here? [17:55] chrisccoulson: it might be worth investigating what happens if all the entries which don't have a /<*value> tag will just get dropped [17:55] seb128: ^ could that work? [17:56] the first value is 8% into the file [17:57] chrisccoulson: good catch anyway! [17:59] parsing xml is slow :/ [18:02] pitti, not sure if gconf needs a mapping of existant keys or not [18:02] would be worth playing with in any case === eeejay_away is now known as eeejay === hggdh_ is now known as hggdh [19:39] 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] Is that from /.disk/info too? [19:44] or is it from the Release file? [19:47] hm, looks like Release file Label is what I want === eeejay is now known as eeejay_away === eeejay_away is now known as eeejay [20:13] rickspencer3_, didrocks: any chance to finish drafting of desktop-lucid-quickly{,-templates} soon (deadline is today)? at least add WIs? [20:14] pitti, SURE [20:14] sorry, I can get to it maybe tomorrow or this weekend [20:14] the WIs are probably a bit more urgent [20:37] pitti: hi, is the update-gnome-menus-cache your new work? [20:37] mvo: I know, I know, it's broken; looking at it now ;) [20:37] mvo: yes, from today [20:37] pitti: it seems to be crashing during hardy->lucid because gmenu can not be imported (the old pysupport thing) [20:38] oh noes [20:38] mvo: curious, though; does it actually fail the package? [20:38] well, just add a try: except: and a trigger, that should be fine [20:38] update-gnome-menus-cache /usr/share/applications > "$cache.dpkg-new" || rm -f "$cache.dpkg-new" [20:38] no, ist just a crash file [20:38] ah [20:38] because for reasons like that I wrote it like above [20:38] but the upgrader-tester is picky about crash files generated during the upgrades [20:39] if it ever fails, it removes the cache to not leave inconsistent data around [20:39] and not fail the package postinst [20:39] right, its not breaking aanything, its just crashing :) [20:39] (which is great btw) [20:39] mvo: what's the particular exception? [20:39] mvo: just an ImportError? [20:40] mvo: I don't generally like hiding those, but for this kind of script a mere stderr message is fine [20:40] yes, just that [20:40] I can give you the crash file, but its really just a import error for gmenu [20:41] nevermind [20:41] mvo: btw [20:41] 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] mvo: fixed in http://bazaar.launchpad.net/~ubuntu-desktop/gnome-menus/ubuntu/revision/28 [20:42] thanks pitti! [20:43] * mvo hugs pitti [20:43] * pitti goes back to fixing the thing to not mess up your menus [20:44] Riddell: is bug 484802 already fixed in lucid by chance? [20:44] Launchpad bug 484802 in kdeedu "SRU: Parley fails to initialize Python scripts" [Undecided,Fix committed] https://launchpad.net/bugs/484802 [20:47] mvo: btw, we support dapper->lucid upgrades? [20:47] mvo: I'm afraid me and other people have dropped a *lot* of upgrade quirks from edgy/feisty/gutsy/hardy [20:48] so far I assumed that we only support dapper->hardy->lucid [20:48] oh, same here [20:48] mvo: oh, nevermind; you said hardy->lucid [20:48] I cleaned all the pre-hardy hacks... [20:49] where the heck did I read "dapper"? [20:49] pitti: from your box running dapper? [20:49] the only thing I have left from dapper is a chroot.. [20:49] yeah, no dapper->lucid, that would be ... woah [20:50] *phew* :) [20:50] the only thing I have left is memories :) [20:50] "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]