[00:00] <fagan> seb128_: thats what confused me
[00:00] <fagan> it was there in karmic
[00:00] <fagan> but on a fresh install of lucid a few days ago its gone
[00:00] <seb128_> well bugs happen
[00:01] <fagan> ill debug it tomorrow and see were the error lies
[00:03] <seb128_> fagan, do you get a /proc/acpi/battery?
[00:05] <fagan> yep its there
[00:05] <seb128_> the status is correc too?
[00:05] <seb128_> the status is correct too?
[00:06] <seb128_> TheMuso, hey
[00:06] <seb128_> TheMuso, are you still interested in doing the gnome-media update?
[00:06] <fagan> Well when im on battery its detected and it appears in the notification area
[00:06] <seb128_> TheMuso, there is a new version available for some weeks, not sure if you want to work on it
[00:07] <chrisccoulson> fagan - what is in /sys/class/power_supply?
[00:07] <fagan> chrisccoulson: ADP1  BAT0
[00:08] <chrisccoulson> hmmm, so, the battery is detected then
[00:08] <fagan> ill grab a screen of the bug if you want
[00:08] <seb128_> will the dkpower log is clearly buggy
[00:08] <seb128_> it lists no battery
[00:09] <fagan> ah that must be it
[00:14] <chrisccoulson> fagan - did you figure it out?
[00:14] <fagan> nope
[00:15] <fagan> I was just agreeing with seb128_ that that may be the problem
[00:15] <fagan> so devkitpower must be not picking up on the battery
[00:16] <seb128_> good night there
[00:16] <fagan> night seb128_
[00:17] <chrisccoulson> night seb128_
[00:20] <fagan> chrisccoulson: ill have a chat with pitti tomorrow and see if he can figure it out
[01:22] <huats> didrocks, bug 513038
[01:47] <LLStarks> hi.
[01:48] <LLStarks> i was wondering if someone can help me find a bug report that sebastien says already exists, but won't link  to.
[01:49] <LLStarks> the proper bug for this: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/502784
[01:50] <LLStarks> a bug i'd like to track, but not have to waste hours tracking down
[01:50] <fagan> LLStarks: wait for seb he will be back on tomorrow
[01:50] <fagan> its late in europe
[01:51] <LLStarks> k
[01:53] <LLStarks> i don't blame him for having his hands full and being unable to remember every single bug number to link from duplicates, but it certainly helps when the original bug is linked when a duplicate is closed. i have a vested interest in seeing the well-intentioned dupes that i report get fixed.
[01:54] <LLStarks> nothing screams dead-end like an invalid with no indication of what the actual afflicted package is
[01:55] <LLStarks> it's not transparent enough
[01:55] <fagan> LLStarks: seb is awesome he would know if it was a dup or not but id say he cant remember them all
[01:56] <fagan> LLStarks: it is transparent
[01:56] <fagan> but you cant expect the devs to drop what they are doing to fix something on the wishlist
[01:57] <LLStarks> that's not what i'm asking
[01:57] <fagan> Its fine
[01:57] <LLStarks> all i ask is that dupes are linked instead of a generic "i can't remember or link the bug, but i already know about it".
[01:57] <LLStarks> that's annoying
[01:58] <LLStarks> because i can't follow anymore
[01:58] <fagan> LLStarks: he takes care of a lot of bugs id trust that he did see it
[01:59] <fagan> Someone would take care of it if it was important
[02:01] <LLStarks> that doesn't change my concerns, where do i go from here? seb hasn't given me any information that would guide me to the proper bug.
[02:02] <LLStarks> i don't know the package or even the proper way to describe the bug so that i could find it
[02:02] <LLStarks> all i have is an invalid  unlabeled dupe.
[02:03] <LLStarks> this isn't the first time i've run into this problem with seb's way of doing things.
[02:07] <chrisccoulson> LLStarks - you say "a bug i'd like to track, but not have to waste hours tracking down", but you expect us to waste hours tracking these down instead?
[02:07] <chrisccoulson> that's not productive use of our time...
[02:07] <LLStarks> it's difficult to search for a bug when i don't even know the proper package
[02:08] <LLStarks> that's the problem.
[02:08] <LLStarks> i don't need a link.
[02:09] <LLStarks> if he had said "it's not nautilus, it's PackageX" that would be enough
[02:10] <LLStarks> launchpad search is pretty useless you know the proper package to bugsearch
[02:11] <LLStarks> is even this unreasonable to ask for?
[06:04] <pitti> Good morning
[06:21] <baptistemm> hello pitti
[06:31] <robert_ancell> pitti, hey
[06:31] <pitti> hey baptistemm
[06:31] <pitti> robert_ancell: good morning!
[06:31] <robert_ancell> pitti, thanks for the simple-scan MIR!
[06:31] <pitti> robert_ancell: you're welcome; just sponsored your new package
[06:32] <robert_ancell> thanks
[06:39] <robert_ancell> bratsche, hi
[06:39] <bratsche> Hey!
[06:56] <pitti> TheMuso: hey
[06:57] <pitti> TheMuso: WDYT about changing pulseaudio to drop /etc/xdg/autostart/pulseaudio.desktop and /usr/bin/start-pulseaudio-x11, and instead enabling the three modules in default.pa? that would save some startup overhead
[06:58] <pitti> ah, I'll file a bug for it
[07:03] <pitti> TheMuso: filed as bug 513120 now; let's discuss it there
[07:58] <didrocks> good morning
[08:06] <pitti> bonjour didrocks
[08:07] <didrocks> hey pitti, how are you?
[08:07] <pitti> I'm great, thanks! did you sleep well?
[08:08] <didrocks> oh yes, thanks, long and resting night :-)
[08:22] <seb128> hey
[08:23] <didrocks> hey seb128
[08:23] <didrocks> seb128: thanks for the sponsoring yesterday
[08:23] <didrocks> how are you?
[08:23] <seb128> good! you?
[08:23] <pitti> bonjour seb128
[08:23] <seb128> you're welcome
[08:23] <seb128> hey didrocks, hey pitti
[08:24] <seb128> had a good night?
[08:24] <pitti> yes, indeed
[08:24] <didrocks> so do I :)
[08:24] <pitti> went to bed at 22:15 yesterday, I was so tired :)
[08:24] <pitti> so I got up at 6:30 again
[08:24] <seb128> waouh
[08:24] <seb128> I should do that too
[08:24] <seb128> I went to bed after 1am again yesterday
[08:25] <seb128> I don't feel tired in the evening
[08:25] <pitti> well, as long as you sleep long
[08:25] <seb128> but I do in the morning next day
[08:25] <pitti> usually I go to bed past midnight, too
[08:25] <pitti> it seems to be a more natural cycle for me
[08:26] <seb128> right, I like 1am to 8am
[08:26] <seb128> as sleep cycle I mean
[08:37] <seb128> pitti, btw do you have the xul greasmonkey package installed?
[08:37] <seb128> pitti, I got the "firefox is not starting after upgrade" issue yesterday too
[08:37] <pitti> seb128: I got it again today
[08:37] <seb128> pitti, it was due to greasemonkey for me
[08:37] <pitti> I blame the langpacks
[08:37] <seb128> uninstalling it make it work
[08:38] <pitti> ah, indeed
[08:38] <pitti> can be
[08:38] <pitti> I removed all extensions again today
[08:38] <pitti> and right now I don't have greasemonkey
[08:38] <seb128> ok
[08:38] <seb128> here firefox exit on start without error when it's installed
[08:38] <seb128> and works when I uninstall it
[08:47] <seb128> pitti, do you want me to have a look to what nm-applet is doing?
[08:47] <seb128> pitti, I was going to do that but I noticed you just edited the whiteboard about it
[08:47] <pitti> seb128: sure, that'd be great
[08:47] <pitti> seb128: oh, I just fixed the duplicate
[08:47] <pitti> there were two items for the same nm-applet thing
[08:47] <seb128> ok
[08:47] <seb128> doing that then
[08:49] <seb128> pitti, oh btw the 2 seconds g-s-d gap on our laptops is xrandr indeed
[08:49] <pitti> ah, ok
[08:49] <seb128> pitti, having a .xml config or not makes no difference
[08:49] <seb128> neither do being docked or not
[08:49] <seb128> but if I turn the xrandr off in gconf the 2 seconds gap go away
[08:49] <seb128> I guess it's the screen probing g-s-d does for the magic key to be working etc
[08:50] <seb128> seems xorg is busy during that time on the chart
[08:50] <seb128> I'm not sure why it's not an issue on the mini though
[08:50] <pitti> no external TFT?
[08:55] <seb128> bah launchpad going down in 5 minutes
[08:55] <seb128> can't they do that out of work hours ;-)
[08:56] <chrisccoulson> i just thought the same thing there too ;)
[08:57] <chrisccoulson> i never see announcements for LP going down any more. perhaps i'm subscribed to the wrong mailing lists
[08:57] <mvo> I hope my bzr push finishes in time
[08:57] <mvo> (or is not affected by the LP maintainace)
[08:58] <pitti> well, you can still use staging to read bugs :)
[08:59] <Hobbsee> o
[08:59] <chrisccoulson> seb128 / pitti - i wonder if gsd could use the less expensive XRRGetScreenResourcesCurrent call when starting up, rather than XRRGetScreenResources, which does a re-probe and is slow
[09:00] <pitti> chrisccoulson: perhaps you can ask tseliot when he comes back online? he dealt with this quite a lot in the past
[09:00] <chrisccoulson> i suppose that would only work if X probes the monitors when it starts, and all the information requested is already up-to-date
[09:00] <chrisccoulson> yeah, i might ask him
[09:00] <chrisccoulson> other than that, i don't know of any way to avoid that
[09:00] <pitti> but doesn't it?
[09:00] <pitti> (I mean X probing monitors)
[09:00] <seb128> chrisccoulson, they are announced on launchpad-announce
[09:00] <pitti> the log has everything about it, after all
[09:01] <chrisccoulson> pitti - thats what i'm thinking. perhaps we are actually probing the monitors twice here
[09:03] <seb128> chrisccoulson, gnome-desktop already has code for that apparently
[09:03] <seb128> #if (RANDR_MAJOR > 1 || (RANDR_MAJOR == 1 && RANDR_MINOR >= 3))
[09:03] <seb128>         /* Runtime check for RandR 1.3 or higher */
[09:03] <seb128>         if (info->screen->rr_major_version == 1 && info->screen->rr_minor_version >= 3)
[09:03] <seb128>             resources = XRRGetScreenResourcesCurrent
[09:04] <seb128> ...
[09:04] <seb128> but it has a "needs_reprobe" too
[09:04] <chrisccoulson> seb128 - it does, but when you call gnome_rr_screen_new, it calls it with needs_reprobe
[09:04] <seb128> and it calls XRRGetScreenResources() in those case
[09:04] <seb128> I'm leaning toward saying that if somebody did that it's for a reason
[09:04] <seb128> but maybe not ;-)
[09:05] <chrisccoulson> seb128 - yeah, i think you're probably right
[09:05] <Ng> aha, I might have an idea about what causes the gnome screensaver password pop-under bug. It happened just now and just at the same time docky was calling attention to itself because of the Mounter applet seeing my phone
[09:06] <chrisccoulson> screensaver pop-under?
[09:06] <Ng> chrisccoulson: twice ever, I've unsuspended my laptop and been typing my password to a screensaver unlock "screen" that's under all my desktop stuff (I only know this because my desktop is always covered in translucent terminals, so I can see the unlock dialog through them
[09:06] <Ng> I filed a bug last time, just looking for it now
[09:07] <Ng> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/487165
[09:09] <chrisccoulson> oh, it's reported against compiz. that's why i didn't notice it reported
[09:10] <Ng> chrisccoulson: it seemed like the most appropriate place, but I can open a task against gnome-screensaver if that should be taking more defensive measures to prevent this happening. I kinda assumed it was up to the window manager to enforce whatever policy gnome screensaver requests
[09:11] <chrisccoulson> Ng - yeah, it's more likely a WM issue
[09:16] <pitti> chrisccoulson: and there's tseliot :)
[09:20] <didrocks> updating brasero
[09:20] <didrocks> seb128: ^
[09:21] <didrocks> well, when I will be able to branch again :)
[09:21] <seb128> didrocks, ok
[09:21] <seb128> didrocks, well launchpad is supposed to be down for 2.5 hours
[09:22] <didrocks> seb128: right, I'm reading/writing some docs in the meanwhile (that's good, I had that planned but never prioritarized it)
[09:49] <chrisccoulson> Ng - for your screensaver issue, could you switch to a console when the issue happens, and run "DISPLAY=:0.0 xprop -root | grep _NET_ACTIVE_WINDOW"
[09:49] <Ng> chrisccoulson: I'll leave that on a post-it note for whenever it next happens :)
[09:49] <chrisccoulson> and then run "DISPLAY=:0.0 xprop -id <id>", where <id> is the window ID from the last command
[09:50] <chrisccoulson> you might need to tweak the display number there as well
[09:50] <Ng> chrisccoulson: out of curiosity, what will this tell us?
[09:51] <chrisccoulson> it will tell us what the WM thinks the current focused window is
[09:59] <Ng> ok
[09:59] <Ng> fwiw, from my perspective the unlock dialog totally had focus, I couldn't deliver keyboard or mouse events to anything else (and I really tried, to see if I should escalate my complaining to screaming ;)
[09:59] <Ng> but I'll get that info if I see it again
[10:03] <chrisccoulson> Ng - it might be worth providing the full output of xprop -root is actually, as that will also indicate what the WM thinks the windowing order is
[10:04] <Ng> ok
[11:03] <TheMuso> pitti: afaik crimsun said something about that earlier, don't know if you saw it. I'll dig it up if not.
[11:04] <pitti> TheMuso: hm, seems I missed it then; I got thrown out of the channel over night, apparently I wasn't registered to freenode
[11:05] <TheMuso> pitti: ah ok, I'll dig it out of logs.
[11:07] <TheMuso> 10:28:01 < crimsun> pitti: there is a rather stern warning in default.pa that says that X11 modules shouldn't be loaded from default.pa.
[11:08] <pitti> # X11 modules should not be started from default.pa so that one daemon
[11:08] <pitti> # can be shared by multiple sessions.
[11:08] <pitti> I don't understand that, though
[11:08] <pitti> if you use pactl to add another module at runtime, it will affect the other sessions as well if you share the daemon
[11:09] <pitti> if that means "by multiple users", I'd agree, but that's what /etc/pulse/system.pa is for?
[11:09] <pitti> crimsun: ^
[11:23] <didrocks> seb128: huats asked me to sponsor gtksourceview2 update, but I got a rejection, can you do in whenever you have some free time, please? bug #513038
[11:24] <seb128> didrocks, ok
[11:24] <didrocks> thanks :-)
[11:24] <seb128> np
[11:24]  * pitti finishes measuring impact of autostart files
[11:25] <seb128> pitti, what is the result?
[11:25] <pitti> added to https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed
[11:25] <pitti> it also has a link to the detailled charts
[11:25] <seb128> boot speed is quite depressing
[11:25] <pitti> nothign too surprising
[11:26] <pitti>  - essentials: g-p-m, g-s-d, nm-applet, screensaver: 8.0 (+3.5)
[11:26] <pitti> i. e. those four increase by 3.5 seconds
[11:26] <pitti> gsd is 80% background image, though
[11:26] <seb128> " - the ones deferred with a sleep: 4.5 (+0) -> no impact, as expected"
[11:26] <seb128> bah
[11:26] <seb128> chrisccoulson, not worth doing your change maybe then
[11:27] <chrisccoulson> seb128 - yeah, i just noticed that too
[11:27] <seb128> the "add a new delay key to avoid spawning a shell etc"
[11:27] <pitti> it would just be for cleanliness
[11:27] <pitti> but not first priority indeed
[11:28] <seb128> pitti, are you sure that xdg-user-dirs spawns a shell there?
[11:28] <seb128> it's a bit weird, it's a C program
[11:28] <pitti> it first appeared in http://people.canonical.com/~pitti/bootcharts/autostart-impact/4-polkit-userdirs.png
[11:28] <pitti> checking that was next on my list
[11:29] <seb128> pitti, well it uses g_spawn_command_line_sync to call xdg-user-dirs-update...
[11:29] <pitti> $ strace -e execve xdg-user-dirs-gtk-update
[11:29] <pitti> execve("/usr/bin/xdg-user-dirs-gtk-update", ["xdg-user-dirs-gtk-update"], [/* 50 vars */]) = 0
[11:29] <pitti> hmm
[11:29] <pitti> ah
[11:30] <seb128> I doubt that costs anything
[11:31] <seb128> pitti, background rendering... would be worth testing with an image matching the screen
[11:32] <seb128> just to see what difference the rescaling does
[11:32] <seb128> that could maybe be cache too
[11:32] <seb128> cached
[11:32] <pitti> ah, indeed
[11:33] <pitti> we could at least have a special image for a _totally_ arbitrary resolution, say 1024x600 :)
[11:33] <seb128> lol
[11:33] <pitti> well, to be fair that's a pretty common netbook res
[11:34] <seb128> let's see first how much win that would make
[11:34] <seb128> pitti, btw g-s is essential?
[11:34] <seb128> or could it start 30 seconds after login
[11:34] <pitti> oh, it can for sure
[11:34] <seb128> the other ones can't really
[11:34] <pitti> seb128: I can do these four again perhaps, with separate charts for each
[11:34] <seb128> you want to go online and g-s-d sets themes, etc
[11:35] <pitti> g-s-d and nm-applet are essential indeed
[11:35] <pitti> we could cheat a bit with g-p-m
[11:35] <seb128> I was not sure about gpm
[11:35] <pitti> but seriously, it' just be circumventing bootchart
[11:35] <seb128> but I guess gnome-screensaver can be delayed after busy time
[11:35] <pitti> not change the user experience
[11:35] <seb128> we need gnome-session to send a signal "done loading"
[11:35] <pitti> this stuff all happens in the bg
[11:35] <seb128> and trigger those at this time
[11:36] <seb128> well
[11:36] <pitti> seb128: we could start g-p-m with nice level?
[11:36] <chrisccoulson> gnome-screensaver used to be deferred for 30 seconds when it was spawned by g-s-d
[11:36] <seb128> how much login speed is impacted by the number of processes?
[11:36] <pitti> number of processes by itself shouldn't matter
[11:36] <pitti> if they are mostly in poll()/sleep()
[11:36] <seb128> ie, how much tasks commutations cost us
[11:40] <seb128> lunch time bbl
[11:44] <pitti> seb128: hm, g_spawn_command_line_sync() doesn't actually invoke a shell, though
[11:44] <pitti> I guess it's coming from somewhere else then
[11:44] <pitti> LANG= strace -f -e execve /usr/bin/xdg-user-dirs-gtk-update
[11:44] <pitti> -> directly execve's /usr/bin/xdg-user-dirs-update
[12:02] <pitti> didrocks: hi
[12:03] <pitti> didrocks: so, replacing /usr/share/backgrounds/warty-final-ubuntu.png with an already correctly sized version (1024x600) halves g-s-d's CPU time
[12:04] <pitti> didrocks: in order to exploit that, we'd need to add a new feature to g-s-d to check /desktop/gnome/background/<resolution>/ first, before /desktop/gnome/background/
[12:04] <pitti> didrocks: so that we can add a warty-final-ubuntu-1024x600 and point to that in /desktop/gnome/background/1024x600/
[12:04] <pitti> didrocks: do you have enough cycles to work on that?
[12:05] <chrisccoulson> pitti - want me to do that?
[12:05] <chrisccoulson> ah
[12:05] <chrisccoulson> no worries ;)
[12:05] <pitti> chrisccoulson: if you have the cycles, sure
[12:05] <pitti> but you already have so much, and still have a dayjob, and all that :)
[12:05] <didrocks> pitti: sorry, I was having my lunch :)
[12:05] <pitti> didrocks: how can you DARE having food!?!
[12:05] <didrocks> pitti: I can work on that, yes, can you please add a WI with those info?
[12:05] <chrisccoulson> pitti - yeah, my day job is still a bit of an obstacle
[12:05] <didrocks> pitti: heh
[12:06] <pitti> didrocks: thanks; I'll add a WI for it
[12:06] <didrocks> pitti: sometimes, like 3 times a day, sorry ;)
[12:06] <pitti> *tsk*
[12:06]  * pitti hugs didrocks
[12:06]  * didrocks hugs pitti
[12:06] <pitti> and hugs chrisccoulson, too
[12:06]  * chrisccoulson hugs pitti
[12:08]  * seb128 back from lunch
[12:08] <seb128> yeah, I dare having food too :-)
[12:08] <seb128> we french need to eat!
[12:08] <didrocks> :)
[12:09] <pitti> didrocks: added
[12:09] <didrocks> pitti: thanks
[12:09] <pitti> seb128: so, that was a good hint; saves a lot of g-s-d's CPU time
[12:09] <pitti> as a revenge, I'll have lunch now!!
[12:09] <seb128> pitti, excellent
[12:09] <seb128> hehe
[12:09] <seb128> pitti, enjoy
[12:09] <didrocks> enjoy pitti!
[12:10] <seb128> didrocks, pitti: other solution would be to cache the updated image
[12:10] <seb128> didrocks, pitti: that would apply to any screen setting...
[12:10] <pitti> *nod*
[12:10] <seb128> rather than depending on us to ship an image for a special screen config
[12:10] <pitti> I don't care much about the implementation
[12:11] <seb128> well, the cache would work for user images too
[12:11] <seb128> I guess most users change their background
[12:11] <seb128> where the hacked version would benefit benchmarks mostly
[12:11] <seb128> didrocks, ^
[12:12] <didrocks> seb128: yes, that's better, so, saving the pixbuf on the disk
[12:12] <seb128> didrocks, yes
[12:13] <pitti> didrocks: WI updated
[12:13] <pitti> I removed the implementation, and just kept the effect
[12:13] <didrocks> yep :)
[12:14] <seb128> didrocks, I guess it's probably a gnome-desktop change
[12:14] <seb128> since gnome-bg apis are there
[12:14] <didrocks> at least, I'll have made some work to reduce the loading time :)
[12:14] <seb128> vuntz, there for a gnome-panel question?
[12:14] <didrocks> seb128: gnome-desktop in g-s-d?
[12:15] <seb128> didrocks, no, gnome-desktop gnome-desktop
[12:15] <seb128> the gnome-bg apis are in libgnome-desktop as said before
[12:15] <didrocks> seb128: oh ok, looking at it
[12:16] <didrocks> thanks
[12:16] <seb128> np
[12:16] <tseliot> pitti: would something like this work well for you (note: I haven't written a test for it yet)? http://pastebin.ubuntu.com/363821/
[12:17] <pitti> tseliot: looks fine to me
[12:18] <tseliot> pitti: I guess there's no need to prevent Jockey from enabling the module (in enable) if we pass do_blacklist=False
[12:18] <pitti> tseliot: no, I don't think so; if it's still in blacklist.local, it should still be removed I think
[12:18] <pitti> if for nothing else, then for upgrading
[12:19] <tseliot> pitti: right, it's what I thought
[12:20] <tseliot> bzr diff --diff-options -Nurp gives me the equivalent of diff -Nurp :-) http://pastebin.ubuntu.com/363823/
[12:21] <tseliot> s/of/for/
[12:22] <tseliot> pitti: BTW we should be able to upload the new jockey soon, thanks to Riddell
[12:25] <didrocks> seb128: do you know the difference between libgnome-desktop-2-17 and gnome-menu? I would have said that the second one is using libgnome-desktop-2-17 to open desktop file, but it's not listed as a build-dep
[12:27] <Riddell> tseliot: should be appearing in the archive as soon as publisher does its thing
[12:27] <seb128> didrocks, I would say gnome-menus uses g_key directly
[12:28] <tseliot> Riddell: sounds good
[12:30] <seb128> didrocks, gnome-desktop is mostly deprecated, and gnome-menus handle menus, ie layouts, categories, etc
[12:30] <seb128> didrocks, libgnome-desktop just handles .desktop entries
[12:34] <tseliot> pitti: oh, shipped_handlers.py already runs the tests against the nvidia handler. I think it should be enough
[12:39] <pitti> I need to leave for 1.5 hours to visit my grandpa; bbl
[12:41] <didrocks> seb128: ok, thanks for the info
[12:52]  * vish just found ~2GB + 700mb gdm log files :/   
[12:53] <vish> seems to be full of repeat error >  http://paste.ubuntu.com/363843/    [since update gdm (2.29.5-0ubuntu1) to 2.29.5-0ubuntu2 ???]
[12:54] <seb128> doesn't seem a gdm error
[12:54] <seb128> rather an xorg or video driver one
[12:54] <vish> yeah , but gdm is logging it
[12:55]  * vish checks x-org update
[13:25] <didrocks> is really g-s-d which draw the background, because on the code calling libgnome-desktop bg API, I see: http://paste.ubuntu.com/363862/
[13:27] <huats> hello everyone
[13:27] <chrisccoulson> didrocks - that checks if nautilus is drawing the desktop (i think)
[13:27] <chrisccoulson> if nautilus is configured in gconf to not draw the desktop, then g-s-d draws it instead
[13:27] <didrocks> chrisccoulson: yes, and in that case, g-s-d doesn't draw it
[13:27] <chrisccoulson> i don't know how you do it on UNE though
[13:28] <didrocks> oh right, UNE doesn't have nautilus drawing the desktop
[13:29] <didrocks> that's why pitti's test have some impact on g-s-d :)
[13:29] <didrocks> hey huats
[13:30] <chrisccoulson> didrocks - thats what i though too :)
[13:30] <chrisccoulson> s/though/thought
[13:30] <chrisccoulson> s'oh
[13:30] <chrisccoulson> d'oh
[13:30] <huats> hey didrocks
[13:30] <chrisccoulson> my fingers are too big for the keyboard ;)
[13:30] <didrocks> chrisccoulson: heh
[13:42] <fagan> why was qt jack control pulled into lucid?
[13:43] <fagan> oh and pitti why would devkit power not log my battery?
[13:44] <fagan> Im trying to figure out why my battery isnt showing up in the pm prefences
[14:06] <Riddell> tseliot: new python-kde4 is in
[14:07] <tseliot> Riddell: \o/ thanks a lot
[14:14] <pitti> re
[14:15] <pitti> didrocks: yes, in UNE nautilus doesn't manage the desktop
[14:16] <pitti> fagan: hm, can you run sudo /usr/lib/devicekit-power/devkit-power-daemon -v manually and put the output into a bug report?
[14:16] <pitti> fagan: (kill the previous daemon first)
[14:17] <rickspencer3> good morning all
[14:17] <rickspencer3> what's the word on the street?
[14:17] <pitti> hey rickspencer3
[14:17] <pitti> "the fast and the furious" :)
[14:18] <kenvandine> hey rickspencer3
[14:18] <dpm> hi pitti, we've detected a problem with the translations of Firefox in some languages on the karmic-proposed language packs. That has now been fixed.
[14:19] <dpm> After talking to ArneGoetje, it seems that the easiest thing would be to remove all the current language packs from karmic-proposed for now, wait until the next PPA build and then copy those again to karmic-proposed.
[14:19] <pitti> dpm: can do
[14:19] <dpm> What do you think? May I ask you remove all language packs from -proposed?
[14:19] <dpm> ok, thanks pitti, do you want me to file a bug or something or is that enough?
[14:21] <pitti> dpm: no, it's JFDI (just not entirely trivial to do)
[14:22] <seb128> hey rickspencer3
[14:22] <dpm> ok, thanks a lot pitti
[14:22] <rickspencer3> hi seb128
[14:22] <fagan> pitti: https://bugs.launchpad.net/ubuntu/+source/devicekit-power/+bug/513271
[14:23] <fagan> and the log is http://launchpadlibrarian.net/38448686/devkit-power%20output.log
[14:23] <seb128> the fonts aliasing look weird in new firefox or that's me?
[14:23] <seb128> or anti aliasing rather
[14:26] <fagan> pitti: do you need any more info from me?
[14:27] <pitti> seb128: known
[14:29] <pitti> fagan: looks fine; now, perhaps you can also remove the battery, then do "devkit-power --monitor-detail", plug in the battery, then ^C and copy&paste the output to the bug?
[14:29] <pitti> fagan: (just to have it complete)
[14:30] <chrisccoulson> seb128 - i thought the fonts looked weird too, but i wasn't sure whether it was just because i was running it in virtualbox
[14:30] <seb128> pitti, chrisccoulson: thanks
[14:31] <chrisccoulson> oh, i didn't see pitti's response there already ;)
[14:34] <chrisccoulson> seb128 - bug 512615
[14:34] <seb128> thanks
[14:35] <fagan> pitti: attached
[14:35] <fagan> http://launchpadlibrarian.net/38448914/devkit-power%20--monitor-detail.log
[14:35] <pitti> fagan: hm, seems to detect it just fine; with that you don't get a battery in gpm either?
[14:36] <fagan> pitti: nope still not there
[14:36] <fagan> Its a mystery :)
[14:36] <pitti> fagan: hm, and then finally "devkit-power --dump" output ?
[14:36] <seb128> pitti, yesterday it was not in devkit-power --dump log
[14:39] <fagan> pitti: https://bugs.launchpad.net/ubuntu/+source/devicekit-power/+bug/513271/comments/4
[14:40] <pitti> fagan: thanks; it seems that dk-p is actually doing alright here
[14:40] <pitti> fagan: so I'm afraid we need to look at g-p-m now
[14:40] <seb128> fagan, did you restart gpm?
[14:44] <pitti> fagan: can you please killall gnome-power-manager
[14:44] <pitti> gnome-power-manager  --verbose >/tmp/log 2>&1
[14:45] <pitti> let it sit for a while, ^C, and attach /tmp/log ?
[14:45] <fagan> cool
[14:46] <fagan> oh that fixed it :)
[14:46] <fagan> It just needed a restart
[14:48] <seb128> oh
[14:48] <seb128> buglists got an heat column on edge now
[14:50] <fagan> pitti: https://bugs.launchpad.net/ubuntu/+source/devicekit-power/+bug/513271 its fixed but if you want to see the gpm log I attached it
[14:50] <pitti> fagan: ok; invalid then?
[14:50] <pitti> fagan: if gpm is working, it's not of much use
[14:50] <seb128> fagan, does it work after a restart?
[14:50] <seb128> or does it work only after you restart devkit-power and gpm?
[14:50] <fagan> Yep so its invalid now
[14:50] <chrisccoulson> seb128 - is the heat column there for measuring the rage of users then?
[14:51] <seb128> lol
[14:51] <mclasen> pitti: hey, I just talked to jakub about __assert_msg
[14:51] <fagan> well I restarted both and it was fixed seb128 so I presume so
[14:51] <seb128> chrisccoulson, I think some other datas are taken in account for it
[14:51] <pitti> hi mclasen
[14:51] <mclasen> pitti: he recommends that we should just call glibc's __assert_fail instead of trying to write to __assert_msg
[14:51] <seb128> fagan, well it was broken and it's fixed for no reason
[14:52] <seb128> fagan, usually bugs don't go away this way, it might be a race on start on something
[14:52] <pitti> mclasen: ah, that does seem to be public indeed
[14:52] <fagan> seb128: true but id say it was configured with a bug somewhere and when both were restarted it was reconfigured and fixed
[14:53] <fagan> I did a fresh install about 2 weeks ago
[14:54] <mclasen> pitti: it has to, since it is used in the assert() macro
[14:55] <seb128> fagan, well still have a look at next reboot
[14:56] <fagan> seb128: Yep I will if its still broken ill reopen it
[14:57] <pitti> mclasen: that would indeed solve  all that hocuspocus; we'd need to drop the g_test_log() though, which would change the output string format
[14:57] <pitti> (not sure how much is relying on that)
[14:58] <mclasen> can't we just replace abort by __assert_fail ? I guess that would give duplicated messages...
[14:58] <pitti> *nod*
[14:58] <pitti> that would look even worse
[15:11] <pitti> seb128: did you do a chart comparison with your panel change?
[15:13] <seb128> pitti, yes, but it's hard to tell how much it wins, especially than gnome-panel is not the slower part
[15:13] <seb128> pitti, I'm doing some new ones without the wm and nautilus now
[15:14] <seb128> pitti, it changed from 0.8s to 0.6s start on hot cache for my laptop config...
[15:14] <pitti> sounds like a good improvement
[15:14] <seb128> it should also avoid the delay we have between some applets load or some charts
[15:14] <pitti> it might not change the total chart a lot
[15:14] <seb128> right
[15:14] <pitti> since the CPU is pretty much full anyway
[15:15] <seb128> still it's good to take
[15:15] <pitti> but more compact CPU blobs make the entire thing more predictable and easier to optimize
[15:15] <seb128> and it's probably a better win for desktop
[15:15] <seb128> une doesn't have lot of applets loaded
[15:16]  * pitti turns his attention to ssh-agent again
[15:20] <seb128> slomo, hum
[15:21] <seb128> slomo, the totemplparser gir naming you choose doesn't respect the gir policy
[15:21] <seb128> slomo, and you picked a naming different from ubuntu too...
[15:21] <huats> seb128, didrocks Can I do the pessulus update ?
[15:21] <seb128> huats, sure
[15:22] <huats> than I am on it
[15:24] <pitti> chrisccoulson: do you know what currently triggers gconfd?
[15:24] <fagan> seb128: I have a bug with gbrainy, it punshes you for bad spelling :)
[15:24] <fagan> *punishes
[15:25] <chrisccoulson> pitti - gnome-session spawns gconf-sanity-check, which activates it
[15:25] <seb128> fagan, no clue about that one, ask robert_ancell when he's around
[15:25] <seb128> chrisccoulson, is gconf-sanity-check really required? what does it do?
[15:25] <pitti> chrisccoulson: I'd like to play around with starting it alongside gnome-session
[15:25] <pitti> chrisccoulson: we have a free CPU slot right when g-s starts
[15:26] <chrisccoulson> pitti / seb128 - i was thinking about dropping gconf-sanity-check as well. my gnome-session patch starts gconf-sanity-check earlier than normal too
[15:26] <didrocks> seb128: FYI, my patch for totemplparser is integrated upstream
[15:26] <seb128> didrocks, good work
[15:26] <seb128> makes me think I need to sponsor gtksourceview
[15:26] <seb128> doing that now
[15:27] <pitti> chrisccoulson: just execv'ing gconfd wouldn't work, would it? it needs some d-bus env vars AFAIK?
[15:27] <chrisccoulson> pitti - want me to look at starting gconfd alongside?
[15:27] <chrisccoulson> i wrote a tiny little helper a few weeks back, which could drop in Xsession.d
[15:27] <pitti> chrisccoulson: if you want to, that'd be great; I'm just curious to understand that bit, too
[15:28] <chrisccoulson> the helper literally just fork'd, and the child exec'd gconfd and the parent exec'd gnome-session
[15:28] <pitti> we have some 0.7 seconds when g-session starts
[15:28] <pitti> until anything else happens
[15:28] <pitti> we should start gconfd alongside
[15:28] <seb128> didn't chrisccoulson's changes took care of this delay?
[15:28] <chrisccoulson> pitti - i agree. and that 0.7s should shrink with my change to get the required components from a keyfile too
[15:28] <chrisccoulson> although there's still a 150ms delay parsing the desktop files
[15:29] <pitti> seb128: well, but I think we need to start gconfd earlier, not later
[15:29] <pitti> chrisccoulson: once we have enough parallelism to keep both CPUs busy, the order doesn't matter so much any more
[15:29] <pitti> I guess that's why your patches change some details, but don't have a huge impact on the overall time
[15:30] <pitti> also, I just compared a chart without autostart with and without ssh-agent
[15:31] <pitti> the difference is about 0
[15:31] <pitti> in the second chart ssh-agent is absent, but the delay between g-session and maximus/panel/etc. is the same
[15:34] <pitti> chrisccoulson: ok, if you want to look into that (thanks!), I'll have another stab at some gconf optimization
[15:42] <chrisccoulson> pitti - thanks, i will take a look at that when i get home
[16:01] <huats> didrocks, seb128 bug 513316
[16:02] <seb128> huats, thanks
[16:03] <huats> seb128, it feels good to do some stuffs :)
[16:03] <huats> (well even it was trivial..)
[16:03] <seb128> ;-)
[16:07] <tseliot> pitti: shall I copy b43.py broadcom_wl.py and dvb_usb_firmware.py to examples/handlers/ in trunk or shall I just update fglrx and nvidia?
[16:08] <didrocks> all my FF tabs are lost /o\
[16:08] <didrocks> what is strange is that sessionstore.js still have them
[16:08] <tseliot> google chrome FTW
[16:08] <tseliot> ;)
[16:09] <tseliot> 254 tabs and the app doesn't crash
[16:09] <didrocks> well, first, I must get back my tabs
[16:10] <fagan> didrocks: wont firefox recover them when it restarts?
[16:10] <didrocks> fagan: not this time, this is what is strange
[16:10] <didrocks> otherwise, I won't have tell that
[16:10] <fagan> didrocks: must be a bug then
[16:11] <didrocks> right
[16:16] <seb128> doing the libwnck gnome-desktop gnome-panel upgrades
[16:17] <chrisccoulson> pitti - would banshee releases be covered under the standing freeze-exception we have for GNOME packages (it seems banshee has a time-based release schedule aligned with GNOME now)
[16:18] <chrisccoulson> hyperair sent a mail to the ubuntu-motu list asking if there could be a freeze exception for the stable release, due on 31 March
[16:18] <hyperair> \o/
[16:19] <seb128> I think tracking those is a good idea
[16:19] <seb128> shame that they didn't decide ealier on a schedule
[16:20] <seb128> we would perhaps have switched for the lts
[16:20] <chrisccoulson> yeah, i quite like banshee :)
[16:24] <hyperair> =\
[16:24] <hyperair> oh well.
[16:31] <pitti> rickspencer3: that's what I get for ~apport-hackers team assigned bugs: http://paste.ubuntu.com/363960/
[16:32] <rickspencer3> ah
[16:32] <rickspencer3> pitti, so that's a bug in lazr
[16:32] <rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/lazr.restfulclient/+bug/495326/
[16:32] <rickspencer3> they've merged in my fix, and it should be available soon
[16:32] <seb128> is that the same bug I got a month ago?
[16:32] <rickspencer3> seb128, yes
[16:32] <seb128> ok
[16:33] <seb128> no need to try bughugger again then
[16:33] <seb128> I had that on my todolist
[16:33] <rickspencer3> if you want to fix it yourself, you just need to add a gaurd condition to one spot in the code
[16:33] <seb128> do you need help to get the fix in lucid?
[16:33] <rickspencer3> seb128, when you see the new JSON features from bdmurray and bryceh, I think you will be happy
[16:33] <seb128> it seems ridiculous it's waiting for a month now
[16:34] <rickspencer3> seb128, I think they just merged the code like a couple of days ago
[16:34] <seb128> well, doesn't mean we will get a new version or a lucid upgrade before weeks
[16:34] <rickspencer3> if you wouldn't mind seeing if they need some help getting it into Ubuntu, that would be great
[16:34] <seb128> ok, will check
[16:35] <pitti> rickspencer3: sweet!
[16:35] <rickspencer3> pitti, ?
[16:35] <pitti> rickspencer3: for retroactively fixing the bugs that I find
[16:35] <rickspencer3> lol
[16:36] <seb128> pitti is quite good at this game too
[16:36] <seb128> :-)
[16:36] <pitti> you could perhaps just add an except:/pass: workaround to bug_task_dict ?
[16:36] <tseliot> pitti: ^^^
[16:36] <rickspencer3> yeah
[16:36] <rickspencer3> pitti, exception handling throughout is needed
[16:36] <rickspencer3> bughugger is a small script that I wrote to answer a question I had one day
[16:36] <rickspencer3> but it became sentient and started writing itself
[16:37] <rickspencer3> at that point, I had to send a robot back through time to fix the lazr bug
[16:37] <pitti> tseliot: what did you change in b43.py/ broadcom_wl.py? anyway, if the changes would be sensible to have on e.g. Fedora, then change them in trunk; if they are truly ubuntu specific (like uor alternatives handling), just change them in the ubuntu branch
[16:38] <tseliot> pitti: they aren't included in trunk, that's all
[16:38] <pitti> chrisccoulson: banshee> if they get out their stable releases with the same criteria that GNOME itself has, sure (like, stable branches, etc.)
[16:38] <pitti> chrisccoulson: and obeying the UI/string/etc. freezes
[16:38] <pitti> tseliot: ah, right; no need then, just change in the ubuntu branch
[16:38] <chrisccoulson> pitti - thanks
[16:38] <chrisccoulson> hyperair^^
[16:40] <tseliot> pitti: ok, so shall I put only the do_blacklist thing in trunk and put the changes to the handlers in the ubuntu branch, then finally merge from trunk?
[16:40] <pitti> tseliot: right
[16:40] <tseliot> pitti: ok then
[16:42] <hyperair> pitti: where can i find these said criteria?
[16:42] <pitti> hyperair: hm, they should be documented at gnome.org somewhere; I'll have a loo
[16:43] <pitti> hyperair: I just sponsored the dk-p karmic-proposed change, wil process now
[16:43] <hyperair> pitti: thanks
[16:43] <pitti> hyperair: AFAIR the gnome-power-manager in karmic-proposed is already good, right?
[16:43] <pitti> hyperair: I don't see an updated patch
[16:43] <hyperair> pitti: i haven't uploaded it.
[16:43] <hyperair> pitti: it's in svn.debian.org
[16:43] <pitti> ah
[16:43] <hyperair> lemme just get it out
[16:44] <pitti> hyperair: so it does need yet another g-p-m patch then?
[16:44] <hyperair> yes.
[16:44] <pitti> hyperair: I thought the one that you added yesterday was for swsusp
[16:44] <pitti> but that's not really a concern for Ubuntu (we don't support that anyway)
[16:44] <hyperair> pitti: it was.
[16:44] <hyperair> pitti: but uswsusp does chvts
[16:44] <hyperair> pitti: and that caused the issue.
[16:44] <pitti> right, mbiebl told me
[16:44] <hyperair> pm-utils also does chvts.
[16:44] <hyperair> and we support non-KMS users.
[16:45] <hyperair> so we should have this patch.
[16:45] <pitti> hm, I heared that the pm-utils quirks have a different timing, and somehow aren't affected by this race (so much? just not enough?)
[16:45] <pitti> ok
[16:45] <hyperair> they are affected
[16:45] <hyperair> just that my first attempt at fixing it managed to fix pm-utils' one
[16:45] <hyperair> that method used g_idle_add
[16:46] <hyperair> that should delay it by a few milliseconds
[16:46] <seb128> pitti, I think the banshee case is different, lucid has an unstable version
[16:46] <hyperair> but i think uswsusp's chvts are done later
[16:46] <seb128> pitti, that's about following versions to the stable one
[16:46] <seb128> pitti, their stable is due after our freeze
[16:47] <hyperair> seb128: yeah that's right. also, we got 1.5.1 into karmic after finalfreeze as it had a whole truckload of bugfixes.
[16:48] <hyperair> it's likely that 1.5.3 onwards will also have a similar number of bugfixes.
[16:48] <seb128> tracking 1.5 for karmic was a weird choice
[16:49] <hyperair> the other option is 1.4.3 but it's very dated.
[16:51] <hyperair> pitti: i'll wring out a patch for gpm (karmic) tomorrow. right now my arms feel like lead.
[16:51] <seb128> right, good that they decided on a schedule now ;-)
[16:51] <hyperair> seb128: yeah, that's right. it took them long enough >_
[16:51] <hyperair> >
[16:51] <pitti> hyperair: thanks; I accepted dk-p for now
[16:52] <hyperair> pitti: thanks. that should solve half the problem.
[16:52] <hyperair> what's left is the consolekit issue
[16:53]  * hyperair => bed
[16:55] <mvo> asac: could you have a look at http://paste.ubuntu.com/363976/ please? from a hardy->lucid upgrade , probably trivial, but the debian/changelog does not mention when the -branding package got split out
[16:58] <asac> mvo: yes. the 3.0 transition packages are on our list
[16:58] <asac> so thats expected
[16:58] <asac> will get that to micahg
[16:58] <asac> mvo: does that block you from testing?
[16:59] <asac> e.g. urgent to get in?
[17:30] <seb128> ok, I'm off for sport and dinner outside
[17:30] <seb128> see you later or tomorrow
[17:54] <ccheney> pitti: who should i ping about getting 509920 silgraphite2.0 mir done
[17:57] <pitti> ccheney: I'll do a round of MIR assigning
[17:58] <ccheney> pitti: thanks
[18:08] <didrocks> going to enjoy some japanese food now. See you later or tomorrow :)
[18:14] <pitti> au revoir didrocks
[18:36] <pitti> bye everyone
[19:03] <rickspencer3> ok
[20:44] <djsiegel> kenvandine: ping
[20:44] <kenvandine> djsiegel, pong
[20:44] <djsiegel> kenvandine: any news on the empathy theme bits we talked about two weeks ago?
[20:44] <djsiegel> I just wanted to push on it a bit
[20:44] <kenvandine> no, i haven't heard anything
[20:44] <djsiegel> can we JFDI and see if it works/
[20:45] <djsiegel> and see what comes up?
[20:45] <kenvandine> wasn't the theme dude making some changes for us?
[20:46] <kenvandine> the author of renkoo
[21:12] <Sarvatt> hmm thats odd, hit tab for completion in gnome-terminal and get this robert@asuka{~/Desktop}:scp ScreenWARNING: Unhandled message: interface=org.freedesktop.DBus.Introspectable, path=/, member=Introspectshot.png
[21:12] <Sarvatt> hit tab after typing Screen there
[21:22] <bryceh> Sarvatt, checked for recent changes in bash-completion?
[21:22] <Sarvatt> 14 Nov 2009
[21:26] <djsiegel> kenvandine: yeah, but as far as I can see it's ready to drop
[21:26] <djsiegel> I am sure there will be some more changes
[21:57] <Sarvatt> completion is just broken like above in gnome-terminal at least, works fine from a VT
[22:00] <chrisccoulson> Sarvatt - what sort of environment are you running gnome-terminal in?
[22:01] <Sarvatt> just a normal gnome session
[22:01] <chrisccoulson> hmmm, strange
[22:03] <Sarvatt> lucid, all the latest updates if thats what you meant, sorry
[22:05] <Sarvatt> started after pulling in ~8 hours worth of updates a few hours ago, still happening after a reboot
[22:10] <rickspencer3> kenvandine, any psuedo-code for me. how to find images in Gwibber streams?
[22:10] <kenvandine> rickspencer3, one sec
[22:11] <rickspencer3> thanks
[22:11] <kenvandine> a view function:
[22:11] <kenvandine> if (doc.images.length > 0)
[22:11] <kenvandine> emit(doc._id, doc.images);
[22:11] <kenvandine> in couchdb
[22:11] <kenvandine> for a view
[22:11] <kenvandine> but ryan is going to add a method to get "real" images... which doesn't include a bunch of junk we get now
[22:11] <kenvandine> mostly from facebook
[22:12] <kenvandine> all the quizzes, etc
[22:14] <rickspencer3> kenvandine, what's the name of the database and record types?
[22:15] <rickspencer3> and also, I assume that will return urls pointing to images?
[22:16] <kenvandine> yeah
[22:16] <kenvandine> one sec
[22:16] <kenvandine> check out lp:~segphault/gwibber/overhaul
[22:16] <kenvandine> and look at
[22:16] <kenvandine> gwibber/microblog/util/couch.py
[22:16] <kenvandine> it defines all that stuff
[22:18] <rickspencer3> kewl
[22:18] <rickspencer3> thanks kenvandine
[22:18]  * rickspencer3 has project for the evening
[22:34] <crimsun> TheMuso: WRT pitti's bug report on /etc/xdg/autostart/pulseaudio.desktop: is there a method to hook into the session besides /etc/X11/Xsession.d/ ?
[22:38] <TheMuso> crimsun: afaik no.
[22:50] <TheMuso> rickspencer3: When do you want to do Eastern Edition Desktop team meeting?
[22:57] <rickspencer3> TheMuso, sure, give me 10 mins?
[23:05] <TheMuso> rickspencer3: sure
[23:06] <rickspencer3> TheMuso, just updating the wiki atm, be done shortly
[23:06] <TheMuso> ok
[23:10] <rickspencer3> TheMuso, wiki is saving
[23:10] <rickspencer3> robert_ancell, around for Eastern Edition, one day late?
[23:10] <robert_ancell> rickspencer3, can do
[23:11] <rickspencer3> the full meeting was only 30 minutes, so I hope this doesn't take much longer ;)
[23:11] <rickspencer3> looking at the wiki I don't see anything specifically urgent to call out
[23:11] <rickspencer3> except that start time targets, still lots of work to do there
[23:13] <rickspencer3> TheMuso, I just added in your activity report
[23:13] <rickspencer3> oops
[23:13] <rickspencer3> I suppose the link would help:
[23:13] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-01-26
[23:15] <rickspencer3> TheMuso, robert_ancell any questions about the meeting minutes?
[23:15]  * robert_ancell reading
[23:17] <robert_ancell> nope
[23:17] <robert_ancell> irc log is a bit hard to read...
[23:17] <rickspencer3> huh
[23:17]  * rickspencer3 fixes
[23:18] <robert_ancell> thanks
[23:18]  * bryceh waves
[23:19] <rickspencer3> TheMuso, fixed now?
[23:20] <robert_ancell> bryceh, another name change?
[23:21] <bryceh> robert_ancell, yeah I need a new nick.  Seems I've lost 'bryce'.  !<3 freenode
[23:21] <rickspencer3> TheMuso, any audio status update?
[23:24] <TheMuso> rickspencer3: Not this week.
[23:35] <seb128> hey robert_ancell
[23:36] <robert_ancell> seb128, hry
[23:36] <robert_ancell> hey
[23:36] <seb128> robert_ancell, how are you?
[23:37] <seb128> robert_ancell, I did change gnome-panel today to user an higher idle priority for the applets loading
[23:37] <Nafai> yay, about to upgrade to Lucid
[23:38] <seb128> robert_ancell, strace says it delays the redraws to after the load calls as expected and reduce their numbers
[23:38] <robert_ancell> seb128, cool
[23:38] <seb128> robert_ancell, that doesn't seem to make a strong difference on loading time though, ie it's still slow...
[23:38] <seb128> but that's still something ;-)
[23:39] <robert_ancell> :)
[23:39] <seb128> loading on hot cache on my laptop went from 0.8s to 0.6s