[03:58] hmm, it sounds like gnome-appearance properties is doing something to compiz settings [03:58] s/e p/e-p/ [03:59] I've gotten a couple bug reports about some compiz settings randomly getting reset but it seems to only happen when doing something else in g-a-p [07:47] Good morning [08:03] hello pitti [08:03] hey didrocks [08:45] hello & good morning [08:45] chrisccoulson, apparently you're now a father? [08:46] * baptistemm is just 1 week late at least [08:51] baptistemm: no, he is late, there's no flood of pictures in here (: [09:12] hey there [09:13] hi seb128 [09:18] lut seb128 [09:18] hey baptistemm [09:19] salut baptistemm didrocks [09:36] hey seb128 [09:37] seb128: good news wrt. boot speed: http://www.piware.de/2009/11/sudo-dpkg-p-hal/ :) [09:37] seb128: hm, aren't you on vac today? [09:37] hey pitti [09:38] on swap day officially [09:38] but I've a little ubuflu for some days and the weather is not so nice [09:39] so I'm in a "staying inside and looking a boot speed" mood now [09:39] great work ;-) [09:39] If having a swap day /and/ being ill doesn't stop you from working, what will? :) [09:40] well, I slept in the morning and will probably be out in the afternoon [09:40] but right now I'm doing some computer ;-) [09:40] Good boy :) [09:40] pitti, btw, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091127-2.png [09:41] chart of the day, we are back on normal timing with compiz fixed [09:41] good [09:41] pitti, I did some playing yesterday, removed nautilus from the session, turned off compiz and moved Xsession.d away [09:41] desktop loading was still some 7 seconds [09:42] darn [09:42] soren: didn't you know that seb128 was unstoppable? :) [09:42] didrocks: Yes, I noticed :) [09:42] but on your boot chart, compiz, nautilus, and gnome-panel each take 11 seconds still [09:43] right [09:43] hm, there's still xkbcomp, I thought that was gone now [09:43] pitti, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091126-52.png [09:44] that's the no compiz, no nautilus, no Xsession.d [09:44] ah, so there it's ssh-agent, g-s-d, and panel delays [09:45] right [09:45] I discussed with Scott yesterday [09:45] I think we will need to go back to what old gnome-session did [09:45] start everything together [09:45] and defer drawing until g-s-d sends a signal "theme set"? [09:46] we will never reach the target with ordering [09:46] *nod* [09:46] no [09:46] just start everything [09:46] we don't care about theme set, moving, flickering [09:46] we don't show the desktop while loading [09:47] right, but won't redrawing the desktop cost us more CPU? [09:47] setting the theme etc takes some 1 second [09:47] (on theme change) [09:47] which is the g-s-d to next components delay [09:48] well, that needs testing but my gut feeling is that it will cost less that the 1 second delay we have there... [09:48] i. e. could nautilus'/panel's do_update_screen() whatever just return until it receives a signal from g-s-d? [09:48] especially with duo cores [09:48] ok, so let's shelve that idea until when we need it [09:48] yes [09:49] I think that signal thing makes sense [09:49] but right now we block nautilus, etc start on theme to be set [09:49] we should maybe block displaying on it [09:49] this way we would do inits, loading, etc already [09:49] right [09:49] and perhaps we can load the extensions first, and then draw the desktop [09:49] (or perhaps that already happens) [09:49] but that's not something we can do from gnome-session [09:50] yes, that already happens [09:50] I would say drop the "wait on g-s-d" to start and see how it goes [09:50] so in the usual case, we coudl think that panel loading menus, or nautlus loading extensions will usually take longer than g-s-d loading the theme, and we win [09:50] there is a chance that the theme will be in place before nautilus reach the drawing code anyway... [09:50] and if g-s-d is really slower, you get a redraw, but *shrug*, it's behind xsplash [09:50] right [09:50] * pitti hugs seb128 [09:51] * seb128 hugs pitti back [09:51] seb128: how much work is it to drop the phase handling from g-s? [09:51] I was just starting looking at that [09:51] i. e. is it just changing the .desktop files/gconf keys, or does it require code changes? [09:51] man, you rock [09:51] I will do a first quick hack now [09:51] ie edit desktop files and gconf keys [09:52] not sure yet if code changes are required [09:52] I just started with a drop from phases from autostart desktops there [09:52] I will also empty required components [09:52] and add normal autostarts for gnome-panel, compiz, nautilus [09:53] let's see how that goes === kwwii_ is now known as kwwii [10:16] seb128: want me to add the dx work items into a desktop-lucid-dx-integration blueprint? [10:36] seb128: hi... I'm unable to find the dup of Bug #481411 .... the closest i could find is Bug #398110 , are you sure its been reported already... [or maybe i'm blind :( ] [10:36] Launchpad bug 481411 in empathy "Empathy's chat service list is unordered and ugly" [Low,Invalid] https://launchpad.net/bugs/481411 [10:36] Launchpad bug 398110 in empathy "add account dialog is confusing" [Wishlist,New] https://launchpad.net/bugs/398110 [10:38] mac_v, for one thing that bug describe severals issues [10:38] yeah , the second bug has many problem. but 481411 is only about the alignment [10:38] mac_v, bug #437414 [10:38] Launchpad bug 437414 in empathy "some protocol icons in create account dropdown menu are missing" [Low,Triaged] https://launchpad.net/bugs/437414 [10:38] for example [10:39] seb128: ah.. awesome , thanks [10:39] you're welcome [10:40] * seb128 kicks the session menu hibernate [10:40] I keep selecting that by mistake [10:40] no confirmation [10:46] seb128: i also do the same mistake ;) > Bug #367626 [10:46] Launchpad bug 367626 in pm-utils "Hibernate does not ask for time-out confirmation" [Undecided,New] https://launchpad.net/bugs/367626 [11:16] pitti: what is desktop team doing to target specs for milestones accurately? do you split up specs to reflect things that will be done in two steps? e.g. first for alpha-2, rest for -3 etc.? [11:18] asac: we don't split up, we just target them to a2, and then re-target later on for the remaining work items [11:19] ok thanks! [11:21] asac: also, https://wiki.ubuntu.com/WorkItemsHowto has some thoughts about splitting the WIs in the blueprint whiteboard [11:22] pitti: can i already use that syntax without breaking the parser? [11:23] asac: sure, it will just look at "Work items:", not at anything else [11:23] it's just for shelving future work items [11:23] and track them without going into the parser while we are pre-alpha2 [11:24] ah [11:24] ok so current ones go in Work items: ... and the future ones in something else ... makes sense [11:24] first thought we would use that syntax to target too ... but ok [11:25] so i am using: Work items for post-alpha-2: [11:25] that should be fine [11:25] asac: the only drawback is that it won't go into the "lucid" work item chart [11:26] but we don't actually have (a lot of?) such "split" specs in desktop [11:26] they are either completely for alpha-2, or just for final [11:26] asac: for such finer-grained scheduling we probably need to switch to bugs [11:27] right. but the spec i am looking at is of the kind "investigate, document and defer new work items for post-alpha-2" anyway [11:27] so the work items would get expanded anyway [11:27] yeah. when do you think can we use bugs? this cycle? [11:27] when there's a demand for it and someone (me?) finds time to implement it [11:28] we didn't have a real demand for it so far [11:28] all fine. [11:28] it's quite some overhead, so we don't want to use it for all WIs [11:28] right [11:28] i would think splitting up specs would be less overhead if we really want that [11:29] rather then editing bugs etc. for each item [11:31] pitti: how about parsing all work items.*: for the main trendline chart? so we can split up now and things we know about wouldnt be initially hidden? [11:32] (or later hidden) [11:32] if you can invent an easy and robust syntax and semantics for that, sure [11:32] could perhaps be [11:32] so basically have two parser runs: a) full cycle items: "work items.*" ... and b) target milestone tasks: "work items:" [11:32] work items: -> (always considered) [11:33] Work items (milestone-name): -> only considered for that particular milestone name [11:33] asac: other way round rather, I guess? [11:33] work items.*: -> always considered, rather [11:33] right like i said ;) [11:33] pitti, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091127-8.png [11:33] ^ all started together [11:34] asac: "work items:" would then just be for the entire cycle [11:34] both ways work i think. [11:35] so basically we have [11:35] Work items (next-milestone): [11:35] ... [11:35] and then for the rest we will schedule later [11:35] seb128: now, that looks much more compact already [11:35] Work items: [11:37] whatever is easier for you to implement [11:37] seb128: seems that pulseaudio is started three times? [11:38] pitti, is it? [11:39] seb128: by canberra-gtk, gnome-volume-applet, and again by gnome-session [11:40] oh right [11:40] weird [11:41] that's one of those things it would maybe make sense to get starting earlier [11:43] pitti, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091127-15.png [11:43] ^ without menus [11:43] it's some 0.3s win [11:43] not a lot [11:44] a bit less CPU on panel, yes [11:48] good morning everyone [11:49] hey chrisccoulson [11:49] how are you? [11:49] hello Keybuk [11:49] hey seb128. i'm ok thanks, how are you? [11:49] good thanks [11:49] morning(ish) [11:49] Keybuk, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091127-8.png [11:50] hey chrisccoulson [11:50] hey pitti, how are you? [11:50] Keybuk, I did try to make every run as an application in gnome-session [11:50] Keybuk: http://www.piware.de/2009/11/sudo-dpkg-p-hal/ *grin* [11:50] chrisccoulson: I'm good, thanks! [11:50] ie no early components blocking things [11:51] seb128: that looks pretty good, no? [11:51] better yes [11:51] we still have a ~1s gap [11:51] but I think it's gconfd as chrisccoulson pointed yesterday [11:51] we probably need something between the two, in practice; a gnome-session that starts things in a certain order, but with no gaps [11:51] i was going to do some profiling with gnome-session today to try and figure out what the gap is [11:51] right [11:52] chrisccoulson, you rock ;-) [11:52] gconfd doesn't appear until later on your chart [11:52] i tried last night, but when i ran gnome-session manually from xterm, i didn't see that delay :-/ [11:52] pitti: so if we parse the way you suggested, wouldnt just "work items:" mean that those are targetted to whatever milestone the blueprint is targetted for? [11:52] rather than "entire cycle" (not that its really different) [11:53] Keybuk, hum, it seems rather it's done loading around the time everything starts [11:53] e.g. moving towards targetting full blueprint from "first" delivery milestone to "final delivery"? [11:53] Keybuk - "a gnome-session that starts things in a certain order, but with no gaps" should already happen with the current design, if clients register faster [11:53] chrisccoulson, well, "if clients register faster" [11:53] like g-s-d takes over 1 second [11:54] to set themes, etc [11:54] even if they registered at the top of main, you'd still be loading executables and relocating symbols in series [11:54] seb128 - i don't understand why that happens actually. gnome-session doesn't wait for clients to register in the initialization phase (where g-s-d starts) [11:54] it waits for them to exit before starting the next phase [11:55] and g-s-d fork()'s before loading the plugins and setting the theme [11:55] chrisccoulson: assumedly you wait for them to fork() ? [11:55] Keybuk - yes [11:55] that's the last thing most software does before entering its main loop [11:55] so again, you're doing all the initialisation in series [11:55] Keybuk - i'll have a look at g-s-d in a second, but I thought it fork()'ed before loading the plugins [11:55] i might be wrong though [11:56] http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091127-22.png [11:56] http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091127-22.png is an empty gnome-panel [11:56] lunch, bbl [11:57] Keybuk - you're right. it fork()'s very early on, but the parent only terminates before entering the main loop (after loading the plugins) [11:57] i'm not sure why it delays terminating the parent until then [11:57] obviously sometimes letting everything run at once isn't the right solution either [11:58] but most machines now have multiple cores [11:58] so you can run multiple CPU-bound apps at once anyway [11:58] and most aren't CPU bound, but doing syscalls [11:58] (or IO which should already be in the page cache) [11:59] i'll have a look at removing that delay later, but i want to try and figure out where this other 1 second goes first [11:59] timechart may help more than bootchart at this stuff [11:59] but requires kernel patching and struff [12:00] timechart? [12:00] ah, http://blog.fenrus.org/?p=5 [12:00] asac: that's what I mean with "not that easy to figure out a sensible semantics" :) [12:01] pitti: naturally i would think that blueprints should be targetted to the milestone when they are supposed to be completely done. [12:02] asac: right; for those we wouldn't even use several "work item (milestone)" things [12:02] so if we really had the syntax you suggested (work items (milestone)) [12:02] pitti: well. what i mean is if we hav a blueprint which is targetted for lets say beta-1, but have parts that should be done by alpha-2 [12:03] it would just work to keep the blueprint targetted for beta-1 [12:03] but have work items alpha-2 [12:03] if a blueprint doesnt have the intermediate steps we would just have Work items: [12:04] feels sensible semantic to me ;) [12:05] okay [12:15] pitti: I feel that when the first daily image without HAL is done, we should hold a great, big, world-wide party [12:15] Keybuk: the changes are all in the Debian experimental git branch (new x server, udevification, and my udev rules), so I hope we can upgrade to that next week [12:15] yay for celebrations :) [12:16] I didn't think our X was based on Debian? [12:17] it should be nowadays [12:17] well, perhaps not the server itself, I don't know [12:17] but I thought we'd regularly merge [12:18] no idea [12:21] Could gnome-settings-daemon delay calling xrdb until after everything else is loaded? [12:22] hrm, compiz is chewing CPU for about 10 seconds there [12:28] So I'm thinking of patching compiz so it's not possible to set "edge" bindings [12:29] So you can't have a compiz action happen by moving your mouse to the top, bottom, left, or right of your screen [12:30] hmm, and if we're going to force our new default settings on upgrades to lucid we can cleanup the patches and packaging that set defaults as well [12:57] re [12:58] Amaranth, did you have a look at splitting compiz binaries? [13:08] seb128 - gnome-session blocks for 600ms here in gsm_manager_new. i haven't gone any further yet, but that will probably be the preloading of gconf keys [13:08] chrisccoulson, ok [13:09] so you were guessing right with gconf yesterday [13:09] possibly, i need to make it more verbose just to make sure, but i can't see anything else in there that would take that much time [13:17] seb128 - also, 200ms loading the desktop files in /etc/xdg/autostart [13:28] preloading of gconf keys? [13:28] preloading implies it's not actually using them? [13:28] what happens if you just take that out [13:33] Keybuk - the preloaded keys are used to build the required components list a little while later [13:33] s/a little while later/straight after [13:34] that seems like a long time [13:34] i'm just doing another build with it broken down further, so i can see where the time is spent [13:36] but it doesn't seem that long if gconfd is still loading it's XML files [13:43] Keybuk, so, the biggest delays at the start of gnome session seem to be ~500ms loading GConf keys, 200ms loading desktop files and ~100ms in gtk_init [13:45] so if I gave you half the time to do that in, what would you change? :) [13:46] replace gconf with dconf ;) [13:46] but i'm wondering if we can start gconfd before the session starts (ie, from a script in Xsession.d) [13:46] and whether it would actually make any difference === cypher_ is now known as czajkowski [15:17] mpt: any decisions on the appdetails throbber thing? [15:17] and471_, I need to find out somewhere how to slow down my Internet connection to test it [15:17] I know there's a command line to use to make it slower [15:18] but I don't know what it is [15:18] mpt: did trickle not work? [15:18] ah, trickle, is that what it is [15:19] * mpt installs it [15:19] mpt: google 'linux slow down internet connection trickle' [15:19] mpt: and see you later :-) [15:22] mpt: aloha there [15:22] :) [15:22] kia ora === soren` is now known as soren [16:01] Keybuk - I just tried starting my session with an already running gconfd process, and the preloading time in gnome-session went from ~500ms to ~150ms [16:01] but i don't know how we'd start it early enough to avoid this delay [16:01] Xsession.d ? [16:02] I think I'm going to try that. i was going to do it earlier but had to disappear somewhere else instead [16:02] and maybe we could make a cache of the autostart desktop files to shrink the other 200ms too [16:21] mpt: any luck? [16:26] and471, I tried it, and I think it's better to show the throbber [16:26] and471, maybe one way of making it look better on a fast connection is to not show the throbber until 2 seconds after the screenshot starts loading [16:26] That way if it loads within 2 seconds, the throbber doesn't get shown at all. [16:29] mpt: okay [16:29] mpt: currently I am trying to use webkit's animation functionality, I have done it on the department view and I am now going to try the appdetailsview [16:29] however after sunday I really cannot do anymore work :-) [16:30] and471, what's happening on Sunday? [16:30] mpt: well after that I have exams :-/ [16:30] ah [16:30] Best of luck with those [16:30] and thanks for all your contributions :-) [16:34] mpt: sure :-) [16:37] Keybuk - are you running i386 or amd64? mind testing a build of gnome-session with no preload on your reference machine? it seems to speed things up here, but my bootchart results are all over the place at the moment (running in virtualbox) [16:44] i386 [16:44] I don't have test reference machines atm though [16:44] they're both doing reinstalls [16:45] so if you don't mind waiting a few hours? [16:45] yeah, thats ok [16:45] i've hosted the files here: http://people.ubuntu.com/~chrisccoulson/gnome-session-no-gconf-preloading/ [16:46] i'll probably try some more things shortly [16:47] the changelog is not very verbose though ;) [16:48] but that build completely disables preloading, and also writes some timestamps in ~/.xsession-errors [17:37] robbiew_, could you please set me as drafter for foundations-lucid-non-applications-in-software-center, foundations-lucid-ratings-and-reviews-in-software-center, foundations-lucid-software-center-subcategories, and foundations-lucid-user-contributed-metadata-for-software-center? [17:37] ok [17:37] thanks [17:40] mpt: done [17:41] ta [17:43] good night everyone [17:46] good night pitti [17:50] bratsche, were you in the accessibility-by-default UDS session? If so, do you remember if it was written up anywhere? I don't see a Gobby document [17:51] Hey, it's gilir, maintainer of my favorite PPA [17:52] mpt: hi, why ? [17:58] mpt: if i read the notification spec correct, the do not distrub mode will be automatically triggered by apps? meaning if i go fullscreen in totem, then automatically i will be in dnd mode? [17:58] please tell me i read it wrong. [17:59] tgpraveen11, meaning you should be able to configure whether Totem going into full-screen suppresses non-urgent notifications or not. [17:59] yes that is what i want. is that what is planned? [18:00] yes [18:00] mpt:^^? [18:00] oh ok. thats great. will it be global or per app. like i set my status to DND and all apps accept it or in each app i have to set it? [18:00] tgpraveen11, per-app [18:02] mpt: hmm is there any reason for per app? in the karmic cycle the documentation mentioned doing it global iirc. also can you shed some light on how one would set it per app? i mean like will totem have a menu item for this [18:03] tgpraveen11, a global option would be pretty meaningless -- Hide non-urgent notifications: (*) Never ( ) Sometimes [18:04] Individual apps can do a better job of presenting the option in an understandable way [18:05] mpt: hi... are we not supposed to change the icon firefox on the panel ? [18:05] mac_v, change it to what? [18:05] mpt: monochrome > http://dl.dropbox.com/u/1325768/Screenshot.png [18:05] hmm i was thinking more like in the user switch applet the status could be available() DND(*) . [18:06] this would make more sense as once done it affects all apps. and this was what was there in the doc originally as well [18:06] mac_v, no, that's just for the status icons -- application icons should be left as they are [18:06] mac_v, and anyway, we couldn't legally alter the Firefox icon even if we wanted to [18:06] ah ok ;) [18:06] and say i dont want to be disturbed for 1 hour i just set it and do my business what i want [18:07] but per app each time i watch a movie, open a pdf etc i would have to set it. [18:07] * mac_v hates legalities ;p [18:07] also a global DND helps when i am not using fullscreen apps but just dont want to be disturbed with my work [18:09] mpt: ^^ === eeejay_away is now known as eeejay === eeejay is now known as eeejay_away === eeejay_away is now known as eeejay === cassidy` is now known as cassidy === eeejay is now known as eeejay_away === eeejay_away is now known as eeejay [22:42] aloha [22:42] anyone alive for a daft question? [22:43] did an update recently and looked at my options under applications and the ubuntu software center is missing ??? any idea [22:43] I'm not the only person missing it, JanC is also [22:44] I just did apt-get install gnome-app-install and got back the add/remove options [22:44] seems like I have a .local/share/applications/gnome-app-install.desktop / removing that now... [22:45] so, that makes that disappear [22:45] but still no software center... [22:45] hmmm [22:45] it's very odd as I know it was there, but no idea when it went or why it went [22:46] idem ☺ [22:47] typical friday adn I break things [22:47] JanC: is your add/remove populated with stuff?? [22:48] add/remove didn't work as gnome-app-install wasn't installed (leftover .desktop file for some reason?) [22:48] add/remove for me wasn't there, so did apt-get install and there is it === eeejay is now known as eeejay_away [22:49] yeah, after removing the leftover .desktop file under ~/.local it went away here too [22:50] BTW, installing it removes software-center ;) [22:50] JanC: but mine wasnt there [22:50] the package you mean? [22:51] I just removed & re-installed software center and it's still not in the menu [22:51] add/remove wasnt there [22:53] I had a leftover user .desktop file for add/remove for some reason which probably caused the menu to be shown, so removing it removed the menu entry, but software-center didn't come back [22:55] so I should it? [23:06] I asked somebody else and he doesn't have this issue :-/ [23:07] ah feck [23:07] JanC: log a bug and i'll comment [23:08] not sure against what to file the bug yet [23:09] thats always my issue :( [23:17] czajkowski: do you have ubuntustudio-menu installed ? [23:18] or something similar ? [23:18] removing that solved it for me... [23:18] nope [23:18] tis damn flippin' odd [23:19] and now I have a 2 screens high audio/video menu again, *sigh* [23:19] hmm sorry I mentioned it now [23:19] as now it's annoying me [23:21] do you have any menu-related packages installed ? [23:21] wine? === eeejay_away is now known as eeejay [23:22] I have wine installed too, and I get the software center menu now [23:22] edubuntu-menus, extra-xdg-menus ? [23:23] I'll do another update [23:23] nope, nope [23:23] it was there till wednesday and after that i can't be sure, but I've not installed any new things [23:23] hmm restart [23:30] JanC: The desktop file was a leftover from alacarte due to you editing your menu [23:30] JanC: no difference [23:30] Amaranth: what is alacarte? [23:32] Amaranth: I doubt I ever consciously edited *that* menu entry (but maybe accidentally?) [23:33] alacarte is the menu editor [23:33] which Amaranth wrote long ago ;) [23:34] yup we;; I've definately not been editing it [23:34] ;) [23:34] *we'll [23:36] well, the menu item comes & goes when I install/remove ubuntustudio-menus [23:36] that might give some clue ☺ [23:38] so we can blame ubuntu studio :) [23:38] right, that one references gnome-app-install.desktop instead of ubuntu-software-center.desktop [23:38] but you said you don't have it? [23:38] I've ubuntu studio theme installed not menu [23:39] doesn't look like that pulls anything weird in [23:45] czajkowski: the menu is a combination of '/etc/xdg/menus/applications.menu', '~/.config/menus/applications.menu' plus whatever can be found in '~/.local/share/applications/' [23:45] I think [23:49] okay, this is the ubuntustudio-menu issue: https://bugs.launchpad.net/ubuntu/+source/ubuntustudio-menu/+bug/479156 [23:49] Launchpad bug 479156 in ubuntustudio-menu "gnome-app-install instead of ubuntu-software-center" [Undecided,In progress] [23:50] czajkowski: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/477127 might be useful too [23:50] Launchpad bug 477127 in software-center "menu for software-center is missing " [Undecided,Confirmed] [23:56] JanC: cheers [23:57] you might want to comment on the last one and tell them the first one isn't the same issue ;) [23:58] (but maybe related) [23:59]