[00:58] <robert_ancell> jasoncwarner_, RAOF, https://launchpad.net/ubuntu-boot-speed seems like the right place to track boot issues
[00:59] <jasoncwarner_> yeah, that makes sense...perhaps I should upload the video there ;)
[01:00] <jasoncwarner_> robert_ancell: that video un-glitch for you? I'm uploading the native video to U1 now
[01:00] <robert_ancell> it could be a flash problem, I've only just got it working again
[01:02] <RAOF> That video worked fine for me.
[01:03] <jasoncwarner_> uploading to U1...but it is taking a long time...
[01:04]  * robert_ancell -> dentist (duh, duh, duhhhhh!)
[01:07] <jasoncwarner_> a big thank you to rodrigo for getting me back my keyboard options...and putting it in keyboard instead of the insane default gnome has...thank you rodrigo!
[01:15] <RAOF> Yeah, props!
[01:20] <kenvandine> jasoncwarner_, interesting thing about your bootchart is the cpu usage
[01:20] <kenvandine> i compared mine, which is a little faster, and it looks similar
[01:20] <kenvandine> most of the cpu is xorg
[01:22] <kenvandine> i don't recall xorg being such a consumer of cycles at boot time last time we focused on speeding up boot
[01:23] <kenvandine> for me unity-greeter runs from 12s until 43s
[01:23] <kenvandine> and my boot is 49s total
[01:24] <bryceh> kenvandine, me either
[01:25] <kenvandine> i am sure pitti still has his old bootcharts
[01:25] <kenvandine> probable on people
[01:26] <kenvandine> http://people.canonical.com/~pitti/bootcharts/donald-maverick-final.png
[01:26] <kenvandine> maverick final
[01:26] <kenvandine> 12.89s
[01:26] <bryceh> well, fair bit of cpu there on xorg
[01:26] <kenvandine> xorg was still the biggest consumer...
[01:26] <bryceh> fwiw, cpu and memory for xorg are often mostly driven by client program needs
[01:27] <bryceh> so it's possible Xorg by itself hasn't changed at all in this respect, but we're driving load via heavier clients
[01:27] <bryceh> in the Xorg.0.log it has timestamps for log messages, so that should give an idea of how long X is taking for its own internals
[01:27] <kenvandine> yeah, in this case it is lightdm
[01:28] <desrt> does anyone still have natty installed on a non-VM?
[01:28] <kenvandine> desrt, not me
[01:28] <bryceh> looking at my Xorg.0.log on a sandybridge with oneiric I see it showing 15 sec -> 17 sec, about 2 seconds which is about what we got it down to before (maybe .5-1 second more)
[01:28] <bryceh> however it's odd that it starts at 15 sec rather than 0
[01:29] <micahg> desrt: I do
[01:29] <kenvandine> bryceh, on the maverick bootchart it started at about 8s
[01:30] <kenvandine> just 4s before completion
[01:30] <desrt> micahg: would you mind testing something for me?
[01:30] <desrt> micahg: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/838975
[01:30] <ubot2`> Ubuntu bug 838975 in eglibc "weird pthread/fork race/deadlock" [Undecided,New]
[01:30] <kenvandine> bryceh, maybe lightdm is pushing X harder than gdm was?
[01:30] <micahg> desrt: how long? doesn it need to be tonight
[01:30] <bryceh> maybe
[01:30] <desrt> micahg: download, compile, run
[01:30] <desrt> should take < 1 minute
[01:30] <kenvandine> would be surprising... but dunno
[01:31] <micahg> desrt: k, np
[01:31] <bryceh> mm I spot a sec we can easily win back
[01:31] <desrt> micahg: you'll need -pthread for the compile
[01:31] <desrt> micahg: when you run the program it should display a sequence of dots on your screen
[01:31] <bryceh> unity_support_test is run, taking ~1 sec, but we shouldn't need to run that every boot
[01:31] <desrt> micahg: either the dots will stop at some point, or will go forever
[01:31] <kenvandine> good point
[01:31] <desrt> micahg: running it for a minute or two should be enough to see if the bug exists
[01:31] <desrt> it is known to exist in oneiric but not in lucid
[01:32] <desrt> i'm trying to bisect that a bit :)
[01:32] <kenvandine> bryceh, zg is a bit harsh too
[01:32] <kenvandine> and it seems to block unity
[01:32] <micahg> desrt: gcc -pthread test.c?
[01:32] <desrt> that will work
[01:32] <desrt> then run ./a.out
[01:33] <kenvandine> over 4s of thrashing on mine before unity starts
[01:33] <micahg> desrt: stops
[01:33] <desrt> micahg: thanks.
[01:34] <desrt> wi micahg
[01:34] <micahg> desrt: that's with natty with -proposed enabled
[01:34] <bryceh> wonder if laptop-mode is causing some of the lagging?
[01:34] <desrt> micahg: this is a pretty wide-spread bug.  probably upstream.
[01:34] <kenvandine> and there is a load of stuff starting before unity that doesn't need to
[01:34] <kenvandine> like gnome-screensaver starts very early
[01:34] <bryceh> no, we had laptop-mode before
[01:34] <kenvandine> i suppose that is lightdm
[01:35] <kenvandine> the eds related stuff starts before unity too
[01:35] <bryceh> indicator-sound appears to take a large chunk of time?
[01:35] <jasoncwarner_> desrt: I have it installed...that is what my wife runs
[01:35] <jasoncwarner_> desrt: need me to test something?
[01:35] <kenvandine> seems like all the unity services start after everything else desktop related
[01:35] <desrt> jasoncwarner_: micahg just confirmed the bug
[01:35] <bryceh> kenvandine, yeah
[01:35] <jasoncwarner_> desrt: ok
[01:35] <kenvandine> bryceh, not on mine
[01:36] <desrt> i guess i need to find a maverick box to test next :)
[01:36] <bryceh> kenvandine, looking at jason's
[01:36] <jasoncwarner_> desrt: out of luck there!
[01:36] <kenvandine> we should be starting all the unity related things first
[01:36] <micahg> desrt: this doesn't show in a VM?
[01:36] <jasoncwarner_> desrt: I don't run something I didn't work on ;)
[01:36] <desrt> micahg: i don't know if it will
[01:36] <bryceh> on jason's I see indicator-sound twice
[01:36] <desrt> micahg: just wanted to eliminate a possible extra factor
[01:36] <jasoncwarner_> kenvandine and bryceh any idea why X cpu usage would be so high? and what is going on at various stages of my boot? i can't believe it would take that long etc
[01:37] <desrt> micahg: it's quite possible to get a false negative here -- but false positives are impossible
[01:37] <jasoncwarner_> kenvandine: luckily, I can't blame gwibber ;)
[01:37] <kenvandine> indeed :)
[01:37] <desrt> since if it stops printing dots then, by definition, something is broken
[01:37] <micahg> desrt: I can try in my maverick vm
[01:37] <desrt> micahg: would be appreciated
[01:37] <bryceh> jasoncwarner_, can you pastebin /var/log/Xorg.0.log ?
[01:37] <kenvandine> gwibber-service should start on a 30s delay :)
[01:37] <bryceh> it has timestamps so we can see what X is doing
[01:37] <desrt> micahg: can i get the verisons on your kernel and libc?
[01:37] <jasoncwarner_> bryceh: sure...one sec
[01:38] <jasoncwarner_> ps. anyone know a command line pastebin tool? would be super handy
[01:38] <desrt> fpaste or pastebinit
[01:38] <bryceh> jasoncwarner_, anyway, like I mentioned earlier, oftentimes X cpu usage is due to it responding to client demands, rather than its own internal needs
[01:38] <micahg> desrt: 2.6.38-11.49 and 2.13-0ubuntu13
[01:38] <desrt> cheers
[01:38] <bryceh> my guess is that X is done setting itself up within a few seconds, and all the later cpu activity is driven by clients
[01:39] <jasoncwarner_> bryceh: http://pastebin.com/0iQeR82D
[01:39] <bryceh> jasoncwarner_, yeah pastebinit rocks :-)
[01:39] <kenvandine> http://ubuntuone.com/4hq85aJPLb1j0Vmeu0Mpwp
[01:39] <kenvandine> that is my bootchart
[01:40] <kenvandine> quite a bit different than jasoncwarner_'s
[01:40] <bryceh> The X log starts at 17.0 sec's
[01:40] <bryceh> at 17.1 it starts probing video outputs
[01:41] <bryceh> jasoncwarner_, looks like it takes a whole *2 seconds* to do that
[01:41] <kenvandine> jasoncwarner_, SSD in that thing?
[01:41] <jasoncwarner_> kenvandine: do you have an SSD? I have 7200rpm right now....but really most people are not going to hvae SSD for a while more
[01:41] <kenvandine> mine is an SSD
[01:41] <bryceh> yikes...  3 HDMI, 3 DisplayPort, an LVDS, and a VGA.  Lots of outputs.  Still, that's a long time spent
[01:41] <kenvandine> and for comparison... it had a 9s boot with maverick
[01:42] <kenvandine> clean install and fresh user account with maverick that is
[01:42] <kenvandine> it was FAST
[01:42] <micahg> desrt: yeah, keeps going in the maverick vm
[01:42] <jasoncwarner_> 9 sec boot on maverick to a 40 second boot now?
[01:42] <kenvandine> 49s now
[01:42] <jasoncwarner_> sorry, 50 second boot?
[01:42] <desrt> micahg: version numbers from that one?
[01:42] <jasoncwarner_> sheesh!
[01:42] <kenvandine> yup
[01:42] <jasoncwarner_> at least not 1.5 minutes like mine...but, you know...bad ;)
[01:42] <kenvandine> but... the cycle before... it was over 2 minutes :)
[01:42] <bryceh> ew, then it probes the outputs again a second time... another 2 sec hit
[01:43] <kenvandine> jasoncwarner_, in one cycle it went from over 2m to 9s
[01:43] <micahg> desrt: 2.6.35-28.50 and 2.12.1-0ubuntu10.2
[01:43] <jasoncwarner_> I like that way, let's do that! ;)
[01:43] <kenvandine> early this cycle it was well over a minute too
[01:43] <kenvandine> it has gotten faster
[01:44] <desrt> micahg: thanks.  infos added.
[01:44] <bryceh> then I'm seeing several more EDID info gathering's which are probably client apps asking for monitor info
[01:44] <bryceh> kenvandine, pastebin your Xorg.0.log too
[01:45]  * desrt starts to ponder the possibility of a glibc build
[01:45] <kenvandine> http://ubuntuone.com/05PsmJwntn4cd6LlprxUTX
[01:45] <kenvandine> bryceh, ^^
[01:46] <jasoncwarner_> desrt: btw...just got the x220...love it. my battery life is like 5.5 hours...miss some screen realestate, but loving how small it is and stuff...you should get another one and make this one the x220 ;)
[01:46] <kenvandine> ugh, those u1 urls have gotten ugly
[01:46] <bryceh> [     5.810] (II) intel(0): Output VGA1 has no monitor section
[01:46] <bryceh> [     8.469] (II) intel(0): Output HDMI1 has no monitor section
[01:46] <kenvandine> that looks slow
[01:46] <jasoncwarner_> kenvandine: how are you putting those up on u1 so fast? do you have command line tool to get the URL or something? I have been using webclient and that is slow
[01:46] <bryceh> kenvandine, 2.5 sec for it to study your video outputs?
[01:47] <bryceh> [     8.530] (II) intel(0): EDID for output VGA1
[01:47] <bryceh> [    11.174] (II) intel(0): EDID for output HDMI1
[01:47] <kenvandine> jasoncwarner_, just the cp command
[01:47] <desrt> jasoncwarner_: i got a T420 now.  loving it.
[01:47] <kenvandine> bryceh, and nothing is plugged into it
[01:47] <bryceh> kenvandine, craziness there
[01:47] <desrt> jasoncwarner_: i need the T series.  i have two external monitors at home and i use my laptop to double as a desktop when docked
[01:47] <bryceh> RAOF, what do you think is going on?  probing output and sleeping?
[01:47] <kenvandine> i get about 5 hours on battery with my old T400
[01:47] <kenvandine> with the SSD
[01:48] <kenvandine> the SSD was the single best upgrade ever!
[01:48] <RAOF> bryceh: Looking at it; VGA output probing can be slow, I understand.
[01:48] <jasoncwarner_> desrt: nothing wrong with the Tseries...can't wait to put an SSD in this and get 6+ hours, however ;)
[01:48] <desrt> jasoncwarner_: the evil nvidia optimus crap t420s was sent back.  lenovo was nice enough to take it without restocking fee due to the troubles.
[01:48] <desrt> jasoncwarner_: with the slice battery i'm supposed to get ~30 hours on the T420 :)
[01:48] <jasoncwarner_> then, watch out...the number of manager emails I can send is limited to my battery life...this thing is gonna make my emails go through the roof!
[01:48] <bryceh> kenvandine, looks like X is pretty much done by 11.383, so it took about 6.5 sec (mostly that VGA output probing).
[01:49] <jasoncwarner_> desrt: slice battery?
[01:49] <bryceh> kenvandine, but notice the stuff after 11.383; things are asking for monitor info  multiple times
[01:49] <desrt> jasoncwarner_: clips onto the bottom, attaching to the dock port
[01:49] <kenvandine> yeah, in my bootchart something is clearly using cpu and blaming X
[01:50] <kenvandine> bryceh, what kinds of things would be asking for that?
[01:50] <kenvandine> i would think the only thing that would care is unity and X
[01:50] <kenvandine> but unity is staring way late
[01:50] <RAOF> bryceh: Didn't we determine that compiz was doing a *huge* amount of unnecessary work during startup roundtripping to the X server?
[01:50] <bryceh> hmm
[01:50] <bryceh> RAOF, yeah
[01:51] <bryceh> did we include or exclude compiz with the earlier boot speed studies?
[01:51] <kenvandine> RAOF, but in my care Xorg appears to be very busy long before compiz starts
[01:51] <RAOF> Which was why switching away from X to VT1 made startup much faster, even including the switch-back to X.
[01:51] <desrt> jasoncwarner_: it's a bit on the heavy side, but at 30 hours, that's not too surprising...
[01:52] <bryceh> kenvandine, gnome-settings-daemon has a fair bit of X invocations in it
[01:52] <RAOF> bryceh: You know, we could totally make X startup not block on the VGA polling.
[01:52] <kenvandine> RAOF, bryceh: in my bootchart compiz is starting at about 32s into the 49s boot
[01:52] <bryceh> RAOF, do tell
[01:53] <RAOF> bryceh: Oh, just by doing it asynchronously.
[01:53] <RAOF> bryceh: It'd be not a *lot* more than a SMOP.
[01:53] <bryceh> hmm, maybe we should hook up xtrace for the first 2 min to record what client operations are actually going on?
[01:54] <jasoncwarner_> bryceh: tell me what to do and I'll run it....
[01:54] <bryceh> jasoncwarner_, heh, also a SMOP
[01:54] <kenvandine> on my bootchart, g-s-d isn't starting before compiz either
[01:54] <kenvandine> the only thing running at the same time that looks like it could be using X is lightdm
[01:54]  * kenvandine blames robert_ancell :-p
[01:54] <RAOF> kenvandine: DUDE!  Why is your udev so fast?
[01:55] <kenvandine> RAOF, dude... this laptop had a 9s boot with maverick...
[01:55] <kenvandine> :-D
[01:55]  * kenvandine hopes this T400 lasts 3 more years :)
[01:55] <RAOF> Alternatively, why does my modprobe take like 10 seconds.
[01:55] <kenvandine> hehe
[01:55] <kenvandine> good question too
[01:55] <RAOF> On a SandyBridge, with fast SSD.
[01:55] <jasoncwarner_> bryceh: SMOP?
[01:55] <kenvandine> simple matter of programming
[01:55] <RAOF> Simple Matter of Programming.
[01:55] <jasoncwarner_> ah ;)
[01:56]  * jasoncwarner_ waves hands and talks about it being easy...
[01:56] <kenvandine> i gotta run guys... bbiaf
[01:56] <bryceh> yeah I think we'd need to hack xtrace into the boot sequence somewhere, maybe in lightdm
[01:56] <RAOF> Well, with X there's a *lot* of scope for things not just being a SMOP.
[01:57] <RAOF> That should be a simple matter of getting lightdm to execute "xtrace gnome-session" rather than just "gnome-session", right?
[01:58] <bryceh> yeah maybe
[01:59] <bryceh> but I'm not sure that'd report all client activity or just gnome-session itself
[01:59] <bryceh> well, worth trying anyway
[01:59] <RAOF> xtrace sets up a proxy X server; gnome-session and everything with the same environment as gnome-session would go thorugh it.
[01:59] <RAOF> I'd expect that to mean "everything that gnome-session starts", and that's everything :)
[02:00] <bryceh> alrighty
[02:00] <bryceh> hey if this works it could give us a really powerful tool for analyzing boot slowness
[02:01] <RAOF> Hey, how did we test that "boot is super fast if we're not at X" thing?
[02:01] <bryceh> not at X?
[02:01] <bryceh> oh, hmm.  stick in a chvt 1 somewhere?
[02:02] <RAOF> Hm, in lightdm's post-start staza should do.
[02:04] <RAOF> Let's give this a whirl.
[02:06] <bryceh>  /var/log/lightdm/lightdm.conf has some timing info in it too
[02:07] <bryceh> hmm, on my system it looks like X signalled itself ready after about 4.5 sec; not bad
[02:07] <kenvandine> [+0.03s] DEBUG: Waiting for ready signal from X server :0
[02:07] <kenvandine> [+5.73s] DEBUG: Got signal 10 from process 1175
[02:07] <bryceh> kenvandine, yep 5.7 sec in your case
[02:07] <kenvandine> and the log ends at +5.80
[02:08] <kenvandine> so lightdm itself looks like it is almost all waiting
[02:08] <bryceh> maybe with async VGA we could drop that to closer to 2 sec, but still doesn't explain all the other time
[02:08] <bryceh> yeah mind seems to end with
[02:08] <bryceh> [+5.99s] DEBUG: Activating VT 7
[02:09] <kenvandine> i guess the rest is waiting for gnome-session to do something
[02:09] <kenvandine> about 6s after lightdm starts, gnome-session starts
[02:09] <kenvandine> ssh-agent
[02:09] <kenvandine> and gnome-settings-daemon
[02:10] <kenvandine> and then like 19s before anything else really happens
[02:10] <kenvandine> but all the time X is getting hit... so must be g-s-d
[02:10] <jbicha> my indicators keep crashing which makes Unity very frustrating to use, how do I report this? http://paste.ubuntu.com/680255/
[02:12] <jasoncwarner_> bryceh: btw...I <3 you for pastebinit
[02:12] <bryceh> :-)
[02:12]  * bryceh tries slapping an xtrace into Xsession
[02:13] <kenvandine> jbicha, looks like unity-panel-service not the indicators
[02:14] <kenvandine> jbicha, actually maybe it is indicator-weather
[02:14] <kenvandine> jbicha, try removing that and see if it gets better
[02:16] <kenvandine> jbicha, looks like indicator-weather uses gtk2... but the unity-panel-service is gtk3
[02:16] <kenvandine> so that can't work
[02:16] <bryceh> hmm, that did not work
[02:17] <jbicha> kenvandine: thanks, that might be it
[02:18] <bryceh> my bootchart:  http://www.bryceharrington.org/files/clanfield-oneiric-20110901-1.png
[02:18] <jasoncwarner_> bryceh: wow..80s ?
[02:19]  * jasoncwarner_ steps out for a few...be back later.
[02:23] <kenvandine> holy stacking craziness batman
[02:23] <kenvandine> alt-tab only shows up if all the windows aren't shown and the dash shows up behind everything
[02:27] <TheMuso> jbicha: Ah crap, didn't notice your yelp-tools branch was an ubuntu-desktop packaging branch, I'll use that branch then, since its better to use the packaging branch anyway.
[02:30] <jbicha> TheMuso: thanks, Launchpad makes it easy to propose a merge with the wrong one :(
[02:30] <TheMuso> Yup.
[02:33] <RAOF> For the sake of completeness, here's my bootchart http://ubuntuone.com/4JPVYvpQV432sBGgXNzH8z
[02:34] <RAOF> And trying to chvt during startup is no longer much fun; I think unity_support_test fails, so the session doesn't get loaded.
[02:34] <TheMuso> jbicha: Seems itstool is also needed at build time. Nvm updating, I've done it locally, but please test build next time.
[02:34] <bryceh> haha
[04:19] <pitti> Good morning
[04:19] <pitti> jasoncwarner_: hey, do you have some time to tweak your bootchart to include the desktop session, too?
[04:32] <jasoncwarner_> pitti: sure...let me know wha tyou need me to do and I can do that...
[04:33] <pitti> jasoncwarner_: please edit /etc/init/bootchart.conf
[04:34] <pitti> jasoncwarner_: and comment out the "stop on stopped rc" line
[04:34] <jasoncwarner_> ok...edit it? like in libreoffice? :P j/k
[04:34] <jasoncwarner_> after that, reboot?
[04:35] <pitti> jasoncwarner_: right
[04:35] <jasoncwarner_> rebooting...be back in a few...
[04:35] <pitti> jasoncwarner_: and as soon as you are in the desktop session, do "sudo stop bootchart"
[04:35] <jasoncwarner_> ok
[04:45] <jasoncwarner_> pitti: back...that took a long time!
[04:45] <jasoncwarner_> also lost my theme and icons :/
[04:45] <jasoncwarner_> pitti: emailed you latest bootchart
[04:46] <jasoncwarner_> rebooting again....
[04:49] <pitti> urgh
[04:50] <jasoncwarner_> freakin' gnome-systems-deamon...always crashing on me...
[04:50] <jasoncwarner_> I wonder if 1/2 my problems are because of that thing
[04:52] <pitti> yes, presumably more than half
[04:52] <pitti> jasoncwarner_: still with 2.21.90?
[04:53] <pitti> jasoncwarner_: replied to your first mail
[04:55] <pitti> jasoncwarner_: sorry, you sent me the .tgz; can you send me the .png?
[04:56] <jasoncwarner_> pitt
[04:56] <jasoncwarner_> pitti: sure
[04:56] <pitti> jasoncwarner_: I'll do two reboots to get a bootchart of mine, to compare
[04:56] <jasoncwarner_> pitti: btw..saw a note on one of the gnome-settings-daemon bugs from robbiew and it says tha tif you are plugged into power, the g--s doesn't crash
[04:56] <jasoncwarner_> I just tested that and it is true
[04:56] <jasoncwarner_> it doesn't crash
[04:56] <jasoncwarner_> weird
[04:56] <jasoncwarner_> g-s-s tha tis
[04:59] <jasoncwarner_> hey pitti should I do this from your email? sudo rm /var/lib/ureadahead/*pack and reboot twice?
[05:02] <pitti> jasoncwarner_: yes, it doesn't crash for me either
[05:02] <pitti> jasoncwarner_: yes, please do this: after the first boot, wait a bit (45 seconds into the session or so) until /var/lib/ureadahead/ has some pack files
[05:02] <pitti> jasoncwarner_: then reboot the second time, and remember the "sudo stop bootchart"
[05:03] <pitti> jasoncwarner_: after that, wait for a bit until /var/log/bootchart/ has a new one, and send that
[05:03] <jasoncwarner_> should I do sudo stop bootchart both times or just he second?
[05:03] <pitti> jasoncwarner_: both times
[05:03] <jasoncwarner_> ok...going
[05:11] <jasoncwarner_> hey pitti just emailed latest...
[05:12] <pitti> jasoncwarner_: replied again with a comparison with my bootchart
[05:12] <pitti> http://people.canonical.com/~pitti/bootcharts/donald-oneiric-20110902.png
[05:12] <pitti> compared to your's it's good, but compared to natty, or considering what this machine is able to do, it's ridiculously poor
[05:12] <pitti> my boot time more than doubled since natty, where natty already was 50% slower than lucid
[05:13] <jasoncwarner_> and you and I have the same machine now, except I don't have SSD righ tnow
[05:13] <jasoncwarner_> gah...looks like we have some work ahead of us!
[05:13] <pitti> right, but SSD vs. HDD should only make a difference initially, in ureadahead stage
[05:13] <pitti> i. e. it should take almost no time for me, and about 10 seconds for you
[05:14] <pitti> jasoncwarner_: xdub-oneiric-20110902-1.png (from your latest mail) looks really bad
[05:14] <pitti> jasoncwarner_: xdub-oneiric-20110902-2.png looks fine, ureadahead did its job there
[05:15] <pitti> jasoncwarner_: is xdub-oneiric-20110902-1.png after you removed the pack files?
[05:15] <jasoncwarner_> they both are
[05:15] <jasoncwarner_> 1 would be the first boot
[05:15] <jasoncwarner_> 2 would be the second boot after removing the pack files
[05:15] <pitti> ok, so we can ignore -1
[05:16] <pitti> so, 15 seconds until X starts
[05:16] <pitti> that's about as fast as it can be with a HDD
[05:16] <pitti> still very poor HDD utilization
[05:16] <pitti> jasoncwarner_: look at the green line at the top of the bootchart
[05:17] <pitti> you reach 86 MB/s for about a second, more than half of the big red IO wait block it just crawls along
[05:17] <pitti> seek times suck :)
[05:17] <pitti> I still don't understand why there is just one CPU utilized, and the other is completely idle
[05:18] <pitti> and there's a horrible amount of IO going on during the desktop session
[05:18] <pitti> it seems ureadahead didn't catch that part
[05:18]  * jasoncwarner_ thinks he should mail pitti his laptop ;)
[05:19] <pitti> jasoncwarner_: ok, nothign specific I could put my finger on, but there's two blatant things:
[05:19] <pitti> - X is ridiculously slow
[05:19] <pitti> - IO wait kills desktop performance
[05:19] <pitti> jasoncwarner_: for the second, we can try something
[05:19] <jasoncwarner_> k
[05:20] <pitti> 1. edit /etc/init/ureadahead.conf and change "sleep 45" to "sleep 90"
[05:20] <pitti> make that 95
[05:20] <pitti> 2. sudo rm /var/lib/ureadahead/pack
[05:20] <pitti> 3. reboot, "sudo stop bootchart"
[05:21] <pitti> 4. wait until you have /var/lib/ureadahead/pack
[05:21] <pitti> 5. perhaps clean up old boot charts, to not lose track what's new
[05:21] <jasoncwarner_> do I need to reboot twice again?
[05:21] <pitti> 6. reboot a second time, wait for boot chart to appear
[05:21] <pitti> sorry, after the second reboot you again need "sudo stop bootchart"
[05:21] <pitti> [done]
[05:22] <pitti> that should hopefully take the desktop part into ureadahead's umbrella
[05:22] <pitti> and we can then see the CPU problems
[05:22] <jasoncwarner_> ok...going to reboot, step #3
[05:22] <jasoncwarner_> be back in a few
[05:22] <pitti> jasoncwarner_: I have no idea about the X.org part, though; perhaps bryce or RAOF know about some known performance problems on your system?
[05:22] <RAOF> pitti: No; we were hypothesising that it's likely to be client traffic being the problem.
[05:23] <pitti> RAOF: did you see jason's?
[05:23] <pitti> RAOF: he has a more modern computer than mine, and my looks like http://people.canonical.com/~pitti/bootcharts/donald-oneiric-20110902.png
[05:23] <pitti> RAOF: it also needs a whole 7 seconds to initialize until lightdm starts, where it should take 2
[05:24] <pitti> well, in lucid bryce actually had the init time down to 0.5 seconds
[05:24] <RAOF> Man, mine's worse than yours too. http://ubuntuone.com/4JPVYvpQV432sBGgXNzH8z
[05:24] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100305-1.png
[05:24] <pitti> this is a crappy slow Mini 10v with atom
[05:24] <pitti> and X.org initialized faster than on my X201 with oneiric
[05:25] <pitti> RAOF: oh, you also have the big aptd blob
[05:25] <pitti> whatever triggers this needs to be taught not to
[05:25] <RAOF> Heh.
[05:25] <pitti> oh, you also start gwibber
[05:26] <RAOF> I don't know why mine takes so long to start udev.
[05:26] <pitti> how do yo mean?
[05:26] <RAOF> It takes more than double the time that yours does, and my system should be faster in every way.
[05:27] <pitti> RAOF: I suppose all the udev-y things at the start like modprobe, mtp-probe, etc. are just because ureadahead runs in parallel
[05:27] <RAOF> For Donald, init→udev is ~1.5sec.  For Faye, init→udev is ~6 sec
[05:27] <pitti> ureadahead is meant to own the HD, so everything else has to wait for a bit
[05:27] <pitti> but that's fine
[05:28] <RAOF> I mean from the start of the graph to the start of the actual activity.
[05:28] <pitti> RAOF: ah, that's mostly noise; depends when upstart gets around to start bootchart
[05:28] <RAOF> Ah, fair enough.
[05:28] <pitti> RAOF: the more interesting thing is that modprobe takes so long for you
[05:28] <pitti> seems you have a module or two which take very long to initialize
[05:29] <RAOF> Must be.
[05:29] <pitti> RAOF: looks like you use ecryptfs?
[05:29] <RAOF> For ~/Private, yeah.
[05:29] <pitti> yes, that's the solid 1 s blob that's called "lightdm"
[05:30] <RAOF> Oh, really.
[05:30] <RAOF> Man compiz eats CPU on startup.
[05:31] <jasoncwarner_> hey pitti I just shared my boot directory on ubuntu one with you.
[05:31] <jasoncwarner_> you should have access to all the stuff in there
[05:31] <jasoncwarner_> I just put the two latest bootcharts in there as well.
[05:31] <pitti> RAOF: also, it shows that CPU utilization during sessino startup is poor; the whole thing is pretty much just an exercise in waiting
[05:32] <pitti> but not on IO or free CPU
[05:32] <pitti> jasoncwarner_: hm, it's not shown in my shares
[05:32]  * pitti pokes U1
[05:33] <jasoncwarner_> hmm...
[05:33] <pitti> so yeah, in summary, we desperately need to fix GNOME all over again to stop waiting on Godot and just start in parallel
[05:33] <pitti> seems there's nothing left from our lucid efforts :(
[05:33] <jasoncwarner_> I shared with RAOF, bryceh and robert_ancell as well
[05:34] <jasoncwarner_> pitti: do you want me to email them to you?
[05:34] <pitti> sorry, I still don't see them; I disconnected and reconnected
[05:34]  * jasoncwarner_ emailing
[05:34] <pitti> thanks
[05:35] <jasoncwarner_> just emailed. you , robert_ancell bryceh and RAOF should have them
[05:35] <jasoncwarner_> anyone else who wants them, feel free to ping em :)
[05:36] <pitti> jasoncwarner_: you can also put them on people.canonical.com :)
[05:36] <jasoncwarner_> don't think I've ever used that, (checking now)
[05:36] <pitti> jasoncwarner_: ooh, I got an email from U1
[05:36] <pitti> "Jason Warner shared boot with you via Ubuntu One"
[05:36] <pitti> apparently I have to ack that first
[05:36] <robert_ancell> pitti, Godot?
[05:36] <pitti> well, makes sense, otherwise anyone could DoS my net connection
[05:36] <didrocks> good morning
[05:37] <pitti> bonjour didrocks
[05:37] <pitti> jasoncwarner_: ok, trying U1 (dogfooding..)
[05:37] <didrocks> guten morgen pitti! How are you?
[05:38] <pitti> robert_ancell: http://en.wikipedia.org/wiki/Waiting_for_Godot
[05:38] <jasoncwarner_> pitti: be back in a few (showering ... wife just told me we are expecting company! doesn't she know I work from home!)
[05:38] <pitti> jasoncwarner_: ok, U1 working really nicely
[05:38] <pitti> didrocks: quite fine, thanks! how about yourself?
[05:38] <pitti> didrocks: congrats about landing oneconf!
[05:39] <didrocks> pitti: I'm fine as well, thanks, it's some kind of a relief TBH. Just to check again with isd guys now when the server will be in production :)
[05:39] <pitti> jasoncwarner_: ok, that helped; 91 -> 75 seconds
[05:39] <didrocks> pitti: new Qt 4.7.4 as well!
[05:39] <didrocks> and some dbusmenuqt, appmenu-qt stack to update :)
[05:39] <pitti> jasoncwarner_: so the massive IO wait during the session is gone, and now it's just generally slow everywhere
[05:39] <pitti> and X takes tons of CPU
[05:40] <pitti> jasoncwarner_: I'm afraid I can't tell much more from it now
[05:41] <pitti> it takes some 18 (!) seconds until gnome-session starts compiz
[05:41] <pitti> and even trivial things like xrdb take 5 seconds
[05:41] <jasoncwarner_> pitti: so what do we know right now then?
[05:41] <didrocks> pitti: FYI, I'll move the nux checking a little bit before (during the loader)
[05:41] <jasoncwarner_> did we learn anything that we can fix?
[05:42] <pitti> jasoncwarner_: yes, aptd, initramfs wait for root device, and general pointless waiting in GNOME
[05:42] <pitti> jasoncwarner_: but I don't know what's so wrong on your particular system
[05:42] <pitti> it's like you were using the VESA driver or so
[05:44] <pitti> jasoncwarner_: just that it's not a general problem that happens everywhere
[05:45] <BigWhale> Good Morning
[05:51] <RAOF> Mine does quite a lot of CPU spinning in X, and gnome-session takes ages to start compiz, too.
[05:51] <TheMuso> pitti: I noticed that you uploaded pygobject 2.90.2. Any reason why you didn't upload 2.90.3? I need 2.90.3 for the latest orca update.
[05:52] <didrocks> hey TheMuso! Btw, do you activate now QT_ACCESSIBLITY=1 when accessibility is enabled?
[05:54] <pitti> TheMuso: I'm currently packaging it
[05:54] <jbicha> didrocks: oneconf isn't fully operational yet then?
[05:54] <TheMuso> didrocks: No, will be uploading a new at-spi2-core either today or Monday to turn that on.
[05:54] <TheMuso> pitti: ok thanks.
[05:54] <didrocks> jbicha: not the server part, it's waiting for going in production
[05:54] <didrocks> TheMuso: excellent, thanks :)
[05:58] <pitti> TheMuso: working fine here; uploading to experimental/oneiric now
[05:59] <TheMuso> pitti: ok thanks.
[06:00] <pitti> jbicha: do you know what gnome-power-manager does these days? seems it's pretty much obsolete since it moved into g-settings-daemon?
[06:01] <pitti> jbicha: I'll sponsor your updates now, thanks!
[06:01] <jbicha> pitti: it still provides gnome-power-statistics which you can see when you click on an item in the power menu
[06:01] <pitti> jbicha: in fact I dropped it from the seeds yesterday
[06:02] <jbicha> I have no idea what else it does
[06:02] <pitti> jbicha: aah
[06:02] <pitti> right, that's the only thing I found
[06:03] <jbicha> pitti: ok, the statistics looked a bit out-dated
[06:05] <rickspencer3> good morning all
[06:06] <pitti> hey rickspencer3
[06:06] <rickspencer3> pitti, if I dist-upgrade today, will I get a usable system?
[06:06] <jbicha> rickspencer3: now that we're in beta, have photobomb sales improved?
[06:06]  * rickspencer3 is worried about cracky post B1 uploads
[06:07] <pitti> rickspencer3: from beta-1?
[06:07] <rickspencer3> jbicha, well, I am only selling it on Natty
[06:07] <pitti> rickspencer3: I upgraded and rebooted, working fine here
[06:07] <rickspencer3> pitti, ok
[06:07] <rickspencer3> I shall go full Oneiric today (dist-upgrade all 'puter ;))
[06:07] <pitti> rickspencer3: it was a lot, but every single one was relatively moderate
[06:07] <rickspencer3> 1 at a time of course
[06:07] <didrocks> good morning rickspencer3
[06:07] <rickspencer3> hiya didrocks
[06:08] <rickspencer3> didrocks, are you going to come down for the Oneiric release party in November?
[06:08] <didrocks> rickspencer3: yeah, as usual :-)
[06:08] <rickspencer3> sweet!
[06:08] <didrocks> the 11/11/11 IIRC :)
[06:08] <didrocks> you are coming as well?
[06:08] <rickspencer3> didrocks, of course!
[06:08] <didrocks> (the Paris one)
[06:08] <rickspencer3> no no no the Toulouse one!!
[06:09] <didrocks> ah, the Toulouse one, not sure, let's see if huats is ok to host me ;-)
[06:09] <rickspencer3> lol
[06:09] <rickspencer3> you can stay with us if he says "no" ;)
[06:09] <didrocks> rickspencer3: you should go to the parisian one as well :)
[06:09] <didrocks> heh, thanks :-)
[06:09] <rickspencer3> speaking of which, I'm going to get ready to head to huats office
[06:09] <rickspencer3> ttyl
[06:09] <didrocks> see you!
[06:11] <didrocks> robert_ancell: hey, the fact the the input window in unity greeter isn't focus is known, isn't it?
[06:11] <robert_ancell> yes, should be fixed on master
[06:13] <didrocks> robert_ancell: excellent! Also, I wait to tackle next week the pre-unity test (during user typing), we discussed about patching unity-greeter for that, isn't it?
[06:13] <robert_ancell> didrocks, yes
[06:14] <didrocks> robert_ancell: ok, will propose a patch shortly, will look where it's the best ;)
[06:20]  * pitti grabs a few more GNOME updates to package
[06:20] <didrocks> pitti: I'll talk to Neil about the unity/compiz slowdown
[06:21] <chrisccoulson> wow, viewing my own bootchart here consistently crashes X
[06:21] <ricotz> pitti, good morning, could you restart https://launchpad.net/ubuntu/+source/evolution-data-server/3.1.5-0ubuntu2/+build/2759340 it shouldnt fail if it catches up vala 0.13.3
[06:22] <pitti> ricotz: done
[06:22] <pitti> chrisccoulson: eek, that sounds bad
[06:23] <pitti> chrisccoulson: buffer overflows which crash X are security-ish
[06:23] <chrisccoulson> pitti - i'll share one of my bootcharts. my situation is even more dire than jasoncwarner_ ;)
[06:23] <chrisccoulson> i seem to have a similar problem, but on an even worse scale
[06:25] <ricotz> pitti, thanks
[06:27] <chrisccoulson> huh, what happened to the nautilus integration for ubuntu one? i don't have any option to share files here
[06:27] <pitti> jbicha: whoops, simple-scan FTBFS on segfaulting valac :/
[06:27] <pitti> chrisccoulson: presumably it wasn't ported to GTK3?
[06:27] <pitti> U1 is still completely GTK2
[06:27] <chrisccoulson> seriously?
[06:27] <chrisccoulson> :(
[06:29] <pitti> jbicha: hm, gnome-games failed as well, with a vala type error; did you build these two with a different vala than 0.13.3-0ubuntu1?
[06:30] <jbicha> pitti: yes 13.3 was only uploaded a few hours ago
[06:31] <pitti> ah, darn; I guess gnome-games needs porting, and maybe robert_ancell has an idea how to work around the simple-scan valac segfault
[06:33] <robert_ancell> jbicha, haven't seen the simple-scan fault
[06:33] <pitti> robert_ancell: apparently it worked with valac 0.13.1, but now valac 0.13.3 segfaults when building simple-scan
[06:34] <jbicha> robert_ancell: https://launchpad.net/ubuntu/+source/simple-scan/3.1.90-0ubuntu1/+build/2760596/+files/buildlog_ubuntu-oneiric-amd64.simple-scan_3.1.90-0ubuntu1_FAILEDTOBUILD.txt.gz
[06:34] <jbicha> hmm, it works in my pbuilder though
[06:44] <jbicha> oh, my pbuilder just needed updating
[06:45] <ricotz> pitti, while you are grabbing GNOME updates, it could be useful to update glibmm2.4 to 2.29.12 before updating glib2.0 which would break it
[06:45] <BigWhale> Hmm I've noticed that dbus-daemon is taking 99$ of my CPU time
[06:45] <BigWhale> errr, that's 99% .. :>
[06:46] <pitti> ricotz: oh, ok; I'm just test-building glib2.0
[06:47] <ricotz> pitti, glib2.0 broke api and glibmm2.4 suffers from it
[06:47] <pitti> ricotz: but shoudln't glibmm2.4 be builtl against the new glib then?
[06:48] <ricotz> pitti, no the generated cpp files still have references to the timezone stuff which breaks it
[06:50] <ricotz> i mean the bindings arent generated with this build, they are already included in the tarball
[06:51] <pitti> ah
[06:51] <pitti> ricotz: so it doesn't strictly need to go before, packaging right afterwards would work fine as well?
[06:52] <ricotz> it needs to go first to prevent breaking things ;)
[06:54] <ricotz> without the updated glibmm2.4 things like inscape and gnome-system-monitor break
[06:55] <pitti> chrisccoulson: your ureadahead is completely broken
[06:56] <chrisccoulson> pitti - as in, you can't view it?
[06:56] <pitti> chrisccoulson: perhaps you can remove /var/lib/ureadahead/*pack, change "sleep 45" to "sleep 100" in /etc/init/ureadahead.conf, reboot, wait until you get /var/lib/ureadahead/*pack, and reboot again?
[06:56] <pitti> chrisccoulson: no, as in "looks horrible"
[06:57] <chrisccoulson> ok, i'll try that
[06:57] <pitti> chrisccoulson: you are drowning in IO wait, and there's hardly any HD throughput
[06:57] <pitti> you essentially spend two minutes waiting for the bits to come off the HD
[06:58] <pitti> chrisccoulson: the only things that really use CPU are aptd, gwibber, and ubuntuone..
[06:58] <chrisccoulson> pitti - yeah, that seems to tie in with my experience after it's finished booting too
[06:58] <chrisccoulson> (ie, everything grinds to a halt when I do something disk intensive)
[06:58] <chrisccoulson> and the firefox link taking 4 times as long as it used to
[06:58] <pitti> chrisccoulson: that's not due to IO wait, that's because linux sucks
[06:59] <chrisccoulson> ah, ok
[06:59] <chrisccoulson> but it's got worse ;)
[06:59] <pitti> I even get that here with a 250 MB/s SSD with virtually no latency
[06:59] <pitti> yes, muchly
[06:59] <pitti> if I rsync a CD or DVD, I can hardly do anything else
[06:59] <pitti> not even IRC
[06:59] <chrisccoulson> yeah, that's the same here too
[07:00] <pitti> that might be even worse on HDD, or better because the HDD throughput is much lower, and thus the cache gets destroyed much slower
[07:00] <pitti> I don't know
[07:00] <pitti> but from what you tell, it seems to be just as bad
[07:00] <pitti> chrisccoulson: did you ever try booting a  lucid kernel and see if that makes a difference?
[07:00] <pitti> jasoncwarner_: ^ might be worth a try
[07:01] <chrisccoulson> pitti - oh, i don't have any ureadahead pack files :/
[07:02] <RAOF> Oh, boy.  You should see my poor x200s' bootchart.
[07:09] <pitti> ricotz: ok, new glibmm building here
[07:09]  * pitti goes to have breakfast while glib, glibmm, and jhbuild are running
[07:15] <TheMuso> I'll join in the fun next week. I'll get a bootchart from my desktop I use for work, as well as my THinkpad, once both have fresh installs. :)
[07:18] <RAOF> TheMuso: Could we also have bootcharts from your mature installs?  We don't particularly want to only measure bootspeed before users have actually _used_ their system.  If it gets slow over time we should fix that, too.
[07:18] <TheMuso> RAOF: Yeah we can do that.
[07:18] <TheMuso> But I'm about EOW, so it won't be today.
[07:18] <TheMuso> RAOF: It will be interesting for my desktop because it has a radeon.
[07:22] <chrisccoulson> pitti - so, it doesn't look like there's any difference with your suggestion
[07:22] <chrisccoulson> ureadahead holds up the boot for much longer now, but the rest of it looks the same
[07:23] <pitti> chrisccoulson: hm, still lots of IO wait?
[07:23] <pitti> chrisccoulson: refreshing ureadahead seemed to do the trick for jasoncwarner_
[07:23] <pitti> it was still awfully long, but 15 seconds shorter, and no huge IO wait any more
[07:23] <chrisccoulson> pitti - yeah, IO wait for pretty much the entire boot
[07:23] <pitti> chrisccoulson: can you compare with a lucid kernel?
[07:24] <chrisccoulson> yeah, i'll try that in a bit
[07:24] <chrisccoulson> pitti - http://ubuntuone.com/6wf4aOvUGAs28c81J6JPCc
[07:24] <chrisccoulson> that's the new one
[07:25] <pitti> ah, suck
[07:25] <pitti> chrisccoulson: even ureadahead doesn't do much, look at the disk bandwidth utilization (the green line at the top)
[07:25] <pitti> 91 MB/s for two seconds, and then just sloooooow
[07:25] <chrisccoulson> oh yeah, i didn't notice that green line
[07:26] <didrocks> chrisccoulson: btw, the "inbox ony" property just affect the messaging menu, not the notification?
[07:26] <didrocks> on thunderbird ;)
[07:28] <RAOF> Hm.  Can someone with a non-intel system try opening this bootchart: http://ubuntuone.com/64uqNfyoaan2pr1Vlv0Wtt
[07:28] <RAOF> Or an intel system, of course, but beware - it might lock up X.
[07:28] <pitti> I better wait until my glib build is done
[07:28] <pitti> RAOF: in firefox or eog?
[07:29] <htorque> no problem on intel (opened in opera)
[07:29] <RAOF> eog was what was hanging for me.
[07:29] <RAOF> Let's see if firefox works..
[07:29] <RAOF> Yeah, it's apparently just eog.
[07:29] <RAOF> Man, look at that iowait.
[07:30] <pitti> RAOF: can you try shotwell?
[07:30] <pitti> that ought to use the same GNOME libs
[07:30] <RAOF> Shotwell also seems to work.
[07:31] <RAOF> htorque: In eog, firefox, or what?
[07:31] <htorque> RAOF: eog killed it
[07:32] <RAOF> And killed it in a particularly silent way.
[07:32] <htorque> i could slowly move the pointer but nothing else happened, couldn't even change to tty
[07:32] <RAOF> Yeah.  It looks like the intel driver either infinite-loops or blocks indefinitely on the kernel.
[07:32] <RAOF> The mouse pointer works, because that's special, but everything else goes away.
[07:32] <htorque> should i try it with nvidia?
[07:33] <RAOF> Yeah, why not.
[07:33] <RAOF> It shouldn't crash, but it's obviously a hard image for graphics drivers to deal with :)
[07:35]  * didrocks tackles the gnome-session update
[07:36] <htorque> RAOF: yes, works fine with nouveau.
[07:36] <RAOF> htorque: Yeah, thought so.  Since I can easily reproduce it, I'll do the hunting.
[07:36] <htorque> good luck! :)
[07:36] <RAOF> Ooops.
[07:37] <RAOF> Opening that in firefox can also apparently kill X.  Although this time it was a crash, rather than a EQ overflow.
[07:42] <htorque> RAOF: no crash here when opening it with FF
[07:43] <RAOF> Happened on sandybridge, not gm45, and when scrolling while zoomed in before the image had fully loaded.
[07:43] <RAOF> I don't particularly want to reproduce that right now, though.  I like my X session :)
[07:50]  * didrocks reboots with the new gnome-session
[08:06] <xclaesse> hm, still missing gir for libaccountsservice
[08:06] <xclaesse> needed to run latest gnome-shell
[08:15] <jbicha> I don't suppose any of you have tried sushi, the new previewer for Nautilus
[08:19] <huats> morning
[08:24] <jasoncwarner_> pitti didrocks anyone? Anyone know when the 2 ubuntu one's in system settings will become one item in system settings?
[08:24] <jasoncwarner_> feel that thing is dragging on there.
[08:24] <jasoncwarner_> is ken online? (nope..answers own question)
[08:24] <pitti> jasoncwarner_: question for rodrigo, I guess
[08:25] <didrocks> I don't really know TBH, I just have one there?
[08:25] <jasoncwarner_> ok..I'll see when Rodrigo get's online...thanks
[08:27] <didrocks> pitti: can you force the retracer to get bug #839382 quickly? the fts extension cjk patch makes zg-daemon crashing (hopefully, I had the debug symbol for the fts part locally, so even if I didn't push it yet, we have it there, but would be nice to have the rest of the xapian part
[08:28] <pitti> hm, it shouldn't take that long in teh first place
[08:28] <didrocks> pitti: oh ok, in that case, that's fine :)
[08:28] <pitti> didrocks: when was it reported?
[08:28] <didrocks> pitti: just reported it, but as sometimes it took a lot of day because of the retracers being on and off…
[08:28] <pitti> didrocks: and which arch? I can run it right now if you are waiting for it
[08:29] <didrocks> pitti: is your new version get no issue anymore since you moved out of a chroot?
[08:29] <pitti> didrocks: oh, was that during your holidays?
[08:29] <pitti> I rewrote the entire thing
[08:29] <pitti> and because it's so robust and fast now, I run the retracers every 15 minutes instead of 30
[08:29] <pitti> didrocks: no, it has run happily for the past week
[08:29] <didrocks> pitti: yeah, I saw your blog post, robustness was really bumped by that? nice :)
[08:29] <didrocks> excellent!
[08:30] <pitti> didrocks: i386 starts in 3 minutes, amd64 in 10
[08:30] <didrocks> so ok, 15 minutes should be enough, no worry :
[08:30] <didrocks> ):)
[08:30] <didrocks> thanks
[08:33] <pitti> didrocks: there you go
[08:33] <pitti> not very useful, though, I'm afraid
[08:34] <didrocks> pitti: urgh, indeed :/
[08:35] <didrocks> ok, so zg-extension 0.0.9 is messy with this cjk support, I'll get kamstrup to test his release :-)
[08:40] <chrisccoulson> pitti, the lucid kernel didn't seem to make any difference btw
[08:42] <htorque> chrisccoulson: just another idea: have you checked your hard disk for bad sectors etc.?
[08:42] <chrisccoulson> yes
[08:42] <pitti> cyphermox: you didn't commit your last gnome-icon-theme uplaod to bzr, doing now
[08:59] <rodrigo_> am I online?
[09:00] <pitti> hey rodrigo_
[09:00] <rodrigo_> hi pitti
[09:00] <rodrigo_> power going down and up because of a storm :(
[09:00] <pitti> uh
[09:04] <ronoc> pitti, besides mvo who else works on apt ?
[09:05] <pitti> ronoc: David Kalnischkies is a very active contributor these days, but I don't know whether he IRCs
[09:05] <ronoc> pitti, grand I'll wait for mvo, i have bug for him :)
[09:05] <ronoc> thanks
[09:05] <pitti> ronoc: he's on holidays this week
[09:05] <ronoc> pitti, sure, is he back next week ?
[09:06] <pitti> not sure whethher it's one or two weeks
[09:06] <ronoc> no panic
[09:06] <ronoc> its not a massive bug
[09:06] <ronoc> wrong signature on a variant he is returning
[09:08] <RAOF> pitti: It's just occurred to me that reading the bootchart output to try to determine how drm in the initramfs affects boot time is not actually going to measure the right thing.  Is there a better way than stopwatch-time-to-X?
[09:12] <xclaesse> seems upstream has a fix for https://bugzilla.gnome.org/show_bug.cgi?id=657225
[09:12] <ubot2`> Gnome bug 657225 in general "Missing dep on libGL" [Normal,Assigned]
[09:13] <xclaesse> could that be pulled into ubuntu please? :D
[09:13] <pitti> RAOF: bootchart2 has been around for some time, and is said to be massively better, but I haven't tried it yet
[09:14] <pitti> RAOF: stopwatch time is actually not that bad
[09:14] <pitti> RAOF: as bootchart itself has quite a high impact on the boot (some 5 or 10 percent, depending on the machine speed)
[09:14] <RAOF> pitti: Can bootchart2 measure time-from-bios rather than time-from-kernel-load?
[09:14] <pitti> I doubt it
[09:14] <pitti> you need the kernel and initramfs started before you can start anything like bootchart
[09:15] <RAOF> I guess I can just try stopwatch time; my bootchart seems to suggest throwing drm in the initramfs is a slight win, which is probably because it doesn't need to load it from disc again :)
[09:20] <jbicha> rodrigo_: could we hide the useless "Checking for Updates" in System Info...or maybe tie it into Update Manager so it works?
[09:21] <rodrigo_> jbicha, it works here, and runs update-manager instead of packagekit one
[09:21] <rodrigo_> jbicha, it doesn0t work for you?
[09:22] <jbicha> rodrigo_: no, maybe I should reboot, I had some packagekit remains on my computer which might be confusing it
[09:23] <rodrigo_> jbicha, yes, it uses the Dbus API from PK, which we implement, so it should work
[09:28] <pitti> bigon: hey, how are you?
[09:29] <pitti> bigon: you have a lot of staged changes in libnotify svn, is that ok to upload? I'd like to update svn to 0.7.4
[09:30] <bigon> pitti: it's multiarch changes
[09:30] <bigon> mainly
[09:30] <pitti> right
[09:30] <pitti> which are fine for unstable now
[09:30] <bigon> yep
[09:30] <bigon> so it's ok for me
[09:32] <jbicha> rodrigo_: my Disk always reads "Calculating..." in System Info too
[09:34] <rodrigo_> jbicha, yes, also for me, looking...
[09:34] <jbicha> rodrigo_: http://paste.ubuntu.com/680409/
[09:34] <rodrigo_> ok
[09:36] <jbicha> I wish System Settings were smart enough to hide Wacom & Bluetooth from users like me who don't have them
[09:37] <jbicha> although based on their panels, Wacom looks way cooler than Bluetooth
[09:56]  * didrocks reboots
[10:09] <dupondje> somebody else hit the bug that NetworkManager in debug doesn't set dns servers?
[10:14] <jbicha> pitti: robert_ancell fixed the gnome-games vala compiling but I think I'll just wait for 3.1.91 which should be in a couple days
[10:15] <pitti> jbicha: hm; might be nice to test .90, depending on how many changes it got; but a few days sounds fine
[10:16] <jbicha> only a few lines of code changed since 3.1.5
[10:18] <jbicha> 2 betas in a week is pretty fast
[10:20] <jbicha> will the software-center-gtk3 binary be renamed to software-center before release? I think it might mess up the launcher icon for upgrades otherwise
[10:20] <pitti> jbicha: I think so, yes; we'll probably drop gtk2 entirely
[10:20] <jst> @ricotz
[10:20] <pitti> jbicha: or at least rename it to -gtk2, and -gtk3 becomes s-c
[10:20] <pitti> jbicha: but when we switched it wasn't 100% sure that we'll keep it
[10:22] <jst> whois jst
[10:22] <jbicha> pitti: right, it's pretty usable now though :-)
[10:30] <ronoc> pitti, how do i file an UI exception ?
[10:31] <pitti> ronoc: file a bug against the package, and subscribe ubuntu-release
[10:31] <pitti> ronoc: https://wiki.ubuntu.com/FreezeExceptionProcess
[10:31] <ronoc> pitti, great thanks
[10:31] <ronoc> pitti, lovely
[10:31] <pitti> I have to leave now to catch a train
[10:31] <ronoc> safe travels !
[10:31] <pitti> I probably won't be around much this afternoon, the week was long enough with the release and all that
[10:32] <ronoc> aye, good w/end
[10:32] <pitti> see you on Monday!
[10:32] <ronoc> take it easy
[10:34] <didrocks> pitti: see you on Monday pitti :)
[10:43] <rodrigo_> jbicha, sorry, got power down again
[10:43] <rodrigo_> jbicha, do you have sessioninstaller installed?
[10:44] <jbicha> rodrigo_: no, would you like me to install it
[10:44] <jbicha> sorry about your power trouble :-(
[10:45] <rodrigo_> jbicha, well, that won't solve the problem, but it's the one providing the PK dbus API
[10:45] <rodrigo_> but yes, there's something wrong here also
[10:46] <rodrigo_> Disk info is all the time calculating
[10:46] <rodrigo_> and I get no upgrade buttons
[11:36] <pitti> argh, I screwed up gdbus-codegen in glib, fixing
[11:43] <pitti> anyway, will go offline, spotty 2G on the train
[11:43] <pitti> see you on Monday!
[11:43] <rodrigo_> bye pitti, have a good weekend!
[11:51] <didrocks> rodrigo_: hey, did you finallly track the decorator issue btw?
[11:53] <rodrigo_> didrocks, no, still looking at it
[11:53] <rodrigo_> didrocks, I updated the patch to change both gconf keys, but still doesn't work until you log out and back in
[11:53] <didrocks> rodrigo_: that's really weird, is there a bug to track it?
[11:53] <didrocks> yeah, that's weird :/
[11:53] <rodrigo_> hmm, not that I know
[11:54] <didrocks> we should open one, will do it next week
[11:54] <rodrigo_> ok cool
[11:59] <dupondje> Somebody around that can run NetworkManager in debug mode and see if it setting the resolv.conf?
[12:02] <didrocks> rodrigo_: don't you think it can be gsd not notifying anymore on gconf key change?
[12:02] <GunnarHj> pitti: Hi Martin, suggesting two items for your (or someone else's) todo-list:
[12:03] <rodrigo_> didrocks, the notification is done by gconf itself, isn't it?
[12:03] <didrocks> rodrigo_: oh right, would maybe worse checking the notification is still done? just a silly idea…
[12:04] <rodrigo_> didrocks, not sure that's the problem, gconf-editor shows the change correctly
[12:05] <didrocks> you're right :/
[12:06] <GunnarHj> 1. bug #833065 - see the latest comments
[12:06] <GunnarHj> 2. can't start gdm-guest-session in gdm 3; the description in the lightdm bug #799950 covers also the gdm side of it.
[12:06] <ubot2`> Launchpad bug 833065 in language-selector "fontconfig-voodoo crashed with TypeError in getUserDefaultLanguage(): expected string or buffer" [High,Fix released] https://launchpad.net/bugs/833065
[12:06] <ubot2`> Launchpad bug 799950 in lightdm "Can't launch guest session from a LightDM session" [Low,Triaged] https://launchpad.net/bugs/799950
[12:06] <rodrigo_> didrocks, I think the problem might be gnome-shell and unity not listening to the change?
[12:07] <rodrigo_> didrocks, can you check what does unity do and I'll check gnome-shell?
[12:07] <didrocks> rodrigo_: it's not unity, it's metacity or compiz and the code didn't change
[12:07] <rodrigo_> right, for the unity cause it's compiz, so it should be as it was before
[12:08] <didrocks> rodrigo_: and metacity code didn't change a lot…
[12:08] <didrocks> rodrigo_: it's using libmetacity-private (compiz), not sure what mutter is using
[12:08] <rodrigo_> right
[12:08] <rodrigo_> there was a similar bug with keybindings in gconf, so it's starting to look a gconf problem
[12:09] <rodrigo_> I'll think more about it while having lunch :-)
[12:09] <rodrigo_> bbl
[12:09] <didrocks> like ctrl + alt + T not working?
[12:09] <didrocks> rodrigo_: enjoy! :)
[12:10] <didrocks> chrisccoulson: oh, speaking of small issues to get the release done, do you have a lot of part of thunderbird that appears as transparent as well? (like the statusbar)
[12:10] <didrocks> chrisccoulson: got that on metacity and compiz
[12:10] <rodrigo_> didrocks, the bug I refer to is about the screenshot keybindings
[12:10] <rodrigo_> didrocks, but yeah, bbiab
[13:05] <asac> hello! asac's friday challenge: if i click on the keyboard preferences, the gnome control center opens and i cannot find the UI for changing keyboard layout anymore.
[13:06] <asac> tried to find the direct command on cmdline without luck :/
[13:06] <asac> oneiric latest that is
[13:08] <jbicha> asac: gnome-control-center region
[13:09] <asac> will try after reboot
[13:09] <asac> bbib
[13:17] <nessita> pitti: p[ing
[13:23] <didrocks> nessita: hey, he's away for the week-end
[13:24] <nessita> didrocks: oh, ok :-)
[13:24] <nessita> maybe someone knows about this:
[13:25] <nessita> would these traces ring any bell for anyone? http://pastebin.ubuntu.com/680551/ I think they are related to the gi changes pitti added a couple of weeks ago. The maverick builds for the controlpanel are failing with that, so I guess some of the changes are not that compatible with gi in maverick
[13:26] <didrocks> nessita: waow, maverick? gi is changing a lot I would even don't dare trying on natty
[13:27] <nessita> didrocks: the changes we added were "small" (try-except clauses to use gobject if already import, Gobject if not)
[13:27] <nessita> I thought that was "harmless" for older releases
[13:28] <didrocks> nessita: not that you can't mix anymore pygi things and pygtk, is it the issue?
[13:29] <nessita> I would guess, but in these traces the problem occurs when using libSoup
[13:49] <rodrigo_> hey nessita
[13:50] <rodrigo_> nessita, do you work on ubuntuone-installer?
[13:51] <nessita> rodrigo_: nopes, dobey does. Can I help?
[13:52] <rodrigo_> nessita, dobey: the .desktop file contains the magic to show it on the gnome-control-center (Categories and the X-GNOME-Settings-Panel field), which is wrong since it shouldn't show up on the control center
[13:53] <nessita> rodrigo_: can you please report a bug in the project?
[13:53] <rodrigo_> nessita, yes
[14:04] <rodrigo_> nessita, there's already one -> https://bugs.launchpad.net/ubuntuone-installer/+bug/838778
[14:05] <ubot2`> Ubuntu bug 838778 in ubuntuone-installer "After installing Ubuntu One, there are 2 Ubuntu One launchers in System Settings" [Undecided,New]
[14:06] <nessita> rodrigo_: ack, I'll ping dobey on Monday
[14:09] <rodrigo_> nessita, ok
[16:47] <didrocks> ok, time for week-end! see you on Monday everyone :)
[17:34] <tjaalton> slomo_: hey, are you planning on backporting the fix to gnome bug 656018 for oneiric?
[17:34] <ubot2`> Gnome bug 656018 in don't know "crash playing some mp3's" [Critical,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=656018
[18:44] <dupondje> Somebody around for a NetworkManager issue/bug?
[18:52] <dupondje> lol
[18:53] <dupondje> somebody smelled my issue I guess
[18:53] <dupondje> latest upload fixed it :)
[18:55] <dupondje> cyphermox: thx!
[18:56] <cyphermox> moo?
[18:56] <cyphermox> what was your issue? ;)
[18:56] <dupondje> when making vpn connection
[18:56] <dupondje> default route was not set
[18:56] <dupondje> its is now :)
[18:56] <cyphermox> aye
[18:57] <cyphermox> there was something broken in the way netlink was used to replace the default route (it wasn't passing the "replace" flag ;)
[18:57] <dupondje> well yea :) it fixed it :D
[18:57] <dupondje> still have the other issue tho
[18:57] <dupondje> if I run networkmanager in debug, it doesnt set resolv.conf ...
[18:58] <dupondje> but ok :) no need to debug anymore, as the reason I needed debug is gone :)
[19:04] <cyphermox> dupondje: doesn't set resolv.conf, I'm pretty sure there's a but open about that (iirc kees opened something similar)
[19:05] <cyphermox> I'll get to it soon, probably while I figure out stgraber's issue with DNSLL
[19:05] <dupondje> cyphermox: can't see that directly on lp, but yea, not really a breaker now :)
[19:06] <cyphermox> well, it's not going to help though, but np
[19:06] <dupondje> I'll fix a bugreport if you want ...
[19:06] <dupondje> any info you need ?
[19:12] <cyphermox> well, just syslog, so ubuntu-bug network-manager will do everything for you
[19:13] <cyphermox> actually, attaching the resolv.conf (once cleaned if you have any sensitive info there) would help too, so I can see what it looks like "broken"
[19:13] <dupondje> well its empty :)
[19:13] <cyphermox> ok, then just specify that :)
[19:14] <cyphermox> is it just for VPN or just any connection?
[19:14] <dupondje> any
[19:14] <dupondje> only breaks when I have it in debug mode
[19:14] <dupondje> really weird
[19:17] <dupondje> let me fix a bug
[19:17] <dupondje> brb
[19:17] <cyphermox> ok
[19:25] <dupondje> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/839836
[19:25] <ubot2`> Ubuntu bug 839836 in network-manager "resolv.conf empty when running in debug" [Undecided,New]
[19:30] <cyphermox> thanks!
[20:52] <sergio91pt> Hi, I noticed, in gconf, that /desktop/gnome/applications/calendar/exec is set to evolution by default..
[20:52] <sergio91pt> Won't that cause any problems?