[07:28] <pitti> Good morning
[07:41] <didrocks> good morning
[07:59] <pitti> bonjour didrocks
[08:49] <baptistemm> hello
[08:51] <chrisccoulson> hi baptistemm
[08:51] <baptistemm> salut chrisccoulson
[08:51] <chrisccoulson> how are you?
[08:52] <baptistemm> chrisccoulson, fine
[08:52] <baptistemm> like a monday, my sight is quite blurry and my brain is in the fog
[08:52] <chrisccoulson> baptistemm - you need more coffee :)
[08:59] <chrisccoulson> hi seb128
[09:10] <seb128> dangerous?!
[09:11] <seb128> it's some work to organize though
[09:11] <huats> morning
[09:11] <huats> seb128, hello !
[09:13] <didrocks> seb128: yeah, too many people and even large streets can get human traffic jam :)
[09:13] <didrocks> hey huats
[09:14] <huats> hello didrocks !
[09:14] <seb128> didrocks, you say they can't be any event organize in cities?
[09:14] <seb128> I don't think so
[09:14] <seb128> but let's agree to disagree ;-)
[09:14] <seb128> hello huats
[09:15] <didrocks> seb128: sorry no, I was saying that having a "parade" in such an event isn't really possible
[09:15] <seb128> well a parade is just people moving
[09:15] <huats> when you change the language, xdg-user-dir-gtk prompt you asking you if you want to change the various default directories (Desktop, Downloads,...) if there a way to say you always want to do it ?
[09:16] <seb128> you have to select the streets you use and organize so they don't conflicts with people
[09:27] <seb128> oh
[09:27] <seb128> chrisccoulson, robert_ancell, pitti, good work ;-)
[09:28]  * seb128 didn't read any email during weekend and notice all the uploads
[09:28] <pitti> :)
[09:28] <chrisccoulson> heh, i only did 1 upload ;)
[09:28] <seb128> but it's a speed one
[09:28] <seb128> those are very welcome this cycle ;-)
[09:29] <seb128> pitti, you managed to update gvfs without libiphone, etc?
[09:29] <pitti> seb128: it's not required yet
[09:29] <seb128> you didn't build the new backend I guess?
[09:29] <pitti> it needs testing and a MIR first
[09:29] <seb128> pitti, well it's required if we want iphones working
[09:29] <seb128> other distro backported that backend previous cycle already
[09:30] <seb128> pitti, btw did you merge on debian too or just updated?
[09:30] <pitti> yeah, I wasn't saying that we shouldn't enable it :)
[09:30] <seb128> I was sort of waiting for somebody to pick the update and do the merge and mir :-p
[09:30]  * seb128 lazy
[09:30] <pitti> but I have no way of testing it, so I didn't feel like doing it right before an alpha
[09:30] <chrisccoulson> pitti - you need to get hold of an iphone to replace your G1, so you can test it ;)
[09:31] <pitti> seb128: didn't feel like doing an MIR on a Sunday; but you can still consider it on my plate
[09:31]  * seb128 hugs pitti
[09:31] <pitti> chrisccoulson: neeeever! :)
[09:31] <chrisccoulson> pitti - i thought you'd say that :)
[09:31] <seb128> pitti, well I don't consider a new backend risky for an alpha1 but no hurry either ;-)
[09:32] <seb128> I can test on my ipod touch
[09:32] <seb128> it's detected as a camera right now
[09:32] <seb128> when there is no camera in the device
[09:33] <glatzor_> morning mvo
[09:33] <mvo> hi glatzor_
[09:38] <seb128> hey glatzor_ mvo
[09:38] <mvo> hey seb128
[09:38] <seb128> mvo, not sure if you noticed but your update-manager upload in lucid didn't build
[09:39] <mvo> seb128: oh, right. I noticed and then forgot :(
[09:40] <chrisccoulson> vuntz - would you mind reviewing a gnome-session patch? (i think i mentioned it on here a few days ago - about starting DK-Power only when it's actually needed)
[09:40] <chrisccoulson> the patch is here: http://bazaar.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu/annotate/head%3A/debian/patches/21_dkp_start_on_demand.patch
[09:41] <vuntz> chrisccoulson: looks easy to forget to call manager_ensure_dkp_client()
[09:42] <vuntz> but might be good enough
[09:42] <vuntz> chrisccoulson: just send the patch upstream, I've no real time to think about it today :/
[09:42] <chrisccoulson> vuntz - yeah, i'm not sure if there's a better way of doing it
[09:47] <huats> seb128, chrisccoulson, pitti I can test it with my iphone if you need...
[09:47]  * huats shame on me...
[09:57] <seb128> huats, thanks
[10:01] <glatzor_> morning seb128 !
[10:03] <glatzor_> mvo, I created a branch of software-center which follows the latest api changes in aptdaemon
[10:03] <mvo> glatzor_: oh sweet, let me update and merge
[10:03]  * mvo hugs glatzor_
[10:06] <didrocks> pitti: I'll remove this evening /usr/bin/gnome-stracciatella-session wrapper and directly call in the .destkop file if you don't mind
[10:07] <pitti> didrocks: sure, if you have a better replacement
[10:08] <didrocks> pitti: GDMSESSION is exported by the new GDM itself. Also, this will enable sourcing ~/.gnomerc which is not the case as of today
[10:09] <pitti> yay
[10:09] <mvo> glatzor_: I created a ubuntu-lucid branch now
[10:12] <seb128> bah, robert_ancell doesn't pay any attention to conflicts or replaces to use
[10:12]  * seb128 fixes libgnomekbd
[10:18] <glatzor_> mvo, great. I plan to not introduce any further descrutive api changes in this cycle anymore.
[10:18] <mvo> glatzor_: cool. I do some testing now and will upload then
[10:19] <glatzor_> mvo, I am not sure about turning (Add|Remove)VendorKey into a non transaction based method
[10:20] <glatzor_> in the end it isn't a package management task, but does it make sense to change the key while installing software?
[10:21] <mvo> glatzor_: I think its fine to have it non-transactunal, it returns very quickly and there is no need for any queing AFAICS
[10:21] <glatzor_> mvo, could there be any side effects if the authentication gets checked and another programme changes the pub keys?
[10:21] <lifeless> mvo: ping; hi, you were going to merge my deprecations fix for the conflict checker ?
[10:22] <glatzor_> mvo, ok. then this will be the only descrutive API change in this cycle to follow :)
[10:23] <mvo> lifeless: I thought sbeattie has access, no? but i can do it quickly now, but I kind of handed it off to him
[10:24] <mvo> glatzor_: hm, good point. it should be all done in a safe way, I guess audit/test-code is a good way to check
[10:25] <lifeless> mvo: I just want to stop getting cron mail complaining about the deprecation  :)
[10:29] <mvo> lifeless: hrm, I seem to be unable to find the mail about it nor a branch from  on LP :/
[10:32] <lifeless> mvo:  https://code.edge.launchpad.net/~conflictchecker/conflictchecker/trunk has it, but perhaps its not been deployeD?
[10:32] <lifeless> or, perhaps there are now two copies running somewhere ? ><
[10:33] <lifeless> I'll look more closely at the next mail I get.
[10:34] <mvo> lifeless: indeed, thanks. its there now (I was confused because it requires a merge instead of a pull)
[10:34] <lifeless> it does?
[10:36] <mvo> lifeless: it did, I fixed it now
[10:37] <mvo> lifeless: ok, hopefully the spam stops now
[10:37] <mvo> lifeless: although I also got a mail that it was having trouble with some package, but I have not investigated yet
[10:43] <mvo> glatzor_: hm, aptd --replace seems to be no longer work, is that a known issue?
[10:44] <glatzor_> mvo, not yet
[10:44] <glatzor_> :)
[10:50] <mvo> glatzor_: I also get http://paste.ubuntu.com/336442/ when trying to install something, I hope its not a false error from the replace daemon problem (I did kill the daemon manually before trying it)
[10:52] <Laney> I think I saw a replaces problem with totem-plugins
[10:53] <Laney> my firefox is completely screwed so i can't check bugs atm
[10:55] <Laney> dpkg: error processing /var/cache/apt/archives/totem-plugins_2.28.4-0ubuntu3_amd64.deb (--unpack):^M trying to overwrite '/usr/lib/totem/plugins/gromit/gromit.totem-plugin', which is also in package totem-plugins-extra 0:2.28.4-0ubuntu3
[10:56] <glatzor_> mvo, thanks for reporting. I will fix this in a few minutes
[10:56] <TeTeT> asac: first question, What is the easiest way to provide a package with an additional root certificate for the browser?
[10:57] <mvo> glatzor_: cool, many thanks!
[10:57] <asac> TeTeT: its intentionally not that simple afaik
[10:58] <asac> mozilla does not want us or distributors to ship root certificates
[10:58] <asac> that are different from theirs
[10:58] <lifeless> mvo: you should push the changes that are outstanding to trunk then ?
[10:58] <TeTeT> asac: a customer needs to add their own root certificate for their own websites
[11:01] <asac> TeTeT: i have to check that with mozilla folks. from what i know its not easy to do
[11:01] <TeTeT> asac: ok, thanks for investigating
[11:02] <TeTeT> asac: second, this bug on Network Manager: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/483773
[11:03] <TeTeT> asac: somehow Network Manager does not work in some cases, but in others
[11:03] <TeTeT> asac: some=user mode, others=system mode
[11:03] <TeTeT> asac: I don't have the system with the problem yet, but will get access to it early next year, if that's of any help
[11:05]  * asac checks
[11:06] <seb128> Laney, I will have a look to that one
[11:07] <asac> TeTeT: asked user to test latest dailies. we bumped ppp timeout which might be what the user hits here
[11:08] <asac> also we had a fix for sytem connections landed there
[11:09] <TeTeT> asac: where are the latest dailies?
[11:09] <asac> TeTeT: posted there
[11:09] <asac> TeTeT: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/483773/comments/7
[11:10] <TeTeT> asac: thanks!
[11:10] <Laney> seb128: cool, just looks like a plugin move
[11:10] <seb128> Laney, right, I did resync on Debian and probably did an error in the .install changes
[11:11] <Laney> ok
[11:12] <seb128> pitti, be careful with sru comments please before flagging bugs as failed verification
[11:13] <pitti> seb128: if it later turns out to be a wrong comment, we can change it back
[11:13] <pitti> but we need to flag it as "don't copy to -updates"
[11:13] <pitti> and rather err on the side of caution
[11:13] <seb128> some users say to have current version 2.22.2
[11:13] <seb128> but the update is 2.22.3
[11:13] <seb128> and I bet most didn't restart their session
[11:14] <seb128> pitti, also any reason you didn't pocket copy the nautilus sru you moved to updates some days ago?
[11:14] <pitti> ah, can do
[11:15] <seb128> pitti, danke
[11:15] <pitti> done, closing bugs now
[11:16] <seb128> I hate when sru are blocked by users not able to test an update
[11:16] <seb128> or commenting on random bugs
[11:16] <seb128> pitti, thanks
[11:16] <pitti> double-edged sword, yes; we depend on user feedback, but sometimes it's utterly wrong
[11:17] <chrisccoulson> pitti - what shall we do about the seahorse-plugins update in karmic-proposed? that's still blocked on user comments, which haven't been possible due to launchpad timing out?
[11:17] <pitti> chrisccoulson: it is possible, by replying via email
[11:17] <pitti> but I didn't hear any feedback about it
[11:17] <pitti> (on IRC, etc.)
[11:18] <chrisccoulson> yeah, i've not seen any feedback either
[11:18] <chrisccoulson> i'm not sure if that's a good or bad thing ;)
[11:18] <seb128> it's not the sort of updates you will get easy feedback on
[11:18] <pitti> well, "installed it and still works" would suffice
[11:18] <pitti> no need to reproduce the crash, etc.
[11:19] <chrisccoulson> i could probably say that, but it should perhaps come from somebody more independent ;)
[11:19] <pitti> chrisccoulson: did you test the actual .debs from -proposed? (not a local build)
[11:20] <chrisccoulson> pitti - i did the testing on a local build, although i have the debs from proposed installed now
[11:20] <chrisccoulson> and i haven't noticed nay issues (and no more crashes too)
[11:20] <pitti> chrisccoulson: thanks; copying then
[11:20] <chrisccoulson> thanks:)
[11:21] <pitti> another, and hopefully final, spam wave
[11:21] <chrisccoulson> hopefully! that bug report annoyed quite a lot of people
[11:21] <pitti> damn, forgot to copy to lucid first
[11:22] <chrisccoulson> it contributed to about 800 e-mails in my inbox over a couple of weeks
[11:22] <pitti> now I need to wait for an hour
[11:22] <seb128> seems launchpad is quite busy making bzr and bugs match or something
[11:22]  * seb128 almost done with email backlog from the weekend there was a lot of such emails from launchpad
[11:32]  * pitti gets tons of "branch linked" bug mail
[11:42] <seb128> ok, done with weekend backlog now
[11:52] <glatzor_> mvo, fixed now.
[11:53] <mvo> glatzor_: thanks, merging now
[12:01] <mvo> glatzor_: thanks, work better now, I commited a minor typo fix in r292 (or I'm trying to, its still commiting :)
[12:01] <mvo> glatzor_: or some reason I do not get transaction finished signal in s-c, but that may well be my fault, I have not debugged it yet. but the "re-read cache in the background when a transaction finished" is not working currently
[12:04] <glatzor_> mvo, that is my fault
[12:04] <glatzor_> sorry. it was an oversight of mine. wait a minute
[12:04] <mvo> glatzor_: ok :) if you know the reason already, I will stop debugging
[12:04] <mvo> glatzor_: \o/
[12:11] <glatzor_> mvo, you can merge now.
[12:11] <glatzor_> I fixed this in software-center glatzor
[12:13] <mvo> glatzor_: aha, the "finished" signal? nice
[12:15] <mvo> glatzor_: what is the replacement for "client.py: Transaction.get_error()"?
[12:17] <glatzor_> It is now a property: client.error
[12:18] <glatzor_> äh, client.Transaction.error
[12:18] <glatzor_> furthermore you can use client.Transaction.error_code and client.Transaction.error_details if you don't require an Exception
[12:19] <glatzor_> mvo, oh, looking at the backend code again I see why you are asking :)
[12:26] <mvo> glatzor_: :) thanks, I think I can fix it
[12:29] <asac> seb128: there is an upstream patch for bug 467972 ... if you know any metacity dev getting some attention would be great.
[12:42] <seb128> asac, not really no, I've not been looking at what they are doing since I use compiz which means for some years now
[12:43] <seb128> asac, I will try pinging robert_ancell in case when he's around though
[12:44] <seb128> restarting session brb
[12:52] <pitti> seb128: I demoted compiz-fusion-plugins-extra, FYI
[12:52] <seb128> pitti, thanks
[12:52] <pitti> I'm curious, how much did that buy?
[12:52] <seb128> not sure, we won another 1 seconds with icon cache + that
[12:53] <pitti> right, icon cache
[12:53] <seb128> the current chart is 11 seconds desktop login
[12:53] <seb128> 21 seconds total
[12:54] <seb128> the real offender is gnome-panel
[12:54] <seb128> a boot without compiz is 18 seconds
[12:55] <seb128> but gnome-panel has a "several seconds nothing then use cpu for 3 seconds"
[12:55] <seb128> if we dropped the empty spot there we would be much better
[12:55] <pitti> unless some magic happens, we probably need to resort to metacity anyway
[12:55] <seb128> let's see
[12:55] <pitti> but nautilus is still a problem, too, I guess? and the delays in gnome-session?
[12:55] <seb128> but yeah...
[12:55] <pitti> but, good progress in the last week already
[12:56] <seb128> yes, I've nautilus on my todolist too
[12:56] <seb128> there is not too many delays in gnome-session
[12:56] <seb128> the current gap gnome-session, runs is 2 seconds
[12:56] <seb128> 1 second being gconf init
[12:56] <seb128> which chrisccoulson is working on
[12:56] <seb128> the other one second is half due to the xrand g-s-d capplet
[12:57] <seb128> and 0.5 seconds is settings themes, etc
[12:57] <seb128> but in any case we have to reduce cpu use in some way
[12:58] <seb128> without the gnome-panel blank spot and without compiz we would be around 8 seconds now
[13:00] <seb128> I think by holidays time we will have tackled all the obvious delays
[13:00] <seb128> then we need to start making gnome-panel and nautilus use less cpu
[13:00] <seb128> I'm a bit concerned that we don't have a good tradeoff though
[13:00] <seb128> we will trade 3 seconds login for slugish user experience
[13:01] <seb128> like having delays on first action
[13:01] <seb128> I like much better waiting 3 seconds and having things ready than having to wait 1 seconds on first click on menus, etc
[13:02] <tjaalton> pitti: howdy. are you available to sync some packages for the new xserver? :)
[13:02] <pitti> tjaalton: sure
[13:02] <pitti> tjaalton: just toss me the list, preferably separated by experimental/unstable?
[13:03] <tjaalton> pitti: ok, I'll make one up
[13:03]  * pitti can't wait to get the new x server :)
[13:03]  * tjaalton neither
[13:04] <pitti> tjaalton: If you want, I'm happy to take a look at your -server/-evdev/-synaptics merges/branches, to ensure that the udev rules are correct now?
[13:04] <pitti> tjaalton: also, jcristau added the input_id prober to xorg-server temporarily, we don't need that any more (not in Debian either)
[13:05] <tjaalton> pitti: synaptics isn't done yet, but rest are in git.d.o in the debian branches
[13:05] <tjaalton> I mean that synaptics hasn't been merged yet
[13:05] <pitti> oh, we can sync -evdev and server?
[13:05] <tjaalton> pitti: yes, I disabled the local version
[13:06] <tjaalton> evdev yes, server no :)
[13:06] <tjaalton> I guess we can use what debian has?
[13:06] <pitti> http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evdev.git;a=summary ?
[13:07] <tjaalton> yes
[13:07] <pitti> http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evdev.git;a=blob;f=debian/local/65-xorg-evdev.rules;h=48bbc8aa43393729b001a3bd75cfd018a0228d2b;hb=HEAD
[13:07] <pitti> ^ that doesn't load the keyboard layout
[13:07] <pitti> I take it that's done from somewhere else
[13:08] <tjaalton> right, it's on xorg-server
[13:08] <pitti> so, that one looks good
[13:08] <pitti> (nice, then we can sync -evdev)
[13:08] <tjaalton> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=dec68ef3470d39edabb5f6990d1f40c2c51f2601
[13:09] <tjaalton> though I changed it to use console-setup
[13:09] <pitti> tjaalton: right, was about to say
[13:09] <tjaalton> because we don't have keyboard-configuration just yet
[13:09] <pitti> tjaalton: for synaptics, http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-synaptics.git;a=blob;f=debian/66-xorg-synaptics.rules;h=b3b457fdbe24c005dc465fd5697d11fd163fee6c;hb=HEAD looks fine as well
[13:10] <tjaalton> yep
[13:11] <tjaalton> oh bah, I didn't fix the server to use udev's input_id
[13:12] <pitti> tjaalton: could you prepend a ENV{ID_INPUT_KEY}=="?*"  in debian/local/64-xorg-xkb.rules ?
[13:12] <pitti> (then you can drop the SUBSYSTEM/KERNEL checks if you want)
[13:13] <pitti> I don't think we need to apply the layout to devices which don't have keys
[13:13] <pitti> but well, it's just a nitpick
[13:13] <tjaalton> ok, I'll let jcristau know as well
[13:13] <pitti> tjaalton: what do you use now to read console-setup?
[13:13] <pitti> tjaalton: ISTR that I already mailed him about it
[13:13] <pitti> but well, it shouldn't really hurt
[13:13] <tjaalton> pitti: /usr/lib/hal/debian-setup-keyboard
[13:14] <pitti> tjaalton: my local rule still has a sed expression, but that can be simplified since I think jcristau changed the server to understand both xkb.foo and xkbfoo
[13:14] <pitti> and it's using stricmp(), so the lower-case stuff isn't necessary either
[13:14] <pitti> ENV{ID_INPUT_KEY}=="?*", IMPORT{program}="/bin/grep ^XKB /etc/default/console-setup"
[13:14] <pitti> in theory that should work
[13:15] <pitti> tjaalton: I meant, how did you change the udev rule for console-setup
[13:16] <tjaalton> pitti: I only changed the path, but didn't think that the format probably changed..
[13:16] <pitti> tjaalton: right, but console-setup exports a whole bunch of other variables, which we don't need as properties on the udev devices
[13:16] <tjaalton> heh, right
[13:16] <pitti> $ /bin/grep ^XKB /etc/default/console-setup
[13:16] <pitti> that looks right to me
[13:17] <pitti> tjaalton: I think we should use that for now, and we'll switch to /etc/default/keyboard once we merged the new console-setup
[13:17] <pitti> it's much better than my current seddery, anyway
[13:17] <tjaalton> pitti: yes, fixing
[13:18] <pitti> tjaalton: thanks
[13:18] <pitti> sorry for holding you up, I just want to avoid large regressions right before a1
[13:18] <tjaalton> ..and there would have been some :)
[13:19] <pitti> and there will :)
[13:19] <tjaalton> hehe, indeed
[13:19] <pitti> but, it's alpha-1
[13:36] <mvo> glatzor_: if you don't mind I would like to switch the description for error_unknown to have "Unknown error" in it?
[13:37] <mvo> glatzor_: nevermind
[13:39] <glatzor_> mvo, the error message are still on my TODO list. This is not the only one which would need some love :9
[13:39] <glatzor_> mvo, my first goal was to get the API review of aptdaemon done.
[13:41] <glatzor_> mvo, is it possible to store some extra html pages about a project on launchpad?
[13:48] <mvo> glatzor_: I don't know, sorry :(
[13:55] <tjaalton> pitti: ok, here's the list http://pastebin.ubuntu.com/336548/
[13:57] <pitti> tjaalton: xcb-proto is quilt 3.0, needs manual upload
[13:57] <tjaalton> pitti: ah, ok
[13:57] <tjaalton> don't bother then
[13:57] <tjaalton> it's not critical
[13:58] <tjaalton> yeah it isn't maintained by XSF so didn't know :)
[13:59] <pitti> there, buildd fodder
[14:00] <tjaalton> they should end up in depwait until xserver is built
[14:00] <tjaalton> hmm, but maybe not openchrome..
[14:00] <pitti> tjaalton: all done
[14:00] <tjaalton> pitti: thanks!
[14:01] <pitti> tjaalton: the rest (synaptics/server/etc.) are merges?
[14:01] <kenvandine> seb128, did you see the gtk upload to ~ubuntu-desktop?
[14:01] <tjaalton> pitti: yes
[14:01] <kenvandine> and the nautilus upload there is needed as well
[14:01] <tjaalton> xorg & xorg-server uploaded
[14:01] <seb128> kenvandine, yes, my dellmini wanted to install that this morning I had to comment the ppa ;-)
[14:02] <pitti> \o/
[14:02] <kenvandine> seb128, it does cause a fair bit of weirdness
[14:02] <kenvandine> mostly redraw related
[14:02] <kenvandine> it looks
[14:02] <seb128> ok
[14:02] <seb128> I will give that a try on my laptop later
[14:02] <kenvandine> like in a terminal window, if you scroll up and down a bunch of time you see artifacts
[14:02] <kenvandine> bratsche knows about that
[14:02] <seb128> is cody working on those issues?
[14:02] <kenvandine> just not sure how to fix
[14:02] <kenvandine> yeah
[14:02] <kenvandine> it doesn't seem to crash anything
[14:03] <kenvandine> just a little annoyance :)
[14:03] <kenvandine> it is most noticable in nautilus
[14:03] <kenvandine> scrolling a nautilus browse window
[14:03] <kenvandine> the patched nautilus is required to just let it draw the desktop :)
[14:05] <seb128> without having to active a theme using those features or with one?
[14:05] <seb128> I though it would be a nop in the case it's not used
[14:05] <kenvandine> even without activating it
[14:05] <kenvandine> that is the only known issue
[14:05] <kenvandine> with activating it there might be more
[14:05] <kenvandine> i haven't been able to test that yet, there is no theme for it just yet :)
[14:07] <kenvandine> seb128, i plan to try to figure out how to enable that today and see how buggy it is
[14:07] <seb128> ok
[14:07] <seb128> any news about the empathy update btw?
[14:09] <kenvandine> no, i will get that done this week too
[14:09] <kenvandine> hopefully tomorrow
[14:09] <kenvandine> i need to get the libappindicator stuff out first
[14:12] <seb128> why?
[14:12] <seb128> it's a standard update no? should work with the libs from karmic
[14:12] <seb128> I wanted to get that update for alpha1 but seems it will be short
[14:12] <seb128> it should land today or maybe tomorrow for that
[14:14] <kenvandine> oh... i can try to get it today then
[14:15] <seb128> thanks
[14:15] <kenvandine> np
[14:17] <kenvandine> hey tedg
[14:17] <tedg> morning kenvandine
[14:18] <tedg> Anyone else having Evolution segfault on them this morning? (Karmic)
[14:18] <seb128> hey tedg
[14:18] <seb128> no, but I'm not using karmic
[14:18] <seb128> it didn't change recently and we didn't get bugs about that
[14:20] <tedg> :(  It's in pthread_create -- not a fun place to look for bugs.
[14:20] <TeTeT> asac: do you know if bluetooth phones are supported in NM eventually?
[14:22] <tedg> kenvandine: I played with your doc branch, and it's dying on "make dist" for me.
[14:27] <kenvandine> tedg, ok, i hadn't tested that yet
[14:28] <kenvandine> tedg, i am not done
[14:28] <tedg> kenvandine: Okay, cool.
[14:28] <kenvandine> tedg, is it what you expected though?
[14:29] <tedg> kenvandine: Yes, with make dist ;)
[14:29] <kenvandine> ok
[14:29] <kenvandine> cool
[14:29] <kenvandine> will finish it :)
[14:29] <pitti> tjaalton: I just removed the last rdepends to hal on the ubuntu CD now (oem-config, submitted a branch and merge proposal)
[14:31] <mclasen> pitti: out of interest, what are you doing about backlight control ?
[14:31] <pitti> mclasen: I think we need to add a hal dependency to the fglrx/nvidia packages
[14:32] <pitti> either that, or switch hal to be dbus-activated instead of started on login
[14:32] <pitti> so that it only gets started when g-p-m wants to talk to it
[14:33] <Ng> TeTeT: some of them work now - if they support PAN. I think DUN support is on the way
[14:33] <Ng> TeTeT: e.g. an iPhone can be used for bluetooth tethering just fine in Karmic
[14:34] <TeTeT> Ng: no idea what PAN and DUN are :)
[14:36] <asac> TeTeT: they PAN is already supported OOB ... DUN should work with latest blueman that adds some workarounds
[14:36] <asac> s/they//
[14:37] <TeTeT> asac: good
[14:42] <pitti> tjaalton:
[14:42] <pitti>   * On upgrade, restart hal on kfreebsd and run udevadm trigger on linux to
[14:42] <pitti>     make sure we can pick up input devices correctly.
[14:42] <pitti>   * Because of the above, move udev and hal from Recommends back to Depends.
[14:42] <pitti> tjaalton: ^ do we have a hal dependency in xorg due to that?
[14:42] <pitti> also, why depend on a package at all if you merely need to restart it? if it's not installed, no need to restart, and it can just be ||true'ed
[14:45] <tjaalton> pitti: only on [kfreebsd-any]
[14:45] <pitti> ah, *phew* :)
[14:45] <tjaalton> :)
[14:51] <kenvandine> morning rickspencer3
[14:51] <rickspencer3> good morning kenvandine
[14:52] <pitti> hey rickspencer3
[14:52] <rickspencer3> hi pitti
[14:53] <rickspencer3> how is everyone today?
[14:54] <mclasen> pitti: that seems a somewhat superficial notion of hal removal, when the only X driver halfway supporting xbacklight is intel...
[14:55]  * pitti puts down the hal chasing gun and waves; great!
[14:55] <pitti> mclasen: radeon doesn't?
[14:56] <pitti> mclasen: then we probably need to keep it installed by default, and change to dbus-activation
[14:56] <pitti> but at least it's out of the boot path
[15:02] <rickspencer3> my email is taking a very long time to sync
[15:02]  * rickspencer3 wonders if this is a bad sign
[15:07] <rickspencer3> we're already over the trend line for work items :(
[15:07] <rickspencer3> I'll get the desktop in the cloud one knocked out asap
[15:13] <rickspencer3> tseliot, hi
[15:13] <tseliot> hi rickspencer3
[15:13] <rickspencer3> tseliot, I saw your email regarding plymouth plugins
[15:14] <tseliot> good
[15:14] <rickspencer3> looks like you are making good progress
[15:14] <rickspencer3> are your remaining work items for it captured in a blueprint anywhere?
[15:14] <tseliot> rickspencer3: yes, it's almost complete (it depends on what the design team needs)
[15:15] <rickspencer3> tseliot, I expect it to take them to near the end of the cycle to finalize the designs
[15:15] <tseliot> rickspencer3: good question, I think the proprietary drivers spec and the one about touchscreens should contain all of my work items
[15:15] <rickspencer3> tseliot, well, it looks like you have more work for plymouth, we should capture the work items somewhere
[15:15] <tseliot> rickspencer3: yes, that's likely. In the meantime they can ask for new features or corrections
[15:16] <rickspencer3> also, is there anything keeping you from pushing the artwork that you have now into Lucid?
[15:16] <tseliot> rickspencer3: right
[15:16] <tseliot> rickspencer3: no, I guess not. Is the artwork from the pdf acceptable? If so, maybe Keybuk can push it
[15:17] <rickspencer3> tseliot, I don't think we should block on getting real artwork
[15:18] <rickspencer3> developer artwork is fine for finding bugs and other issues
[15:18] <rickspencer3> in fact, we'll probably want to experiment with the artwork to figure out how to make it fast
[15:18] <tseliot> ok, good
[15:18] <rickspencer3> Keybuk, thoughts wrt pushing plymouth plugin asap? ^
[15:19] <Keybuk> rickspencer3: yes
[15:19] <Keybuk> plymouth is in NEW but doesn't work properly
[15:20] <rickspencer3> ah
[15:20] <rickspencer3> so as soon as plymouth itself is ready, tseliot's plugin with placeholder art work will go?
[15:21] <tseliot> it sounds like a plan
[15:21] <Keybuk> yes
[15:23] <tseliot> good
[15:23] <pitti> hey Keybuk
[15:23] <pitti> Keybuk: do you plan to have plymouth in a1?
[15:24] <pitti> Keybuk: FUI, udevified Xorg was uploaded :)
[15:24] <pitti> "FYI", too
[15:24] <Keybuk> pitti: depends on the NEW gods ;)
[15:24] <Keybuk> it's been sat there since last week
[15:24] <Keybuk> ooh, AWESOME!
[15:24] <pitti> "Keybuk | plymouth is in NEW but doesn't work properly"
[15:25] <Keybuk> pitti: still needs to get out of NEW though
[15:25] <pitti> I was about to offer to review it, but this scares me a bit?
[15:25] <pitti> ok
[15:25] <pitti> well, having it in universe and build can't hurt for now
[15:25]  * pitti reviews
[15:25] <Keybuk> exactly
[15:26] <seb128> hey rickspencer3
[15:26] <seb128> hey Keybuk
[15:26] <Keybuk> pitti: does this mean there isn't a HAL dependency left on the CD?
[15:26] <pitti> ./themes/details/.gitignore:                            \012- Assembler source
[15:26] <pitti> lol
[15:26] <pitti> Keybuk: by that --><-- much
[15:26] <rickspencer3> hi seb128
[15:26] <Keybuk> pitti: ?
[15:26] <pitti> Keybuk: ubuntu-desktop doesn't have one any more
[15:27] <pitti> Keybuk: oem-config still pulls it in, though; I submitted a branch and merge proposal to fix that
[15:27] <pitti> Keybuk: we might eventually put back a hal dep in g-p-m for backlight handling, and change hal to get dbus activated
[15:27] <seb128> http://people.canonical.com/~scott/daily-bootcharts/
[15:27] <seb128> desktop starts in -4 seconds today
[15:28] <pitti> but let's kick it out completely now and see what's left
[15:28] <seb128> good work everybody ;-)
[15:28] <seb128> (on hdd=
[15:28] <pitti> seb128: ...
[15:28] <seb128> pitti, heh, I'm only reading the daily numbers!
[15:28] <Keybuk> seb128: yeah, gdm failed to start in that one
[15:28] <Keybuk> seems to especially affect the HDD one
[15:28] <seb128> Keybuk, the one second difference on the 3 most recent ssd is weird
[15:28] <pitti> oh, that's cool, didn't know about that page
[15:29] <seb128> seems desktop login is not really constant
[15:29] <seb128> I don't think we had changes over the weekend
[15:29] <pitti> how come that seb128's is done in 23 seconds, and Keybuk's in only 29?
[15:29] <pitti> Keybuk: btw, the jockey crash is fixed, so that should be gone now
[15:29] <seb128> pitti, ?
[15:30] <pitti> seb128: http://people.canonical.com/~scott/daily-bootcharts/20091206-sam.png -> @( S
[15:30] <seb128> pitti, look at ssd
[15:30] <Keybuk> seb128: jockey being fixed is what brought that back down afaict
[15:30] <pitti> ERK
[15:30] <seb128> pitti, sam is hdd
[15:30] <pitti> MEH PLZ FIX MY KEYBOARAD
[15:30] <pitti> seb128: ah, ok
[15:30] <seb128> pitti, look at the first column for ssd
[15:30] <pitti> weird, it seems to have thought I had caps lock on, sorry
[15:31] <pitti> ah, cool
[15:32]  * seb128 kicks gnome-panek
[15:32] <seb128> gnome-panel
[15:32] <seb128> Keybuk's chart have the same "do nothing for a while in middle of loading"
[15:33] <Keybuk> (sam's chart today should be fixed again)
[15:33] <seb128> what I don't get is that the bootchart cpu is maxed-out all the time
[15:33] <seb128> while sometime nothing is very busy in the graph
[15:33] <seb128> like during the blank on the gnome-panel bar
[15:33] <seb128> nothing seems 100% busy
[15:33] <seb128> but the cpu load stay at 100%
[15:34] <Keybuk> the CPU sampling is a little imprecise
[15:34] <Keybuk> it's based on nice loading
[15:34] <Keybuk> so can have delayed drops
[15:34] <Keybuk> Michael Meeks has been working on a taskstats based collector instead
[15:34] <seb128> the coloration on the chart of the cpu use graph?
[15:35] <Keybuk> yeah the blue graph - it can fail to drop when the CPU is idle because it's been "not idle" recently
[15:35] <Keybuk> if that makes sense
[15:35] <seb128> it does, thanks
[15:35] <Keybuk> where recently is < 0.5s, but that's enough to be slightly misleading at times
[15:35] <seb128> anyway we are almost done with where bootchart is useful
[15:35] <Keybuk> if you take a bootchart PNG URL
[15:35] <seb128> we will need to switch soon to make gnome-panel and nautilus use less cpu
[15:35] <Keybuk> and replace the .png with .tgz
[15:36] <Keybuk> you can run bootchart --no-prune on it yourself
[15:36] <Keybuk> you get a lot more information
[15:36] <Keybuk> (at some point I guess I'llhttp://people.canonical.com/~scott/daily-bootcharts/20091206-sam.png
[15:36]  * seb128 tries that
[15:36] <Keybuk> argh
[15:36] <Keybuk> I guess I'll switch the generated charts too - but it does make them a lot more noisy)
[15:37] <pitti> Keybuk: plymouth souce NEWed, looks okay
[15:37] <Keybuk> seb128: other desktop speed-ups
[15:37] <Keybuk> one of the things I noticed in the suddenly faster -desktop image was a new GTK+
[15:37] <Keybuk> 2.19 rather than 2.18
[15:37] <Keybuk> maybe that's faster to init?
[15:37] <seb128> could be
[15:38] <Keybuk> gnome-menus has a cacheing patch from pitti in the same image
[15:38] <seb128> one of the recent wins has been making gnome-icon-theme icon cache updated correctly
[15:38] <seb128> that landed on friday
[15:38] <seb128> and wins around 1 second on login
[15:38] <Keybuk> right
[15:38] <Keybuk> saturday morning's chart was the fast one
[15:39] <Keybuk> and it's been consistently faster since
[15:39] <seb128> we got that and compiz dropped it's depends on -extra
[15:39] <Keybuk> anything that landed between thursday morning and saturday morning could have helped
[15:39] <seb128> which means a bit less .so and .xml to load too
[15:39] <seb128> those are the 2 we did change
[15:39] <pitti> seb128: do you still have your "start everything at once" patch? then perhaps other stuff can fill the gaps that g-panel leaves?
[15:40] <seb128> pitti, my concern is not that cpu is not busy it's that gnome-panel is the last thing to still use cpu and would finish earlier without that
[15:40] <pitti> right
[15:40] <seb128> we basically have compiz nautilus gnome-panel using cpu
[15:40] <seb128> so I'm not too concerned about cpu not being busy
[15:41] <seb128> but it's very obvious on graphs without compiz
[15:41] <seb128> gnome-panel finish some seconds later than nautilus on those
[15:41] <seb128> gnome-panel seems to waste seconds sitting there
[15:42] <Keybuk> could it be that it's done with its main loop, and set timers to do more work later
[15:42] <Keybuk> and the 1s/2s gap is just waiting for that timer to fire?
[15:43] <seb128> Keybuk, I don't think it's using a time but rather an idle loop, not sure why that would delay things so much
[15:43] <seb128> or maybe it's busy but that's not reflected on the graph
[15:43] <Keybuk> possibly
[15:43] <seb128> I think from there we need to measure what software do specifically
[15:43] <Keybuk> strace may help here a bit
[15:43] <Keybuk> or ltrace
[15:44]  * halfline summons chrisccoulson
[15:44] <seb128> we have 2 remaing delays around g-s-d
[15:44] <Keybuk> we're certainly at the limits of what bootchart can tell you about a process
[15:44] <seb128> one being gconf loading the other one being xrandr g-s-d code
[15:45] <seb128> and we have some delay between gnome-panel and nautilus we might want to drop
[15:45] <seb128> then we will be done with bootcharts use I guess
[15:45] <seb128> and we need to start looking at nautilus and gnome-panel in details
[15:45] <pitti> well, it'll still be useful for checking the actual outcome and the speedups of changes
[15:45] <seb128> right
[15:45] <seb128> I just meant it's the limit of where it's useful to tell you what to work on
[15:46] <seb128> we have covered that pretty much now
[15:46] <seb128> it's still useful for measures
[15:47] <seb128> I've some concerns about concessions to reach the goal though
[15:47] <seb128> like delaying some loading to first action
[15:47] <seb128> you trade a slightly faster boot for a slughish user experience
[15:47] <seb128> which I'm not sure is somebody which give a better user experience
[15:48] <pitti> what's an example?
[15:48] <Keybuk> our boot goal is supposed to include all that
[15:48] <Keybuk> delaying is considered naughty by my book
[15:48] <pitti> e. g. we can never make e-d-s completely load for all users in 4 seconds
[15:48] <pitti> talking to google calendar etc. just takes a bit
[15:48] <rickspencer3> pitti, fyi, talking to kenvandine ... I updated work items for empathy: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-empathy-indicator
[15:48] <pitti> and it's already sluggish the first time when you click on the clock
[15:49] <pitti> rickspencer3: ah, thanks
[15:49] <pitti> (not a concern for a clean install, of coursre)
[15:49] <seb128> pitti, we are speaking about delaying e-d-s loading for example or nautilus evince properties, etc
[15:50] <seb128> which would mean you get the delay first time you open the clock or a nautilus property
[15:50] <seb128> or context menu
[15:50] <pitti> seb128: ideally we could load those after the desktop is fully set up and usable (i. e. nautilus and panel)
[15:50] <pitti> if you start your session and immediately click on the clock, you'll get a delay
[15:50] <seb128> right but that would still count on the chart as activity
[15:50] <pitti> but if it loads in the background when the desktop is done loading, it'd give us the best of both worlds, no?
[15:51] <seb128> we don't stop counter when desktop is usuable
[15:51] <seb128> but when activity is to 0
[15:51] <pitti> yes, I know
[15:51] <Keybuk> well, depends
[15:51] <pitti> I mean from an user perception POV
[15:51] <seb128> yes
[15:51] <Keybuk> I stop the counter when the load is continually below 25%
[15:51] <seb128> I agree, that's why I say the goals are conflicting there
[15:51] <Keybuk> if the ongoing work is sufficiently niced and can be pre-empted, it's probably not a problem
[15:51] <Keybuk> ie, if the user even moves the mouse, the apps stop what they're doing
[15:51] <Keybuk> (or pause it)
[15:52] <Keybuk> that obviously means no I/O though
[15:52] <seb128> that's like the sleep 30 we have now to start update-manager, etc
[15:52] <Keybuk> I was wondering whether it'd be possible to lay down poison for update-manager
[15:53] <Keybuk> I keep finding it under windows, or hidden in the Alt-Tab list as a "minimised" app
[15:53] <Keybuk> it's like mouse poo in the kitchen
[15:54] <pitti> heh, I never see it at all nowadays
[15:54] <lool> Is anybody taking specifically care of ubuntu-netbook-remix/-edition in the desktop team now?
[15:55] <mvo> Keybuk: you can turn off auto-open of u-m ...
[15:55] <pitti> lool: didrocks will from January on; until then it's still in the hands of mobile, AFAIUI?
[15:55] <Keybuk> mvo: yes, but the minis wipe themselves every day
[15:55] <Keybuk> so all the settings go too
[15:56] <didrocks> pitti: lool : I can handle the transition from unr -> une spec if you wish
[15:56] <didrocks> (I'm working on the session management right now)
[15:56] <pitti> well, depends on how much time you can/want to throw at it, of course
[15:57] <didrocks> pitti: I have 3 weeks of "vacations" (holidays but still on my previous employer contract) starting in less than 2 weeks now
[15:57] <mvo> Keybuk: oh, right. well, then poison is probably the right idea ,)
[15:57] <didrocks> pitti: I can continue to devote some time to it :)
[15:58] <lool> pitti: I had no idea mobile was in charge of UNR until January
[15:59] <lool> pitti: Just noticed that the seeds were only updated for desktop and not unr (at least for gnome-games), so wanted to fix that
[15:59] <pitti> lool: it's the bit I'm not sure of (rickspencer3?)
[15:59] <lool> I guess the seed should move to ubuntu.lucid
[15:59] <pitti> lool: I just know that we don't have anyone to work on it until then
[15:59] <pitti> ah, thank you
[15:59] <didrocks> again, if you need some hand, I can work on it as community until then :)
[15:59] <lool> didrocks: That's nice; I'm not really looking for any particular work to be achieved, I thought I'd share a couple of hints if I knew who was picking it up
[16:00] <lool> I was also wondering who would look at the A1 images
[16:01] <didrocks> lool: not sure to have the time (and the time to learn how to check the image) for A1. If you think we can have a phone call to deal with that
[16:01] <pitti> I'm inclined to say that if mobile team can't work on it any more, we just skip a1; it's just the first alpha, after all
[16:02] <rickspencer3> lool, pitti I was expecting that SteveA would do the rename and that would be A1
[16:02] <seb128> tedg, you should open your bugs directly upstream, nobody is going to do anything for your ticket which is not opened using apport, not retraced and has no debug symbols installed
[16:02] <rickspencer3> (for UNR -> UNE)
[16:02] <pitti> rickspencer3: StevenK?
[16:03] <lool> rickspencer3: You mean stevenk I guess
[16:03] <rickspencer3> pitti, yes
[16:03] <rickspencer3> lool, yes
[16:03] <tedg> seb128: How do I apport a bug in a stable release?  I used apport to collect the data.
[16:03] <lool> Hmm pitti had already said that
[16:03] <tedg> seb128: Can I run evo under apport?
[16:04] <pitti> tedg: "under" apport?
[16:04] <pitti> tedg: you just need to enable it in /etc/default/apport and then sudo start apport
[16:04] <lool> pitti: I don't mind skipping A1 for UNE; I don't think the rename needs to happen for A1 either
[16:04] <pitti> then apport will catch crashes again
[16:04] <tedg> pitti: I have a segfault, but apport is turned off as I'm in Karmic.
[16:04] <lool> In fact I'm just happy to help anybody who has any question about UNE/UNR
[16:04] <tedg> pitti: Ah, I was hoping I could do "apport evolution" and then I wouldn't have to turn it on globally.
[16:04] <lool> didrocks: Let me know when you start looking into UNE stuff; will be happy to help
[16:05] <pitti> lool: we will probably have an induction meeting in January
[16:05] <pitti> lool: in Paris :)
[16:05]  * pitti looks forward to getting back to la ville d'amour
[16:05] <lool> That's news to me; I have trips planned in January; any specific dates set already?
[16:05] <seb128> tseliot, hey
[16:05] <tseliot> hey seb128
[16:05] <didrocks> pitti: hope you'll have a good weather there :)
[16:06] <pitti> lool: not firmly determined yet, but probably January 12th to 14th (Tue to Thu)
[16:06] <seb128> tseliot, did you start on desktop already? do you think you would have some time to help on GNOME merges this week?
[16:06] <lool> didrocks: I was under the impression you'd be included in such a meeting
[16:06] <pitti> lool: of course he will :)
[16:06] <rickspencer3> since lool is on Foundations now, I doubt that davidm invited him to the UNE mini-sprint ;)
[16:06] <lool> I was surprised by "hope *you*'ll have good weather -- instead of we
[16:07] <seb128> pitti, do we get an office in paris now? ;-)
[16:07] <tseliot> seb128: yes, I started last week but I'm dealing with some deadlines for OEM and I haven't begun my work on proprietary drivers yet... so it might not be the best time for that. Sorry
[16:07] <pitti> rickspencer3: it's not like he's that far away :)
[16:07] <didrocks> lool: the "you" is for pitti to enjoy paris. I'm used to have a bad weather there :p
[16:07] <seb128> tseliot, ok, no problem, thanks anyway
[16:08]  * seb128 grrrrs at oem stealing robert_ancell and then keeping tseliot busy ;-)
[16:08] <tseliot> hehe
[16:08] <lool> rickspencer3: There's an UNE mini-sprint in Paris organized by davidm?  never heard of it
[16:09] <pitti> seb128: on http://piware.de/workitems/desktop/lucid/versions.html ?
[16:09] <pitti> lool: no, it's more like an induction meeting for didrocks
[16:09] <rickspencer3> lool, it was going to be in London, but I think we'll do Paris instead
[16:09] <lool> Who's we?
[16:10] <pitti> seb128: want me to do dbus and the two syncs (gmime2.4, telepathy-glib) for a start?
[16:10] <pitti> and telepathy-gabble
[16:10] <seb128> pitti, I synced telepathy-glib, you are welcome to do dbus and gmime
[16:11] <seb128> pitti, don't telepathy-gabble we don't track that serie
[16:11] <seb128> (need a way to filter series on versions)
[16:11] <pitti> seb128: ack, will do
[16:11] <seb128> pitti, danke
[16:11]  * seb128 hugs pitti
[16:11] <seb128> pitti, and if you feel borred feel free to do gnome-menus too :-p
[16:11] <seb128> since you touched it ;-)
[16:11]  * seb128 hugs pitti again
[16:11] <kklimonda> pitti: what is your opinion about getting beta of transmission 1.80 into lucid already? is it worth the effort at this time?
[16:11]  * pitti hugs seb128
[16:12] <pitti> kklimonda: sure, always; if 1.8 final will land before lucid beta, it's better to land it early for getting more testing
[16:14] <kklimonda> pitti: ok, I'll prepare a merge/update
[16:20] <jcastro> hi pitti, can you reset our community graph? the baseline is wrong: http://piware.de/workitems/community/lucid/report.html
[16:20] <jcastro> I've fixed all the errors that dholbach pointed out from the cron run
[16:21] <pitti> jcastro: do you just want me to trash the db, so that it starts all over and considers today the starting point? or change the trend line start?
[16:21] <jcastro> consider today the start point please
[16:21] <pitti> that's easier
[16:22] <jcastro> I was formatting mine wrong and it was all messed up, so better to do it right I guess
[16:29] <pitti> jcastro: reload
[16:29] <pitti> jcastro: there are 5 without work items, no other errors
[16:31] <jcastro> hmmm, there shouldn't be any
[16:32] <pitti> jcastro: if you just added them some minutes ago, that's due to the edge->production lag
[16:34] <jcastro> pitti: oh ok, so it will just work itself out next cron run?
[16:34] <pitti> should, yes
[16:34] <jcastro> \o/ thanks!
[16:45] <kklimonda> chrisccoulson: ping
[16:46] <kklimonda> chrisccoulson: does suspend inhibition only work for "idle" suspend? i.e. it doesn't prevent manual suspend from happening?
[16:49] <chrisccoulson> kklimonda - it will prevent any suspend without user intervention
[16:50] <kklimonda> thanks
[16:50] <chrisccoulson> i should correct that - it will prevent g-p-m from suspending without user intervention, and you should see an inhibit dialog when suspending manually via the session dialog
[16:51] <chrisccoulson> however, suspending via the session indicator will be no different, because it talks directly to dk-power and doesn't check the inhibitors
[16:52] <kklimonda> chrisccoulson: and closing laptop lid?
[16:54] <kklimonda> chrisccoulson: http://pastebin.com/d742b38d0 - care to take a look? It looks like the Inhibitor is added but I can still suspend system
[16:54] <kklimonda> both using indicator-session-applet and by closing laptop lid
[17:00] <chrisccoulson> kklimonda - could you ping me when i arrive home from work (i'm just leaving now)?
[17:00] <kklimonda> sure
[17:43] <kklimonda> chrisccoulson: ping :)
[17:43] <chrisccoulson> hey kklimonda
[17:43] <kklimonda> chrisccoulson: maybe that's the way the new inhibition works? when I use inhibitor applet it also doesn't prevent laptop from going to sleep when I close a lid
[17:43] <chrisccoulson> suspend inhibit will have no effect on suspending from indicator-session
[17:44] <chrisccoulson> as it bypasses the mechanism entirely :)
[17:44] <chrisccoulson> it will only work for suspending using the gnome-session dialog
[17:44] <chrisccoulson> i'm not sure about the lid-closing case though. i need to check that out
[17:45] <kklimonda> chrisccoulson: so what is the best way of testing it?
[17:45] <kklimonda> I don't know how to open gnome-session dialog :)
[17:45] <chrisccoulson> "gnome-session-save --shutdown-dialog"
[17:46] <james_w> hey chrisccoulson
[17:46] <james_w> how are you?
[17:46] <kklimonda> chrisccoulson: that works fine :)
[17:46] <chrisccoulson> hey james_w - yeah, i'm good thanks
[17:46] <chrisccoulson> how are you?
[17:46] <kklimonda> chrisccoulson: but this dialog doesn't show to anyone :D
[17:46] <chrisccoulson> kklimonda - \o/
[17:46] <james_w> glad to hear it, I'm good too thanks
[17:47] <james_w> chrisccoulson: are you a father yet?
[17:47] <chrisccoulson> james_w - i am :)
[17:47] <james_w> congratulations! :-)
[17:47] <chrisccoulson> whilst you were at UDS ;)
[17:47] <chrisccoulson> thanks:)
[17:47] <james_w> good job you didn't come then :-)
[17:47]  * james_w demands a picture 
[17:48] <chrisccoulson> i think I would have been quite unpopular if I'd gone to UDS ;)
[17:48] <chrisccoulson> yeah, i'll host some pictures somewhere soon
[17:48] <james_w> next time, and you can bring them
[17:48] <chrisccoulson> i'm not sure where to host them yet though
[17:49] <halfline> chrisccoulson: hey, i'm here now
[17:49] <chrisccoulson> james_w - if you're on facebook, then I have some on there
[17:49] <chrisccoulson> hey halfline
[17:49] <james_w> I am
[17:49] <halfline> chrisccoulson: hey
[17:50] <chrisccoulson> halfline - i haven't done any more testing with gnome-screensaver yet, but i forgot that i saved some data i got from xtrace when i was initially debugging it
[17:50] <chrisccoulson> and that sort-of shows what is going on :)
[17:51] <halfline> oh cool, could you attach it to bug?
[17:51] <chrisccoulson> halfline - i can, but i'll need to trim the interesting bits out first, as it's like 3MB in size ;)
[17:51] <halfline> well i don't mind a 3mb attachment as long as bugzilla doesn't mind :-)
[17:52] <chrisccoulson> halfline - the trace currently on the bug actually doesn't look like it's with --sync.
[17:52] <chrisccoulson> the BadDrawable is triggered from an earlier XCreatePixmap call
[17:52] <chrisccoulson> and xtrace shows the reason or this is the drawable passed to it was destroyed earlier on
[17:52] <halfline> chrisccoulson: hmm, the trace has to be with sync though if you look close
[17:52] <halfline> XFreePixmap doesn't normally force a round trip
[17:52] <halfline> and if you look at the top few frames of the trace
[17:52] <halfline> it shows it forcefully doing Sync
[17:53] <chrisccoulson> halfline - have you used xtrace before?
[17:54] <halfline> no.  i've used xscope before
[17:54] <halfline> i assuem it's the same sort of thing
[17:55] <chrisccoulson> i'm not sure. i quite like xtrace though, it's helped with quite a few issues like this :)
[17:55] <halfline> some intermediate man-in-the-middle x server that displays X traffic as it whizzes by
[18:00] <kklimonda> chrisccoulson: ok, I've found an error in T code so suspend inhibition works now - but only in gnome-session dialog :)
[18:00] <chrisccoulson> kklimonda - cool, that's expected
[18:00] <chrisccoulson> it should also inhibit automatic suspend in g-p-m too
[18:02] <kklimonda> chrisccoulson: is inhibiting the session being marked as idle going to stop screensaver from launching?
[18:02] <chrisccoulson> kklimonda - yes. transmission shouldn't need to do that though
[18:02] <chrisccoulson> it should only need the suspend inhibit
[18:02] <kklimonda> ok, thanks
[18:10] <pitti> seb128: hm, how important is it for you to get dbus 1.3.0?
[18:10] <pitti> seb128: most of our patches were applied after 1.3.0 release
[18:10] <pitti> so I'd need to rebase them against 1.3.0
[18:10] <seb128> pitti, not at all
[18:10] <pitti> but there are tons of changes upstream since 1.3.0 as well, so I'd rather wait for 1.3.1
[18:10] <pitti> ok, good
[18:10] <seb128> pitti, I was not even sure if 1.3 was an unstable serie
[18:10] <pitti> I'll upload my merge then
[18:10] <seb128> I'm rather looking at what hasn't been merged yet
[18:11] <seb128> pitti, thanks
[18:11] <Keybuk> pitti: I can handle worrying about that
[18:11] <Keybuk> since most of the patches are mine, and in 1.3.0 anyway
[18:11] <Keybuk> seb128: 1.3 is an unstable series
[18:12] <pitti> of the four ubuntu specific patches, two are applied in trunk, but zero in 1.3.0
[18:12] <pitti> 1.3.0 is actually pretty old already
[18:12] <seb128> is there a 1.4 schedule?
[18:12]  * pitti uploads the merge for now; it's tested and works
[18:12] <Keybuk> it's a "when it's ready" schedule ;)
[18:12] <Keybuk> pitti: really, which were the patches?
[18:12] <seb128> ie we might want to stay on 1.2
[18:13] <pitti> 82_link-order.patch, 11_timeout_handling.patch
[18:14] <chrisccoulson> halfline - i added the xtrace log to the bug report now, and also my analysis which I used to come to my original conclusion
[18:14] <pitti> argh, 82_link-order doesn't even apply to current debian version
[18:14] <chrisccoulson> but you probably know GDK internals much better than me, so what I found might still be wrong :)
[18:14] <Keybuk> 82_link-order should be in GIT
[18:14] <Keybuk> timeout handling is in GIT
[18:14] <Keybuk> http://cgit.freedesktop.org/dbus/dbus/commit/?id=03cc20707a3e7b2d8629e84d7a766f41edb8b444
[18:15] <pitti> Keybuk: yes, as I said
[18:15] <pitti> but they aren't in 1.3.0
[18:15] <Keybuk> yeah 1.3.0 is old at this point ;)
[18:15] <artir> how are those RGBA/CSD patches going ? :)
[18:16] <pitti> ah, it's because Debian applied it under a different name
[18:16] <Keybuk> http://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.2&id=be89ffacc9051238d9b99b1b3e4fa5f67a9c7f5f
[18:17] <Keybuk> that's the GIT commit for the link order patch
[18:17] <Keybuk> doesn't seem to be in master, just dbus-1.2
[18:19] <pitti> it's ~ 90% applied
[18:19] <pitti> some hunks were missing apparently
[18:19] <kklimonda> chrisccoulson: is the fact that indicator applet "bypasses" inhibition purposeful?
[18:20] <chrisccoulson> kklimonda - the issue is that the functionality is not really exported by gnome-session in a way that other applications can use
[18:20] <chrisccoulson> ie, displaying the inhibit dialog is internal to gnome-session
[18:21] <kklimonda> I see
[18:23] <mclasen> chrisccoulson: thats by design though, its not a dialog that other applications are supposed to 'use'
[18:24] <chrisccoulson> mclasen - yeah, i know. i was just explaining why our method of choosing suspend in ubuntu bypasses the suspend inhibits :)
[18:26] <kklimonda> but shouldn't it be somehow exposed to indicator applet as it replaces gnome-session shutdown dialog?
[18:27] <chrisccoulson> kklimonda - we already patch gnome-session to expose shutdown and reboot methods for this very purpose (for inidicator-session to use)
[18:27] <chrisccoulson> so perhaps we need to do something similar for suspend
[18:27] <chrisccoulson> that's perhaps something to ping tedg about though
[18:28] <chrisccoulson> but the current situation in ubuntu is somewhat sub-optimal
[18:37] <pitti> good night everyone, Taekwondo time!
[18:38] <chrisccoulson> good night pitti
[18:38] <ccheney> has anyone noticed that popcon seems to indicate the most installed version of ubuntu is gutsy (at least with popcon enabled) which is already past EOL
[18:38] <ccheney> that seems bad
[18:39] <Amaranth> dang, I'm too late
[18:39] <ccheney> hmm maybe i am just reading the chart incorrectly
[18:39] <Amaranth> wanted to talk to mvo or seb128 about uploading a compiz package that splits the plugins into separate packages
[18:40] <ccheney> seems that the first field is ever installed not neccesarily still being used
[19:07] <rickspencer3> pitti, note that I've sent mail to get the UNE mini-sprint set up ...
[19:07] <rickspencer3> and I added an item to the team meeting agenda for information dispersal as well
[19:13] <chrisccoulson> heh, i subscribed to bug mail on some more gnome components today, and i'm getting lots more bug traffic now. i don't know how seb128 copes with it all!
[19:15] <kklimonda> chrisccoulson: he gets paid for that :)
[19:15] <chrisccoulson> yeah, but that doesn't make it any less impressive ;)
[19:15] <kklimonda> indeed
[19:15] <kklimonda> chrisccoulson: are you subscribed to desktop-bugs? :)
[19:16] <chrisccoulson> kklimonda - yes, but there's no mailing list for it ;)
[19:16] <chrisccoulson> so i have to subscribe to individual components
[19:18] <chrisccoulson> right, dinner time
[19:31] <kklimonda> chrisccoulson: can I use 1.80~1-0ubuntu1 as a version string instead of 1.80~b1-0ubuntu1 ?
[19:31] <kklimonda> I don't really want to change debian/watch file :)
[21:07] <chrisccoulson> hmmm, LP is going slow for me tonight
[21:09] <kklimonda> chrisccoulson: I've linked branch with T 1.80b1 to bug 460620 if you want to take a look at it
[21:10] <chrisccoulson> kklimonda - thanks, i will take a look at that shortly
[21:11] <chrisccoulson> i've just got to get all my work stuff ready, and then it's ubuntu all evening :)
[21:18] <chrisccoulson> hello robert_ancell
[21:19] <robert_ancell> chrisccoulson, hey
[21:19] <chrisccoulson> how are you?
[21:21] <robert_ancell> good.  just got a netbook to play with :)
[21:21] <chrisccoulson> fantastic!
[21:21] <chrisccoulson> i really want a netbook :)
[21:33] <halfline> chrisccoulson: ugh
[21:34] <halfline> chrisccoulson: you might want to change your password
[21:34] <halfline> i'm going through the trace now and i'm noticing all the key events...
[21:35] <halfline> ohhh unless you only did gibberish
[21:35] <halfline> then you're okay :-)
[21:35] <chrisccoulson> halfline - good spot ;)
[21:35] <chrisccoulson> i'll have a look at it again just to make sure
[21:41] <chrisccoulson> halfline - it's just gibberish. it doesn't look like i ever unlocked the screen successfully on that run
[21:42] <halfline> okay good
[21:42] <chrisccoulson> but thanks for pointing that out
[21:55] <seb128> hey robert_ancell
[21:56] <robert_ancell> seb128, hey
[21:56] <seb128> robert_ancell, thanks for the help on merges you rock
[21:56] <robert_ancell> seb128, no prob, slowly chipping away at them :)
[21:57] <robert_ancell> seb128, hey, do you know what the future of yelp is, are we picking up the debian "webkit" version?
[21:57] <chrisccoulson> robert_ancell - just so you know, i started g-s-t and liboobs last night
[21:57] <seb128> you seem to forget to use replaces easily though, but that's a detail ;-)
[21:57] <chrisccoulson> i don't know if you already started them or not
[21:57] <robert_ancell> chrisccoulson, where are your bug reports!! :P
[21:58] <robert_ancell> seb128, yeah, I still don't quite "get" the whole replaces/conflicts :(
[21:58] <chrisccoulson> errrrrmmmm... :P
[21:58] <seb128> chrisccoulson, you should open workflow bugs or do a small changelog update in bzr
[21:58] <chrisccoulson> seb128 - yeah, i'll do that
[21:58] <chrisccoulson> i didn't so it straight away as i thought they'd be simple updates, but they're not ;)
[21:58] <seb128> robert_ancell, easy, when files were in an another binary and you move those you need a replaces
[21:58] <seb128> robert_ancell, you can add a conflict when the previous binary should be uninstalled
[21:59] <robert_ancell> seb128, ok
[21:59] <robert_ancell> someone should make apt/dpkg smarter - it should be able to work this out itself
[21:59] <chrisccoulson> robert_ancell - http://www.debian.org/doc/debian-policy/ch-relationships.html :)
[21:59] <seb128> you can start this debate ;-)
[21:59] <seb128> without me though
[21:59] <robert_ancell> hehe
[21:59] <chrisccoulson> lol
[22:00] <seb128> the people who did that decided that breaking is being on the safe side
[22:00] <seb128> otherwise you start overwritting other package content without noticing
[22:00] <seb128> and that's not always good either
[22:00] <kenvandine> seb128, i finished porting the patch for empathy and a little testing
[22:00] <seb128> kenvandine, oh, nice, thanks!
[22:00] <seb128> you rock too
[22:01] <kenvandine> i need to do the changelog still
[22:01] <kenvandine> it's long :)
[22:01] <robert_ancell> seb128, no I mean that apt knows what files are installed and what files are to be installed so it should automatically hold back packages that overwrite existing files until it can order the upgrade so no packages are installed with the same files at the same time
[22:01] <jcastro> kenvandine: is this the one that will let upstream stop hating us?
[22:01] <kenvandine> seb128, can you take a look at lp:~ken-vandine/empathy/ubuntu?
[22:01] <kenvandine> yes
[22:01] <seb128> kenvandine, don't bother to summarize changes
[22:01] <seb128> robert_ancell, ah right
[22:01] <kenvandine> seb128, can you take a look at that branch and see if i did the Replaces right?
[22:01] <seb128> kenvandine, ok
[22:01] <kenvandine> seb128, basically this version removes libempathy*
[22:02] <kenvandine> so only two packages are empathy and empathy-doc
[22:02] <seb128> kenvandine, you didn't rebase on Debian?
[22:02] <seb128> kenvandine, they did those changes already...
[22:02] <kenvandine> ah
[22:02] <kenvandine> damn... i should have done that :)
[22:02] <seb128> I told you when I pinged to use their work as a basis it's easier
[22:02] <kenvandine> i will make sure it is the same
[22:02] <seb128> thanks
[22:02] <kenvandine> yeah... i remember now
[22:02] <seb128> sorry for the extra work
[22:02] <kenvandine> not much work
[22:03] <kenvandine> the patch was the real work :)
[22:03] <seb128> good ;-)
[22:03] <seb128> right, that's what I figured
[22:03] <kenvandine> they renamed headers and stuff :)
[22:03] <kenvandine> ok, i'll just upload after comparing it to debian
[22:03] <kenvandine> later tonight or first thing in the AM
[22:04] <seb128> ok thanks!
[22:04] <seb128> the versions list starts looking good again
[22:04]  * kenvandine runs for a bit... bbiab
[22:08] <robert_ancell> seb128, ^^^ yelp?
[22:09] <seb128> ups I skipped this one
[22:09] <seb128> dunno what the deal is there
[22:09] <seb128> I think upstream delayed due to accessibility support
[22:09] <robert_ancell> ok
[22:10] <seb128> could be ready this cycle
[22:10] <seb128> did you try the Debian version?
[22:10] <robert_ancell> does yelp run _really_ slow for you?
[22:10] <seb128> is there any difference in speed or rendering?
[22:10] <robert_ancell> no, didn't look at it, was going to see if you guys knew
[22:10] <robert_ancell> my yelp on my lucid box takes at least 5 seconds to start
[22:10] <seb128> I don't use often
[22:10] <seb128> but I did some random desktop testing before hardy and it was taking some 15 seconds to open sometime
[22:11] <Amaranth> yay I can't build compiz anymore
[22:11]  * Amaranth pokes at KDE
[22:11] <jcastro> Amaranth: happy birthday!
[22:11] <seb128> robert_ancell, I would say to check with TheMuso when he will be around
[22:11] <Amaranth> seb128: I've got a compiz package that splits the plugins into separate packages
[22:12] <Amaranth> jcastro: thanks
[22:12] <robert_ancell> seb128, I hope that's going to be fixed... It looks really unprofessional (and it's the new users who are going to notice it the most)
[22:12] <robert_ancell> seb128, ok, will do
[22:12] <seb128> Amaranth, oh nice, how many of those are installed or not installed by default?
[22:12] <seb128> robert_ancell, you might want to try to debian version they use webkit
[22:12] <seb128> if it starts faster maybe go for it in lucid
[22:12] <seb128> we can roll back later if required
[22:13] <robert_ancell> seb128, ok, will look at that if I have time
[22:13] <seb128> thanks
[22:13] <robert_ancell> seb128, I got a dell mini to install today :)
[22:13] <seb128> nice
[22:13] <seb128> it's for working on boot speed?
[22:13] <Amaranth> 29 plugin packages, 15 installed by default
[22:13] <Amaranth> seb128: ^
[22:14] <johanbr> I thought yelp upstream decided not to switch to webkit yet because of the a11y issues?
[22:14] <seb128> Amaranth, did you discuss that with mvo?
[22:14] <seb128> johanbr, what I wrote before
[22:14] <Amaranth> nope, haven't seen him today
[22:14] <seb128> johanbr, but I expect they will sort that this cycle or next since they want to use it for GNOME3
[22:14] <seb128> johanbr, they get closer every cycle
[22:14] <robert_ancell> seb128, yes
[22:14] <johanbr> ahh, okay
[22:15] <seb128> robert_ancell, excellent ;-)
[22:15] <seb128> robert_ancell, we figured most of the bootchart issues, now we are down to making gnome-panel and nautilus efficient
[22:15] <seb128> and compiz
[22:15] <seb128> other slow spots are gconf loading which chrisccoulson was looking at
[22:15] <robert_ancell> seb128, cool, at this rate i'll only have to backport changes!
[22:15] <seb128> and the xrandr g-s-d code
[22:16] <seb128> robert_ancell, you with, but no
[22:16] <seb128> we are down to 11 seconds now
[22:16] <seb128> that's desktop login
[22:16] <seb128> once we clean the extra delay we will have some 9.5 seconds
[22:16] <seb128> without compiz you can say it's a bit under 8 seconds
[22:17] <seb128> then it's the fun part with nautilus and gnome-panel
[22:17] <seb128> gnome-panel is acting weird in any case
[22:17] <seb128> the bootcharts show activity, nothing for some seconds, activity
[22:17] <seb128> I'm wondering what the nothing is
[22:18] <Amaranth> I hope I can at least get compiz down to 0.5 second difference
[22:18] <seb128>  
[22:18] <Amaranth> instead of 1.5
[22:18] <seb128> Amaranth, could you hold those compiz changes for a day?
[22:18] <Amaranth> sure
[22:18] <seb128> thanks
[22:18] <Amaranth> I can't do another test build right now away, KDE is broken
[22:18] <seb128> I want to discuss that with other distro team guys
[22:19] <seb128> maybe during the meeting tomorrow
[22:19] <seb128> I don't like having too many binaries it's mostly confusing users and making apt slower
[22:19] <seb128> but I want to collect opinions from other people
[22:19] <seb128> we should split for sure default options and extra ones...
[22:20] <seb128> not sure if we should have that many binaries
[22:20] <Amaranth> I'm actually tempted to just toss out half the plugins we don't want to install anyway
[22:21] <seb128> if those are buggy and create issues rather than are useful go for it
[22:22] <Amaranth> well, some of them are replaced by plugins in the compiz-fusion packages
[22:24] <seb128> we should do a good cleaning for the lts anyway
[22:24] <seb128> too many options just confuse users
[22:24] <seb128> and buggy ones don't deserve anybody
[22:25] <seb128> users trying those don't get a good experience and we are flooded in bugs for buggy options
[22:25] <Amaranth> I've been tempted several times to just drop everything we don't use
[22:26] <seb128> let's drop the things we think no users are really using and those too buggy
[22:26] <Amaranth> yeah, I plan to clean out a lot of options too
[22:26] <seb128> will benefit user experience and bug load
[22:26] <seb128> you rock ;-)
[22:26] <Amaranth> All I have to do is patch out the code from the xml files and it'll be effectively gone
[22:27] <Amaranth> s/code/option/
[22:33] <chrisccoulson> hey seb128 - i had a bit more of a look at gconf and g-s-d delays over the weekend
[22:34] <chrisccoulson> the g-s-d plugins already defer work they don't need to do straight away, so that the rest of the session can start
[22:34] <chrisccoulson> although there's probably scope for optimising the work they do
[22:35] <chrisccoulson> but i don't know how to avoid this gconf delay, as most of the g-s-d plugins need to access gconf anyway (eg, xsettings and fonts)
[22:37] <seb128> robert_ancell, I pushed a small hack to versions which let define a list of source watching GNOME 2.28
[22:37] <robert_ancell> seb128, cool
[22:37] <seb128> I just did it for GNOME because that was easy
[22:37] <seb128> I don't want to start hacking the regexps logic for other things ;-)
[22:38] <seb128> chrisccoulson, hum
[22:38] <seb128> chrisccoulson, what takes the 0.5 second, gconf init or the preloading g-s-d does?
[22:39] <robert_ancell> seb128, heh, it will make the page more green
[22:39] <chrisccoulson> there will be a 0.5 second delay when gconfd parses the default keys
[22:39] <chrisccoulson> that's unavoidable at the moment, but i was hoping we could just defer that delay to a stage where it wouldn't matter so much
[22:40] <chrisccoulson> but that's proving difficult
[22:44] <seb128> ok
[22:47] <chrisccoulson> seb128 - it's a difficult one really. whilst we could probably put the keys that are needed early in the session in to their own smaller tree, the 0.5 second delay will still have to happen at some point in the session. and whilst gconfd is parsing that xml file, any application needing values from gconf will block :(
[22:47] <seb128> robert_ancell, in fact the yelp versions play well with us, we could do the 2.28.0 to 2.28.0+webkit update in lucid
[22:47] <seb128> and then we can update to 2.28.1 later using the backend we want
[22:48] <seb128> chrisccoulson, I'm wondering if we could have the xrandr and gconf delay in parallel
[22:48] <seb128> 0.5 seconds is not end of the world
[22:49] <chrisccoulson> seb128 - we could possibly do that, as xrandr doesn't need gconf
[22:49] <robert_ancell> seb128, it would be good to try webkit for a2 and see how it goes
[22:49] <chrisccoulson> the only issue is that g-s-d needs gconf before it loads any plugins
[22:49] <chrisccoulson> so we'd maybe need to hack g-s-d to hard code the xrandr plugin
[22:49] <seb128> robert_ancell, if you push it today we can try for a1
[22:49] <robert_ancell> seb128, ok, will do
[22:50] <seb128> chrisccoulson, I would be fine with that...
[22:50] <seb128> robert_ancell, thanks ;-)
[22:50] <chrisccoulson> seb128 - i'll look in to doing that then
[22:50] <seb128> chrisccoulson, thanks
[22:50] <chrisccoulson> it will also depend on my gconf-less gnome-session too
[22:51] <dobey> anyone around that can do a couple uploads for lucid? :)
[22:52] <seb128> dobey, which ones do you need?
[22:52] <dobey> seb128: am filing the bugs right this second. just did ubuntuone-storage-protocol and ubuntuone-client releases for lucid
[22:53] <seb128> dobey, ok, I can do that
[22:53] <dobey> seb128: bug #493806 is the first one
[22:55] <dobey> seb128: and bug #493807 is ubuntuone-client
[22:55] <dobey> seb128: thanks so much! :)
[22:56] <seb128> you're welcome
[22:57] <chrisccoulson> pitti - you might be interested in bug 493788 :)
[22:57] <chrisccoulson> seems related to the gnome-menus change
[23:07] <seb128> dobey, you don't need to nominate new version sponsoring request for lucid so early
[23:08] <dobey> seb128: ok. i just wanted to make it clearer in the bug report that it was for lucid
[23:08] <seb128> by default anything open is for lucid
[23:08] <dobey> ok
[23:08] <dobey> thanks
[23:09] <seb128> the nominations are to keep track of things we should fix for lucid
[23:09] <seb128> but that one will be fixed quickly enough so no need to put it on the tracker
[23:09] <seb128> you're welcome
[23:10] <chrisccoulson> halfline - did my analysis of the gnome-screensaver issue sort-of make sense?
[23:29] <dpic> rickspencer3: sorry about adding the solang item to the wrong part of the blueprint
[23:29] <rickspencer3> dpic, no worries at all
[23:29] <rickspencer3> I hope I didn't sound snitty in my response
[23:29] <dpic> no not at all
[23:30] <rickspencer3> I think I just moved it to later in the release
[23:30] <dpic> did it say the "edit" button item was added by me? in the email it said i added it but that wasn't me...
[23:37] <rickspencer3> dpic, I dunno, it was prolly just lp craziness
[23:37] <dpic> mm, yeah
[23:37] <rickspencer3> also, it could have been someone else at a similar time moving it back and lp just did it's best to cope
[23:37] <dpic> so how do i raise a discussion about solang?
[23:37] <rickspencer3> well, your timing is not ideal for Lucid, obviously
[23:37] <rickspencer3> but it's probably not horrible either
[23:38] <dpic> and making the change for Lucid +1 is still possible
[23:38] <rickspencer3> you could send an email to ubuntu-desktop list with the proposal
[23:38] <rickspencer3> do you think it would be good for Lucid?
[23:38] <dpic> how formal should the proposal be?
[23:42] <dpic> rickspencer3: is there any proposal template i should use, or just bring it up casually?
[23:42] <rickspencer3> dpic, it depend
[23:42] <rickspencer3> s
[23:43] <rickspencer3> if you think it would be good for Lucid, you should probably make a pretty strong case about how it meets the needs outlined in the UDS session on app selection
[23:43] <rickspencer3> if you are truly shooing for Lucid +1, it's really a UDS issue
[23:43] <rickspencer3> so I would be casual and start getting people to use it, but then write a pretty hard core blueprint at the end of the Lucid cycle
[23:44] <dpic> hm, well i don't see any reason to not try getting it in for lucid
[23:44] <dpic> where are these needs outlined?
[23:54] <dpic> rickspencer3: i can't seem to find what needs you're referring to
[23:55] <rickspencer3> well, we discussed at UDS in depth regarding photos
[23:55] <rickspencer3> we need:
[23:55] <rickspencer3> 1. typical photo management software (f-spot fits bill nicely, as do others)
[23:56] <rickspencer3> 2. Ability to view an image in a fast way, without importing it (eog does this today)
[23:56] <rickspencer3> 3. Ability to rotate an image without importing it (eog does this today)
[23:56] <rickspencer3> 4. red eye removal without importing (gimp does this today)
[23:56] <rickspencer3> 5. ability to crop without importing (gimp does this today)
[23:57] <rickspencer3> other things that would be nice to do without importing are
[23:57] <rickspencer3> 6. annotating (like making lolcat)
[23:57] <rickspencer3> 7. painting on it
[23:58] <rickspencer3> today we use gimp for 4-7, but gimp is a professional tool, not well suited for most people to do these tasks
[23:58] <rickspencer3> current POR is to juice up f-spot a bit to take care of 4-5, and possibly also can do some filters and other nice filters and stuff
[23:58] <dpic> rickspencer3: what room did the app selection discussion take place in?
[23:59] <rickspencer3> I forget
[23:59] <rickspencer3> but it's the most viewed session by far on youtube
[23:59] <rickspencer3> many folks weren't too happy that we are going to remove the gimp from the default install, though in general the consensus from the community was that we are doing the right thing
[23:59] <rickspencer3> as it's an easy matter for folks who want it to install the gimp