[00:03] <Nafai> Hello from Lucid!
[00:04] <Nafai> It boots way fast, great job guys
[00:05] <Sarvatt> bootup times are just getting worse and worse here, 42 seconds on 1-21 and steadily rising to 1 minute 11 seconds today. guess I need to buy a SSD for this netbook :D
[00:06] <seb128> do you have a bootchart of your boot?
[00:07] <Sarvatt> http://sarvatt.com/downloads/asuka-lucid-20100127-1.png
[00:08] <Amaranth> Sarvatt: you have to reboot twice after an upgrade :)
[00:08] <seb128> hey Amaranth
[00:08] <Amaranth> howdy
[00:08] <seb128> it has been a while
[00:08] <seb128> how are you?
[00:09] <Amaranth> I've been going to bed at a proper time and thus missing you :)
[00:09] <rickspencer3> Amaranth!
[00:09] <Amaranth> good, doing some contract work on top of my day job, crazy busy
[00:09] <rickspencer3> welcome back
[00:09] <seb128> hehe
[00:09] <rickspencer3> Nafai sweet
[00:09] <Amaranth> one part of the contract work: make compiz start faster
[00:09] <seb128> Sarvatt, try booting again, it was profiling on this one
[00:09] <Amaranth> handy, that
[00:09] <seb128> Amaranth, who contracted you for that?
[00:10] <seb128> Amaranth, speaking of which do you still plan to work on cleaning things to install by default?
[00:10] <Amaranth> hmm, don't really want to say right now
[00:10] <seb128> k
[00:10] <Amaranth> seb128: dunno if I'll have time for it any time soon
[00:10] <seb128> I planned to look at that with mvo next week since you didn't reply to my pings from some weeks ago
[00:10] <seb128> ok
[00:10] <Amaranth> It's easy enough, just split the packaging into stuff we use + cube/rotate and stuff we don't
[00:11] <seb128> right
[00:11] <Amaranth> oh, and wobbly, need to keep wobbly in the default install
[00:11] <Sarvatt> that might explain it, i dont think i've ever rebooted without having upgraded something inbetween unless I crashed..
[00:11] <seb128> it's just that I didn't want to go through every .xml and .so to figure which ones are used
[00:11] <Amaranth> I spent all my time on it making separate packages for everything
[00:11] <seb128> especially if you did that already
[00:11] <seb128> is there an easy way to list those used?
[00:12] <Amaranth> $ gconftool-2 --get /apps/compiz/general/allscreens/options/active_plugins
[00:12] <seb128> the file matches the gconf list?
[00:12] <seb128> and there is no depends system or anything to take in consideration?
[00:12] <Amaranth> yeah, fade plugin has libfade.so and fade.xml files, etc
[00:13] <Amaranth> if there are dependencies we have those plugins loaded too so if you're just splitting it in half you don't need to care about those
[00:13] <Amaranth> s/half/two packages/
[00:13] <seb128> ok good
[00:13] <seb128> I want a least to delete the not used one there to see what difference it makes on boot
[00:14] <seb128> not used ones rather
[00:14] <seb128> I expect there is several of those ;-)
[00:14] <Amaranth> you can do that without doing any packaging work then, just remove all the lib*.so and *.xml files that aren't in that list and reboot a couple times :)
[00:14] <Amaranth> probably gain you 0.5s
[00:14] <seb128> yeah, I will do that
[00:15] <seb128> ok, almost nothing then
[00:15] <seb128> I'm wondering where those 10 seconds of cpu use go
[00:15] <Amaranth> highest I could see would be 1 second
[00:15] <Amaranth> probably plugins interacting with all these windows loading
[00:15] <Amaranth> hack gnome-session to make compiz load last, see what happens
[00:16] <seb128> we sort of do that now, well we don't load it first
[00:16] <seb128> we load it as a standard application
[00:16] <seb128> but I will try to delay it
[00:16] <Amaranth> really it needs to load (and be done loading) right before xsplash goes away
[00:16] <Amaranth> I was talking about that with keybuk
[00:17] <Amaranth> If we have xsplash we can hide the fact that things are ugly while compiz is loading by making them talk
[00:17] <seb128> well officially we don't need to speed compiz since it's too slow anyway and we changed targets
[00:17] <seb128> but still would be nice to have faster desktop boot
[00:17] <Amaranth> changed targets?
[00:17] <seb128> boot target is une now
[00:17] <Amaranth> ah
[00:18] <Sarvatt> there we go, a little better that time. http://sarvatt.com/downloads/asuka-lucid-20100127-2.png   i think that solar plymouth theme is a little too nice for this atom cpu :D
[00:29] <seb128> 'night everybody
[00:34] <seb128> robert_ancell, I've accepted your ubuntu-desktop post and added you to the whitelist
[00:35] <seb128> robert_ancell, quicker to reply there than by email ;-)
[00:36] <djsiegel> TheMuso: did you find anything about about webkit accessibility?
[00:38] <robert_ancell> seb128, thanks!
[00:38] <seb128> np
[00:38] <seb128> really off to bed this time ;-)
[00:38] <seb128> 'night
[00:50] <chrisccoulson> hey robert_ancell
[00:52] <robert_ancell> chrisccoulson, hi
[00:52] <chrisccoulson> how are you?
[00:53] <robert_ancell> good
[00:53] <hyperair> dpkg-deb: building package `gnome-power-manager' in `../gnome-power-manager_2.28.1-0ubuntu1.3_amd64.deb'
[00:53] <hyperair> woo
[00:53] <hyperair> pitti: ^^
[00:54] <chrisccoulson> another gpm update? it's taking up all my bandwidth this week ;)
[00:54] <hyperair> chrisccoulson: ;-) this is the final one.
[00:54] <chrisccoulson> cool!
[00:54] <hyperair> chrisccoulson: final one for the double suspend issue.
[00:55] <hyperair> chrisccoulson: would you prefer i just paste the patch here or upload it to launchpad?
[00:55] <chrisccoulson> i think it would be better in launchpad
[00:55] <hyperair> okay then
[00:55]  * hyperair reluctantly lets the huge bug page load
[01:23] <Nafai> yay, lucid fixed one of my major complaints about the ubuntu desktop
[01:32] <LLStarks> ArneGoetje, would package should i file that antialiasing issue against, fontconfig?
[01:53] <hyperair> chrisccoulson: the patch is attached.
[01:53] <chrisccoulson> hyperair - thanks
[01:53] <chrisccoulson> i'm going to go to bed in a minute anyway, so i will look at it in the morning
[01:54] <hyperair> sure
[02:01] <ArneGoetje> LLStarks: if it's a general issue, yes. If it's only with some fonts, it might be a configuration issue in the font package.
[02:02] <ArneGoetje> LLStarks: please also consider the application to play a role there. Please do test if it only affects one application or multiple or all.
[02:15] <LLStarks> ArneGoetje, i'm a bit curious as to what ubuntu falls back on in firefox when tahoma fonts are called and ttf-tahoma-replacement is not installed.
[02:22] <ArneGoetje> LLStarks: depends on which other fonts are installed on the system
[04:23] <kenvandine> TheMuso, ping
[08:02] <didrocks> good morning
[08:47] <seb128> hey there
[08:49] <didrocks> salut seb128
[08:49] <didrocks> ça va ?
[08:49] <seb128> lut didrocks
[08:49] <seb128> ouais, et toi ?
[08:50] <didrocks> ça va bien, couché tôt ;)
[08:52] <seb128> didrocks, lucky you ;-)
[08:52] <seb128> hey slomo
[08:53] <slomo> hi seb128
[08:53] <seb128> slomo, did you read my comments about totem-pl-parser yesterday?
[08:53] <didrocks> seb128: heh, I saw that you were still active at 01:40 ;)
[08:53] <slomo> seb128: sorry for choosing a different package name than ubuntu, i wasn't expecting this to be in ubuntu already (i mean, i updated the package yesterday morning very few hours after the release)
[08:54] <seb128> didrocks, yeah, I was out in the evening and did read bug emails to make sure I didn't break anything when coming back
[08:54] <didrocks> ok :)
[08:54] <seb128> slomo, we update some minutes after the tarballs if those are duing work hours ;-)
[08:54] <seb128> slomo, no problem, it's just that the name you picked don't match the debian gir policy
[08:54] <seb128> slomo, ie you didn't use the gir version there for example
[08:55] <pitti> Good morning
[08:55] <didrocks> (and upstream gir version is incorrect, we have a patch for this release which has been integrated upstream)
[08:55] <didrocks> hey pitti
[08:55] <seb128> hello pitti!
[08:55] <pitti> crimsun: if we need to keep it, nevermind; I'll just try to trim it a little then
[08:56]  * pitti waves bonjour to the French mafia
[08:56] <slomo> seb128: the gir has no version... the only thing that was wrong was the '-' unless i misunderstood the policy
[08:56] <slomo> seb128: which version did you add in ubuntu?
[08:56] <seb128> slomo, the "no version" is an upstream bug that didrocks fixed in ubuntu and upstream git
[08:57] <slomo> ok
[08:57] <seb128> slomo, http://git.gnome.org/browse/totem-pl-parser/commit/?id=2d51c9ad64a0b4b6504d99e2f29716701bcf0c6b
[08:57] <seb128> slomo, or https://bugzilla.gnome.org/show_bug.cgi?id=608176
[08:58] <slomo> thanks
[08:59] <seb128> np
[09:00] <seb128> slomo, btw http://launchpadlibrarian.net/38478987/buildlog_ubuntu-lucid-i386.gstreamer0.10_0.10.25.2-2_FAILEDTOBUILD.txt.gz
[09:01] <seb128> slomo, known issue?
[09:01] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-1.png
[09:02] <seb128> pitti, any special change in that one?
[09:02] <slomo> seb128: no, thanks
[09:02] <pitti> seb128: just the daily; but I wanted to look at g-panel
[09:02] <pitti> with yesterday's change
[09:03] <seb128> pitti, doesn't seem to make a real difference
[09:03] <pitti> *nod*
[09:04] <seb128> still 7 seconds of desktop loading
[09:04] <seb128> almost twice the budget
[09:04] <chrisccoulson> good morning everyone
[09:04] <pitti> I'll try the new kernel
[09:04] <pitti> hey chrisccoulson
[09:04] <seb128> rather 8 seconds
[09:04] <seb128> hey chrisccoulson
[09:05] <chrisccoulson> hey pitti - i've got something for you to try this morning. we discussed yesterday about starting gconfd from Xsession.d, so I hosted the work I initially did at http://people.ubuntu.com/~chrisccoulson/desktop-startup-speed/crack/
[09:05] <chrisccoulson> hey seb128, how are you?
[09:05] <seb128> chrisccoulson, a bit tired but good otherwise thanks
[09:05] <seb128> chrisccoulson, you?
[09:05] <chrisccoulson> pitti - it's not packaged in any way at all, and the helper needs compiling
[09:06] <chrisccoulson> seb128 - i'm quite tired too this morning. we have a sick baby, so i didn't get much sleep last night
[09:06] <seb128> oh :-(
[09:07] <pitti> chrisccoulson: nice! will do
[09:08] <chrisccoulson> pitti - cool, thanks!
[09:08] <seb128> pitti, seems we won 1 seconds compared to yesterday though
[09:08] <seb128> pitti, do you know what boot speed changes landed yesterday?
[09:08] <seb128> out of the gnome-panel one
[09:09] <pitti> seb128: not using gnome-wm any more
[09:09] <pitti> that made a big difference
[09:10] <seb128> pitti, that should was 2 days ago though no?
[09:10] <seb128> pitti, it should have been in yesterday's chart of yours?
[09:10] <pitti> hm, could be
[09:11] <pitti> right, it was
[09:11] <pitti> seb128: the new wncksync perhaps
[09:11] <seb128> I'm just wondering if after all the gnome-panel did win some 0.1 seconds
[09:11] <pitti> ah, no, that landed Tuesday evening, and was on yesterday's
[09:11] <seb128> bootchart is not reliable enough to be affirmative on such differences
[09:12] <pitti> *nod*
[09:13] <seb128> so next win is the background caching
[09:13] <seb128> I still need to investigate the nm-applet today
[09:13] <seb128> and chrisccoulson's gconf change
[09:14] <seb128> pitti, the "sh" process is not on today's daily btw
[09:14] <pitti> seb128: it sometimes disappears in the noise
[09:14] <seb128> ok
[09:18] <pitti> gosh, is g-s-d still calling xkbcomp?
[09:20] <seb128> pitti, it should not, why?
[09:21] <pitti> http://people.canonical.com/~ogra/osiris-lucid-20100127-3.png
[09:26] <seb128> pitti, it's probably coming from libxklavier
[09:28] <chrisccoulson> it is
[09:28] <chrisccoulson> xkl_config_get_keyboard
[09:29] <chrisccoulson> oh, actually, that's not public
[09:29] <chrisccoulson> it's xkl_xkb_activate_config_rec
[09:30] <seb128> chrisccoulson, that one is not used in libgnomekbd or g-s-d though...
[09:30] <pitti> hm, no difference with 2.6.32-12
[09:30] <seb128> I've been trying to find which call lead to that without luck though
[09:31] <chrisccoulson> hmmm
[10:08] <pitti> chrisccoulson:
[10:08] <pitti> old: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-1-2.6.32-12.png
[10:08] <pitti> with your hack: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-gconf-xsession.d.png
[10:09] <seb128> no win
[10:09] <pitti> it increased the latency for the apps a tad (could also be noise, though), and there's still a slight CPU drop
[10:09] <pitti> structually it worked, though
[10:09] <pitti> I'll check what the difference is to drop sanity-check
[10:19] <pitti> chrisccoulson: any chance we could sqeeze it before ssh-agent?
[10:20] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-gconf-xsession.d-disabledsanitycheck.png
[10:21] <pitti> this ^ already looks better
[10:22] <seb128> seems to win 0.1 second?
[10:22]  * pitti tries 91x11-gconfd-helper
[10:27] <pitti> no real difference
[10:30] <didrocks> seb128, pitti: wallpaper caching seems to work well, I'll do additional test this afternoon
[10:30]  * didrocks gets in Paris to meet lool
[10:30] <pitti> didrocks: wow!
[10:30] <pitti> didrocks: where are you doing this? postinst magic? or at runtime?
[10:30] <didrocks> pitti: runtime
[10:31]  * didrocks back in a couple of hours
[10:31] <pitti> o/
[10:32] <pitti> didrocks: let's look over this when you are back; there are some gotchas that come to my mind
[10:36] <baptistemm> hello
[10:37] <pitti> eww, gst-plugins-bad now pulls in jack
[10:38] <pitti> is that intended?
[10:38] <seb128_> dunno
[10:52] <chrisccoulson> pitti - just checking the scrollback
[10:52] <chrisccoulson> (sorry, i was away from my desk)
[10:53] <chrisccoulson> pitti - is this with my build of gconf too?
[10:54] <pitti> chrisccoulson: no, stock lucid otherwise
[10:54] <pitti> chrisccoulson: shall I reinstall your other packages again?
[10:54] <chrisccoulson> i think i need to hack gnome-session to comment out the gconf_init bit, to stop it from spawning gconf-sanity-check
[10:54] <pitti> I just chmodded that to 0
[10:54] <chrisccoulson> also, gconfd has to be loaded with a working session bus, so it can't load before ssh-agent unfortunately
[10:55] <seb128_> so compiz is much less busy when delayed
[10:55] <pitti> chrisccoulson: I thought it just needs to be dbus-launch gconfhelper ssh-agent gnome-session ?
[10:56] <seb128_> (just checking delay desktop boot on the mini to see how that changed)
[10:56] <chrisccoulson> pitti, yeah, we could do it that way. i think it is currently ssh-agent dbus-launch gcond-helper gnome-session isn't it?
[10:56] <seb128_> seems quite some compiz work is due to things moving on screen
[10:56] <pitti> chrisccoulson: I moved the gconfhelper to 91, that should have done it; no real difference in the chart, thuogh
[10:56] <pitti> seb128_: ah, due to re-rendering?
[10:56] <seb128_> pitti, that's what amaranth suggested
[10:57] <seb128_> the compiz bar is also twice less busy when using a sleep 5 to start it
[10:57] <seb128_> it takes less than 5 second then
[10:57] <vuntz> pitti, chrisccoulson: may I ask why you still put ssh-agent everywhere? :-)
[10:57] <seb128_> rather than some 9 seconds
[10:57] <chrisccoulson> vuntz - good question ;)
[10:57] <pitti> for the non-GNOME sessions and for people who prefer the openssh agent
[10:57] <seb128_> vuntz, we don't, the script check if ssh-agent should be used or not
[10:57] <vuntz> (not that it'd be a huge win, but well)
[10:58] <pitti> seb128_: well, that was the plan, but I gave up on it
[10:58] <vuntz> seb128_: ah, ok
[10:58] <seb128_> vuntz, also the openssh maintainer argue than ssh-agent is robust compared to gnome-keyring
[10:58] <seb128_> vuntz, so that we should make hard to opt gnome-keyring out
[10:58] <pitti> since asking gconf whether gnome-keyring will have ssh agent support is more expensive than just starting it
[10:58] <vuntz> pitti: so, if you're using GNOME, it's not possible to use the ssh-agent launched in the startup scripts
[10:58] <seb128_> vuntz, not to mention features gnome-keyring lacks
[10:58] <pitti> vuntz: if it was so easy..
[10:58] <vuntz> ah, yes, unless you look at the gconf key
[10:58] <vuntz> hrm
[10:59] <pitti> vuntz: in reality, it's "if you are using gnome _and_ yuo did not disable the g-keyring gconf key"
[10:59] <seb128_> vuntz, we were considering using ssh-agent instead of gnome-keyring as an agant
[10:59] <seb128_> agent
[10:59] <vuntz> pitti: indeed, I forgot about the gconf key
[10:59] <pitti> vuntz: and since ssh-agent has to start before g-keyring, it becomes a game of looking into the future
[11:00] <vuntz> on the other hand...
[11:00] <vuntz> a workaround would be to have ssh-agent started by gnome-session in the initialization phase, and set the env var via the gnome-session dbus method
[11:00] <vuntz> (using a wrapper app, I guess)
[11:01] <vuntz> but then, might not be worth the 0.05s win
[11:01] <vuntz> or whatever it is
[11:01] <seb128_> we still need it to be started out of GNOME though
[11:01] <vuntz> seb128_: why?
[11:01] <pitti> XFCE and the like
[11:02] <vuntz> ah, I misunderstood. Yes, of course
[11:02] <pitti> although we could just package this script separately
[11:02] <pitti> and pull it in with XFCE, etc.
[11:02] <pitti> but not in UNE
[11:02] <seb128_> would help those boxes with several desktops installed
[11:02] <seb128_> like une session on ubuntu desktop
[11:02] <vuntz> but yeah, in the end, it's probably not worth it, so just discard what I said for now ;-)
[11:03] <pitti> by and large I think the "package separately" idea will work best
[11:03] <seb128_> the easier would be to disable gnome-keyring agent and just use the ssh one everybody
[11:03] <seb128_> one *for* everybody
[11:03] <pitti> or that
[11:03] <pitti> but you loose a lot of nice integration with that
[11:03] <seb128_> I'm not sure how much the agent is "integrated"
[11:03] <pitti> openssh's doesn't cache passphrases by default
[11:04] <pitti> and you have no way to put it into your normal keyring, of course
[11:04] <chrisccoulson> pitti - sorry, i didn't see the 3rd chart there when you dropped gconf-sanity-check
[11:04] <seb128_> right...
[11:04] <chrisccoulson> i just saw it now
[11:04] <pitti> from my POV, g-keyring is so much nicer than the openssh one
[11:05] <chrisccoulson> pitti - how are you measuring the improvement on the bootchart?
[11:05] <seb128_> right
[11:05]  * pitti reduces the gconf loading time by 10% with some silly seddery trick and wonders if it's worth it
[11:05] <seb128_> what did you sed out?
[11:05] <chrisccoulson> the red line doesnt seem to move, but g-s-d starts quite a bit earlier
[11:06] <pitti> chrisccoulson: first, looking at the latency of the general app stage, and second looking at the time between the long gnome-session start line and the red "end" line
[11:06] <pitti> seb128_: tabs, empty string default values, and mtime
[11:06] <chrisccoulson> pitti - what about comments?
[11:07] <pitti> what annoys me much more is that this has millions of locale specific defaults
[11:07] <seb128_> I would have though that space, etc would win so much
[11:07] <pitti> which would be handled much more elegantly with gettext
[11:07] <seb128_> wouldn't
[11:07] <pitti> seb128_: well, that alone reduces it from 2.2 to 1.8 MB
[11:07] <pitti> chrisccoulson: it doesn't have any
[11:08] <chrisccoulson> pitti - there's no short and long descriptions in the defaults?
[11:08] <pitti> there are
[11:08] <chrisccoulson> do we need them?
[11:08] <pitti> hah, another such thing: %s/short_desc=""//g
[11:08] <pitti> chrisccoulson: unfortunately yes
[11:08] <chrisccoulson> :(
[11:09] <pitti> I think the biggest potential win would be to throw out locale specific defualts and get them through gettext
[11:09] <seb128_> then you would get the "load the mo files to get the value"..
[11:09] <seb128_> which I'm not sure would turn to be a win
[11:09] <pitti> that could be done on the client side only, though
[11:09] <pitti> similar to the translated descriptiosn
[11:10] <seb128_> well I though you didn't do it for the values to avoid the mo reading?
[11:10] <pitti> I just didn't consider teh values at all back then
[11:10] <seb128_> are you sure?
[11:10] <pitti> I thought they were for real localized default values
[11:10] <seb128_> I though we discussed that
[11:10] <pitti> not for translated text strings
[11:10] <pitti> seb128_: I'm not sure, no
[11:11] <pitti> <entry name="description"
CD 수준의
[11:11] <pitti> [...]
[11:11] <pitti> this is pure abuse of gconf
[11:11] <pitti> having a gconf value being used as a three-line text value which is human visible
[11:11] <seb128_> well usually translation of default are for specific usecases...
[11:11] <seb128_> like gedit has a key with default encodings
[11:11] <pitti> yeah, it does make sense for those
[11:12] <seb128_> the one you describe seems a bug
[11:12] <seb128_> do we have many of those?
[11:12] <pitti> but gnome-media is really abusing it
[11:13] <pitti> /usr/share/gconf/schemas/gnome-audio-profiles.schemas
[11:13] <pitti> that's plain crazy
[11:14] <seb128_> urg, yes
[11:17] <pitti> seb128: moving away /usr/share/gconf/schemas/gnome-audio-profiles.schemas alone already saves 10%
[11:17] <pitti> and reduces file size from 2.3 to 2.0 MB
[11:19] <pitti> this might be worth fixing in the package itself
[11:20] <seb128> what do you call "fix"?
[11:20] <pitti> drop the audio profile descriptions from gconf
[11:20] <seb128> to put it where?
[11:21] <pitti> using gettext on the value in the app itself perhaps?
[11:21] <seb128> pitti, well those profiles are used in different apps
[11:21] <seb128> ie rhythmbox let you choose the profile to use on cd copies
[11:22] <pitti> well, it was just an idea
[11:22] <pitti> but this is not "configuration", it's a huge translation database
[11:22] <pitti> anyway,just looking at the hogs here
[11:22] <seb128> right, wrong use in any case, but I can understand why they do that
[11:22] <pitti> with the easy seddery we already win 10%, so that might be worth doing
[11:22] <seb128> should rather be a file on disk
[11:22] <pitti> *nod*
[11:22] <seb128> how much are we speaking about btw?
[11:23] <seb128> gconf is 0.5s?
[11:23] <pitti> with a libgnome-media API around
[11:23] <seb128> so 10% is 50ms?
[11:23] <pitti> somethign like this
[11:23] <pitti> little effort, little gain kind of thing
[11:23] <seb128> right, I was rather thinking about either it's worth breaking the profiles thing if that requires apps updates
[11:24] <seb128> I'm trying to check if they use the libgnome-media lib to get those
[11:24] <seb128> or if things get the gconf values directly
[11:24] <pitti> the three compiz-*schemas are huge as well
[11:25] <pitti> l -Sr /usr/share/gconf/schemas/
[11:25] <pitti> ls -lSr /usr/share/gconf/schemas/
[11:25] <pitti> sorry
[11:25]  * pitti checks if compiz is installed by default
[11:25] <seb128> tomboy too
[11:26] <pitti> oh?
[11:26] <pitti> oh, I purged it from my laptop, so I don't see it
[11:26]  * pitti does on the mini
[11:27] <seb128> pitti, the tomboy schemas seems to not be stripped from translations
[11:27] <seb128> what build component does that again? cdbs
[11:27] <seb128> tomboy doesn't use cdbs
[11:28] <pitti> /usr/share/cdbs/1/rules/langpack.mk
[11:28] <pitti> GETTEXT_DOMAIN="$$DOMAIN" perl /usr/lib/cdbs/strip-schema.pl $$d > $$d.new; mv $$d.new $$d
[11:28] <pitti> urgh
[11:28] <pitti> indeed, tomboy should be fixed
[11:29] <seb128> they use dh7
[11:29] <pitti> seb128: you could just add the strip-schema.pl call to debian/rules manually?
[11:29] <seb128> yes
[11:29] <seb128> I will do that
[11:30] <seb128> the .desktop doesn't have the gettext domain either
[11:30] <seb128> we should make those cdbs magics work on dh7 too one day
[11:30] <pitti> why does libcompizconfig0 depend on compiz-core?
[11:31] <pitti> ah, nevermind; can be purgd along
[11:33]  * pitti unseeds compiz from netbook then
[11:33] <pitti> $ bzr commit -m 'drop compiz, we use mutter now'
[11:33] <pitti> that was an easy one :-)
[11:34] <seb128> does it make any difference on boot?
[11:34] <pitti> twiddling thumnbs, waiting on bootchart
[11:34] <seb128> we didn't want to have a GNOME session on UNE install?
[11:34] <pitti> you can install it (apt-get install ubuntu-desktop)
[11:35] <seb128> right, I meant by default
[11:35] <pitti> didrocks: ^
[11:35] <pitti> I don't konw
[11:35] <seb128> I didn't use the une a lot before this cycle
[11:35] <seb128> but they use to have a desktop switcher
[11:35] <seb128> I know rick says he uses the GNOME mode to hack usually
[11:35] <seb128> and the une mode for other things
[11:35] <seb128> use -> used
[11:36] <pitti> well, but structurally the "netbook" seed should stop pulling in compiz
[11:36] <seb128> pitti, didrocks is not around I think, let him reply later
[11:36] <pitti> if we want to add GNOME to the UNE build, it should be pulled in through the desktop seed
[11:36] <seb128> he's having lunch with lool today iirc
[11:36] <pitti> so I'm not actually sure whether that really dropped compiz
[11:36] <seb128> ok
[11:37] <pitti> but we didn't drop compiz from the netbook seed when changing from netbook-launcher to the mutter plugin
[11:37] <seb128> still worth doing a chart without compiz
[11:38] <kklimonda> pitti, is mutter going to replace both compiz and nautilus in lucid?
[11:39] <pitti> seb128: nice one; gconf reduced to 60% after purging tomboy and compiz
[11:39] <pitti> kklimonda: no, nautilus stays around as a file browser; it just won't render the desktop (as in previous UNEs)
[11:40] <kklimonda> erm, I was thinking about metacity..
[11:40] <kklimonda> my bad
[11:40] <pitti> kklimonda: yes, mutter is a composite-enabled fork of metacity
[11:51] <pitti> seb128: hmm
[11:51] <pitti> seb128: WDYT about removing the locale defaults for locales which aren't actually available on the system?
[11:52] <pitti> seb128: I thought about writing a "gconf-trim-defaults" script (via dpkg trigger) which removes the tabs, empty defaults, etc.; this could also filter out those localized default values which we don't need
[11:54] <pitti> I'll write such a thing and see what difference it'll make
[11:54] <pitti> ... after lunch
[11:54] <chrisccoulson> pitti - could that not be added to whatever registers the schemas?
[11:54] <chrisccoulson> rather than adding another script?
[11:54] <pitti> chrisccoulson: could, yes
[11:55] <pitti> gconf-schemas is python, but it calls gconftool
[11:55] <pitti> and there it becomes hairy and requries touching C
[11:55] <pitti> I'll see whether this will be easier, though
[11:55] <pitti> it would be more elegant for sure
[12:26] <seb128> pitti, sorry i was away for lunch
[12:27] <seb128> pitti, could we split the .xml by locale as upstream is doing?
[12:27] <seb128> pitti, would be even better than have several locales and having to rebuild the file on new locales install...
[12:28] <seb128> you would read one .xml matching your locale only
[12:38] <pitti> seb128: we already have per-locale files today
[12:38] <pitti> hm, indeed that would be even better
[12:39] <pitti> for me it parses /var/lib/gconf/defaults/%gconf-tree.xml first, then /var/lib/gconf/defaults/%gconf-tree-de.xml
[12:41] <seb128> pitti, shouldn't all those translations be stripped from the default one?
[12:41] <seb128> I would expect that one to be C locale...
[12:41] <pitti> it is C, yes
[12:42] <seb128> but it has defaults for all locales?
[12:42] <pitti> seb128: the only stripping that we do during build right now is localized descriptions (since we can use gettext on them)
[12:42] <seb128> but it has defaults for all locales?
[12:42] <seb128> grrr
[12:42] <seb128> (sorry focus)
[12:42] <pitti> I don't know why the locale defaults end up in the C file
[12:42] <pitti> I'll investigate this
[12:42] <seb128> pitti, right but upstream does do those by locale xml?
[12:42] <seb128> thanks
[12:43] <seb128> it would be sense to have the defaults in the corresponding xml
[12:43] <seb128> ie the -de.xml for the german defaults
[12:43] <seb128> and not on the C one
[12:43] <pitti> agreed
[12:51] <pitti> meh
[12:51] <pitti> (process:19416): GConf-CRITICAL **: Failed to load file "/var/lib/gconf/defaults/%gconf-tree-de.xml": Line 162 character 1: Element <default> is not allowed below <local_schema>
[12:52] <pitti> seems the %gconf-tree-locale.xml file is only for descriptions??
[12:52] <seb128> vuntz, ^ do you know?
[12:53] <pitti> parse_local_schema_child_element() does have a case for <default>, though
[12:55] <pitti> and ./backends/markup-tree.c only writes <default> tags if (!is_locale_file ...)
[13:24] <seb128> pitti, oh, I just found an apport bug
[13:25] <seb128> pitti, oh, I just found an apport bug but I'm not sure how you want to fix it
[13:25] <seb128> pitti, the .desktop has no gettext domain or translations stripped
[13:26] <seb128> pitti, that's because the langpack magic looks for GETTEXT_PACKAGE in po/Makefile
[13:26] <seb128> which you don't have
[13:26] <seb128> either create one with "GETTEXT_PACKAGE="apport""
[13:26] <pitti> hm, that .desktop is just for the mimetype link, though; does it need to be translated at all?
[13:26] <seb128> or add debian/rules lines to do the change
[13:27] <seb128> pitti, it's listed in nautilus context menu when right clicking on a .crash
[13:27] <seb128> open with "name"
[13:27] <pitti> ah, I see
[13:27] <seb128> do you want a bug about that?
[13:27] <pitti> seb128: I'll just manually add it to the desktop file in the ubuntu branch
[13:27] <seb128> it's a minor issue
[13:27] <seb128> but I was checking what .desktop miss the gettext domain and stripping
[13:28] <seb128> I've some 18 of those there
[13:28] <seb128> I will fix some like tomboy and file some bugs
[13:28] <seb128> firefox and openoffice are buggy too
[13:28] <dpm> seb128, here are some more that the translations team has been collecting -> https://bugs.edge.launchpad.net/ubuntu-translations/+bugs?field.tag=needs-desktop-entry-i18n
[13:29] <dpm> yeah, ff and oo are in there, too
[13:29] <seb128> I see you have the firefox and openoffice ones
[13:29] <dpm> :)
[13:29] <seb128> any reason scim is still in main? I though we used ibus now...
[13:29] <pitti> seb128: committed, thanks for spotting
[13:30] <seb128> pitti, thanks!
[13:32] <seb128> pitti, ArneGoetje: ^ scim should go in universe?
[13:32] <pitti> seb128: ideally yes
[13:32] <seb128> but in practice there is an issue?
[13:32] <pitti> perhaps we kept it in main for karmic for the transition
[13:33] <pitti> seb128: deferring to ArneGoetje  about that
[13:33] <seb128> ok
[13:36] <seb128> dpm, btw you want to open tasks on the corresponding ubuntu packages if you want somebody in the distribution to ever read those...
[13:36] <seb128> dpm, I did that now for you
[13:37] <seb128> I assigned the firefox and openoffice ones to our team too
[13:37] <dpm> thanks seb128!
[13:38] <seb128> pitti, should we move ekiga to universe?
[13:38] <pitti> seb128: fine for me; not really maintained anyway, and it won't disappear either way
[13:39] <dpm> seb128, on the ones I filed, I wasn't quite sure which was the correct package to open the bug task against - I'll open them on the ubuntu pkgs from now on, thanks for the heads up!
[13:39] <seb128> dpm, you're welcome
[13:39] <seb128> pitti, right but it might be easier to find a motu to work on it
[13:40] <pitti> seb128: so, please go ahead and unseed then
[13:40] <seb128> thanks
[13:42] <seb128> didrocks, back from lunch?
[13:51] <pitti> -rw-r--r-- 1 root root 2302656 2010-01-28 14:51 %gconf-tree.xml
[13:51] <pitti> -rw-r--r-- 1 root root 1486799 2010-01-28 14:51 %gconf-tree.xml.new
[13:51] <pitti> now, not too bad for such a gross hack
[13:51] <didrocks> seb128: right, finishing to backlog :)
[13:51] <pitti> hey didrocks, enjoyed an elaborate Parisian lunch?
[13:52] <didrocks> pitti: italian food in fact :)
[13:52] <didrocks> but it was good ;)
[13:52] <seb128> didrocks, after a 3 hours lunch time for a nap now right? ;-)
[13:53] <seb128> didrocks, could you push the work you did on tomboy the other day? I've other changes to do on it
[13:53] <seb128> didrocks, I think you said you started on the version update
[13:53] <didrocks> seb128: not really :-) the longest part was to go to Paris and to come back (and also, to take some dollars in La Poste)
[13:53] <seb128> lol
[13:53] <seb128> another of those people taking money before leaving! ;-)
[13:53] <didrocks> seb128: didn't have the time to work on the update. It was failing and I delayed it (huats was supposed to tackle it)
[13:53] <didrocks> seb128: right :)
[13:54] <seb128> didrocks, ok, it's not failing there, so doing it, thanks
[13:54] <didrocks> pitti: seb128: concerning your question about GNOME desktop session in UNE
[13:54] <didrocks> seb128: oh? really? perfect so… strange, maybe a bad lib :/
[13:54] <seb128> didrocks, you probably didn't update the build-depends for the mono changes
[13:54] <seb128> they put the .pc in new binaries
[13:54] <didrocks> seb128: I guess something related to that, right
[13:54] <Laney> you should look at what we did to tomboy in debian
[13:55] <didrocks> so, there will be a GNOME session available (gnome.desktop is shipped by gdm package)
[13:55] <didrocks> but it won't have all ubuntu-dekstop seed package (and so, no more compiz if we drop it from UNE seed)
[13:55] <didrocks> people will have to install ubuntu-desktop to get those back
[13:55] <seb128> Laney, I'm looking at that and fixing it too, the switch from cdbs to dh7 broke all the translations magics be have
[13:56] <seb128> be -> we
[13:56] <seb128> Laney, some for f-spot
[13:56] <didrocks> maybe, we can notify the first time the user "you don't have all apps from ubuntu-desktop full experience, do you want to install them?"
[13:56] <seb128> same
[13:56] <Laney> seb128: didn't we add that in debian?
[13:56] <seb128> Laney, you added the template update
[13:57] <seb128> Laney, not the "add the ubuntu gettext domain" not the "strip translations from the desktop entry"
[13:57] <seb128> Laney, not the "clean the schemas"
[13:57] <Laney> ok well if you have not-too-intrusive patches then we can take them
[13:57] <seb128> I doubt you want to add ubuntu gettext domains in debian...
[13:57] <seb128> I'm pondering switching it back to cdbs in ubuntu
[13:57] <Laney> those are handled transparently by cdbs?
[13:58] <seb128> yes
[13:58] <Laney> well i would wonder if the same cannot be done for dh
[13:58] <seb128> it can probably
[13:58] <seb128> but until somebody steps for that...
[13:58] <Laney> it would probably be less long term work
[13:59] <Laney> than merging all the time
[13:59] <seb128> we don't need to merge
[13:59] <seb128> we usually have newer version than debian anyway
[13:59] <seb128> but well, would be nice in any case yes
[14:00] <czajkowski> Could anyone explain - why does Software Centre present a "different version" than apt-get or an actual package GUI ?
[14:00] <czajkowski> to me ?
[14:00] <seb128> czajkowski, hi, what version of ubuntu and do you have a specific example?
[14:00] <pitti> nice, that script shrinks %gconf-tree.xml from 1.7 MB to 910 kB
[14:01] <seb128> pitti, waouh
[14:01] <czajkowski> seb128: Karmic fresh install
[14:01] <pitti> seb128: I added the trimming to gconf-schemas now
[14:02] <pitti> seb128: it just means that I need to add a --register-all call to locale-gen when adding a new locale
[14:02] <seb128> pitti, did you measure how much speed win that makes?
[14:02] <seb128> pitti, do you still get the correct default?
[14:02] <pitti> seb128: getting to that now
[14:02] <seb128> ok
[14:10] <pitti> $ gconftool -g  /desktop/gnome/keybindings/onscreenkeyboard/name
[14:10] <pitti> that's a good test case
[14:10] <pitti> it has localized defaults
[14:10] <seb128> I get an english screen there
[14:11] <pitti> "Bildschirmtastatur ein- oder ausschalten" for me
[14:11] <pitti> perhaps there's no French translation for that one
[14:11] <seb128> right
[14:11] <seb128> the media profiles you listed before work too for testing
[14:11] <pitti> yep
[14:12] <seb128> bah, strip-schema.pl is in cdbs
[14:12] <pitti> ok, so current stripping on my laptop reduces parsing from 0.107137 to 0.0709558 s
[14:12] <seb128> I'm pondering adding a cdbs build-depends to tomboy
[14:12] <seb128> or doing a local copy
[14:12] <pitti> sure
[14:12] <seb128> I think I will go with the build-depends
[14:12] <pitti> but on the netbook the cpu is slower
[14:12]  * pitti tries another change
[14:13] <seb128> that's hot cache right?
[14:13] <pitti> right
[14:13] <pitti> pure CPU
[14:14] <seb128> is there a way to empty cpu cache without disk cache?
[14:14] <pitti> "cpu cache"?
[14:14] <pitti> ok, removing all the \n just reduces it to 0.0695608
[14:14] <pitti> not really worth it
[14:14] <seb128> well cpu have caching too
[14:15] <pitti> well, but I restart the process
[14:15] <pitti> (gconf)
[14:15] <pitti> I don't think CPU caches are that good
[14:15] <pitti> so, confirmed to work, off to doing a bootchart
[14:16] <seb128> I think they are quite useful
[14:16] <seb128> hot cache benchmarks are far from first run ones
[14:16] <seb128> ie gnome-panel starts in 0.6 seconds there
[14:16] <seb128> and it takes over 3 seconds of cpu use on boot
[14:17] <pitti> isn't that more because it shares the CPU with a bazillion other processes?
[14:17] <seb128> no
[14:17] <seb128> I made a session entry which runs gnome-panel and not gnome-session
[14:18] <seb128> so there is only it in the session
[14:24] <chrisccoulson> good afternoon everyone
[14:24] <czajkowski> seb128: any thoughts ?
[14:24] <pitti> chrisccoulson: wb
[14:24] <chrisccoulson> hey pitti
[14:25] <seb128> czajkowski, no, you didn't reply to my questions though
[14:25] <czajkowski> I did
[14:25] <seb128> chrisccoulson, hey again
[14:25] <czajkowski> 14:01 < czajkowski> seb128: Karmic fresh install
[14:25] <seb128> czajkowski, what about the "do you have a specific example"?
[14:26] <czajkowski> didn't see that. I don't it was someone who asked me who's just installed it on a dell machine and I don't have clean install to see. just wondered did anyone know off hand.
[14:26] <czajkowski> seb128: sorry.
[14:26] <seb128> I don't know then but maybe mvo does
[14:27]  * pitti grins at http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-optimized-gconf-defaults.png
[14:27] <pitti> chrisccoulson, seb128 ^
[14:27] <pitti> much better
[14:27] <seb128> nice
[14:27] <chrisccoulson> pitti - what did you change?
[14:27] <mvo> czajkowski: that sounds like a bug, what version number are there?
[14:28] <seb128> pitti, seems another 0.3 seconds win
[14:28] <seb128> so we are down to 7 seconds login
[14:28] <czajkowski> mvo: I can try and find out
[14:30] <seb128> Laney, did you send your tomboy .pc change upstream btw?
[14:32] <Laney> no, I mentioned it in IRC afaik but didn't file a report yet
[14:32] <seb128> could you do that?
[14:32] <Laney> its on the stack
[14:32] <Laney> i should make that into a queue one day...
[14:33] <seb128> Laney, thanks
[14:39] <pitti> chrisccoulson: trimmed %gconf-tree.xml
[14:40]  * pitti packages the stuff now
[14:40] <rickspencer3> kenvandine, working with Gwibber via desktopcouch is incredibly easy
[14:40] <rickspencer3> last night I was easily able to pull all the images in the streams in
[14:41] <chrisccoulson> pitti - awesome. so, you didn't need to make any actual changes to gconf itself?
[14:41] <rickspencer3> tonight I will use the protocol settings to go up to facebook and pull down albums and such
[14:41] <pitti> chrisccoulson: no; I'm very hesitant to doing that, since it will immediately also apply to user's gconf, etc.
[14:41] <pitti> chrisccoulson: and I don't want the locale sorting there
[14:41] <pitti> like calling locale -a, etc.
[14:41] <pitti> or suppressing them
[14:42] <pitti> chrisccoulson: it's not a very clean solution, but then again gconf is an evolutionary dead-end anyway
[14:42] <kenvandine> rickspencer3, awesome!
[14:42] <pitti> so hacking it is bearable, I think
[14:42] <kenvandine> rickspencer3, desktopcouch really makes things far simpler
[14:42] <chrisccoulson> thats good anyway, that's the one thing that was delaying the whole session from loading
[14:45] <pitti> chrisccoulson: do you think it's worth doing another chart with your patched gconf/gsd _and_ the early start of gconf?
[14:45] <pitti> (recent chart reverted both of that, for better comparability)
[14:55] <tseliot> pitti: shall I merge all the things from jockey trunk or only my commit with the ubuntu branch?
[14:56] <pitti> tseliot: are there so many more? yes, a general merge is easier
[14:56] <tseliot> pitti: a few kde and test related things
[14:59] <chrisccoulson> pitti - it would be worth doing it with the patched gconf and gconf early start stuff
[14:59] <pitti> seb128, chrisccoulson: AFAICS that's about as much as we can do with an adequate amount of effort, so I close the WI for now
[14:59] <pitti> we can revisit it again later on if necessary
[14:59] <seb128> pitti, on gconf you mean?
[14:59] <pitti> chrisccoulson: ack
[14:59] <seb128> pitti, or on boot sequence out of optimizing code now?
[14:59] <pitti> seb128: yes; I don't know what else to take out, and I'm not yet despearate enough to write a new gconf backend just yet
[15:00] <pitti> seb128: with a different file format we'll still need some CPU time to load everything
[15:00] <pitti> chrisccoulson: will do now
[15:01] <pitti> chrisccoulson: that will introduce the hardcoded gnome-wm file again, won't it? or should I just try with the updated gconf package and leave g-s-d alone?
[15:02] <chrisccoulson> pitti - yeah, i'd forget about gnome-session and g-s-d for now, as I don't think they'll give that much win with the gconf changes
[15:02] <chrisccoulson> it would be good to see if starting gconfd earlier helps though (and not calling gconf-sanity-check)
[15:02] <pitti> g-sanity-check is still disabled here
[15:02] <pitti> do we really need to run it?
[15:03] <pitti> i. e. does it keep the user from running a session if something is damaged, etc.?
[15:04] <chrisccoulson> pitti - all it does is pop up an error dialog if the configuration sources are broken or it can't do file locking etc
[15:04] <chrisccoulson> it doesn't block the session from loading, and the error message isn't useful anyway
[15:04] <pitti> hm, I guess we should continue to install it
[15:05] <pitti> and then perhaps just not call it from g-s
[15:05] <pitti> so that you at least can run it manually for debugging?
[15:05] <chrisccoulson> pitti - it only runs properly before gconfd is started (ie, it doesn't do a lot when it's already running)
[15:06] <chrisccoulson> so, once gconfd is started, it's no use really
[15:06] <pitti> so with the 56gconf Xsession.d script it's just a waste either way?
[15:06] <chrisccoulson> pitti - yeah, it is
[15:08] <seb128> bah
[15:08] <seb128> I'm wondering what buildds are so busy with today
[15:08] <seb128> uploads on i386 get over 10 hours delay now
[15:08] <seb128> before starting build
[15:08] <pitti> openjdk, linux
[15:09] <pitti> https://edge.launchpad.net/builders
[15:09] <pitti> and now OO.o
[15:09] <chrisccoulson> there was an openoffice upload 21 hours ago too
[15:09] <chrisccoulson> ah
[15:09] <pitti> it was blocked by a MIR
[15:09] <chrisccoulson> oh yeah, openoffice is currently building
[15:09] <pitti> I promoted that package some 4 hours ago
[15:13] <pitti> chrisccoulson: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-optimized-gconf-defaults.png
[15:14] <pitti> ^ old
[15:14] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-gconf-xsession.d-disabledsanitycheck-optimized-gconf-defaults.png
[15:14] <pitti> ^ with your hacked gconf and early gconf loading
[15:14] <chrisccoulson> hmmm, it seems to make it slower
[15:15] <pitti> it doesn't really seem to help indeed
[15:15] <pitti> and it doesn't help to fill in the empty CPU slot either :(
[15:15] <pitti> we just get a new I/O wait spike
[15:15] <pitti> I wonder why
[15:15] <pitti> in gnome-session
[15:15]  * lool is finally home
[15:16] <rickspencer3> hi lool, welcome home!
[15:16] <pitti> chrisccoulson: want me to include your gconf patch in my upload?
[15:17] <pitti> chrisccoulson: that by itself shouldn't make a big difference, since gconfd is triggered on first use anyway
[15:17] <lool> asac: So didrocks has the board + a SATA 2.5" hard disk + a SATA cable; packed in a marvell box with foam
[15:17] <chrisccoulson> pitti - i don't think it's worth including it yet until i understand why it's not making any difference
[15:17] <pitti> chrisccoulson: but it doesn't hurt either
[15:17] <pitti> chrisccoulson: ok
[15:17] <pitti> then I'll just upload the %gconf-tree.xml deflating for now
[15:17] <lool> asac: The hard disk probably has an installed system; feel free to wipe it
[15:17] <pitti> chrisccoulson: thanks a lot so far! (don't worry, we'll crack this nut)
[15:18] <chrisccoulson> pitti - i'm still confused what the 0.5 second gap is where gnome-sesion appears to be doing nothing
[15:19] <chrisccoulson> the gap wasn't shown on the profiling work i did, and i'm convinced it's actually not really gnome-session yet at that point (that bar becomes gnome-session at some point, but doesn't start life as that)
[15:19] <asac> lool: you rock!!!
[15:19] <seb128> pitti, useful hint from rickspencer3, you can change the mini fn keys behaviour in the bios to do fn directly
[15:19] <pitti> chrisccoulson: the gnome-session bar starts out as ssh-agent; couln't it be that?
[15:19] <seb128> without to use the fn key
[15:19] <chrisccoulson> pitti - yeah, i'm fairly sure what happens, but didn't you already profile ssh-agent?
[15:20] <pitti> chrisccoulson: gnome-session starts right at the time when the ssh-agent process starts on the chart
[15:21] <pitti> ssh-agent initializes, forks, and execs g-s in the parent
[15:21] <chrisccoulson> pitti - yeah, that seems to be the case
[15:21] <pitti> so it seems g-s is having its small CPU blip right at the start
[15:21] <chrisccoulson> (although, it's actually ssh-agent -> dbus-launch -> gnome-session)
[15:21] <chrisccoulson> but dbus-launch fork's and exec's so quickly that it doesnt have any effect
[15:21] <pitti> ah, right
[15:22] <pitti> I'm off for some 30 minutes for some fresh air and buying new printer toner
[15:22] <chrisccoulson> pitti - the small CPU blip is expected as it loads the autostart files
[15:22] <pitti> chrisccoulson: yes, and a program which doesn't even do such a small blip is probably not worth having in the first place :)
[15:23] <chrisccoulson> pitti - yeah, definately :)
[15:23] <chrisccoulson> ssh-agent isn't taking 0.5 seconds to fork is it?
[15:23] <pitti> it's not that much
[15:23] <chrisccoulson> so, that bar must be starting life as something else
[15:23] <pitti> I did a comparison without it yesterday, and it's impact is below the noise level
[15:23] <chrisccoulson> perhaps something gdm related?
[15:24] <pitti> I don't truly understand why we have the ssh-agent offset, but g-s-d doesn't start any earlier when removing ssh-agent
[15:24] <chrisccoulson> yeah, so i think we're looking at the wrong thing then
[15:25] <chrisccoulson> that process must start life as something other than ssh-agent
[15:25] <pitti> 90consolekit should be intert
[15:25] <pitti> inert
[15:25] <pitti> there's dbus-launch
[15:26] <pitti> chrisccoulson: perhaps it's just the general shellery from Xsession.d/* ?
[15:26] <pitti> that calls some programs as well
[15:26] <pitti> tests, stats, readlink, etc.
[15:27] <pitti> chrisccoulson: I'll try removing xsession.d/* and check its impact when I'm back home
[15:27]  * pitti -> really out now
[15:40] <chrisccoulson> pitti - so, that bar actually starts out as gdm-session-worker
[15:40] <chrisccoulson> the delay could be there
[15:56] <chrisccoulson> asac - did you have a look through the GVFS diff you attached to bug 512959?
[16:01] <chrisccoulson> asac - this looks wrong to me: http://pastebin.ubuntu.com/364651/
[16:01] <chrisccoulson> "current" isn't an array of strings
[16:03] <chrisccoulson> oh, hang on
[16:03] <chrisccoulson> it is
[16:03] <chrisccoulson> the diff is confusing though without looking at the whole file
[16:04] <asac> chrisccoulson: i just made the diff
[16:04] <asac> yeah
[16:04] <asac> that looked suspicious to me on a quick glance too
[16:04] <chrisccoulson> i don't think that's the issue though
[16:04] <asac> what does  meta_tree_lookup_string do ?
[16:05] <chrisccoulson> "current" is defined twice in the same file, not very far apart (once as a string, and then again as a string array a bit further down), but i don't think that's the issue
[16:06] <seb128> not easy to say what the issue is without a correct stacktrace
[16:07] <seb128> the bug stacktrace has only 3 ?? in libc...
[16:09] <didrocks> pitti: wallpaper cache is now ready and warning cleaned :) You talked about some gotchas to think about, what are they?
[16:10] <seb128> didrocks, do you need patch review?
[16:10] <seb128> or did pitti do that already for you?
[16:10] <didrocks> seb128: he didn't yet, if you want, let me make a final test before pastebinit somewhere
[16:10] <seb128> ok
[16:11] <seb128> didrocks, what gotchas are you talking about?
[16:11] <didrocks> seb128: don't know, just backlogged and see "pitti | didrocks: let's look over this when you are back; there are some gotchas that come to my mind"
[16:12] <seb128> ok
[16:12] <asac> chrisccoulson: i think i need to get the full code to understand what might be problematic
[16:12] <asac> chrisccoulson: what is in gvfs-common?
[16:13] <asac> maybe we can narrow it down a bit like that
[16:13] <asac> libgvfscommon i think
[16:13] <seb128> asac, can somebody maybe get a stracktrace?
[16:14] <asac> of a stack smack? thats probably a bad one
[16:14] <asac> but sure
[16:14]  * asac forwards
[16:14] <seb128> well valgrind log would be useful
[16:14] <seb128> but apparently you don't have valgrind there
[16:15] <seb128> not sure what we can get from a stacktrace but worth looking
[16:15] <chrisccoulson> the changes in libgvfscommon are minimal
[16:15] <chrisccoulson> in that delta
[16:17] <rickspencer3> desktoppers ... hey ... if you are attending the sprint next week, please add goals to the wiki
[16:17] <rickspencer3> it's looking a bit slim atm
[16:18] <rickspencer3> ArneGoetje, bryceh, ccheney, didrocks, kenvandine, pitti, seb128 ^
[16:18] <rickspencer3> who did I orget?
[16:18] <rickspencer3> Riddell, ^
[16:18] <rickspencer3> tseliot, ^
[16:20] <kenvandine> ok
[16:20] <didrocks> seb128: http://paste.ubuntu.com/364665/
[16:21] <didrocks> rickspencer3: ok, will do
[16:22] <seb128> didrocks, you can use g_build_filename rather there
[16:23] <didrocks> seb128: ok, changing that
[16:28] <Nafai> where are you guys sprinting?
[16:32] <rickspencer3> Nafai Portland, OR
[16:33] <seb128> didrocks, one issue is that we don't do clean caches there
[16:34] <didrocks> seb128: right, I was targetting that one second attempt, as I don't think that we'll have too many file from user
[16:34] <seb128> one other issue is that not every api customer might want that
[16:34] <didrocks> seb128: another issue is that we cache thumbnails too
[16:34] <seb128> should probably require a new api or adding a parameter
[16:35] <didrocks> hum, a switch?
[16:35] <seb128> yes
[16:35] <seb128> though adding a switch would mean breaking abi...
[16:35] <seb128> I start wondering if that's specific enough to the wallpaper case to be on the g-s-d side
[16:36] <seb128> could be nice to check maybe with vuntz what he thinks as upstream there
[16:36] <seb128> vuntz, ^ any opinion if background image caching should be done in gnome-bg?
[16:36] <huats> does anyone running karmic on amd64 experience firefox crashes after a few minutes ?
[16:37] <seb128> not me
[16:37] <qense> not here as well
[16:37] <hyperair> not me either
[16:37] <huats> pfff I don't understand then
[16:37] <hyperair> but then i'm using the daily firefox.
[16:37] <huats> thanks everyone
[16:37] <om26er> I have seen many empathy bugs assigned to ubuntu-desktop even if they are upstream. so when triaging an empathy bug should I assign them to ubuntu desktop?
[16:38] <seb128> huats, well I'm neither using karmic nor amd64 so I can't confirm either way
[16:38] <huats> seb128, and btw I am ready for some updates
[16:38] <huats> I'll have a look at the page
[16:38] <seb128> huats, you can do gnome-menus if you want
[16:38] <huats> ok I am it then
[16:39] <seb128> huats, how are you btw? is everybody doing fine?
[16:39] <huats> seb128, everyone is great !
[16:39] <huats> :)
[16:39] <huats> I am just back home :)
[16:39] <huats> thanks !
[16:40] <seb128> good to know ;-)
[16:40] <huats> yep :D
[16:40] <seb128> don't feel forced to work on updates
[16:40] <seb128> you probably have plenty to do out of computer work atm
[16:41] <didrocks> seb128: new version available at http://paste.ubuntu.com/364677/ using g_build_filename and fixing a memleak
[16:41] <pitti> re
[16:41] <pitti> seb128, didrocks: gotchas> like, if you generate the cache as part of g-s-d, you'll have two effects:
[16:42] <pitti> 1) you won't benefit from ureadahead (since that will read the big file, not the small cached one)
[16:42] <seb128> pitti, wb
[16:42] <huats> seb128, actually I do have a lot to do, but I am really happy to find some little time to do some updates...
[16:42] <pitti> 2) every use needs its own cache file
[16:42] <chrisccoulson> huats - you have a baby now?
[16:42] <pitti> 3) it clutters the home dir (but that's the least of my concerns)
[16:42] <huats> YES !
[16:42] <seb128> huats, ok ;-)
[16:42] <huats> chrisccoulson, a lille guy
[16:42] <chrisccoulson> huats - congratulations :)
[16:42] <Tm_T> huats: noooooooo!
[16:42] <pitti> huats: oh, congratulations!
[16:42] <didrocks> pitti: right, it's currently at ~/.cache/wallpaper for every users
[16:43] <huats> theo is born last week exactly :)
[16:43] <seb128> pitti, about 2) the change is to gnome-desktop gnome-bg api
[16:43] <Tm_T> huats: congrats (:
[16:43] <seb128> pitti, but as said before I think we need to add a flag for cache use rather than make every client do caching automatically
[16:43] <huats> thanks everyone
[16:44] <Tm_T> huats: I have little over 1-year old daughter here and have to say this baby ate my productivity
[16:45] <pitti> so my original idea was to ship a pre-generated 1024x600 image (since you need to do clipping etc. as well), and introduce a new gconf lookup for that (backgrounds/<resolution>/{path,size,...}
[16:45] <pitti> didrocks: could we modify your patch to first look for $FILENAME_1024x600.png first before looking for $FILENAME ?
[16:46] <seb128> pitti, I don't like that much
[16:46] <pitti> didrocks: this would avoid my three points, could be done in postinst, and probably won't change your code much
[16:46] <seb128> pitti, the pre-generated image will work for one screen config and one image
[16:46] <pitti> and it doesn't need to be done at runtime
[16:46] <seb128> pitti, ie it's purely for benchmark but not much for real world benefit
[16:46] <pitti> seb128: well, but without ureadahead you reintroduce I/O again
[16:47] <seb128> doesn't that include user datas?
[16:47] <seb128> like gconf dir, etc?
[16:47] <pitti> seb128: the postinst could look up the current resolution and generate the image for that one?
[16:47] <pitti> seb128: probably; but you generate it too late
[16:47] <pitti> seb128: when ureadahead collector runs first, then you don't have a cache yet
[16:47] <seb128> pitti, do you know many users using the default pre-installed background?
[16:47] <pitti> you are just building it
[16:47] <pitti> seb128: I don't know, no
[16:48] <seb128> I don't think I know anybody not changing the background
[16:48] <seb128> not just on ubuntu
[16:48] <pitti> seb128: but what's wrong with additionally looking for /usr/share/filename_resolution.png and using it if it exists?
[16:48] <pitti> seb128: it doesn't preclude looking for it in ~/.cache as well
[16:48] <seb128> but it's something people tend to set to something personal or something they like
[16:48] <seb128> nothing
[16:48] <seb128> it justs seems to me a waste of CD space to put a special case image there
[16:49] <pitti> it's 30 KB..
[16:49] <seb128> still we will get people asking to get a <their_screen_setting> one there too
[16:49] <pitti> but well, we can certainly avoid shipping it
[16:49] <seb128> because why only x600
[16:49] <seb128> why not 1028x768
[16:49] <seb128> etc
[16:50] <didrocks> (also, we should take the transformation effect in the filename)
[16:51] <pitti> hm, so how can we trigger an ureadahead update then..
[16:52] <vuntz> seb128: I'm really not the right person for the GnomeBG stuff. You should ask halfline
[16:52] <seb128> vuntz, ok
[16:54] <seb128> to avoid the user dir cluttering we could save one filename only
[16:54] <seb128> ie caching only the current wallpaper
[16:55] <didrocks> seb128: doesn't work for slideshow
[16:55] <seb128> I would argue that slideshow are a special case and it's fine if they are not cached
[16:55] <pitti> don't worry about slideshow
[16:56] <didrocks> ok, so, removing everything but the last one?
[16:56] <seb128> I would rather have .cache/wallpaper.jpg
[16:57] <seb128> or .cache/wallpaper as the image
[16:57] <seb128> and cache whatever is in gconf key there
[16:57] <seb128> and make g-s-d read it
[16:57] <pitti> like .cache/warty-final-ubuntu_1024x600.png ?
[16:57] <pitti> (you need to remember file and resolution, in case you change it)
[16:57] <didrocks> pitti: it's already the case
[16:57] <didrocks> pitti: filename + resolution + transformation type
[16:57] <pitti> didrocks: nice
[16:58] <seb128> hum right
[16:58] <didrocks> but need to remove previous one when updating
[16:58] <didrocks> (and also, fix the thumbnails caching)
[17:00] <seb128> starts sounding complicated
[17:00] <didrocks> right
[17:02] <pitti> didrocks: so you already implemented that now?
[17:03] <didrocks> pitti: right, http://paste.ubuntu.com/364677/
[17:10] <pitti> didrocks: so, looks correct to me (apart from the indentation problem in get_wallpaper_cache_filename()
[17:10] <didrocks> pitti: oh right
[17:11] <pitti> I'm still unsure how to solve the ureadahead integration
[17:11] <didrocks> but still, this clutter .cache/wallpaper
[17:11] <seb128> I'm a bit concerned by the lack of flag to turn that on though
[17:11] <seb128> not sure if that api has other "customers"
[17:11] <seb128> and if they want their datas to be cached
[17:11] <seb128> it should be an opt-in by the client maybe?
[17:12] <pitti> this should perhaps be added to an upstream bug and discussed there first?
[17:13] <seb128> yes
[17:14] <pitti> introducing the concept of different resolutions into the API does seem to make sense to me
[17:14] <seb128> didrocks, or maybe try #gnome-hackers, halfline is there usually
[17:14] <pitti> it's not that easy to have a bg image which suits a netbook as well as a 1920x1600 screen
[17:15] <seb128> right
[17:15] <seb128> pitti, I was suggesting a flag for turning caching on or not
[17:15] <didrocks> seb128: ok, I will, just fix that tab stuff first
[17:17] <pitti> didrocks: merci for working on this!
[17:17] <didrocks> pitti: you're welcome :)
[17:18] <didrocks> ok, tabs fixed
[17:24] <mvo> seb128: does the recent gstreamer upload require a rebuild or upload of some of the plugins as well ? it appears that the upgrade currently wants to remove sound-juicer for some gstreamer dependencies
[17:25] <seb128> mvo, it conflicts on gst-plugins-base not current yes
[17:25] <seb128> mvo, it conflicts on gst-plugins-base not current yes
[17:25] <seb128> ups
[17:26] <mvo> ok, if its a known issue, no problem
[17:26] <seb128> mvo, and the buildd got DoSed meanwhile by 2 openoffice + 1 openjdk builds
[17:26] <mvo> heh :)
[17:26] <seb128> and we only have 3 i386 buildds
[17:26] <mvo> so its waiting in the queue?
[17:26] <seb128> it should be building now
[17:26] <seb128> openoffice failed to build after 6 hours
[17:26] <mvo> cool, thanks
[17:26] <seb128> ;-)
[17:26] <mvo> haha
[17:26] <seb128> mvo, you're welcome
[17:59] <rickspencer3> is Amaranth_ around?
[17:59] <Amaranth_> sort of
[17:59] <rickspencer3> wondering if we should close out the bug task on bug https://bugs.edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/410407
[18:00] <Amaranth> iz gtk boog :)
[18:00] <Amaranth> or flash, dunno
[18:00] <rickspencer3> hmm
[18:00] <Amaranth> mozilla is having the same problem now  that they do out of process plugins
[18:00] <rickspencer3> it's got lots of "gravity"
[18:00] <Amaranth> GDK_NATIVE_WINDOWS fixes it
[18:00] <rickspencer3> Amaranth, is it possible to fix in the distro?
[18:01] <Amaranth> sure, if you patch everything that uses flash to use GDK_NATIVE_WINDOWS either for the whole app or for the flash part (if they run it out of process)
[18:01] <rickspencer3> hmmm
[18:02] <rickspencer3> that sounds technically possible, but not too feasible
[18:02] <Amaranth> Otherwise since we don't have the source to flash it's rather hard to figure out why gtk's client side windows break it
[18:03] <Amaranth> chrome/chromium already use GDK_NATIVE_WINDOWS when loading flash so you just have to do nspluginwrapper, firefox, epiphany, etc :)
[18:03] <Amaranth> you may only have to do nspluginwrapper and firefox 3.6, actually
[18:04] <Amaranth> err, no, 3.6 doesn't do plugins that way
[18:04] <Amaranth> so hopefully just nspluginwrapper
[18:05] <rickspencer3> hmmm
[18:05] <rickspencer3> seems to be marked Invalid on all packages in any case
[18:05] <rickspencer3> except flash-plugin-nonfree, of course
[18:05] <seb128> it's technically a flash bug
[18:05] <Amaranth> and gtk and flash
[18:06] <rickspencer3>  thanks Amaranth
[18:06] <seb128> Amaranth, hey
[18:06] <rickspencer3> ah yes
[18:07] <seb128> Amaranth, so you were right, delaying compiz from some seconds make it much less busy
[18:07] <Amaranth> thought so
[18:07] <seb128> Amaranth, cleaning the .xml and .so makes no difference
[18:07] <Amaranth> hrm, that sucks
[18:07] <seb128> Amaranth, still it's quite slow, almost 5 seconds delayed after everything else
[18:07] <Amaranth> guess protobuf is very efficient
[18:07] <seb128> but that's better than the 9 seconds otherwise
[18:12] <pitti> seb128: delaying by how much?
[18:12] <pitti> i. e. does it literally end at the same time if you delay it by 4 s?
[18:13] <pitti> just has a more compact CPU usage?
[18:13] <seb128> yes
[18:13] <seb128> between 3 and 5 seconds I tried
[18:13] <pitti> seb128: FYI, deferring g-screensaver buys .1 to .2 s, will do tomorrow
[18:13] <seb128> 3 seconds is a bit too early
[18:13] <seb128> 5 seconds is after other busy things but doesn't change the boot mark then
[18:13] <seb128> pitti, ok
[18:13] <pitti> that's only for the mini platform, though
[18:14] <pitti> would be interesting to see how that performs on my slow disk (the other extreme)
[18:14] <pitti> seb128: did you just add a sh -c and sleep to the .desktop?
[18:14] <seb128> no, to the gnome-wm command
[18:14] <pitti> ah, good idea
[18:15]  * pitti -> dinner, bbl
[18:15]  * seb128 sport and dinner
[18:15] <seb128> bbl too
[18:17] <rickspencer3> pedro_, hi
[18:18] <rickspencer3> seems this bug has lots of gravity:
[18:18] <rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/404351
[18:18] <rickspencer3> anything we can do to help it along?
[18:19] <chrisccoulson> pitti - i see you're deferring gnome-screensaver
[18:19] <chrisccoulson> you just going to use a sleep for now?
[18:19] <chrisccoulson> ah, you've disappeared already
[18:19] <pedro_> rickspencer3, well there's no clear way on how to reproduce the issue, we thought it was an ubuntuone-client issue but it wasn't
[18:20] <pedro_> rickspencer3, seems to only affect karmic though
[18:20] <pedro_> rickspencer3, and we don't have a new report about it since 2009-12-10
[18:20] <rickspencer3> pedro_, should we close the bug then?
[18:20] <pedro_> rickspencer3, i can ask again to the reporters if they are able to reproduce it with latest packages, maybe it's fixed now
[18:20] <pedro_> rickspencer3, let's ask first, i'll do that
[18:20] <rickspencer3> ok
[18:21] <rickspencer3> if it's not going to get fixed we should mark it as such
[18:21] <rickspencer3> if it's not an issue anymore, we should definately mark it as such ;)
[18:21] <pedro_> totally agreed ;-)
[18:37] <pitti> chrisccoulson: I thought about adding a --delay option, and call nice(10) in it
[18:37] <pitti> chrisccoulson: to avoid having yet another shell/sleep invocation
[18:38] <pitti> chrisccoulson: I'll disappear for dinner in a bit again, so far it was just prep; but it's in the oven now :)
[18:38] <chrisccoulson> pitti - i think for now you should probably go with the sleep, and i will implement a proper X-GNOME-Autostartdelay option for the autostart files
[18:38] <chrisccoulson> sometime over the weekend
[18:38] <pitti> chrisccoulson: so, external sleep and patch it to nice?
[18:39] <chrisccoulson> pitti - yeah, can do
[18:39] <pitti> ok, I'll go with that then
[18:39] <pitti> chrisccoulson: but it's not that urgent, I can as well wait for your X-GNOME-AutostartDelay to land
[18:39] <chrisccoulson> i'll work on implementing a proper key for autostart delay, so we can mass-convert all of our autostart apps which have a delay to use the new key, rather than spawning a shell
[18:39] <pitti> \o/
[18:39]  * pitti hugs chrisccoulson
[18:40]  * chrisccoulson hugs pitti
[18:42] <pitti> kenvandine: do you know whether there was some investigation about why indicator-{messages,applet,applet-session} burning so much CPU?
[18:42] <kenvandine> pitti, at start time?
[18:42] <pitti> yes
[18:42] <kenvandine> tedg was going to add some instrumentation code
[18:42] <kenvandine> not sure if he has though
[18:55] <jcastro> qense: hey, jono and I were thinking a hack day for app indicators would be a good idea, interested?
[18:55] <qense> jcastro: Sure, sounds neat. HackDay!
[18:56] <jcastro> next week we'll figure out a day, etc.
[18:56] <qense> Maybe we should collect a list of applications that still need support on the beforehand.
[18:57] <qense> jcastro: ok
[18:57] <jcastro> qense: we used source.debian.net to find things using GtkStatusIcon, but it seems to be down right now
[18:58] <qense> yep, times out here
[18:59] <qense> What about sending a mail to the devel-discuss maillist with a request for suggestions?
[19:16] <Burgundavia> anybody around to talk about artwork in Lucid? is for the official book
[19:19] <jcastro> qense: I'm going to grep through the archive first
[19:19] <jcastro> qense: we'll do a call for help as a last resort
[19:21] <Burgundavia> win 3
[19:21] <qense> jcastro: sounds good
[19:47] <chrisccoulson> vuntz - there?
[19:53] <vuntz> chrisccoulson: yep
[19:54] <chrisccoulson> vuntz - do you remember reviewing a patch I wrote for gnome-session a while ago, to lazy-initialize dk-power?
[19:54] <chrisccoulson> this patch: http://bazaar.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu/annotate/head%3A/debian/patches/21_dkp_start_on_demand.patch
[19:54] <chrisccoulson> i seem to remember that you had some concerns with it
[19:55] <vuntz> I remember it
[19:55] <vuntz> but I don't remember what I thought of it :-)
[19:56] <chrisccoulson> i think you were concerned that it's too easy to forget to call manager_ensure_dkp_client
[19:57] <vuntz> chrisccoulson: yep
[19:57] <vuntz> that's it
[19:58] <chrisccoulson> vuntz - i'd like to try and tidy it up, but i'm not sure how to address that concern, short of creating a new class for fetching information from dk-power (eg, a GsmDkpower class, or something similar)
[19:59] <chrisccoulson> but that seems a bit overkill
[19:59] <vuntz> chrisccoulson: was wondering about a new class too
[19:59] <chrisccoulson> untz - i don't mind doing that then
[19:59] <chrisccoulson> oops
[19:59] <chrisccoulson> s/untz/vuntz
[19:59] <vuntz> chrisccoulson: maybe talk to hughsie to see what he thinks
[20:00] <chrisccoulson> yeah, i can do
[20:00] <vuntz> chrisccoulson: maybe he'll be willing to make the DkpClient object more flexible
[20:00] <chrisccoulson> yeah, that might be a better idea
[20:00] <chrisccoulson> ie, only fetch the properties from the daemon when you first try to get them
[20:36] <pitti> good night everyone
[20:37] <didrocks> good night pitti!
[20:39] <seb128> good night pitti
[21:15] <didrocks> well, time to go to bed :)
[21:16] <didrocks> have a good night everyone
[21:25] <seb128> 'night didrocks
[22:03] <chrisccoulson> hey seb128
[22:03] <seb128> hello chrisccoulson
[22:03] <seb128> how are you?
[22:03] <chrisccoulson> yeah, good thanks
[22:04] <chrisccoulson> and you?
[22:04] <seb128> good too
[23:11] <seb128> good night everybody
[23:25] <Nafai> jcastro: btw, I'm not sure what apt-daemon is that jono mentioned in his e-mail.  I can't find a package of that name or anything in any package by that name (using apt-file)
[23:38] <chrisccoulson> Nafai - aptdaemon?
[23:38] <chrisccoulson> !info aptdaemon
[23:43] <Nafai> doh
[23:44] <Nafai> jono included a - in the name and I didn't think to try without the - :)
[23:44] <Nafai> Thanks
[23:51] <jono> Nafai, hehe
[23:51] <Nafai> :)
[23:51] <jono> you getting the hang of things?
[23:51] <Nafai> getting there
[23:52] <jono> Nafai, what have you been working on?
[23:52] <Nafai> unfortunately, not a ton this week (luckily, I don't start paid work until next week)...mainly getting my dev environment set up and such
[23:52] <Nafai> upgraded to lucid and such
[23:52] <jono> no worries!
[23:52] <Nafai> following the developer week stuff
[23:52] <jono> I am not expecting you to work this week :)
[23:53] <jono> cool :)
[23:53] <Nafai> btw, I loved dholbach and jcastro's tag team this morning
[23:57] <jono> Nafai, awesome :)