[00:00] seb128_: thats what confused me [00:00] it was there in karmic [00:00] but on a fresh install of lucid a few days ago its gone [00:00] well bugs happen [00:01] ill debug it tomorrow and see were the error lies [00:03] fagan, do you get a /proc/acpi/battery? [00:05] yep its there [00:05] the status is correc too? [00:05] the status is correct too? [00:06] TheMuso, hey [00:06] TheMuso, are you still interested in doing the gnome-media update? [00:06] Well when im on battery its detected and it appears in the notification area [00:06] TheMuso, there is a new version available for some weeks, not sure if you want to work on it [00:07] fagan - what is in /sys/class/power_supply? [00:07] chrisccoulson: ADP1 BAT0 [00:08] hmmm, so, the battery is detected then [00:08] ill grab a screen of the bug if you want [00:08] will the dkpower log is clearly buggy [00:08] it lists no battery [00:09] ah that must be it [00:14] fagan - did you figure it out? [00:14] nope [00:15] I was just agreeing with seb128_ that that may be the problem [00:15] so devkitpower must be not picking up on the battery [00:16] good night there [00:16] night seb128_ [00:17] night seb128_ [00:20] chrisccoulson: ill have a chat with pitti tomorrow and see if he can figure it out === bryyce is now known as bwh [01:22] didrocks, bug 513038 [01:22] Launchpad bug 513038 in gtksourceview2 "Update to 2.9.5" [Undecided,New] https://launchpad.net/bugs/513038 === bwh is now known as bryceh [01:47] hi. [01:48] i was wondering if someone can help me find a bug report that sebastien says already exists, but won't link to. [01:49] the proper bug for this: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/502784 [01:49] Ubuntu bug 502784 in nautilus "unable to select a file or directory from an app" [Wishlist,Invalid] [01:50] a bug i'd like to track, but not have to waste hours tracking down [01:50] LLStarks: wait for seb he will be back on tomorrow [01:50] its late in europe [01:51] k [01:53] 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] nothing screams dead-end like an invalid with no indication of what the actual afflicted package is [01:55] it's not transparent enough [01:55] LLStarks: seb is awesome he would know if it was a dup or not but id say he cant remember them all [01:56] LLStarks: it is transparent [01:56] but you cant expect the devs to drop what they are doing to fix something on the wishlist [01:57] that's not what i'm asking [01:57] Its fine [01:57] 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] that's annoying [01:58] because i can't follow anymore [01:58] LLStarks: he takes care of a lot of bugs id trust that he did see it [01:59] Someone would take care of it if it was important [02:01] 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] i don't know the package or even the proper way to describe the bug so that i could find it [02:02] all i have is an invalid unlabeled dupe. [02:03] this isn't the first time i've run into this problem with seb's way of doing things. [02:07] 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] that's not productive use of our time... [02:07] it's difficult to search for a bug when i don't even know the proper package [02:08] that's the problem. [02:08] i don't need a link. [02:09] if he had said "it's not nautilus, it's PackageX" that would be enough [02:10] launchpad search is pretty useless you know the proper package to bugsearch [02:11] is even this unreasonable to ask for? [06:04] Good morning [06:21] hello pitti [06:31] pitti, hey [06:31] hey baptistemm [06:31] robert_ancell: good morning! [06:31] pitti, thanks for the simple-scan MIR! [06:31] robert_ancell: you're welcome; just sponsored your new package [06:32] thanks [06:39] bratsche, hi [06:39] Hey! [06:56] TheMuso: hey [06:57] 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] ah, I'll file a bug for it [07:03] TheMuso: filed as bug 513120 now; let's discuss it there [07:03] Launchpad bug 513120 in pulseaudio "Can /etc/xdg/autostart/pulseaudio.desktop be dropped?" [Undecided,New] https://launchpad.net/bugs/513120 [07:58] good morning [08:06] bonjour didrocks [08:07] hey pitti, how are you? [08:07] I'm great, thanks! did you sleep well? [08:08] oh yes, thanks, long and resting night :-) [08:22] hey [08:23] hey seb128 [08:23] seb128: thanks for the sponsoring yesterday [08:23] how are you? [08:23] good! you? [08:23] bonjour seb128 [08:23] you're welcome [08:23] hey didrocks, hey pitti [08:24] had a good night? [08:24] yes, indeed [08:24] so do I :) [08:24] went to bed at 22:15 yesterday, I was so tired :) [08:24] so I got up at 6:30 again [08:24] waouh [08:24] I should do that too [08:24] I went to bed after 1am again yesterday [08:25] I don't feel tired in the evening [08:25] well, as long as you sleep long [08:25] but I do in the morning next day [08:25] usually I go to bed past midnight, too [08:25] it seems to be a more natural cycle for me [08:26] right, I like 1am to 8am [08:26] as sleep cycle I mean [08:37] pitti, btw do you have the xul greasmonkey package installed? [08:37] pitti, I got the "firefox is not starting after upgrade" issue yesterday too [08:37] seb128: I got it again today [08:37] pitti, it was due to greasemonkey for me [08:37] I blame the langpacks [08:37] uninstalling it make it work [08:38] ah, indeed [08:38] can be [08:38] I removed all extensions again today [08:38] and right now I don't have greasemonkey [08:38] ok [08:38] here firefox exit on start without error when it's installed [08:38] and works when I uninstall it [08:47] pitti, do you want me to have a look to what nm-applet is doing? [08:47] pitti, I was going to do that but I noticed you just edited the whiteboard about it [08:47] seb128: sure, that'd be great [08:47] seb128: oh, I just fixed the duplicate [08:47] there were two items for the same nm-applet thing [08:47] ok [08:47] doing that then [08:49] pitti, oh btw the 2 seconds g-s-d gap on our laptops is xrandr indeed [08:49] ah, ok [08:49] pitti, having a .xml config or not makes no difference [08:49] neither do being docked or not [08:49] but if I turn the xrandr off in gconf the 2 seconds gap go away [08:49] I guess it's the screen probing g-s-d does for the magic key to be working etc [08:50] seems xorg is busy during that time on the chart [08:50] I'm not sure why it's not an issue on the mini though [08:50] no external TFT? [08:55] bah launchpad going down in 5 minutes [08:55] can't they do that out of work hours ;-) [08:56] i just thought the same thing there too ;) [08:57] i never see announcements for LP going down any more. perhaps i'm subscribed to the wrong mailing lists [08:57] I hope my bzr push finishes in time [08:57] (or is not affected by the LP maintainace) [08:58] well, you can still use staging to read bugs :) [08:59] o [08:59] 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] chrisccoulson: perhaps you can ask tseliot when he comes back online? he dealt with this quite a lot in the past [09:00] 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] yeah, i might ask him [09:00] other than that, i don't know of any way to avoid that [09:00] but doesn't it? [09:00] (I mean X probing monitors) [09:00] chrisccoulson, they are announced on launchpad-announce [09:00] the log has everything about it, after all [09:01] pitti - thats what i'm thinking. perhaps we are actually probing the monitors twice here [09:03] chrisccoulson, gnome-desktop already has code for that apparently [09:03] #if (RANDR_MAJOR > 1 || (RANDR_MAJOR == 1 && RANDR_MINOR >= 3)) [09:03] /* Runtime check for RandR 1.3 or higher */ [09:03] if (info->screen->rr_major_version == 1 && info->screen->rr_minor_version >= 3) [09:03] resources = XRRGetScreenResourcesCurrent [09:04] ... [09:04] but it has a "needs_reprobe" too [09:04] seb128 - it does, but when you call gnome_rr_screen_new, it calls it with needs_reprobe [09:04] and it calls XRRGetScreenResources() in those case [09:04] I'm leaning toward saying that if somebody did that it's for a reason [09:04] but maybe not ;-) [09:05] seb128 - yeah, i think you're probably right [09:05] 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] screensaver pop-under? [09:06] 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] I filed a bug last time, just looking for it now [09:07] https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/487165 [09:07] Ubuntu bug 487165 in compiz "screensaver unlock dialog under other windows" [Undecided,Confirmed] [09:09] oh, it's reported against compiz. that's why i didn't notice it reported [09:10] 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] Ng - yeah, it's more likely a WM issue [09:16] chrisccoulson: and there's tseliot :) [09:20] updating brasero [09:20] seb128: ^ [09:21] well, when I will be able to branch again :) [09:21] didrocks, ok [09:21] didrocks, well launchpad is supposed to be down for 2.5 hours [09:22] seb128: right, I'm reading/writing some docs in the meanwhile (that's good, I had that planned but never prioritarized it) [09:49] 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] chrisccoulson: I'll leave that on a post-it note for whenever it next happens :) [09:49] and then run "DISPLAY=:0.0 xprop -id ", where is the window ID from the last command [09:50] you might need to tweak the display number there as well [09:50] chrisccoulson: out of curiosity, what will this tell us? [09:51] it will tell us what the WM thinks the current focused window is [09:59] ok [09:59] 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] but I'll get that info if I see it again [10:03] 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] ok [11:03] pitti: afaik crimsun said something about that earlier, don't know if you saw it. I'll dig it up if not. [11:04] 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] pitti: ah ok, I'll dig it out of logs. [11:07] 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] # X11 modules should not be started from default.pa so that one daemon [11:08] # can be shared by multiple sessions. [11:08] I don't understand that, though [11:08] 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] if that means "by multiple users", I'd agree, but that's what /etc/pulse/system.pa is for? [11:09] crimsun: ^ [11:23] 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] Launchpad bug 513038 in gtksourceview2 "Update to 2.9.5" [Wishlist,New] https://launchpad.net/bugs/513038 [11:24] didrocks, ok [11:24] thanks :-) [11:24] np [11:24] * pitti finishes measuring impact of autostart files [11:25] pitti, what is the result? [11:25] added to https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed [11:25] it also has a link to the detailled charts [11:25] boot speed is quite depressing [11:25] nothign too surprising [11:26] - essentials: g-p-m, g-s-d, nm-applet, screensaver: 8.0 (+3.5) [11:26] i. e. those four increase by 3.5 seconds [11:26] gsd is 80% background image, though [11:26] " - the ones deferred with a sleep: 4.5 (+0) -> no impact, as expected" [11:26] bah [11:26] chrisccoulson, not worth doing your change maybe then [11:27] seb128 - yeah, i just noticed that too [11:27] the "add a new delay key to avoid spawning a shell etc" [11:27] it would just be for cleanliness [11:27] but not first priority indeed [11:28] pitti, are you sure that xdg-user-dirs spawns a shell there? [11:28] it's a bit weird, it's a C program [11:28] it first appeared in http://people.canonical.com/~pitti/bootcharts/autostart-impact/4-polkit-userdirs.png [11:28] checking that was next on my list [11:29] pitti, well it uses g_spawn_command_line_sync to call xdg-user-dirs-update... [11:29] $ strace -e execve xdg-user-dirs-gtk-update [11:29] execve("/usr/bin/xdg-user-dirs-gtk-update", ["xdg-user-dirs-gtk-update"], [/* 50 vars */]) = 0 [11:29] hmm [11:29] ah [11:30] I doubt that costs anything [11:31] pitti, background rendering... would be worth testing with an image matching the screen [11:32] just to see what difference the rescaling does [11:32] that could maybe be cache too [11:32] cached [11:32] ah, indeed [11:33] we could at least have a special image for a _totally_ arbitrary resolution, say 1024x600 :) [11:33] lol [11:33] well, to be fair that's a pretty common netbook res [11:34] let's see first how much win that would make [11:34] pitti, btw g-s is essential? [11:34] or could it start 30 seconds after login [11:34] oh, it can for sure [11:34] the other ones can't really [11:34] seb128: I can do these four again perhaps, with separate charts for each [11:34] you want to go online and g-s-d sets themes, etc [11:35] g-s-d and nm-applet are essential indeed [11:35] we could cheat a bit with g-p-m [11:35] I was not sure about gpm [11:35] but seriously, it' just be circumventing bootchart [11:35] but I guess gnome-screensaver can be delayed after busy time [11:35] not change the user experience [11:35] we need gnome-session to send a signal "done loading" [11:35] this stuff all happens in the bg [11:35] and trigger those at this time [11:36] well [11:36] seb128: we could start g-p-m with nice level? [11:36] gnome-screensaver used to be deferred for 30 seconds when it was spawned by g-s-d [11:36] how much login speed is impacted by the number of processes? [11:36] number of processes by itself shouldn't matter [11:36] if they are mostly in poll()/sleep() [11:36] ie, how much tasks commutations cost us [11:40] lunch time bbl [11:44] seb128: hm, g_spawn_command_line_sync() doesn't actually invoke a shell, though [11:44] I guess it's coming from somewhere else then [11:44] LANG= strace -f -e execve /usr/bin/xdg-user-dirs-gtk-update [11:44] -> directly execve's /usr/bin/xdg-user-dirs-update === MacSlow is now known as MacSlow|lunch [12:02] didrocks: hi [12:03] 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] didrocks: in order to exploit that, we'd need to add a new feature to g-s-d to check /desktop/gnome/background// first, before /desktop/gnome/background/ [12:04] didrocks: so that we can add a warty-final-ubuntu-1024x600 and point to that in /desktop/gnome/background/1024x600/ [12:04] didrocks: do you have enough cycles to work on that? [12:05] pitti - want me to do that? [12:05] ah [12:05] no worries ;) [12:05] chrisccoulson: if you have the cycles, sure [12:05] but you already have so much, and still have a dayjob, and all that :) [12:05] pitti: sorry, I was having my lunch :) [12:05] didrocks: how can you DARE having food!?! [12:05] pitti: I can work on that, yes, can you please add a WI with those info? [12:05] pitti - yeah, my day job is still a bit of an obstacle [12:05] pitti: heh [12:06] didrocks: thanks; I'll add a WI for it [12:06] pitti: sometimes, like 3 times a day, sorry ;) [12:06] *tsk* [12:06] * pitti hugs didrocks [12:06] * didrocks hugs pitti [12:06] and hugs chrisccoulson, too [12:06] * chrisccoulson hugs pitti [12:08] * seb128 back from lunch [12:08] yeah, I dare having food too :-) [12:08] we french need to eat! [12:08] :) [12:09] didrocks: added [12:09] pitti: thanks [12:09] seb128: so, that was a good hint; saves a lot of g-s-d's CPU time [12:09] as a revenge, I'll have lunch now!! [12:09] pitti, excellent [12:09] hehe [12:09] pitti, enjoy [12:09] enjoy pitti! [12:10] didrocks, pitti: other solution would be to cache the updated image [12:10] didrocks, pitti: that would apply to any screen setting... [12:10] *nod* [12:10] rather than depending on us to ship an image for a special screen config [12:10] I don't care much about the implementation [12:11] well, the cache would work for user images too [12:11] I guess most users change their background [12:11] where the hacked version would benefit benchmarks mostly [12:11] didrocks, ^ [12:12] seb128: yes, that's better, so, saving the pixbuf on the disk [12:12] didrocks, yes [12:13] didrocks: WI updated [12:13] I removed the implementation, and just kept the effect [12:13] yep :) [12:14] didrocks, I guess it's probably a gnome-desktop change [12:14] since gnome-bg apis are there [12:14] at least, I'll have made some work to reduce the loading time :) [12:14] vuntz, there for a gnome-panel question? [12:14] seb128: gnome-desktop in g-s-d? [12:15] didrocks, no, gnome-desktop gnome-desktop [12:15] the gnome-bg apis are in libgnome-desktop as said before [12:15] seb128: oh ok, looking at it [12:16] thanks [12:16] np [12:16] 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] tseliot: looks fine to me [12:18] pitti: I guess there's no need to prevent Jockey from enabling the module (in enable) if we pass do_blacklist=False [12:18] tseliot: no, I don't think so; if it's still in blacklist.local, it should still be removed I think [12:18] if for nothing else, then for upgrading [12:19] pitti: right, it's what I thought [12:20] bzr diff --diff-options -Nurp gives me the equivalent of diff -Nurp :-) http://pastebin.ubuntu.com/363823/ [12:21] s/of/for/ [12:22] pitti: BTW we should be able to upload the new jockey soon, thanks to Riddell [12:25] 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] tseliot: should be appearing in the archive as soon as publisher does its thing [12:27] didrocks, I would say gnome-menus uses g_key directly [12:28] Riddell: sounds good [12:30] didrocks, gnome-desktop is mostly deprecated, and gnome-menus handle menus, ie layouts, categories, etc [12:30] didrocks, libgnome-desktop just handles .desktop entries [12:34] pitti: oh, shipped_handlers.py already runs the tests against the nvidia handler. I think it should be enough [12:39] I need to leave for 1.5 hours to visit my grandpa; bbl [12:41] seb128: ok, thanks for the info [12:52] * vish just found ~2GB + 700mb gdm log files :/ [12:53] 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] doesn't seem a gdm error [12:54] rather an xorg or video driver one [12:54] yeah , but gdm is logging it [12:55] * vish checks x-org update === MacSlow|lunch is now known as MacSlow [13:25] 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] hello everyone [13:27] didrocks - that checks if nautilus is drawing the desktop (i think) [13:27] if nautilus is configured in gconf to not draw the desktop, then g-s-d draws it instead [13:27] chrisccoulson: yes, and in that case, g-s-d doesn't draw it [13:27] i don't know how you do it on UNE though [13:28] oh right, UNE doesn't have nautilus drawing the desktop [13:29] that's why pitti's test have some impact on g-s-d :) [13:29] hey huats [13:30] didrocks - thats what i though too :) [13:30] s/though/thought [13:30] s'oh [13:30] d'oh [13:30] hey didrocks [13:30] my fingers are too big for the keyboard ;) [13:30] chrisccoulson: heh [13:42] why was qt jack control pulled into lucid? [13:43] oh and pitti why would devkit power not log my battery? [13:44] Im trying to figure out why my battery isnt showing up in the pm prefences [14:06] tseliot: new python-kde4 is in [14:07] Riddell: \o/ thanks a lot [14:14] re [14:15] didrocks: yes, in UNE nautilus doesn't manage the desktop [14:16] 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] fagan: (kill the previous daemon first) [14:17] good morning all [14:17] what's the word on the street? [14:17] hey rickspencer3 [14:17] "the fast and the furious" :) [14:18] hey rickspencer3 [14:18] 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] 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] dpm: can do [14:19] What do you think? May I ask you remove all language packs from -proposed? [14:19] ok, thanks pitti, do you want me to file a bug or something or is that enough? [14:21] dpm: no, it's JFDI (just not entirely trivial to do) [14:22] hey rickspencer3 [14:22] ok, thanks a lot pitti [14:22] hi seb128 [14:22] pitti: https://bugs.launchpad.net/ubuntu/+source/devicekit-power/+bug/513271 [14:22] Ubuntu bug 513271 in devicekit-power "Battery preferences not displayed in power management preferences" [Undecided,New] [14:23] and the log is http://launchpadlibrarian.net/38448686/devkit-power%20output.log [14:23] the fonts aliasing look weird in new firefox or that's me? [14:23] or anti aliasing rather [14:26] pitti: do you need any more info from me? [14:27] seb128: known [14:29] 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] fagan: (just to have it complete) [14:30] 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] pitti, chrisccoulson: thanks [14:31] oh, i didn't see pitti's response there already ;) [14:34] seb128 - bug 512615 [14:34] Launchpad bug 512615 in firefox "fonts are incorrectly rendered due to not using system cairo" [Unknown,Confirmed] https://launchpad.net/bugs/512615 [14:34]