=== bjf is now known as bjf-afk [00:35] up === asac_ is now known as asac [07:52] Looking forward to Ubuntu Developer Week next week. Help me get a leg up before I start my contract period on February 1. [07:53] btw, I'm going to be working on app-indicator porting as a contractor [07:58] sweet Nafai :) [08:01] yeah, excited [08:01] been starting to work on transmission to get a head start [08:02] Nafai: transmission integration on app-indicator? [08:02] yeah [08:02] sounds great (even if I only use transmission-daemon on a server) ;) [08:03] I hope y'all won't mind me asking workflow questions and stuff (bzr/launchpad, working with the packaging branches, etc) [08:04] Just so I do things the way the team does things [08:10] Nafai: I'll ask you GTK/Glib related question as a counter-part :) [08:10] but no, don't be shy asking :) [08:10] thanks! [08:13] So what do you work on didrocks? [08:14] Nafai: mosly UNE packaging, but those last two days, I was more focused on patching gdm :) [08:14] cool [08:14] adding some option to select default session on gdmsetup, don't save in .dmrc if we are using a failsafe session, etc. [08:15] nice, the loss of features in the latest GDM is kind of annoying [08:16] I agree, I've added default session support and submitted it upstream. Let's wait for a review [08:21] hey didrocks [08:22] Guten Morgen pitti :) [08:22] * pitti waves to Nafai, good luck with the porting! [08:22] Hey pitti. Thanks! [08:23] Should be fun and I'll be excited to be able to point to the panel in a Lucid install and say "Hey, I did that." :) [08:23] absolutely! [08:24] Nafai: which projects will you work on? (after transmission) [08:24] right, just ask here [08:24] Nafai: new contributors are always a good opportunity for us to update our documentation [08:25] Nafai: so please don't feel mistreated if we point you to docs first; let's discuss the open questions afterwards, and then we can clarify the pages [08:25] good question, I've seen the bug list on launchpad of the projects that need porting, but I am unsure of the priorities [08:25] pitti: Of course, if the answer is "hey, the docs are here", I'll take it :) [08:25] well, I guess they will be in a few priority buckets, not a total order [08:25] Which, is this up-to-date and accurate: https://wiki.ubuntu.com/DesktopTeam/Bzr [08:26] Right [08:26] Nafai: /Bzr is accurate wrt. the way the desktop team does _most_ of pacakges nowadays [08:27] Nafai: however, these days we are developing a new workflow with having the full source in bzr, and "package branches" (which look like lp:ubuntu/transmission) [08:27] Nafai: we don't use this approach yet for packages which we aren't upstream for, though [08:27] Ah, okay [08:27] Nafai: but in general, if you have a package with a Vcs-Bzr: header, use that (debcheckout pkgname) [08:27] hello, good morning [08:28] Nafai: if you happen to stumble across a pacakge without a Vcs-Bzr: header, just ask here [08:28] (since we need to collectively decide what to do about it) [08:28] * Nafai nods [08:30] after you do the debcheckout and your changes are to the source (that we aren't upstream for, like transmission), what's the best strategy for producing the .patches files that are needed? [08:30] I've been doing a bzr bd-do and then copying over the directory in build-area and making the changes there, then producing a patch file from that and re-doing it [08:31] (re-doing bzr bd-do to test after the patch file is in place) [08:35] Nafai: it all depends on what patch system the package is using, you can have a look there to have a presentation about them: https://wiki.ubuntu.com/PackagingGuide/PatchSystems [08:36] Awesome, thanks [08:36] y/w :) [08:37] pitti: I'm looking at your update-gnome-menus-cache, the DesktopEntry module handle l10n itself and return the right Comment/Name in the desired language? [08:40] Nafai: re; yes, PatchSystems page is good; usually it's cdbs-edit-patch or quilt, depending on which patch system is in use [08:41] didrocks: correct, the cache files are per-locale [08:41] avoids expensive gettext [08:41] looks like quilt for transmission [08:41] pitti: I mean, you just load the file using the DesktopEntry python module. This one handle taking the right locale for you, right? [08:42] didrocks: well, you shouldn't load it manually at all [08:42] didrocks: it's only meant as a cache for libgnome-menu [08:42] pitti: I was just curious and looking at your code, and as I didn't see any localisation handling, I was just curious :) [08:42] so if you do gmenu_tree_lookup("applications.menu"), it will use that [08:43] Nafai: right, it's quilt for transmission [08:43] didrocks: /usr/share/applications/desktop.de_DE.utf8.cache [08:43] didrocks: i. e. it's encoded in the file name [08:44] pitti: and what the difference between utf8, UTF8 and UTF-8 ? [08:44] didrocks: /usr/share/applications/desktop.de_DE.UTF-8.cache , sorry [08:44] .UTF-8 is the actual locale name [08:44] I'm not sure why there's an .utf8 file [08:44] oh [08:44] seems that changed recently [08:45] $ locale -a [08:45] [...] [08:45] de_DE.utf8 [08:45] new glibc/ [08:45] ? [08:45] right, same here [08:45] didrocks: anyway, it has to match exactly the locale [08:45] pitti: ok, thanks :) [08:45] the .UTF-8 is not "magic" in any way, it's just a convention [08:46] didrocks: FYI, /usr/share/i18n/SUPPORTED maps the names to encodings [08:46] didrocks: i. e. many UTF-8 locales don't have any suffix at all, since they are relatively new and _only_ available in UTF-8 [08:46] ug_CN UTF-8 [08:46] for example [08:48] pitti: oh, ok, understood [08:49] pitti: in that case, I'm just wondering why I have desktop.fr_FR.UTF8.cache too, which isn't in /usr/share/i18n/SUPPORTED [08:50] didrocks: look at the timestamp; I suspect it's from an older glibc [08:50] 2010-01-19 08:54 /usr/share/applications/desktop.de_DE.UTF-8.cache [08:50] 2010-01-22 00:33 /usr/share/applications/desktop.de_DE.utf8.cache [08:50] i. e. the "old" names aren't built any more [08:51] pitti: right, something should have happened around the 2010-01-16 :) [08:52] triggers seem easy to implement (still looking at your patch) [08:53] in fact, we are still fetching /usr/share/applications/ desktop file and locale one [08:55] good morning everyone [08:57] hey chrisccoulson [08:57] hey chrisccoulson [08:57] hey pitti didrocks, how are you both? [08:57] chrisccoulson: so, my xrdb patch worked; we are booting 4 mm faster now :) [08:58] pitti - excellent :) [08:58] * pitti uses a ruler to measure bootchart distance between g-d-m and last red line [08:58] hey [08:58] what is excellent? [08:58] look! a miniature seb128! [08:58] lol [08:58] seb128mini: │ [08:58] laptop is fscking for 15 minutes [08:59] seb128mini: pitti | chrisccoulson: my xrdb patch worked; we are booting 4 mm faster now :) [08:59] miniature seb = seb32 [08:59] and it only took me until 1 am [08:59] so I figured I would test empathy IRC now [08:59] lol [08:59] * pitti pats seb128mini [08:59] * seb128mini hugs pitti [09:00] if you work really really hard and learn GNOME, then, maybe, one day, you can become almost as good as our famous seb128! [09:00] lol [09:00] let's see [09:00] I feel I still have a way to go before that [09:00] salut seb128mini :) [09:00] I'm trying to figure for now why I can't enable bluetooth on this box [09:00] lut didrocks [09:01] seb128mini: as in the bios or in the applet? [09:01] the gnome-bluetooth "enable bluetooth" button does nothing [09:01] * pitti usually disables BT in the bios [09:01] it's just a power sink [09:01] seb128mini: rick told me that the BIOS power off it [09:01] let me try that [09:01] ok, not typing fast enough :) [09:01] my laptop managed to boot [09:03] i can't get lucid to boot at all anymore [09:04] not even the live CD :( [09:04] oh? [09:04] it hangs at "SMP alternatives: switching to UP code" [09:04] did you try picking old linux version in grub? [09:04] bluetooth is on in the bios [09:05] hi seb128 [09:05] seb128 - not yet. i'll try that later when i get in from work though [09:05] got asked on whether gnome-shell moves to libseed ;)? [09:05] asac, there is no such plan [09:05] that has been discussed in the past though [09:05] but gnome-shell people feel they have enough to do on gnome-shell itself to get it working [09:06] out of rewritting it to use a different js [09:06] right. maybe can you point them to our plan to demote xulrunner and its js lib to universe (or even remove it completely) [09:06] ? [09:06] https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model [09:07] I could [09:13] asac, http://mail.gnome.org/archives/desktop-devel-list/2009-November/msg00028.html [09:13] thanks [09:14] seb128, chrisccoulson: I'm curious, what's the status of Chris' "weaker gconf dependency" patches? is it still worth uploading them? [09:14] pitti, they are pretty useless as long as we don't solve the seahorse case [09:14] but either not running it [09:15] (I'm still not sure why we need the daemon) [09:15] seb128: ah, is that the gap between ssh-agent and seahorse-daemon? just waiting on gconf? [09:15] apparently when not running it people got warning when first trying the nautilus context menu option to encrypt a file etc [09:15] yes [09:16] chrisccoulson delayed gconf use to after the g-s-d session registration [09:16] well, we primarily need this for injecting the env vars into the session, no? [09:16] out of the fact that it does start seahorse [09:16] which does query gconf [09:16] hm, is anyone working on this already? [09:16] if not, it sounds like it could become my Monday project [09:16] pitti, it's not the agent it's the daemon [09:17] I don't see any environment variable due to it [09:17] chrisccoulson said he would I think [09:17] not sure it's that still the case [09:17] today I'm too busy with release/bureaucracy/email/meeting stuff, but I should be able to continue boot speed work on Monday [09:18] I want to have a look at xdg-user-dirs-gtk-update today [09:18] it's not doing a lot but still it seems stupid to run that at every login just to see if you default dirs changed [09:19] defaults being download, music, video,.. [09:22] I'm going to try to sleep. UTC-7 here. :) [09:22] seb128: evolution-indicator 0.2.6-0ubuntu2 , seems to fix Bug #436755 , is it still open for a reason? [ seems the lp janitor didnt close the lp bug , missed mentioning bug# ?] [09:22] Launchpad bug 436755 in evolution-indicator "indicator-applet doesn't change icon when I recieve new e-mails via Evolution" [Low,In progress] https://launchpad.net/bugs/436755 [09:23] want me to close it? [09:24] vish, yes please, [09:24] ok , thanks [09:25] pitti: seb128: clutk needs some bin NEW approval: https://edge.launchpad.net/ubuntu/+source/clutk/0.3.8-0ubuntu2/+build/1459566 [09:26] pitti / seb128 - yeah, i was going to look at seahorse-daemon in the next few days to understand what it's doing when it starts up [09:26] chrisccoulson: ok, great [09:26] my existing gnome-session / g-s-d / gconf patches delay gconf use until the xsettings plugin loads [09:26] didrocks, doing that [09:26] thanks seb128 :) [09:26] it's only the xrandr plugin so far that can run without gconf [09:27] njpatel, seb128, chrisccoulson: so perhaps I'll profile mutter then (the non-UNE bits) [09:28] pitti, if you want to [09:28] pitti, I'm not convinced it's the best use of our ressources right now [09:28] seb128: please suggest something better [09:28] it seems the seahorse one is now the bottleneck [09:28] pitti, seems upstream people will get that one faster over time [09:28] well you can probably work on mutter [09:28] but if chrisccoulson is on that already [09:29] but it will take a while to learn it [09:29] where upstream seems to know what to change and will do it over time [09:29] hello seb128, pitti and chrisccoulson [09:30] hey baptistemm [09:30] how much time does the "start everything at once" change gain? [09:31] chrisccoulson, none [09:31] hmmmm :-/ [09:31] seems start earlier [09:32] but it's traded for extra conflicts and too much activity [09:32] like extra context switches etc [09:32] it's just a potential win so far [09:33] seb128 - i had a thought about maybe restructuring the startup in to 3 phases instead of 5 (so, you have the initialization phase as we do currently, then a middle phase for starting stuff we would consider to make a usable session, and then start everything else at the end) [09:34] and perhaps we could even delay some things starting - eg, gnome-screensaver used to be spawned by g-s-d after a delay, but since it's being started by gnome-session now, it starts straight away - but it doesn't need to really [09:34] that's sort what we did there [09:34] I kept things in the init pahse [09:34] phase [09:34] and moved things away from the wm and panel one [09:35] so you would have application and extra-application? [09:35] seb128 - so, we just use 2 phases now? [09:35] yes [09:35] init and applis [09:35] chrisccoulson: seahorse> I still don't get why seahorse should block everything else (conceptually) -- the only necessary thing is to inject the session env variables, and those don't need gconf; everything else can just start much later on; am I missing something? [09:36] seb128 - i was thinking about adding another key to the autostart files to allow you to specify a delay (eg, start after 10 seconds or so) [09:36] pitti, as said before I don't think there is any variable === tkamppeter_ is now known as tkamppeter [09:36] SSH_AGENT_PID=2047 [09:36] GPG_AGENT_INFO=/tmp/seahorse-8vocQ9/S.gpg-agent:2067:1 [09:36] pitti, that gnome-keyring for ssh [09:36] and gpg is seahorse-agent [09:36] which is not in the default install [09:36] ah [09:36] the issue there is seahorse-daemon [09:37] hm, is that not SSH_AGENT_PID? [09:37] no [09:37] ^ that shoudl be from the ss-agent wrapper, but that should be really quick [09:37] ssh is keyring [09:37] not seahorse [09:37] gnome-keyring is the ssh agent [09:37] oh, I thought seahorse provided the GUI for password [09:37] it does [09:38] it has the gui [09:38] but you can use gnome-keyring with the capplet [09:38] just type your passwords [09:38] seb128: pretty sure GPG_AGENT_INFO is seahorse-agent [09:38] seahorse is a manager gui [09:38] vuntz, it is but we don't install that by default [09:38] ah, that's another story :-) [09:38] vuntz, the issue in boot is seahorse-daemon [09:38] which I'm not sure what it does [09:39] oh, hrm [09:39] https://bugzilla.gnome.org/show_bug.cgi?id=587539 [09:39] hmmm, i can't see why seahorse-daemon blocks the session from starting actually [09:39] "something" [09:39] Gnome bug 587539 in Daemon "seahorse-daemon.desktop should not contain an autostart condition by default" [Minor,Resolved: fixed] [09:39] we used to have a gconf key condition [09:39] it fork's straight away [09:39] but apparently people were getting an error on first use [09:39] "seahorse-daemon - seahorse pass phrase caching agent" [09:39] chrisccoulson, it triggers gconf [09:40] vuntz, that's a lie [09:40] seahorse-agent is that [09:40] that's the man page [09:40] okay, it does at least the "share gpg keys with avahi" part [09:40] which is something any desktop user want... [09:41] see the bug I pointed [09:41] it used to be conditional on a gconf key [09:41] which was off by default [09:41] but it triggers some bug [09:41] yeah [09:42] just remove X-GNOME-Autostart-Phase, I guess [09:42] as long as it doesn't set any environment variable with gnome-session, it should not be done in Initialization [09:43] yeah, it doesn't seem to AFAICT [09:43] trying here [09:47] yay, that looks better [09:47] now it's blockign on g-s-d (which is what chrisccoulson has a patch for?) [09:47] well, it will need to block for a little bit on g-s-d, but i just need to see if i can make it faster [09:48] pitti: the question is of course: do all the gpg feature work fine in the destkop? :-) [09:48] trying with ssh [09:48] vuntz: gpg is seahorse-plugins, we don't install that by default anywawy [09:49] yep, works great [09:50] chrisccoulson: ^ [09:50] excellent :) [09:51] should I just upload this? [09:52] ah, I'll try on my desktop with gpg [09:52] pitti, no it's not [09:52] pitti, see https://bugzilla.gnome.org/show_bug.cgi?id=587632 [09:52] Gnome bug 587632 in general "Impossible to find GPG keys the very first time" [Normal,Resolved: duplicate] [09:52] pitti, the issue was not an agent one [09:56] so, at least ssh and gpg agent still work [09:57] righr [09:57] gnome-keyring has not changed [09:57] and seahorse-agent is a different thing [09:57] seb128: hm, I'm afraid I either don't understand or can't reproduce that bug [09:57] no reason seahorse-daemon should impact on those [09:57] pitti, well try to drop seahorse-daemon and to open the seahorse capplet after boot [09:57] pitti, or to right click and sign a file in nautilus [09:58] seb128: hang on, maybe we are talking about different things [09:58] seb128: the only thing that I did was to comment X-GNOME-Autostart-Phase=Initialization [09:58] it's still autostarted [09:58] oh ok [09:58] that bug is talking about an autostart condition [09:58] I though you dropped it from the session [09:58] no [09:58] pitti, we use to have that to false [09:58] pitti, ie to not start the daemon at all [09:58] it just starts later, together with everything else [09:58] which I was wondering we could get working [09:59] I don't get why it could be spawned on deman [09:59] demand [09:59] since it doesn't export anything [09:59] it should just be a dbus service [09:59] "couldn't"? [09:59] yes sorry [09:59] right, ideally [09:59] but this already helps to take it out of the critical path [09:59] which somewhat works [09:59] the bug says it works on second try [09:59] so it gets spawned [09:59] but the client side fails to wait on that [09:59] or to retry or something [10:00] well it's out of delay [10:00] but will still have the "too much activity" [10:00] seb128: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100122-seahorse.png [10:01] right, of course it would be even better to not start it at all [10:02] * pitti purges seahorse for comparison [10:06] seb128: ^ a tad faster (could be noise or for real, just have one chart for each) [10:07] * pitti puts on the tech lead hat for a bit and does RM stuff [10:08] pitti - i was going to ask if you could get a chart with the xrandr g-s-d plugin disabled. i wouldn't mind seeing how long it blocks for [10:10] chrisccoulson: generating [10:10] thanks [10:10] chrisccoulson: does it do anything by default in the first place? [10:10] chrisccoulson: I mean, without a monitors.xml [10:10] chrisccoulson: do you still have the link about blog posts on speed improvement in GNOME? [10:12] pitti - AFAIK, it will still make calls to the server to get the screen resources etc, and it also listens to events too [10:12] i need to look at that in more depth though [10:12] didrocks - i've got the links on my home PC unfortunately (and i'm at work atm) [10:12] chrisccoulson: ok, I'll ping you then. I've read them 6 months ago and would like to find them again :) [10:14] seb128, hi. We released telepathy-glib 0.10.0 yesterday, which start the new 0.10.x stable branch. You should probably ship this one with Lucid [10:14] package is already in Debian I think [10:15] yes, I noticed the upload in the debian changes list [10:15] pitti - just to point out as well (although you've probably worked it out already) - gnome-session doesn't really start where the bootchart says it starts. in Xsession.d, ssh-agent fork's, and the parent then execve's gnome-session === virtuald_ is now known as virtuald [10:15] chrisccoulson: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100122-no-xrandr.png vs. http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100122-with-xrandr.png [10:15] yes, I noticed the upload in the debian changes list [10:15] cassidy, will sync [10:15] cassidy, thanks [10:15] so the gnome-session bar on your bootchart used to be ssh-agent [10:15] or something like that [10:15] ssh-agent? [10:15] mvo, hey [10:15] can you please get rid of it if there's gnome-keyring? [10:15] hi seb128 [10:16] mvo, trying pygobject? [10:16] or tried rather [10:16] not yet, I do this now [10:16] thanks [10:17] pitti - thanks. so the xrandr plugin takes around 200ms [10:17] chrisccoulson: fwiw, if the randr plugin of g-s-d doesn't do the work of getting screen resources (which is expensive only the first time someone does it), gnome-panel will do it [10:17] chrisccoulson: so AFAICS, the xranrd plugin costs us 2 mm of app start delay and an extra 3 mm CPU time in g-s-d [10:17] (yay for scientific measurement) [10:18] vuntz - i was just interested to know how long the probing takes - i wasn't considering disabling it [10:20] pitti - i will have some other changes for you to try later [10:20] (i need to refresh my packages first though, with the latest changes) [10:25] seb128, chrisccoulson: so, as an intermediate step I'd take out the seahorse AutoStartPhase=init, and add another WI to fix it for spawning on demand; ok for you? [10:26] pitti - yeah, i think so [10:27] * chrisccoulson really needs to understand how all this seahorse and gnome-keyring stuff works [10:28] hm, http://people.canonical.com/~scott/daily-bootcharts/ is still not updating [10:30] seahorse-daemon only communicates via dbus doesn't it? [10:31] so it should just be a case of adding a .service file right? [10:31] ^^^seb128? [10:31] dp/usr/share/dbus-1/services/org.gnome.seahorse.service [10:31] it's _supposed_ to work already, AFAIUI [10:31] chrisccoulson: just causes gnome bug 587632 apparently [10:31] Gnome bug 587632 in general "Impossible to find GPG keys the very first time" [Normal,Resolved: duplicate] http://bugzilla.gnome.org/show_bug.cgi?id=587632 [10:31] it does get spawned, users get it working on second try [10:32] it's just that whatever is calling it doesn't wait or retry [10:32] right, that's because it fork's before the dbus interface is registered [10:32] (most probably) [10:35] asac: hi, any update on question 98187/bug 421673 [10:35] Launchpad bug 421673 in modemmanager "modem-manager tries to probe, crashes PalmOS handhelds" [Undecided,Confirmed] https://launchpad.net/bugs/421673 [10:35] asac: or do you think I should raise it on the nm list? [10:36] didnt catch dan yet [10:36] unfortunately [10:36] TeTeT: yes, pinging nm-list is a good idea [10:39] asac: ok, will send an email there [10:45] pitti, If I read well, you were interested by mutter? so https://bugzilla.gnome.org/show_bug.cgi?id=607746 might worth a sight [10:45] Gnome bug 607746 in general "reduce gconf roundtrips at startup" [Normal,New] [10:45] same applies for metacity but I doubt it is used by default for ubuntu, right? [10:46] seb128, chrisccoulson: FYI, I updated and regrouped the WIs on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed [10:47] baptistemm: thanks for pointing out [10:47] you're welcome, I just a hub which transmit data, not that much [10:47] baptistemm: metacity> not right now, but also it's very harmless during startup [10:47] when will firefox be updated to 3.6 in lucid? [10:48] the real solution would be to make gconf smarter, which been discussed for years, but no one sat down and worked on it [10:49] and the win would be global ... [10:50] baptistemm, it's called dconf [10:50] chrisccoulson: how do you intend to speed up the xrandr plugin of the gnome-settings-daemon? (just curious) [10:50] does it work? I never tried it. [10:52] baptistemm, it's being worked [10:59] tseliot - i can't answer that until i've looked at it properly, but, the 200ms it currently takes to load is an opportunity for initializing gconf in parallel (as the xrandr plugin doesn't need gconf, and the whole session currently blocks on that initializing). if gconfd can parse all the default values inside that 200ms and be ready for the next g-s-d plugin, then there is some win there [10:59] pitti - thanks. sorry, i had to disappear for a bit [11:00] chrisccoulson: yes, g-s-d only checks whether the randr plugin is enabled or not in gconf [11:01] tseliot - i've got a patched g-s-d to hardcode the xrandr plugin to enabled, so that it starts without checking gconf [11:01] it would mean that users could never disable it, but i don't think that's an issue really [11:01] chrisccoulson: yes, most of them use it [11:18] pitti - do you know if bug 510907 is actually meant to work? [11:18] Launchpad bug 510907 in gnome-power-manager "Inhibit suspending (flag 0x4) not working over DBus" [Medium,Triaged] https://launchpad.net/bugs/510907 [11:18] re [11:18] it doesn't seem to be implemented in g-p-m at all [11:19] uh, no idea I'm afraid [11:19] i thought that worked [11:20] i wonder if the functionality worked properly when g-p-m handled the inhibitors [11:21] somebody should be working on g-p-m [11:22] it's a shame we get such a crap experience on such basic things [11:22] like screen dimming not working as expected [11:22] or battery estimation not working [11:23] seb128 - yeah, that sucks a bit. i'm limited with how much i can do with g-p-m, as i don't have a laptop and my desktop won't suspend anyway [11:23] i need to purchase a laptop and then i can fix those things ) [11:23] my main annoyance is dim not going back to where it was [11:24] like put what you like to work on while on battery [11:24] walk away 30 seconds [11:24] come back and touch the keyboard [11:24] it goes back to default dim level [11:24] not to what you set [11:24]