[00:07] <eeejay> is it too late to propose banshee for lucid?
[00:09] <rickspencer3> eeejay, very funny
[00:09] <eeejay> rickspencer3, obviously i am completely out of touch
[00:10] <rickspencer3> eeejay, sorry man
[00:10] <rickspencer3> we covered that in some depth at UDS
[00:10] <eeejay> rickspencer3, ah, gotcha. and the verdict was no?
[00:10] <rickspencer3> right
[00:10] <rickspencer3> sticking with rhythm box for at least one more release
[00:11]  * eeejay is searching for meeting notes
[00:11] <rickspencer3> actually, now that I think about it ... we didn't really cover it there
[00:11] <rickspencer3> heh
[00:11] <rickspencer3> I think we decided before we left, and only touched on it at the application selection meeting and the music store meeting
[00:11] <rickspencer3> eeejay, why would you like banshee as the default music player?
[00:12] <dtchen> speaking of which, are the major "desktop decisions" from UDS-L coalesced somewhere?
[00:12] <eeejay> rickspencer3, i remember the major blocker being a11y. imho banshee has better a11y than rythmbox at this point.
[00:13] <rickspencer3> dtchen, http://theravingrick.blogspot.com/
[00:13] <rickspencer3> of course, the real place to look is here:
[00:13] <rickspencer3> http://piware.de/workitems/desktop/lucid/report.html
[00:13] <eeejay> + it is really hard to spell rhythmbox
[00:14] <rickspencer3> eeejay, well ... we're getting very mixed feedback about Banshee from current users, and also mixed messages about the roadmap
[00:14] <rickspencer3> so for LTS, it was best to stick with rhythmbox
[00:14] <eeejay> rickspencer3, ah, gotcha.
[00:16] <eeejay> rickspencer3, anyway, a11y should not be a concern on banshee anymore in lucid+1, if users are repulsed by it, it's a different issue
[00:16] <rickspencer3> yeah thanks to you
[00:16] <rickspencer3> accessibility was certainly one key blocker
[00:17] <rickspencer3> eeejay,  "repulsed" might be a bit harsh
[00:17] <rickspencer3> ;)
[00:17] <dtchen> rickspencer3: thanks
[00:17] <rickspencer3> dtchen, do you have any specific questions I can try to answer?
[00:17] <dtchen> dtchen: not yet; I'll ping if/when I do.
[00:18] <dtchen> err, rickspencer3 ^^
[00:18] <rickspencer3> dtchen, sounds good
[00:18] <rickspencer3> though I will be dropping offline for the evening soon
[00:18] <rickspencer3> you can always catch up with me tomorrow, or email me
[00:19] <dtchen> right, e-mail is best for me, too
[00:22] <rickspencer3> dtchen, rick.spencer@canonical.com
[01:27] <chrisccoulson> Amaranth - does compiz need to read anything from GConf before it registers with the session manager?
[01:29] <Amaranth> chrisccoulson: not that I can tell, no
[01:29] <Amaranth> chrisccoulson: although it's pretty much one right after another
[01:30] <chrisccoulson> Amaranth - thanks
[06:49] <didrocks> morning! I'll be away all this week as I'm giving my last ubuntu training session for companies :)
[07:27] <baptistemm> hello
[07:47] <pitti> Good morning
[07:50] <fagan> morning
[07:58] <pitti> bryce: thanks for the X requirements mail
[08:04] <pitti> tseliot: I am an upstream udev committer :)
[08:05] <tseliot> pitti: aah, so you accepted your own commit :-)
[08:05] <pitti> tseliot: well, I did discuss it with Kay first
[08:06] <tseliot> of course, that's the way it works, unless there's only 1 maintainer
[08:06] <tseliot> is it just me or is the wiki down today?
[08:07] <pitti> for bryce and me, too
[08:07] <tseliot> :-/
[08:09] <jmarsden> Seems to be back up now, for me at least.  I've not tried editing anything yet though...
[08:10] <jmarsden> Came back up about 40 minutes ago.
[08:15] <tseliot> it's still down for me
[08:15] <baptistemm> hi pitti tseliot and others
[08:16] <tseliot> hi baptistemm
[08:16] <baptistemm> whi is usually "responsible" of fontconfig, I did a packaging of 2
[08:17] <baptistemm> ... 2.8.0 and ported the big patch inside, but I hardly understand how it works, so I would like a review
[08:19] <tseliot> baptistemm: maybe asac knows
[08:30] <baptistemm> pitti, https://bugs.edge.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/444704 does it sound a valid bug for you?
[08:30] <baptistemm> is it permitted to introduce new dependency in stable release?
[08:39] <pitti> it's not a bug I'd fix in a stable release
[08:39] <pitti> hm, I thought we'd install it by default even
[08:39]  * pitti reassigns to dk-disks
[09:17] <glatzor> hello mvo
[09:17] <mvo> hey glatzor!
[09:18] <glatzor> mvo, do you already have got any plany regarding the mime type handlers i software center?
[09:19] <mvo> glatzor: not yet - why?
[09:19] <mvo> glatzor: isn't that something that the session thing is doing?
[09:19] <mvo> or could be doing?
[09:19] <glatzor> mvo, because I would like to query the data in sessioninstaller :)
[09:19] <mvo> glatzor: it should be easy to do with s-c
[09:19] <mvo> the data is in the xapian-db
[09:21] <glatzor> mvo,  in the long run it seems to make sense to merge sessioninstaller with software-center to share the widgets
[09:21]  * mvo nods
[09:21] <glatzor> and the same data :)
[09:23] <seb128> hey glatzor mvo!
[09:23] <glatzor> morning seb128 !
[09:30] <seb128> hum, who is this guy who assign random bugs to the canonical desktop team now?
[09:32] <mvo> glatzor: agreed, I will see if I can work on this today, it should be relatively straightforward
[09:32] <mvo> xapian ftw!
[09:33] <pitti> hey seb128
[09:35] <seb128_> re
[09:35] <seb128_> dsl ip change
[09:35] <seb128_> I was saying, who is this guy assigning random bugs to canonical desktop team now?
[09:36] <pitti> seb128_: I just fixed those, BTW
[09:37] <seb128_> pitti, thanks, I fixed some too and I noticed you changed some others already
[09:39] <pitti> who is that guy who merges poppler and screws up the versio number?
[09:39]  * pitti hugs seb128
[09:40] <seb128_> ups
[09:40]  * seb128_ hugs pitti
[09:41] <seb128_> I think I did dch -i, then the new version update and forgot to change the revision
[09:41] <seb128_> in any case good we don't want the debian version
[09:41] <pitti> we do now
[09:41] <pitti> they reverted the ABI change
[09:41] <seb128_> they did revert upstream changes which I'm not sure is the way to go
[09:41] <pitti> and we don't really want a different API/ABI than Debian
[09:41] <seb128_> well, was the abi change on purpose?
[09:41] <pitti> well, we'd have to fork all packages which use libpoppler-dev
[09:42] <seb128_> we don't want a different api,abi than upstream
[09:42] <pitti> they will currently FTBFS
[09:42] <vegetto71> hello?
[09:42] <seb128_> Debian is being ridiculous there
[09:42] <seb128_> if the abi change was wanted upstream unstable is the right place to deal with it
[09:42] <seb128_> playing undo upstream change is of no use
[09:43] <seb128_> I don't want to keep distro patching upstream apis away
[09:43] <pitti> hm, they rejected the bug reports
[09:43] <pitti> grrr
[09:43] <pitti> this is hilarious
[09:43] <seb128_> I told you that yesterday
[09:43]  * pitti goes to add a "if building on Ubuntu, use this poppler API, else use that" patch to cups then
[09:43] <seb128_> libpoppler has no stable abi
[09:44] <seb128_> what is the upstream bug for reference?
[09:44] <pitti> https://bugs.freedesktop.org/show_bug.cgi?id=25344 https://bugs.freedesktop.org/show_bug.cgi?id=25363
[09:46] <seb128_> pitti, right, typical reaction from them there
[09:46] <seb128_> they don't want to give garanty for libpoppler abi
[09:46] <seb128_> customer applications should be using the glib bindings
[09:46] <seb128_> I agree it's an issue
[09:47] <seb128_> but what Josselin is doing is not useful either
[09:47] <seb128_> in Debian unstable they could as well go over and fix the few applications using it
[09:47] <seb128_> rather than patching away upstream changes
[09:47] <seb128_> they will have to catch up with upstream at some point anyway
[09:47]  * pitti pokes joss to revert the change then
[09:48] <seb128_> I doubt Debian wants to divert from upstream there
[09:49] <baptistemm> salut seb128_
[09:50] <seb128_> lut baptistemm
[09:50] <baptistemm> I did some packaging yesterday
[09:52] <seb128_> I noticed
[09:52] <seb128_> thanks but for stable updates you need extra steps, like adding a debdiff to the bug, giving justifications on why we need the update, etc
[09:53] <baptistemm> seb128_, nautilus packaging is buggy, there is a leftover from a patch i was working on
[09:53] <seb128_> baptistemm, what is buggy?
[09:53] <baptistemm> okay, I'll the remaining steps tonight
[09:53] <seb128_> you worked from a local checkout which had your changes?
[09:53] <baptistemm> s/is buggy/doesn't compile/
[09:53] <baptistemm> no this is a debian patch I was working on
[09:54] <baptistemm> to integrate in my ppa to test to UI thing
[09:54] <seb128_> that change is not in the ubuntu version
[09:54] <seb128_> you probably used a locally modified source to base your work
[09:55] <baptistemm> no but it remains listes in debian/patches/series
[09:55] <seb128_> get a fresh source from the mirror
[09:56] <seb128_> the change is not coming from the ubuntu version
[09:56] <seb128_> ou are working on a locally modified version
[10:00] <baptistemm> at least one can review fontconfig 2.8.0 which targets lucid :)
[10:01] <baptistemm> I'm not happy with this big patch lying in the packaging
[10:01] <baptistemm> it is a pain in the *ss to update
[10:02] <seb128_> baptistemm, nobody likes having distro changes
[10:02] <seb128_> but when we have some often that's for a reason
[10:05] <baptistemm> my complain is not about having distro patch but rather 1) this one is rather hard to update, and 2) I don't understand what it does but of lack of comments in the patch
[10:05] <baptistemm> but my fontconfig fu is low
[10:13] <mac_v> pitti: seb128_: i think lightbreeze is assigning the bugs to canonical desktop since it is mentioned here.. > https://wiki.ubuntu.com/OneHundredPaperCuts#Patched%20Paper%20Cut%20Pipeline
[10:13] <mac_v> but i'm still not sure how assigns or who is supposed to them though ;)
[10:13] <mac_v> s/how/who
[10:14]  * pitti holds up his plate "work with upstream"
[10:14] <pitti> just dumping them on the desktop team's feet won't help anyone
[10:14] <seb128_> especially not this cycle
[10:14] <seb128_> ETOOMUCHTODO
[10:14] <pitti> it's not how FOSS works (or the desktop team's job either)
[10:14] <seb128_> I'm happy to help where I can
[10:15] <seb128_> but there is just too much to do right now
[10:19]  * mac_v feels there isnt a proper plan to actually fix bugs in the papercuts :/  , but rather everything has just been improperly hypothesized 
[10:22] <seb128_> mac_v, it's clear bugs don't get automagically fixed just because somebody decided to nominate those as hundredpapercut
[10:22] <seb128_> it still help to build a list of usuability issues which would be nice to fix
[10:24] <mac_v> seb128_: yeah , there is a big misunderstanding that the papercuts is actually a super squad to fix all the bugs , but folks dont know that only the suggestions are being make in hopes someone comes and fixes them ;)
[10:25] <mac_v> made*
[10:25] <seb128_> would be nice to fix that perception, it would perhaps stop people to nominate any bug as hundredpapercut because they figure that's what will make this bug open for 5 years fixed now
[10:31] <mac_v> ex: > Bug #488129 :/
[10:36] <baptistemm> seb128_, do you I pick git patches from 2-28 for gvfs and nautilus for the packaging update?
[10:37] <seb128_> baptistemm, I get patches where they are, git, bugzilla, etc
[10:37] <seb128_> why?
[10:37] <baptistemm> +want
[10:40] <seb128_> I don't understand the question
[10:40] <seb128_> "do you I"
[10:41] <seb128_> is the question what I do?
[10:41] <seb128_> or what you should do?
[10:42] <baptistemm> do you want I pick up git patches from 2-28 for gvfs and nautilus for the packaging update, I seen alex commited various fixes
[10:43] <baptistemm> dor do you prefer I just stick to latest releases, and we'll put patches later.
[10:43] <seb128_> depends of what those changes fix
[10:43] <seb128_> to be honest I'm not sure those updates will be accepted in karmic sru
[10:43] <seb128_> do they fix any really annoying issue?
[10:43] <seb128_> which is open on launchpad
[10:44] <seb128_> we don't want to waste too much efforts on stable update now
[10:44] <seb128_> we only want to fix issues annoying ubuntu users
[11:47] <mac_v> mpt: hi.. do you have a list of how the IM clients use the label for the "invisible" status?  empathy uses "hidden" but the gmail , yahoo and aol all use "invisible" , so does indicator applet... empathy being the odd one out , the empathy folks are willing to change it , they just want to know how others are named...
[11:48] <mac_v> i'v seen an article of several IM clients being compared but dont recall where :(
[11:48] <Ng> does anyone use those things? ;)
[11:48] <mac_v> lol ;)
[11:48] <Ng> (I'm a very light IM user, I've literally never forced my status)
[11:48] <mpt> mac_v, http://www.szetopia.com/im-presence
[11:49] <Ng> I'd go for "Automatic" and "Privacy" :)
[11:49] <mac_v> mpt: awesome , thats the one [i think]... thanks :)
[11:51] <mac_v> yup , thats the one i was looking for
[12:20] <chrisccoulson> good afternoon everyone
[12:20] <seb128_> hello chrisccoulson!
[12:20] <chrisccoulson> hey seb128_, how are you?
[12:21] <seb128> good! you?
[12:21] <seb128> mvo, the dist-upgrader acts weird on lucid, it wants to clean build-essential, gettext, g++
[12:21] <seb128> and lot of other things
[12:21] <chrisccoulson> seb128 - yeah, not too bad thanks. i've just got back from town
[12:21] <chrisccoulson> so, time to make some coffee :)
[12:21] <seb128> I just got coffee too ;-)
[12:22] <seb128> I'm about to do my daily bootcharts
[12:22] <chrisccoulson> excellent :)
[12:23] <chrisccoulson> i'm going to have a look at gconf in a bit and try and figure out a way of avoiding that 500ms delay you see at the start of your session
[12:23] <seb128> I will try to spend some time on merges and updates too today
[12:23] <seb128> we are lagging being there
[12:23] <seb128> chrisccoulson, that would rock ;-)
[12:23] <chrisccoulson> yeah, i've not done much work on merges recently :(
[12:23] <chrisccoulson> i should do some ;)
[12:23] <seb128> don't worry about those
[12:23] <seb128> better to tackle login speed issues
[12:23] <seb128> we have time for updates and merges
[12:24] <seb128> we can wait for less buggy versions rather than jumping on early unstable
[12:24] <chrisccoulson> yeah, that sounds like a good plan
[12:29] <mvo> seb128: I have a look
[12:37] <seb128> mvo, I'm not sure why those were installed in fact, are they part of the default install?
[12:43] <mvo> seb128: I think we have it for dkms
[12:44] <seb128> mvo, don't bother with that, that's probably not something worth looking at in early lucid
[12:44] <seb128> not sure why I mentioned it ;-)
[13:06] <seb128> is anybody else getting screen dimming too quickly in lucid?
[13:07] <seb128> ie being cut after like 1 minute inactivity
[13:14] <fagan> seb128: yep I got that too
[13:14] <seb128> got? you fixed it?
[13:14] <fagan> nope just put up with it
[13:15] <fagan> I wouldnt know how to fix it :)
[13:27] <seb128> vuntz, hey
[13:28] <seb128> vuntz, how would you make a .desktop hidden by default from a sysadmin perspective (ie not editing the package entry)
[13:35] <seb128> Amaranth, ^
[13:41] <vuntz> seb128: what do you mean exactly?
[13:41] <seb128> vuntz, let's say I'm a sysadmin and I don't want gedit in the menu
[13:41] <seb128> what should I do, which is not editing the .desktop or .menu
[13:42] <seb128> since those will be replaced on upgrade
[13:42] <vuntz> no good way right now, I guess
[13:44] <seb128> installing a .desktop in /usr/local will not take over the /usr one right?
[13:44] <pitti> perhaps copying it into /etc/xdg/menus/ ?
[13:44] <pitti> oh
[13:45] <seb128> my best reply now is to dpkg-divert the ubuntu desktop
[13:45] <mclasen> vuntz: add an exclude into a menu file in applications-merged/ ?
[13:47] <vuntz> mclasen: ah, indeed
[13:47]  * vuntz never tried this
[13:48] <seb128> what format should that one have?
[13:52] <seb128> vuntz, hum, /usr/local/share/applications entry do overwrite /usr ones for the settings categories
[13:52] <seb128> do you know if that's wanted?
[13:52] <seb128> like if you try display-properties
[13:52] <seb128> settings = system, preferences
[13:56] <vuntz> seb128: "If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used."
[13:57] <seb128> vuntz, well, should it overwrite those?
[13:57] <seb128> like if there is a gedit.desktop is both
[13:57] <seb128> should that be 2 entries or should it take only the first one?
[13:57] <seb128> and why does it work differently for the application menu and the system one
[14:01] <vuntz> seb128: if they have the same name, /usr/local/share should win, yes
[14:01] <vuntz> and it should work the same way
[14:01] <seb128> ok thanks
[14:02] <seb128> vuntz, ok thanks, I figured what was wrong
[14:02] <seb128> there was a gedit.desktop in my user dir
[14:03] <chrisccoulson> hello vuntz
[14:04] <chrisccoulson> gnome-settings-daemon-helper is only useful if you're running GTK1 applications isn't it?
[14:05] <vuntz> chrisccoulson: I believe, yes
[14:05] <seb128> vuntz, oh btw I know where GUADEC is going to be now! ;-)
[14:05] <chrisccoulson> vuntz - awesome, we can remove it then :)
[14:05] <vuntz> seb128: it's a secret!
[14:05] <vuntz> chrisccoulson: what about not removing it and putting it another package?
[14:06] <chrisccoulson> vubtz - we could do, but we don't ship GTK1 anymore anyway
[14:06] <chrisccoulson> s/vubtz/vuntz
[14:06] <chrisccoulson> (stupid fingers)
[14:06] <seb128> chrisccoulson, use tab ;-)
[14:06] <seb128> there is only one v<tab> there
[14:06] <chrisccoulson> heh, that's handy :)
[14:07] <chrisccoulson> ah, theres 2 people if i type "se"
[14:07] <seb128> can't win everytime
[14:14] <pitti> chrisccoulson: does g-s-d-helper win us 2 seconds? :-)
[14:14] <chrisccoulson> pitti - unfortunately not :(
[14:14] <chrisccoulson> but it is cruft though ;)
[14:19] <mpt> mvo, hi, do you have a good algorithm for the de-duplication yet?
[14:20] <mvo> mpt: I have not done anything on this yet, the real challenge is making it fast
[14:21] <mpt> mvo, it seems like the sort of thing that could be calculated once whenever the repositories are changed/updated
[14:22] <mvo> mpt: possible
[14:27] <mpt> mvo, one complication is that if someone searches for "wesnoth-data", probably we should return that package, even though it's an integral part of Battle for Wesnoth
[14:27] <chrisccoulson> hmmm - "Various snmp software needs extracted MIBs from RFCs and IANA - which cannot be shipped - to be working as expected. Download and extract MIBs from RFCs and IANA?" Yes/No
[14:27] <chrisccoulson> ok :-/
[14:28] <mpt> chrisccoulson, please tell me that's not in a GUI
[14:28] <chrisccoulson> mpt - it's a debconf question i just encountered whilst upgrading
[14:28] <mvo> mpt: I think we only should de-duplicate if there is a application and a package with the same information "wesnoth" app and "wesnoth" package. if we are too agressive on the de-duplication that will confuse people
[14:28] <mpt> darn
[14:29] <chrisccoulson> i've honestly got no idea whether i should select Yes or No. i guess i'll just drop a pin and see which one it lands on ;)
[14:29] <mpt> mvo, ok, that probably makes it faster too
[14:29] <mvo> mpt: or having a "search more" button or something, but not having a way for users to search the full namespace is not ideal
[14:32] <mpt> mvo, so tell me how silly this sounds
[14:32] <mpt>  software item:: A piece of theoretically-installable software. Where `app-install-data` or an archive index refers to one or more applications inside a package, each application should be treated as a software item, but the package itself should not. All other packages should be treated as individual software items.
[14:33] <mpt> mvo, and then I'd clarify that the searchable text even for an application should include its package name
[14:33] <seb128> chrisccoulson, I got that one too
[14:34] <seb128> I just used the default option
[14:34] <mvo> mpt: give me a moment, I need to (carefully) parse it
[14:34] <chrisccoulson> seb128 - yeah, i did that too
[14:34] <chrisccoulson> i've still got no idea what it was really asking me to do though ;)
[14:39] <mvo> mpt: how about? software-item:
[14:39] <mvo>  A package or a application. A application belongs into
[14:39] <mvo>  exactly one package. If a search matches a application
[14:39] <mvo>  and the package of this application only the application
[14:39] <mvo>  is displayed in the search result.
[14:41] <Laney> an application isn't it?
[14:42] <mpt> mvo, maybe, but it's not just about search results
[14:42] <mvo> mpt: hm, so "System package/Net" will not show firefox?
[14:42] <mvo> mpt: or "System Package/Python" will not show python-wxtools
[14:43] <mvo> mpt: and only "Editra" and "PyShell" (the two apps that python-wxtools ships?
[14:43] <mpt> mvo, correct
[14:43] <mpt> mvo, but if you search for "python-wxtools" you would get back those two results
[14:44] <mpt> mvo, I don't know what you mean by "Net" there
[14:44] <mvo> mpt: "net" as a sub-section, its just a place holder
[14:44] <mpt> ok
[14:45] <mvo> mpt: I'm not sure its useful to de-duplicate it in the system tools category. if a user goes there, he expects (I assume) to see all package. I'm all in favor for de-duplication on searches
[14:46] <mvo> mpt: but if the user wants to browse a category in system packages, why should we hide something from him? he made the choice to go into this territory
[14:46] <mpt> mvo, we're not hiding it, it's right there in the "Developer Tools" department
[14:47] <mpt> mvo, "Tech Stuff" is not a place for every item, it's a place for those items that don't have a better home to go to
[14:48] <mvo> its a different approach of looking for items, I do think its "hidding" because its information that is not available to the user (a package entry)
[14:48] <mvo> even if he search he will only find apps, never the package
 mvo, and then I'd clarify that the searchable text even for an application should include its package name
[14:48] <mvo> in the case of "python-wxtools" he will not be able to find the package, only the apps that are part of the package
[14:48] <mpt> right
[14:49] <mvo> mpt: please do not quote stuff that I already read, my point is a different one
[14:49] <mpt> ok, sorry I didn't understand you then
[14:50] <mpt> Remember we talked about working on ways of pulling things out of that department
[14:50] <mpt> e.g. fonts
[14:50] <mpt> which would mean they didn't appear in there any more, they appeared somewhere better
[14:51] <mpt> e.g. Graphics > Fonts
[14:54] <mpt> mvo, do you know how many packages there are that contain multiple applications?
[14:56] <mpt> in Main and Universe
[14:56] <mvo> I guess it partly depends on what tech stuff should mean. during the uds discussion it was said that its the "System package" place. if its the system package place  I think people expect to find the system package there
[14:56] <mvo> if its not that, but just "other" with a new name, then that is different
[14:58] <mvo> *grumpf* disconnected
[14:58] <mvo> mpt: did you save anything after "<mpt> ok, sorry I didn't understand you then" ?
[14:59] <mpt> (pasted)
[14:59] <mvo> thanks
[14:59] <mpt> mvo, if we showed every package in there, I don't think we could reasonably call it "System Packages" (or "Tech Stuff", for that matter), because gnome-games would be in there
[15:00] <mpt> So either it's "All Packages", or as you say, it's a souped-up "Other"
[15:02] <seb128> asac, do we need your gtk change to hide this warning in lucid?
[15:02] <mpt> The way I imagined it was, items appear only in one department (and one subsection) unless the maintainer specifically provides a secondary department(+subsection)
[15:02] <mpt> bbiab, meeting
[15:06] <mvo_> sorry, something is not right with my network today
[15:09] <rickspencer3> good morning all
[15:09] <rickspencer3> pitti, does the dx team have a burn down charts set up?
[15:10] <seb128> hey rickspencer3
[15:10] <fagan> morning rickspencer3
[15:10] <rickspencer3> hi seb128
[15:11] <rickspencer3> hi fagan
[15:13] <seb128> chrisccoulson, you were looking at some seahorse crash on session closing IIRC?
[15:14] <chrisccoulson> seb128 - the seahorse-agent crash with a gazillion duplicates?
[15:14] <chrisccoulson> yeah, that one is fixed in karmic-proposed now
[15:14] <seb128> chrisccoulson, is bug #439446 the same one?
[15:14] <chrisccoulson> that looks like a different bug
[15:14] <seb128> ok
[15:14] <seb128> thanks
[15:15] <seb128> that one has some 25 duplicates
[15:15] <seb128> I'm cleaning those now
[15:15] <seb128> seems also a crash at session closing
[15:16] <chrisccoulson> yeah, possibly. people get confused with those because they get the crash report when they log in
[15:16] <seb128> we should have a crash timestamp info clearly noted in the bug
[15:17] <seb128> to compare to the bug report time
[15:33] <rickspencer3> rickspencer3, ping
[15:33] <seb128> rickspencer3, you are talking to yourself now?
[15:33] <rickspencer3> seb128, kind of
[15:34] <rickspencer3> I thought I was getting some serious irc lag, butt
[15:34] <rickspencer3> now i know that I am ;)
[15:34] <seb128> lol
[15:34] <seb128> ok, time to be brave and try that glib 2.23.0
[15:34] <seb128> if I don't come back that doesn't work great
[15:37] <chrisccoulson> seb128 - success? :)
[15:37] <seb128> yes!
[15:38] <seb128> let's get the crack in lucid ;-)
[15:38] <rickspencer3> looks like glib 2.23.0 worked ok
[15:43] <djsiegel1> hey pitti
[15:44] <pitti> seb128: what's hot and new about it?
[15:44] <pitti> hey djsiegel1
[15:44] <djsiegel1> sorry if those round-1 paper cuts were unexpected. We worked out at UDS that paper cuts with patches should be assigned to canonical-desktop-team, should we not do that?
[15:44] <asac> seb128: from what i see yes.
[15:45] <asac> we can drop it and file a RC bug to readd if nothing changes
[15:50] <djsiegel1> pitti: ^^
[15:56] <pitti> djsiegel1: if they were sent upstream, and have a patch, then please subscribe ubuntu-main-sponsors
[15:56] <pitti> which will also end up as being done by desktop team, but in a different context
[15:56] <djsiegel1> ok
[15:56] <pitti> djsiegel1: I just reverted the flux from this morning, since few, if any, of them had applicable patches, and no rationale
[15:57] <Laney> it seems to me that this paper cut pipeline emphasises distro patching over upstreaming
[15:58] <djsiegel1> Laney: yes it does
[15:58] <djsiegel1> we did the opposite last cycle
[15:58] <djsiegel1> and 15 paper cuts with patches rotted on the vine upstream
[15:58] <djsiegel1> so we are trying distro-first this time
[15:58] <djsiegel1> or, both simultaneously, rather
[15:59] <pitti> well, we will not apply things like string changes
[15:59] <pitti> unless they are also committed/accepted upstream
[15:59] <djsiegel1> Hmm
[15:59] <djsiegel1> ok
[15:59] <pitti> bug fixes are okay, of course, they just need to be submitted, but not accepted
[15:59] <djsiegel1> Just because string changes are harder to apply?
[15:59] <pitti> string changes are a bit special in that regard (for translation issues)
[15:59] <djsiegel1> ok
[15:59] <pitti> applying them is easy, but as soon as you do, you break all translations
[16:02] <Laney> I wonder if you could get upstreams on board for "paper cut days", like hug days but for patching
[16:03] <djsiegel1> Laney: interesting
[16:03] <Tm_T> Laney: why not
[16:04] <Laney> real-time feedback might make everyone more happy
[16:16] <seb128> asac, it's the only diff we have over debian
[16:16] <seb128> asac, not being able to sync sucks
[16:16] <seb128> asac, I will drop it and reopen the lucid task for the bug I think
[16:16] <seb128> ok with you?
[16:16] <seb128> we can re-add the delta later in the cycle
[16:16] <seb128> but meanwhile we would be able to sync
[16:16] <asac> ack
[16:17] <seb128> cool, thanks
[16:17] <pitti> seb128: the assert patch?
[16:17] <pitti> seb128: sure, we don't even collect apport reports right now
[16:17] <seb128> pitti, no, the sru to drop the xid warning
[16:17] <seb128> pitti, speaking about gtk
[16:18] <seb128> pitti, the glib change I'm pushing upstream so we can sync next version ;-) though the ping-pong is on your side now, desrt commented
[16:18] <pitti> right, saw it
[16:29] <rickspencer3> hi all, desktop team meeting in 1 minute
[16:29] <kenvandine> :)
[16:29]  * kenvandine waves
[16:29]  * ArneGoetje waves
[16:29]  * bryce waves
[16:29] <seb128> hey
[16:29] <tkamppeter> hi
[16:30]  * tseliot waves++
[16:30] <pitti> o/
[16:30] <rickspencer3> ArneGoetje, bryce ccheney kenvandine pitti seb128 Riddell tkamppeter tseliot
[16:30] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-12-01
[16:31] <rickspencer3> most of the meeting will be for pitti and seb128 but I have some managery announcements to get out of the way
[16:31]  * rickspencer3 copies and pastes from wiki
[16:31] <rickspencer3> Welcome back tselliot here on OEM team rotation
[16:31] <rickspencer3>     * bryce will be his "buddy"
[16:31] <rickspencer3>     * will work on xorg drivers and packaging gnome initially
[16:31]  * rickspencer3 hiya tseliot it's great to have you back
[16:32]  * pitti hugs tseliot
[16:32] <seb128> tseliot, welcome!
[16:32] <tseliot> it's great to work with all of you again
[16:32] <kenvandine> :)
[16:32] <rickspencer3> we should have a call with pitti and bryce to discuss your work for the desktop team in Lucid
[16:32] <pitti> my nvidia card is fail plz halp
[16:32] <kenvandine> hehe
[16:32] <tseliot> hehe ok
[16:32] <rickspencer3> I remember meeting tseliot at my first UDS
[16:32] <rickspencer3> he had the best sessions, and he didn't even work at Canonical then
[16:33] <pitti> too bad that you couldn't come this time
[16:34] <rickspencer3> so the OEM rotation means that robert_ancell will be with the OEM team
[16:34] <rickspencer3> for Lucid
[16:34] <tseliot> pitti: yes, I'll try to make up for it by attending the sprint
[16:34] <rickspencer3> :)
[16:34] <pitti> tseliot: you have to cook pasta
[16:34] <rickspencer3> hehe
[16:34] <kenvandine> yum
[16:35] <tseliot> pitti: hehe, actually I'm better at eating pasta
[16:35] <rickspencer3> okay, we'lll set up a call
[16:35] <dobey> hehe
[16:35] <rickspencer3> which brings up ...
[16:35] <tseliot> good
[16:35] <rickspencer3> 1-1 calls: please set these up with me if they are not on your calendar
[16:35] <dobey> yeah, i was wondering where tseliot was in Dallas
[16:36] <tseliot> ;)
[16:36] <rickspencer3> I noticed that a lot of the 1-1 calls have fallen off my calendar, so tseliot and anyone who doesn't seem to have one, please pick a time that is good for you and schedule that
[16:36] <rickspencer3> ok, next
[16:37] <rickspencer3> # UNE and didrocks: UNE will be moved to desktop team, and didrocks will be the maintainer
[16:37] <rickspencer3> not sure everyone is aware of this change, so thought I should bring it up here
[16:37] <bryce> welcome to the team tseliot!
[16:37] <tseliot> rickspencer3: ok, I'll send you an email
[16:37] <tseliot> bryce: thanks
[16:37]  * ccheney is here
[16:37] <seb128> didrocks, congrats again ;-)
[16:37]  * ccheney didn't realize the meeting changed times to 16:20
[16:37] <rickspencer3> UNE is Ubuntu Netbook Edition (was Ubuntu Netbook Remix)
[16:37] <seb128> ccheney, it didn't
[16:38] <seb128> it started at :30
[16:38] <tseliot> didrocks: congrats
[16:38] <ccheney> hmm my system clock is broken then :(
[16:38] <rickspencer3> ccheney is in a space ship traveling at a very high speed
[16:38] <ccheney> wow my system is a full 10m behind
[16:38] <tseliot> :-D
[16:39] <rickspencer3> okay, so anyway, didrocks will be joining the desktop team focused on UNE
[16:39] <rickspencer3> we won't refuse any gnome packaging that he may do to help seb128, though
[16:39] <rickspencer3> okay, almost done with the boring manager stuff
[16:39] <rickspencer3> # receipts and robert_ancell's scanning app: expenses coming up, please give robert's app a try and file bugs
[16:39] <seb128> hehehe :-)
[16:39] <rickspencer3> robert has put together a sweet and simple scanning tool
[16:39] <seb128> doh, I already did those
[16:40] <rickspencer3> with expenses coming up, it seems a good chance to try it out
[16:40] <rickspencer3> tell your friends
[16:40] <tseliot> where can I find this tool?
[16:40] <rickspencer3> help robert out!
[16:40] <seb128> I will find something else to try it anyway ;-)
[16:40] <seb128> rickspencer3, we do we find it?
[16:40] <rickspencer3> tseliot, good question
[16:40] <seb128> we->where
[16:40] <rickspencer3> ACTION: rickspencer3 to track down robert's scanning tool
[16:40] <rickspencer3> I assumed it
[16:40] <pitti> I'll try it, I archive all my snail mail with it
[16:40] <and471> jono, hi
[16:40] <rickspencer3> s in his ppa, but not 100% sure
[16:40] <kenvandine> lp:simple-scan
[16:41] <and471> jono, I see on the ubuntu wiki you have added ##BEGINLERNID
[16:41] <kenvandine> hopefully in a ppa too
[16:41] <seb128> kenvandine, we want ppa
[16:41] <seb128> ;-)
[16:41] <pitti> https://launchpad.net/~robert-ancell/+archive/ppa
[16:41] <rickspencer3> and471,  hiya, we're having our team meeting atm
[16:41] <and471> jono, however I believe we can do it a simpler way
[16:41] <pitti> it's there
[16:41] <and471> rickspencer3, sorry
[16:41] <rickspencer3> and471, feel free to hang out, we'll be done soon
[16:41] <rickspencer3> and471,  no apologies necessary, happens all the time
[16:41] <rickspencer3> ok, that's the boring managery announcements
[16:41] <rickspencer3> assuming there are no questions
[16:41]  * rickspencer3 hands mic to pitti
[16:42] <pitti> thanks
[16:42] <pitti> so, let's look at the alpha-2 BPs
[16:42] <pitti> WARNING: desktop-lucid-unr-session has no work items
[16:42] <pitti> didrocks: I know that you are not yet on duty
[16:42] <pitti> do you want to set them up yourself, or  want someone to help with that?
[16:43] <rickspencer3> pitti, I can get that one statred
[16:43] <rickspencer3> also I was thinking we would not do anything there in a2, since didrocks won't be started yet
[16:43] <rickspencer3> is that okay?
[16:43] <pitti> WFM
[16:43] <seb128> I can as well, I was initially drafter
[16:43] <pitti> it's not critical for alpha-2 anyway, it's not a very intrusive change wrt. to other parts of the distro
[16:43] <seb128> I just handed it to didrocks since he started on the wikipage before me
[16:43] <rickspencer3> ACTION: seb128 to add initial work items to UNR session spec
[16:44] <pitti> moved to beta-1 now
[16:44] <rickspencer3> thanks pitti
[16:44] <pitti> WARNING: desktop-lucid-powermanagement-tweaks has no work items
[16:44] <pitti> that's half my fault
[16:44] <pitti> I pinged Michael Frey again, he'll do the initial drafting now
[16:44] <rickspencer3> who's is the other half? (expect it is me)
[16:44] <pitti> and then I'll review and add WIs
[16:44] <rickspencer3> pitti, again, let's move that to a3?
[16:44] <pitti> rickspencer3: just that you are too gentle with your whip :)
[16:45] <pitti> rickspencer3: I'd like that to be in a2, since it does have intrusive changes
[16:45] <pitti> I just need to follow up on that
[16:45] <pitti> so this was by and large just a FYI
[16:45] <pitti> the others all have WIs
[16:45] <pitti> let's do a quick run-through and check for problems
[16:45] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-halsectomy
[16:45] <pitti> this is well underway
[16:45] <pitti> bryce: what's your plan wrt. merging 1.7.1 from experimental?
[16:46] <pitti> since dropping hal from the default install will likely cause some regressions, it would be great to see that land soon
[16:46] <pitti> I already fixed g-p-m, but I'm sure that there are less visible ones
[16:46] <pitti> I'll talk to Keybuk about updating udev to latest upstream trunk, so that we have the building blocks
[16:47] <pitti> but, I have run my desktop with hal purged since Friday, works well \o/
[16:47] <pitti> (should buy us some ~ 1.5 seconds startup speed)
[16:47] <tseliot> \o/
[16:47] <bryce> pitti, I need to check with timo but as soon as debian feels it is good to go we should pull it in
[16:47] <seb128> 1.5 seconds for early boot and xorg right?
[16:47] <pitti> seb128: *nod*
[16:48] <seb128> no impact on desktop there?
[16:48] <bryce> I need to find out if timo intends to do that or if I should.  But I hope to have it in this week
[16:48] <seb128> still good news ;-)
[16:48] <pitti> bryce: that would be great
[16:48] <pitti> otherwise this seems well underway and realisticc
[16:48] <bryce> pitti, was that "reduced to 1.5 sec" or "reduced by 1.5 sec"?
[16:49] <pitti> (modulo insurmountable regressions with wacom, of cousre)
[16:49] <pitti> bryce: "by"
[16:49] <bryce> pitti, from what approximately?
[16:49] <pitti> it's not _that_ bad :)
[16:49] <pitti> bryce: I'm not sure
[16:49] <pitti> 10ish
[16:49] <bryce> on my laptop (with SSD) it takes ~2 sec
[16:49] <pitti> (that's grub->gdm)
[16:49] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-default-apps
[16:50] <pitti> this seems simple
[16:50] <pitti> would be great if the seeds could be changed soon for gnome-games
[16:50] <pitti> otherwise we need someone to do a MIR for "seed" (two new games pull it in)
[16:50] <pitti> rickspencer3: ^ would be a task for robert?
[16:50] <rickspencer3> pitti, would it be reasonable to ask robert_ancell to do that
[16:50] <rickspencer3> ?
[16:50] <rickspencer3> lol
[16:50] <rickspencer3> okay, gmta
[16:50] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-social-from-the-start
[16:50] <rickspencer3> ACTION: robert_ancell to do mri for new games
[16:50] <pitti> this is a killer
[16:51]  * rickspencer3 looks meaningfully at kenvandine
[16:51] <pitti> kenvandine: ^ this is currently targetted for a2, but it sounds like it'll take two manmonths to implement that all from reading the WIs
[16:51] <pitti> how bad is it really?
[16:51] <pitti> should we spread it out a bit to move some bits to beta1?
[16:51] <kenvandine> not that bad
[16:51] <pitti> rickspencer3: s/mri/seed changes/
[16:51] <kenvandine> i might end up defferring some to b1
[16:52] <kenvandine> but with the couch stuff, it actually greatly simplifies quite a bit
[16:52] <kenvandine> and much of that is done, but still experimental
[16:53] <pitti> ok; let's keep it on the a2 radar for now, but please speak up early if it's getting late
[16:53] <pitti> oh, good!
[16:53] <kenvandine> will do
[16:53] <rickspencer3> can we just move the least essential tasks to a3?
[16:53] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers
[16:53] <kenvandine> rickspencer3, i kind of did
[16:53] <kenvandine> :)
[16:53] <pitti> tseliot: are there any blockers for this?
[16:53] <pitti> bryce, tseliot: and do we actually have a working nvidia driver for xorg 1.7/2.6.32, so that this can go forward and be tested?
[16:54] <tseliot> pitti: I'm waiting for superm1 to review a patch of mine for DKMS
[16:54] <tseliot> pitti: furthermore I've been busy with plymouth but I should be able to work on that soon
[16:54] <bryce> pitti, I believe the currently released one works with 1.7
[16:54] <pitti> nice
[16:54]  * tseliot nods
[16:55] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-gdm-custom-greeter-support
[16:55] <didrocks> pitti: seb128 : rickspencer3 : o/ and sorry for disturbing (just back home) I'm adding WI to the unr spec this evening (was thinking that the spec has to be approved first)
[16:55] <pitti> rickspencer3: ^ can you handle that in the eastern edition?
[16:55] <pitti> didrocks: merci! (no, it won't get approved before  it has WIs :) )
[16:56] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-likewise-open-migration
[16:56] <rickspencer3> pitti, could you please add comments to the white board wrt any issues that you see with the spec?
[16:56] <pitti> this is basically blocked on getting new packages from upstream; nothing to discuss from my side, unless there are questions?
[16:56] <pitti> rickspencer3: no technical ones, just "does robert have time to do it?"
[16:57] <rickspencer3> ah
[16:57] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-triaging-diagnosis
[16:57] <pitti> bryce: any blockers for that?
[16:57] <pitti> and do you think it's a realistic target for a2?
[16:57] <pitti> (42 work items..)
[16:57] <rickspencer3> ACTION: rickspencer3 to confirm robert_ancell commitment to GDM/GDM Greeter refactor
[16:57] <bryce> pitti, manpower mainly
[16:58] <bryce> pitti, well at least 50% of that can (and should) be done by a2
[16:59] <pitti> it seems that it'd be half as useful to do 50% of them, so it's still good to start it early
[16:59] <pitti> great
[16:59] <pitti> so, I think we are well on track
[16:59] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-empathy-indicator
[16:59] <kenvandine> yeah
[16:59] <rickspencer3> bryce, can we move the other 50% out of the a2 work item list?
[17:00] <pitti> kenvandine: so, from what I understand, this will be completely new code, and a new daemon, right?
[17:00] <kenvandine> pitti, did you read my response?
[17:00] <kenvandine> yes
[17:00] <pitti> kenvandine: I did
[17:00] <pitti> kenvandine: (no python please :) )
[17:00] <bryce> rickspencer3, how?
[17:00] <kenvandine> easiest way to maintain it imho
[17:00] <kenvandine> vala!
[17:00] <pitti> kenvandine: FYI, I have example vala d-bus code, if you need it
[17:01] <kenvandine> pitti, do share
[17:01] <kenvandine> docs are weak :)
[17:01] <pitti> kenvandine: do you think you can squeeze it into your already full schedule, or should we postpone some social-from-start issues?
[17:01] <kenvandine> i will move some social stuff
[17:01] <pitti> kenvandine: http://www.piware.de/2009/11/hello-dbus-in-vala/ (I have some more, too)
[17:02] <kenvandine> thx
[17:02] <pitti> any other questions/
[17:02] <pitti> ?
[17:02] <rickspencer3> not a question, but a point I would like to make
[17:03] <rickspencer3> I would *much* rather pull things from a3 into a2
[17:03] <rickspencer3> rather than postpone things from a2
[17:03] <rickspencer3> so I expect everyone to do a reasonable job scoping their a2 work, and I consider "less is more" wrt a2 commitments
[17:03] <pitti> sure, it doesn't mean that you mustn't work on post-alpha2 work items :)
[17:03] <rickspencer3> exactly
[17:04] <rickspencer3> so my feedback is that it's better to be conservative in your estimates about what you can deliver in a2

[17:04] <pitti> mic back to rickspencer3
[17:05] <rickspencer3> pitti, thanks for doing a incredible job getting us organized before, during, and after UDS
[17:05] <rickspencer3> and the burndown charts are amazing
[17:05]  * seb128 hugs pitti
[17:05]  * pitti bows
[17:05] <bryce> rickspencer3, ok done
[17:05] <tseliot> burndown charts?
[17:05] <pitti> I'll adjust the trend lines on Thursday, when we are at the BP definition deadline
[17:05] <rickspencer3> ah, poor tseliot, a burndown chart newbie
[17:05] <pitti> tseliot: http://piware.de/workitems/desktop/lucid-alpha2/report.html
[17:06] <pitti> tseliot: http://piware.de/workitems/desktop/lucid/report.html
[17:06] <pitti> tseliot: check out the previous one (http://piware.de/workitems/desktop/karmic/report.html) for the full idea
[17:06] <tseliot> ok, thanks
[17:06] <rickspencer3> tseliot, we can talk on the phone, it's basically the platform team way to track status of work done compared to commitments
[17:06] <rickspencer3> thanks again pitti
[17:06] <pitti> tseliot: also, https://wiki.ubuntu.com/WorkItemsHowto has some docs
[17:06] <tseliot> ok
[17:07]  * rickspencer3 hands mic to seb128
[17:07] <seb128> alright
[17:07] <seb128> so as everybody probably knows by now we have pretty agressive requirements about boot speed in lucid
[17:07] <seb128> I've started look at desktop login this week
[17:08] <seb128> our budget for desktop is around 4 seconds
[17:08] <seb128> current chart is http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091201-1.png
[17:08] <seb128> (I will copy regular charts from the reference box on this webspace for those interested in that)
[17:09] <seb128> right now we are around 3 times slower than we ough to be
[17:09] <seb128> ie there is quite some hard work to put there and we might need to tweak our default config and selection
[17:09] <seb128> I would like to discuss changing the list of default applet for this cycle
[17:10] <pitti> so unless it's not too much work for speeding up compiz (static linking, drop plugins), the fallback is metacity by default, right?
[17:10] <pitti> I think that'd be acceptable
[17:10] <seb128> yes
[17:10] <pitti> (unlike the "don't render the desktop" one for nautilus)
[17:10] <seb128> but even without compiz and without nautilus and without xsession.d
[17:10] <pitti> ^ I'd really like to avoid that
[17:10] <seb128> we still use some 8 seconds now
[17:10]  * rickspencer3 agrees with pitti and seb128 wrt metacity be default
[17:10] <seb128> so that's not enough to rely on it
[17:10] <rickspencer3> seb128,  what does it mean "without nautilus"?
[17:11] <seb128> we still need to make progress there
[17:11] <pitti> no, just for prioritization
[17:11] <seb128> rickspencer3, I removed it from the session
[17:11] <pitti> we should start with panel, applets, and nautilus
[17:11] <seb128> no nautilus started at all
[17:11] <seb128> right
[17:11] <rickspencer3> so it doesn't start until you pick somehting from places, for example?
[17:11] <seb128> compiz is a would be nice item but doesn't seem the higher priority
[17:11] <pitti> seb128: also, you have a g-s patch to start everything in parallel, no?
[17:11] <seb128> we have fallback plan there
[17:11] <seb128> rickspencer3, yes
[17:11] <seb128> pitti, yes
[17:11] <seb128> I've included some details and comment on the wiki
[17:12] <seb128> I will try to do that every week with my activity report
[17:12] <seb128> starting everything in parallel makes small difference
[17:12] <seb128> we replace delay by io and cpu bounding
[17:12] <pitti> but gives us more potential for optimization
[17:12] <seb128> yes
[17:12] <seb128> chrisccoulson has been looking at gnome-session
[17:12] <pitti> if panel starts 5 seconds in, we can speed it up as we like and still break the bar
[17:12] <seb128> and gnome-settings-daemon
[17:13] <seb128> there is some wins to do there too
[17:13] <seb128> starting dkpower later
[17:13] <seb128> he will try to optimize gconf reading too
[17:13] <pitti> as a "first against the wall" thing, can we drop some applets? -> proposal: "show desktop", trash, firefox/help launchers
[17:13] <seb128> that's a summary of what we did this week
[17:13] <seb128> I would like to discuss the applet selection
[17:13] <seb128> and maybe changing to 1 gnome-panel bar
[17:14] <pitti> yay
[17:14]  * rickspencer3 agrees with dropping all of pittis list
[17:14] <seb128> 1 or 2 bars doesn't make a real speed change
[17:14]  * tseliot uses Docky
[17:14] <seb128> but if we reduce applets we could as well fit on one
[17:14]  * pitti always disables the bottom bar, not for speed, but for screen real estate reasons
[17:14] <seb128> same here
[17:14] <rickspencer3> pitti, what do you do for window switching?
[17:14] <seb128> I agree with pitti's list
[17:14] <seb128> trash costs 0.5 seconds right now
[17:14] <pitti> rickspencer3: it's in my top panel
[17:14] <seb128> the messaging applet costs 0.5 seconds too
[17:15] <seb128> but I guess we can't go around this one
[17:15] <rickspencer3> hmmm
[17:15] <seb128> we can try pushing dxteam to optimize things though
[17:15] <rickspencer3> that's too long
[17:15] <rickspencer3> kenvandine, any thoughts on loading the MI?
[17:15] <pitti> rickspencer3: http://people.canonical.com/~pitti/photos/pitti-virtual-desktop.png
[17:15] <kenvandine> rickspencer3, no...
[17:15] <kenvandine> it starts a bunch of daemons
[17:15] <pitti> (it's  from intrepid or so)
[17:15] <kenvandine> maybe look at how that is being done
[17:16] <pitti> indeed all the MI stuff is exceptionally resource intense, with many d-bus services launched, etc.
[17:16] <rickspencer3> does it make sense to start all the daemons at startup?
[17:16] <kenvandine> it would be reasonable to get dx to review that
[17:16] <pitti> there is 6 (!) indicator related processes
[17:16] <seb128> I get between 0.5 and 0.8 second win on the test box without the message indicator
[17:16] <rickspencer3> I mean, what can they be listening for if you haven't actually started any apps yet?
[17:16] <seb128> so there is for sure place for doing better
[17:17] <seb128> it's some 15% of the login budget right now
[17:17] <kenvandine> rickspencer3, yeah
[17:17] <pitti> we could perhaps at least defer it
[17:17] <ccheney> oh yea if anyone else needs 10v for this testing they might want to get them soon, i have a feeling they will be EOLd around jan 7
[17:17] <kenvandine> make it on demand
[17:18] <pitti> kenvandine: I guess the daemons listen to some signals, so that they can't be dbus activated when you e. g. open empathy or evo?
[17:18] <kenvandine> yeah
[17:18] <rickspencer3> kenvandine, can you take the action to investigate defering startup of MM related daemons?
[17:18] <kenvandine> yes
[17:18] <seb128> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed has a detailed list of work items
[17:18] <seb128> if somebody wants to claim some please do
[17:18] <bryce> ccheney, sucks!  Hope they have something similar to replace it.
[17:18] <pitti> kenvandine: there might be a possibility of one process listening to all the signals, and then start the other daemons on demand?
[17:18] <seb128> put your [name] on the line
[17:19] <rickspencer3> ACTION: kenvandine to investigate deferring startup time of MM
[17:19] <ccheney> bryce: i don't know for certain, but pine trail is supposed to be out on that day so very likely will be update to it
[17:19] <seb128> kenvandine, thanks
[17:19] <pitti> so, if we removed above applets, nobody would cry out?
[17:20] <seb128> going back to the applets list
[17:20] <seb128> should we talk to design team?
[17:20] <rickspencer3> seb128, nah
[17:20] <kenvandine> seb128, mind if i add a work item for the indicator services?
[17:20] <seb128> pitti, I'm not sure about the launchers
[17:20] <pitti> also, removing these launchers is a long-term goal anyway, wasn't it?
[17:20] <seb128> I'm all for droping the show desktop and trash ones
[17:20] <rickspencer3> seb128, tbh. I've wanted to get rid of the ff and help launchers anyway
[17:21] <seb128> kenvandine, oh, please do!
[17:21] <pitti> ^ those two sound good indeed
[17:21] <tseliot> bryce: the mini 12 should be available sooner or later
[17:21] <seb128> ok
[17:21] <seb128> should be try to go on one bar then?
[17:21] <pitti> tseliot: does that boot any faster? :-)
[17:21] <seb128> in which case do we want to change the clock applet to just do time by default?
[17:21] <seb128> and not date
[17:21] <pitti> seb128: oh, please
[17:21] <seb128> I'm for keeping the weather though
[17:22] <tseliot> pitti: I don't have it yet. Here's an article about it: http://apcmag.com/scoop_we_review_the_inspiron_mini_12__dells_supersized_yet_superslim_12_inch_netbook.htm
[17:22] <pitti> having the date is pretty silly; you get it when hovering over it, and it's the same all day :)
[17:22] <pitti> tseliot: j/k
[17:22] <tseliot> aah
[17:22] <seb128> ok
[17:22]  * ccheney thinks the weather is useless after the gweather change last cycle
[17:22]  * ccheney just uses a FF weather applet
[17:22] <rickspencer3> seb128, would it speed up desktop time to just load the clock and no evo calendar, weather, etc...?
[17:22] <seb128> so one bar, no launcher and tasks list where those are now, no show desktop, no trash, only time for the clock
[17:22] <pitti> it's not important enough for me to see all the time, but that's just me
[17:22]  * pitti has a window
[17:23] <pitti> seb128: and no seconds either
[17:23] <seb128> right, that's not on now
[17:23] <seb128> I didn't plan to change that ;-)
[17:23] <seb128> rickspencer3, I'm not sure, but I will keep doing charts next week and have those for next meeting
[17:23] <seb128> let's do what I said as a first step
[17:23] <seb128> and see for changes over that in next meeting?
[17:23] <pitti> having an extra 25 pixels is a big win by itself
[17:24] <pitti> seb128: sounds good
[17:24] <seb128> we can still tweak some options it's early in the cycle
[17:24] <seb128> anybody having other ideas about things we should change?
[17:25] <pitti> seb128: we'd move the work area switcher to the top bar, too?
[17:25] <seb128> I think we should also try to document how we do this work
[17:25] <seb128> our metrics, tools, etc
[17:25] <rickspencer3> seb128, does wallpaper have an impact?
[17:25] <ccheney> tseliot: mini 12 doesn't work with current ubuntu afaik, has gma500 (ugh)
[17:25] <pitti> I'm also working on app menu caching right now
[17:26] <rickspencer3> other theme stuff?
[17:26] <seb128> pitti, yes, or do you think we should keep the second bar because it's too much?
[17:26] <pitti> seb128: I propose that we dedicate this week to panel (applets, caching), and then revisit next week
[17:26] <seb128> rickspencer3, theme and wallpaper have an impact yes
[17:26] <seb128> I didn't measure how much changing the image format impacts on the loading though
[17:26] <pitti> seb128: no, as I said I'm all for removing the second bar
[17:26] <seb128> would be worth testing if somebody wants to do it
[17:26] <ccheney> if we need more pixels getting rid of the username on right could help a lot
[17:26] <rickspencer3> so simple one color picture for wallpaper, and fast loading theme by default?
[17:27] <pitti> rickspencer3: I guess we won't get that past design
[17:27] <kenvandine> rickspencer3, remember there are plans for that applet
[17:27] <seb128> I've the feeling design team will not like those suggestions ;-)
[17:27] <tseliot> ccheney: it's not the same mini 12 I was talking about. I picked up the wrong link
[17:27] <ccheney> tseliot: ok
[17:27] <rickspencer3> well, we should start with getting the desktop to load within budget
[17:27] <rickspencer3> then we can work on making exceptions, etc...
[17:27] <pitti> /sys/class/dmi/id/sys_vendor == "Dell" -> no background :)
[17:28] <rickspencer3> but design should work within the same constraints that we do
[17:28] <kenvandine> seb128, maybe set group when space is limited in the window list would be a good default for a single panel
[17:28] <seb128> if user == keybuk, no background? ;-)
[17:28] <pitti> kenvandine: do you think we can drop the u1 applet by next week?
[17:28] <kenvandine> no
[17:28] <didrocks> seb128: ahah
[17:28] <kenvandine> well... maybe for lucid... i is early :)
[17:28] <kenvandine> s.i/it
[17:29] <kenvandine> s/i/it
[17:29] <seb128> rickspencer3, I will measure background and theme impact for next week
[17:29] <seb128> trying different formats and plain color
[17:29] <rickspencer3> k
[17:29] <seb128> so we can know how much it costs and if it's worth
[17:29] <seb128> enough on the topic it's almost time
[17:29] <seb128> so just to summarize
[17:29] <seb128> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed has work items
[17:30] <seb128> feel free to grab or add some there
[17:30] <seb128> http://people.canonical.com/~seb128/bootchart/ has charts
[17:30] <seb128> I can test on a mini10v so if you want to get changes tested let me know
[17:30] <pitti> so let's do the panel related changes this week
[17:30] <seb128> thanks everybody for helping there ;-)
[17:31] <seb128> I will do the gnome-panel changes this week
[17:31] <pitti> seb128: for next week, it would be great if you could do one with metacity, and the panel changes?
[17:31] <seb128> and measure impact from other applets, theme, background
[17:31] <pitti> (I hope I can get the caching in this week)
[17:31] <seb128> sure
[17:31]  * kenvandine plans to upgrade to lucid this afternoon
[17:31] <seb128> I've been doing something similar this morning
[17:31] <rickspencer3> seb128, thanks, great job!
[17:31]  * pitti hugs seb128 for coordinating this and his great work
[17:32] <seb128> it was around 9 seconds
[17:32] <seb128> but with the non optimized gnome-session
[17:32] <seb128> so I guess we would be around 8 seconds on the optimized one
[17:32]  * seb128 hugs pitti and rickspencer3
[17:32] <seb128> thanks guys
[17:33] <rickspencer3> any other business?
[17:33] <pitti> . o O { gvfs-trash, WTH }
[17:33] <pitti> that belongs started on demand..
[17:33] <seb128> pitti, trash applet?
[17:33] <pitti> seb128: if the applet is gone, so is this?
[17:33] <seb128> pitti, it's delayed until nautilus query for it
[17:34] <pitti> zap it! zap it!
[17:34] <pitti> :)
[17:34] <seb128> ;-)
[17:34] <bryce> sorry, xchat seems to have frozen the last 10 min
 seb128, btw the moblin patches are now in lucid.  dunno if they helped or if so by how much, but I do notice xkbcomp absent on your chart so guess that's some progress
[17:34] <bryce>  seb128, fastest I've gotten X on my hardware is 2 sec, about the same as you
[17:34] <bryce>  moblin says they got it to 1 sec, but dunno how (jbarnes wasn't sure either; maybe kernel stuff)
[17:35] <rickspencer3> bryce, in case you were caught in the same time warp as ccheney, it's 9:34am our time (unless I am also in a time warp)
[17:35] <pitti> bryce: is that with udev already? or hal?
[17:35] <bryce> pitti, nope neither
[17:35] <seb128> bryce, yes, your changes won us almost 1 second, thanks ;-)
[17:35] <pitti> bryce: heh, xorg.conf?
[17:35] <rickspencer3> bryce, has keybuk confirmed that mobile *really* got x to start in 1 second?
[17:35] <bryce> pitti, don't think so
[17:36] <rickspencer3> like, is that from a boot chart that we made, or is this just something they told us?
[17:36] <pitti> bryce: no input devices at all then? :)
[17:36] <ccheney> iirc he said he had and that it was something in the binary itself
[17:36] <bryce> rickspencer3, it is from what they told us
[17:36] <rickspencer3> ok
[17:36] <ccheney> but i am a bit fuzzy on the details
[17:36] <bryce> rickspencer3, (according to keybuk)
[17:36] <rickspencer3> oops, ok, I'll ask him later
[17:37] <bryce> pitti, I mean "without the hal removal changes"
[17:37] <pitti> bryce: ah, ok; perhaps that'll win another .1 seconds
[17:37] <seb128> oh
[17:37] <seb128> dropping compiz-fusion-plugins-extra wins 0.5 seconds
[17:37] <seb128> we don't use it anyway
[17:37] <seb128> so it should go to universe soon
[17:38] <tseliot> bryce: are you using the kernel patches that I recommended already (to reduce X startup time)?
[17:39] <seb128> rickspencer3, I think that's a "no other business"
[17:39] <rickspencer3> lol
[17:39] <seb128> ie those are after meeting discussions
[17:39] <rickspencer3> okay then
[17:39] <seb128> (in case you want to official wrap the meeting now)
[17:39] <rickspencer3> thanks all
[17:39] <seb128> thanks rickspencer3
[17:39]  * rickspencer3 taps gavel
[17:40] <bryce> tseliot, no this was stock lucid kernel; I was testing the patches you flagged on the X.org side
[17:40] <ArneGoetje> thanks
[17:40] <bryce> thanks
[17:40] <tseliot> thanks
[17:40] <pitti> thanks everyone!
[17:40] <ccheney> thanks
[17:40] <tseliot> bryce: oh, those patches are from Moblin and should help
[17:41] <tseliot> I'll bug apw about them
[17:42] <bryce> tseliot, great
[17:45] <didrocks> pitti: about your second remark on the une whiteboard: that can be good, yes, but I prefer if we can have only one package and not "one package if you want only UNE" and another one if you want ubuntu-desktop + UNE. The other solution (appart using xession.d is) is to patch gconfd itself to add /var/lib/${GDMSESSION}.defaults.
[17:46] <pitti> didrocks: one package> so do I :) but right now the spec has about three different package names
[17:46] <pitti> didrocks: ${GDMSESSION}.defaults -> hah, nice trick; please add to whiteboard
[17:47] <didrocks> pitti: ok, so you prefer patching gconf than using xsession.d (I do not have any strong opinion)?
[17:47] <pitti> didrocks: what would the xsession.d script do?
[17:47] <pitti> didrocks: the spec made it sound like "grep the session from xsession.d/*
[17:48] <didrocks> pitti: oh no, it was about exporting ENV_DEFAULTS_PATH used in /etc/gconf/2/path regarding GDMSESSION value
[17:53] <pitti> didrocks: ah, *phew*; that sounds doable as well; can you please clarify this in the spec?
[17:53] <didrocks> pitti: sure
[17:53] <pitti> merci
[18:00] <didrocks> pitti: in which spec is "seeding gdm with a default configuration in /etc/gdm/custom.conf" WI, in gdmsetup one? As I depend on this, I can try to give an hand there next week (now that the Ubuntu Party in Paris is finished, I'll have more time once debriefed ;)).
[18:02] <seb128> didrocks, how was the party btw?
[18:03] <didrocks> seb128: nice, but huge and tiring (http://blog.didrocks.fr/index.php/post/Ubuntu-Party-Paris-%3A-5-000-visitors)
[18:04] <seb128> waouh
[18:04] <seb128> you keep doing high scores ;-)
[18:05] <didrocks> yes, but the walls can't be extended forever :-)
[18:07] <seb128> rickspencer3, pitti: using a colored background rather than an image wins another 0.5 seconds
[18:07] <rickspencer3> nice
[18:09] <didrocks> I guess dxteam will really don't like that :-)
[18:20] <mpt> didrocks, the Design team probably cares more :-)
[18:20]  * mpt waves to mat_t 
[18:22] <rickspencer3> well, we can't have our cake and eat it to
[18:22] <rickspencer3> we have a 4 second budget
[18:22] <rickspencer3> and since we can't warp space time, we'll have to make some sacrifices to meet the budget
[18:25] <kenvandine> seb128, what about sizing of the background image? is the time spent scaling it?
[18:25] <kenvandine> although we went through this already in xsplash
[18:26] <pitti> didrocks: sorry, was on phone
[18:27] <pitti> didrocks: hm, that's only in a bug report so far, let me find it
[18:27] <didrocks> pitti: bug #403291 ?
[18:28] <pitti> didrocks: exactly
[18:29] <didrocks> pitti: I can take this task too and forget about adding a temporary dummy session package, ok?
[18:29] <seb128> kenvandine, i've not tried that yet, any suggestion on what to change for the image?
[18:29] <pitti> didrocks: sweet, thanks!
[18:30] <kenvandine> well for a test, resize the image to the same size as your resolution
[18:31] <seb128> Amaranth, there?
[18:33] <rickspencer3> ccheney, any other plans for OOo aside from shipping 3.2.1?
[18:33] <rickspencer3> what about the split builds, translations, etc...?
[18:34] <seb128> pitti, no compiz + gnome-panel changes + background color = 9.6 seconds
[18:34] <seb128> compared to 12.9 seconds now
[18:35] <pitti> ugh
[18:35] <pitti> great!
[18:35] <seb128> ugh or great?
[18:35] <pitti> at first I misread
[18:35] <seb128> oh, ok ;-)
[18:36] <pitti> but a 3.2 second saving is a huge step already
[18:36] <seb128> right
[18:36] <pitti> that's without the "start everythign at once" yet, right?
[18:36] <seb128> and that's using gnome-session sleeping too much
[18:36] <seb128> pitti, right
[18:36] <seb128> I guess we would be down to 7 seconds otherwise
[18:37] <seb128> that means we cut some stuff and still have 3 seconds to win
[18:37] <seb128> but 3 seconds seem doable
[18:37] <pitti> /msg seb128 let's take out the sleep(5) at the very end, to show that you are a super-hero once again :)
[18:37] <seb128> then we can try to get back what we did cut
[18:37] <seb128> lol
[18:37]  * seb128 hugs pitti
[18:38] <chrisccoulson> i just wish gconf was a little faster
[18:39] <pitti> chrisccoulson: it's reading tons of XML..
[18:39] <pitti> quick, someone write a gconf sqlite backend!
[18:39] <chrisccoulson> pitti - yeah. that's the longest delay in gnome-session before it starts anything
[18:40] <seb128> things will be better when we get dconf
[18:40] <seb128> but that's for lucid+1
[18:40] <chrisccoulson> my gnome-session changes work around that, but just postpone it to g-s-d now
[18:42]  * kenvandine reboots after the upgrade to lucid 
[18:42] <seb128> kenvandine, good luck!
[18:46] <chrisccoulson> gconf really isn't a nice package to try and figure out :-/
[18:53] <RenatoSilva> anyone else got his GDM broken after last update in package gdm? here I've got face browser again
[18:54] <seb128> what distribution version?
[18:55] <RenatoSilva> Karmic
[18:56] <seb128> not known no
[18:56] <seb128> how did you change the setting?
[18:56] <RenatoSilva> gdm theme was changed too, I had changed it previously with some enigmatic procedure
[18:57] <seb128> so maybe the enigmatic procedure was not correct way to do that
[18:57] <RenatoSilva> something more than sudo -u gdm dbus-launch gnome-appearance-properties
[18:58] <RenatoSilva> seb128: or maybe it is easy to write bad software
[18:58] <RenatoSilva> for example, why would this not work as it doesn't in fact? sudo -u gdm gnome-appearance-properties
[18:59] <seb128> RenatoSilva, ubuntu is not writing those software and I'm not interested to troll, goodbye
[18:59] <seb128> urg
[18:59] <seb128> xsplash costs some 0.8 seconds at login
[18:59] <seb128> rickspencer3, pitti: ^
[19:00] <rickspencer3> seb128, this is post gdm?
[19:00] <seb128> rickspencer3, yes
[19:01] <seb128> rickspencer3, that's the gdm to desktop animation
[19:01] <RenatoSilva> anyone else?
[19:02]  * rickspencer3 shoots xsplash in head
[19:03] <chrisccoulson> we should just ditch the panel, filemanager and desktop wallpaper completely, and make the default session just a xterm ;)
[19:03] <RenatoSilva> how to restore gdm theme after a breaking pakcage update (last update of 'gdm')?
[19:04] <mpt> mvo_, I've completed the specification of department and subsection screens: https://wiki.ubuntu.com/SoftwareCenter#department
[19:04] <RenatoSilva> and how to deactivate again the face browser (also broken)
[19:04] <chrisccoulson> RenatoSilva, #ubuntu for support
[19:04] <rickspencer3> chrisccoulson, += xsplash after login
[19:05] <RenatoSilva> chrisccoulson: ok, but please stop annoying users with broken updates, I have more useful things to do other than being scared of updating my system, as I am now
[19:05] <chrisccoulson> one thing i noticed with xsplash is that you have to wait 10 seconds for it to disappear when loading the xterm session, as it doesn't get the signals from gnome-panel and nautilus
[19:06] <chrisccoulson> hmmm, what did i do there?
[19:27] <mat_t> rickspencer3: we're thinking about having a lot smaller image that sits in the middle, rather than a huge fullscreen one that has to be scaled down
[19:27] <rickspencer3> mat_t, how about no image?
[19:28] <rickspencer3> just a color
[19:28] <rickspencer3> seems about the only choice to be made atm
[19:28] <mat_t> rickspencer3: I think 0.5s is not worth it
[19:28] <rickspencer3> mat_t, we have a 4 second budget
[19:28] <rickspencer3> so it's not really a choice to be made
[19:29] <rickspencer3> unless you can get the budget changed
[19:29] <mat_t> I'll see what I can do :)
[19:30] <chrisccoulson> has anyone looked at how that 0.5 seconds is broken down?
[19:30] <chrisccoulson> ie, is it reading it from the disk, or scaling it, or X protocol calls?
[19:30] <chrisccoulson> or something else?
[19:32] <mat_t> chrisccoulson: probably question to bratsche ^
[19:33] <chrisccoulson> mat_t - yeah, possibly. i wasn't sure whether anyone already figured it out
[19:34]  * mat_t hopes someone did
[19:35] <bratsche> 0.5s for xsplash?
[19:35] <bratsche> What's the question exactly?
[19:35] <mat_t> bratsche: what is 0.5 made of? Scaling? Loading? Drawing?
[19:36] <ccheney> rickspencer3: no, sorry was at lunch at the time
[19:36] <chrisccoulson> mat_t - oh, we're talking about xsplash and not the desktop background?
[19:36]  * chrisccoulson is confused
[19:36] <bratsche> I never really made notes of that.  Keybuk said xsplash was doing fine and fit in its budget, so I didn't spend any further time on it.
[19:37] <bratsche> If that's not the case then let me know, but he told me it was not exceeding its budget.
[19:37] <mat_t> rickspencer3: ^
[19:38] <kenvandine> mat_t, it wasn't xsplash
[19:38] <kenvandine> it was the desktop wallpaper loading
[19:39] <kenvandine> using a color with no image saves 0.5s
[19:39] <mat_t> kenvandine: desktop wallpaper? You mean the image that we use as a boot and gdm bg?
[19:39] <kenvandine> no
[19:39] <kenvandine> desktop
[19:40]  * mat_t is confused
[19:40] <kenvandine> hehe
[19:40] <kenvandine> mat_t, or did you start off on your own here? i thought you started to respond to our discussion about desktop login
[19:40] <kenvandine> we talked about image scaling and how xsplash does it
[19:41] <mat_t> kenvandine: no, to the discussion about removing the bg that is loaded during boot
[19:41] <kenvandine> i didn't see that discussion
[19:41] <mat_t> :)
[19:41]  * mat_t is un-confused
[19:42] <kenvandine> sorry :)
[19:42] <mat_t> ok, gotta run, catch you guys later
[19:42] <mat_t> np :)
[19:42] <mat_t> bye!
[19:48] <seb128> kenvandine, chrisccoulson: 0.5 is for the background image
[19:48] <seb128> xsplash takes some 0.8 seconds
[19:49] <rickspencer3> seb128, is xsplash on our budget?
[19:49] <seb128> yes
[19:49] <seb128> I'm only looking at desktop times there
[19:49] <seb128> it's costing 0.8 seconds on gdm to desktop loading
[19:50] <seb128> could be costing some extra time before
[20:48] <pitti> seb128, rickspencer3: I'm not sure, how much of xsplash was going to be replace by plymouth?
[20:48] <pitti> but probably not the part that covers the desktop while it's loading
[20:49] <seb128> pitti, you can look to my bootcharts
[20:49] <seb128> xsplash uses lot of cpu for a whole second
[20:50] <seb128> I guess that's the animation
[20:52] <pitti> yes, I guess that needs a lot
[20:52] <seb128> bratsche, ^ any idea if xsplash could use less cpu in some way?
[20:55] <kenvandine> maybe we could ease up on the animation?
[20:55] <seb128> or change the bouncing bar for a spinning logo?
[20:56] <kenvandine> yeah
[20:56] <bryce> if (pciid != MINIV_PCIID) { xsplash(); }  ;-)
[20:56] <seb128> the bar is skipping when the system is loaded anyway
[20:56] <kenvandine> which would probably be less choppy anyway
[20:56] <seb128> :-)
[20:59] <bratsche> seb128: It could be animation, or it could be doing initial image loading and scaling?
[21:00] <seb128> dunno
[21:00] <seb128> the bootchart has quite some lines and not a colored rectangle there so I would say it's the animation
[21:00] <kenvandine> it is taking a huge image and scaling it for the background
[21:00] <kenvandine> but the background gets scaled early
[21:01] <seb128> could we cache the scaled image?
[21:01] <seb128> so it's scaled once
[21:01] <seb128> and then we use the cache until the screen settings change
[21:02] <bratsche> It's only scaled once already I think.
[21:02] <seb128> ok, so that's not it
[21:02] <seb128> it's the animation
[21:03] <bratsche> I think we already realized that we need to rethink how the animation is done.  It seems like xsplash is being starved so it's not possible to animate this smoothly.
[21:03] <seb128> right
[21:03] <seb128> it's jumping a lot on io load
[21:03] <seb128> or cpu load
[21:03] <seb128> not sure which one in fact, it's just during busy time
[21:04] <bratsche> All the disk IO is done early on, but we could look into how it's drawing.  I'm not sure off hand if it's using server-side pixmaps or not, this could help speed it up.
[21:04] <bratsche> (maybe)
[21:06] <seb128> that's worth trying if you have an idea how to test that easily
[21:06] <seb128> I'm not sure if it's doing anything wrong now, I just know it costs non negligable time for login
[21:07] <bratsche> Depends on when you need this done by.. right now I'm kind of busy trying to get decorations code finished up in time for gtk+ 2.20, and David is pushing me hard right now to start on the application indicator stuff ASAP.
[21:07] <bratsche> Yeah, I understand.
[21:08] <bratsche> Oh, actually I'm taking a look at throbber_frame_cb() right now and it looks terrible.  I'm embarrassed. :)
[21:09] <bratsche> seb128: I'll cook up a patch for you tonight that will improve this.  If it's not good enough still then we can experiment with server-side pixmaps.
[21:10] <seb128> bratsche, oh please don't spend over work hours for this there is no hurry
[21:10] <seb128> the login target is for lucid
[21:10] <seb128> and we want to be on the right track and have a good part done for end of january
[21:10] <bratsche> Okay perfect.  I'll file a bug for myself right now though.
[21:11] <seb128> thanks
[21:11] <seb128> having it looked at by mid-january would be nice though
[21:11] <bratsche> What I'm thinking of doing now should be pretty simple to write.. maybe 30 mins.
[21:13] <seb128> ok, so whenever you have a free slot will do
[21:13] <seb128> thanks ;-)
[21:14] <bratsche> https://bugs.launchpad.net/xsplash/+bug/491029
[21:16] <seb128> bratsche, thanks
[21:18] <Amaranth> seb128: dunno if it was mentioned earlier but using applications-merged to hide something from the menus depends on the item being in the menu you expect
[21:19] <Amaranth> seb128: So if I use alacarte to move (copy, actually) gedit to the Programming menu your file in applications-merged won't hide it
[21:19] <seb128> Amaranth, using a .desktop with the same name in local works there
[21:20] <Amaranth> Sure
[21:20] <Amaranth> I actually wrote to xdg-list about this back in May or so
[21:20] <seb128> it was just a request for a custom image to have some entry not displayed by default
[21:20] <seb128> so using local will do
[21:21] <Amaranth> NoDisplay has two uses and can't fulfill both of them at the same time and none of the other ways of hiding something are reliable
[21:25] <seb128> Amaranth, in this case NoDisplay is enough
[21:25] <seb128> Amaranth, btw have you seen my comment about compiz extras?
[21:27] <kklimonda> is there a full list of packages on live cd?
[21:27] <seb128> yes
[21:28] <seb128> in the directory where the cd isos are on the ftp for example you have the content of the disks
[21:28] <Amaranth> seb128: yeah, we can get it moved out soon
[21:29] <seb128> what is blocking you now?
[21:29] <Amaranth> seb128: Did you see my idea about putting each plugin in a separate (binary) package?
[21:29] <Amaranth> seb128: Doing the work :)
[21:29] <Amaranth> iirc there are 3 places I have to make the change for the default plugins
[21:30] <Amaranth> really want to get all that cleaned up too
[21:30] <Amaranth> since we're going to be forcing our new defaults on users there is an opportunity to clean up some of the craziness in getting our defaults set (some had to be done with .gconf-defaults while some are patches to the xml files)
[21:32] <kklimonda> seb128: so I can take a list of packages from alternate cd and assume that it's the same on live cd/
[21:32] <kklimonda> thanks
[21:35] <seb128_> re
[21:35] <seb128_> Amaranth, got my question?
 what is blocking you now?
 seb128: Did you see my idea about putting each plugin in a separate (binary) package?
 seb128: Doing the work :)
 iirc there are 3 places I have to make the change for the default plugins
 really want to get all that cleaned up too
[21:36] <Amaranth> whoops, got too many lines
[21:37] <seb128_> Amaranth, hum
[21:38] <seb128_> splitting everything seems to be a lot of work and package index clutter no?
[21:38] <seb128_> I though extras could be moved to universe now
[21:39] <seb128_> the main ones can be splitted then
[21:39] <seb128_> not sure if we should have selected and universe though
[21:39] <seb128_> or having extra granularity
[21:52] <seb128_> hey robert_ancell
[21:52] <robert_ancell> seb128_, hey
[21:52] <pitti> robert_ancell: good morning! how are you?
[21:52] <robert_ancell> seb128, pitti, do you know why gnome-games reverted to 2.28 in Lucid yesterday?
[21:52] <seb128> it didn't?
[21:52] <pitti> uh? no
[21:53] <pitti>  1:2.29.3-0ubuntu1
[21:53] <pitti>  is current
[21:53] <robert_ancell> one of my uploads was marked as "rejected by archive administrator"
[21:53] <robert_ancell> I uploaded that afterwards
[21:53] <seb128> reason?
[21:53] <robert_ancell> none given
[21:53] <seb128> hum
[21:53] <seb128> ask slangasek
[21:53] <seb128> was there any binary change?
[21:54] <robert_ancell> yes, it was the 2.29.2 release
[21:54] <seb128> change in the binary packages?
[21:54] <robert_ancell> change? the binaries were different to 2.29.1
[21:55] <seb128> https://edge.launchpad.net/ubuntu/+source/gnome-games/1:2.29.3-0ubuntu1
[21:56] <seb128> robert_ancell, seems that one got accepted
[21:56] <seb128> could be that 2.29.2 binaries got outdated before the 2.29.3 ones got accepted
[21:56] <robert_ancell> maybe it was some LP weirdness, it went down for maintenance about that time
[21:56] <seb128> could be
[21:57] <seb128> robert_ancell, btw when you resync on debian please use a version higher than debian
[21:57] <robert_ancell> anyway, you guys will be happy, one of my OEM goals is "Assist OEM team in achieving boot time targets, especially related to desktop components "
[21:57] <seb128> and also commit your changes to bzr ;-)
[21:57] <seb128> \o/
[21:57] <seb128> robert_ancell, that rocks
[21:57] <robert_ancell> seb128, whoops, which package?  I meant to do that
[21:57] <pitti> robert_ancell: \o/
[21:57] <seb128> you should read my activity report
[21:57] <seb128> and the meeting log from today
[21:58] <seb128> we covered login speed quite a lot
[21:58] <seb128> robert_ancell, file-roller
[21:58] <seb128> you used -0ubuntu2
[21:58] <seb128> and the bzr is outdated
[21:58] <robert_ancell> can't wait until monday, get my new computer.  Finally will have some fast compiling :)
[21:58] <seb128> robert_ancell, do you get to work on gdm too?
[21:58] <robert_ancell> seb128, yes
[21:59] <seb128> ok, pretty good deal then ;-)
[21:59] <pitti> almost as if he never left :-P
[21:59] <seb128> nobody to annoy you about user complaining and bug triage
[21:59] <seb128> and cool hacking ;-)
[21:59] <robert_ancell> hehe
[21:59]  * seb128 wants to go to oem
[21:59] <robert_ancell> though it may be a lot of perfomance hacking which involves pulling out your hair in frustration :)
[22:00] <ccheney> seb128: if you went to oem you would have to do both parts, heh :)
[22:00] <seb128> robert_ancell, don't tell us
[22:01] <rickspencer3> robert_ancell I guess you're the only one here for Eastern Edition?
[22:01] <rickspencer3> TheMuso is moving house, I seem to recall
[22:01] <robert_ancell> yeah, TheMuso is on holidayt
[22:02] <seb128> when is your meeting?
[22:02] <robert_ancell> my clock says it is now, depends on what timezone you are in :)
[22:03] <seb128> oh good
[22:03]  * robert_ancell reading meeting notes
[22:03] <rickspencer3> robert_ancell, well, I haven't gotten them all on there
[22:03] <seb128> they should be on the irc log server
[22:03] <rickspencer3> but there were a couple of things to go over with you
[22:04] <Amaranth> seb128: Right, I want to split compiz-plugins and compiz-fusion-plugins-main so we don't have to have "universe" versions
[22:04] <robert_ancell> (ominous music)
[22:04] <rickspencer3> robert_ancell, lol, nothing like that ...
[22:04] <rickspencer3> first:
[22:04] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-gdm-custom-greeter-support
[22:04] <seb128> Amaranth, doesn't stop us to move extra to universe now though?
[22:05] <Amaranth> no
[22:05] <rickspencer3> we have that down for a2, but hard to say if you can manage that while on the OEM team
[22:05] <robert_ancell> Amaranth, have a look at the xscreensaver packaging - it will be easier to sync with Debian
[22:06] <robert_ancell> rickspencer3, I think I can commit to documenting what is there for a2, and the remaining components to come in later alphas
[22:06] <rickspencer3> also, some gdm work items that I thought you might be able to help with here:
[22:06] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed
[22:06] <robert_ancell> rickspencer3, do we have a requirement from any other teams who may want to make/modify greeters?
[22:06] <rickspencer3> robert_ancell, not yet
[22:06]  * rickspencer3 moves off a2 list
[22:07] <rickspencer3> robert_ancell, well, actually ... this is an intrusive change, so doing in a2 would be best
[22:07]  * rickspencer3 takes finger off of trigger
[22:07] <robert_ancell> rickspencer3, oh and a clarification,  the a2 list is "must complete by a2", rather than "scheduled to complete by a2"
[22:07] <robert_ancell> rickspencer3, well, the first part is completely non-intrusive - it is just information on how to make a greeter in the current gdm
[22:07] <rickspencer3> more like "committed to fix by a2"
[22:08] <rickspencer3> but these two look a bit risky:
[22:08] <rickspencer3> Simplify API:
[22:08] <rickspencer3> Produce libgreeter:
[22:08] <rickspencer3> in any case, I'
[22:08] <rickspencer3> ll keep documentation on the a2 list and move the others off of it for now
[22:09] <robert_ancell> yes
[22:09] <rickspencer3> it's better to pull items from a3 into a2 rather than push items out of a2
[22:09] <seb128> robert_ancell, speaking about gdm I'm not sure now if you said you would do the 2.29 update
[22:09] <robert_ancell> seb128, yes, I was just going to clarify with you and pitti that we definitely would move to 2.29
[22:09] <seb128> thanks
[22:09] <robert_ancell> I'll do that today
[22:10] <seb128> you rock
[22:10]  * robert_ancell crosses the first item off his list for today
[22:10] <pitti> robert_ancell: are there intrusive changes why we shouldn't?
[22:10] <seb128> not so far
[22:10] <seb128> upstream might land the multiseat changes this cycle
[22:11] <seb128> but I don't think that's an issue
[22:11] <rickspencer3> robert_ancell, so about the gdm items in desktop speed?
[22:11] <rickspencer3> do you think you have bandwidth to help seb128 investigate those?
[22:11] <seb128> (that's what I've read there)
[22:11] <robert_ancell> rickspencer3, I will say probably based on my OEM goals I got this morning
[22:12] <rickspencer3> great
[22:12] <Amaranth> That reminds me, has anyone done a test of compiz vs metacity recently to see what the difference in boot speed is?
[22:12] <rickspencer3> last thing robert_ancell, where should folks get your scanner utility to help test it?
[22:12] <seb128> Amaranth, yes, it's about 3 seconds on login
[22:12] <robert_ancell> it's in my ppa, https://launchpad.net/~robert-ancell/+archive/ppa (best installed with a manual download)
[22:13] <Amaranth> ouch
[22:13] <robert_ancell> I just want to get the cropping support done, then I'll release 0.7 and call for wide testing
[22:13] <robert_ancell> (and push into universe)
[22:14] <seb128> Amaranth, see http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091126-nocompiznautilusxsessiond.png
[22:15] <seb128> Amaranth, compared to http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091127-2.png
[22:15] <rickspencer3> robert_ancell, ready to get it into universe maybe?
[22:15] <seb128> there are other changes but you can compare the wm bars there...
[22:15] <seb128> Amaranth, it's 0.5seconds of cpu use against 11 seconds
[22:16] <Amaranth> hrm, what the heck is all the extra CPU usage
[22:16] <seb128> I'm surprised it's only 3s on boot time
[22:16] <robert_ancell> rickspencer3, yes, for 0.7
[22:16] <Amaranth> iirc it only loads gtk-window-decorator once everything else is loading
[22:16] <Amaranth> s/loading/loaded/
[22:17] <seb128> Amaranth, the decorator is another bar on the graph
[22:17] <seb128> the 11 seconds is without that
[22:17] <Amaranth> I know, thus the confusion
[22:17] <chrisccoulson> no more DK-disks!
[22:17] <chrisccoulson> it's been renamed to udisks now
[22:17] <robert_ancell> seb128, file-roller fixed up
[22:17] <seb128> robert_ancell, thanks
[22:18] <Amaranth> I don't see any WM in that stripped down one
[22:18] <robert_ancell> pitti, is versions on your webserver the active one.  Why is it not updating?
[22:19] <seb128> Amaranth, just after g-s-d
[22:19] <seb128> it's a 0.5 bar
[22:20] <seb128> the colored part I mean
[22:21] <pitti> robert_ancell: oh, it's not?
[22:21] <seb128> I'm also wondering why compiz uses so much cpu
[22:21] <seb128> dropping extra just wins 0.5 seconds
[22:21]  * pitti runs manually
[22:22] <robert_ancell> pitti, I normally run a local one but something has broken it in Lucid
[22:22] <seb128> I would have expected to drop that amonth or .so and .xml to drop some seconds
[22:22] <seb128> robert_ancell, it's uptodate?
[22:23] <seb128> timestamp at the bottom on the page says it ran 22 minutes ago there...
[22:24] <pitti> runs fine here
[22:24] <robert_ancell> seb128, "Last updated: Wednesday November 04 2009 14:10:06 +0100"
[22:24] <robert_ancell> weird... something must be caching it
[22:25] <robert_ancell> http://piware.de/workitems/desktop/karmic/versions.html?
[22:25] <seb128> robert_ancell, cf topic?
[22:25] <robert_ancell> ah, karmic->lucod
[22:25] <pitti> Last updated: Tuesday December 01 2009 23:24:06 +0100
[22:25] <seb128> that's a symlink
[22:25] <robert_ancell> it loads properly now
[22:25] <rickspencer3> lucod is my secret side project
[22:25] <seb128> ok
[22:26] <seb128> rickspencer3, was... ;-)
[22:26] <pitti> oops, it's not any more
[22:26] <rickspencer3> dang it
[22:26] <robert_ancell> rickspencer3, oh sorry, quick clean the irc logs!
[22:26] <seb128> quickly clean irclog
[22:26] <pitti> robert_ancell, seb128: /karmic/versions.html symlink fixed
[22:26] <robert_ancell> lucod = ubuntu all written in quickly
[22:26] <rickspencer3> hehe
[22:26] <seb128> pitti, please drop karmic
[22:26] <seb128> it's confusing people rather than helping apparently
[22:26] <seb128> or put a text saying it's lucid now
[22:26] <pitti> done
[22:26] <seb128> danke
[22:26]  * robert_ancell so many packages to sync...
[22:27] <seb128> robert_ancell, right, I was saying that to rickspencer3 today
[22:27] <seb128> it's mostly my fault
[22:27] <seb128> I've been spending most of my week on boot speed
[22:27] <Amaranth> robert_ancell: What were you saying about xscreensaver and syncing with debian earlier?
[22:27] <rickspencer3> seb128, no one will ever accuse you of slacking
[22:28] <seb128> rickspencer3, we apparently didn't cross the same users in bug reports... ;-)
[22:28] <robert_ancell> Amaranth, oh, xscreensaver has a config file that chooses which screensavers go into which subpackage, that way we can choose different defaults from debian but share all the other packaging code
[22:28] <Amaranth> oh
[22:28] <Amaranth> we don't sync with debian at all for compiz stuff
[22:28] <rickspencer3> hehe
[22:28] <robert_ancell> Amaranth, no but I guess we should think about it sometime
[22:29] <seb128> (there is always some of those saying they don't understand how I couldn't fix their bug they had opened for a week now)
[22:29] <seb128> (that's until they realized that one year later the bug might still be open)
[22:29] <robert_ancell> seb128, do you sync fast?  I find syncing takes me ages (slower than a general update)
[22:29] <chrisccoulson> seb128 - i came across a panel bug yesterday (about applets moving) where it seems you made a good friend ;)
[22:29] <Amaranth> robert_ancell: last time I tried the debian maintainer didn't agree to any of my changes and we do a heck of a lot of modifications to compiz itself and the packaging
[22:30] <seb128> chrisccoulson, heh, yeah, that happens...
[22:30] <chrisccoulson> some users can be quite rude :(
[22:30] <seb128> robert_ancell, sync, pretty fast yes, time to run sync-source, I guess you mean merge, that takes a while indeed
[22:31] <robert_ancell> Amaranth, oh well, as long as we tried :)
[22:31] <seb128> chrisccoulson, I can understand their frustration though, I don't pay much attention to what they wrote or I don't it personally at least
[22:31] <seb128> they is a difference of expectation
[22:31] <seb128> good example of that today
[22:31] <robert_ancell> seb128, yeah the merge.  I never know what to call it, so changelogs say merge, some say sync, some say rebasse
[22:32] <seb128> https://bugs.edge.launchpad.net/hundredpapercuts/+bug/488129
[22:32] <seb128> the current comment
[22:32] <robert_ancell> I'm very tempted to make a snarky comment on the gdm bugs when I close them.  Saying "all this discussion has just slowed down development and if it was so damn easy why are there no patches here?"
[22:32] <seb128> there is lot of users wanting to describe their difficulties using the software or their experience which is different from what we expect from bugs
[22:33] <rickspencer3> robert_ancell, don't give in to the temptation
[22:33] <robert_ancell> rickspencer3, I know, but it is very tempting :)
[22:33] <seb128> robert_ancell, I sometime to do but luckily I've greasemonkey replies
[22:33] <rickspencer3> we should always strive to answer their hostility with kindness
[22:33] <robert_ancell> rickspencer3, wise words
[22:34] <rickspencer3> break the cycle of hostility, it will be much more efficient in the long run
[22:34] <seb128> I'm not so wise
[22:34] <rickspencer3> and also, just a lot nicer place to be
[22:34] <seb128> I would tend to say to just stay away from those discussions
[22:34] <seb128> especially if somebody already made your point on the bug
[22:34] <Amaranth> robert_ancell: I've given some snarky replies to compiz bugs
[22:34] <seb128> and they just decided to ignore it and keep complaining
[22:34] <seb128> there is just no point
[22:35] <rickspencer3> right, I just ignore people who aren't being constructive
[22:35] <Amaranth> Otherwise I just go passive aggressive and put their bug on the end of my list to look at
[22:35] <robert_ancell> seb128, it would be nice to be able to mark a bug as "I've read this, don't notify me of any more comments"
[22:35] <Amaranth> behind the other 470 or so compiz it up to now
[22:35] <seb128> robert_ancell, indeed, I keep saying I want a "I don't care button"
[22:35] <rickspencer3> sometimes in a string of non-constructive commentors someone tries to say something that is useful, I'll usually specify a reply to them, and thank them for contributing while I'm at it
[22:36] <seb128> could be useful for corner cases bugs I will never look at
[22:36] <seb128> or complain bugs
[22:36] <robert_ancell> oh, does anyone know how to show the bug stats of a package over time?
[22:36] <rickspencer3> Amaranth, seb128 surely you could set up a tag and then filter out bugs with that tag?
[22:36] <robert_ancell> Amaranth, I was trying to see the trend for compiz
[22:36] <Amaranth> rickspencer3: sure, let me setup a 'jerk' tag :)
[22:36] <seb128> you don't have tags in bug lists
[22:36] <seb128> it would mean always doing custom queries rather than browsing launchpad
[22:37] <rickspencer3> seb128, or using bughugger
[22:37]  * rickspencer3 shameless plug
[22:37] <seb128> I guess I could but I didn't do it yet
[22:37] <rickspencer3> you can filter in and out on tags in bughugger
[22:37] <seb128> I should be using bughugger
[22:37] <robert_ancell> what would we call the tag?  Something blatant or subtle
[22:37] <rickspencer3> seb128, you don't need to humor me
[22:38] <seb128> I was somewhat waiting on a call for testing or an announce as it to be user ready to use it
[22:38] <seb128> but I should maybe give it a try again
[22:38] <rickspencer3> robert_ancell, well, there is a standard tag called ct-rev that is supposed to mean "canonical team reviewed" (and we aren't going to fix it)
[22:38] <seb128> I was just under the impression it was not production ready yet ;-)
[22:38] <rickspencer3> but the usage never really caught on
[22:38] <rickspencer3> seb128, it's in the bughugger PPA, bdmurray is getting it ready for universe
[22:39] <robert_ancell> rickspencer3, I guess we want a ct-ready.  Meaning it's ready to fix and we wont monitor it anymore
[22:39] <seb128> tagging is work from launchpad, but maybe bughugger will be the answer there
[22:39] <rickspencer3> well, you could write script to tag selected bugs with bughugger and drop it into the plugins fodler
[22:39] <seb128> I'm still not decided on what would be my idea workflow
[22:40] <rickspencer3> or at least that's the idea, I haven't tested it with a real plugin yet
[22:40] <seb128> either I want to know about
[22:40] <rickspencer3> robert_ancell, for ct-ready, I think we need more smarts for that
[22:40] <rickspencer3> this is where bryce has a lot of good knowledge that we need to harness
[22:40] <seb128> - bugs I never looked at or bugs I've opt-in because I'm interested
[22:40] <seb128> or
[22:41] <seb128> - bugs which got a higher number of comments or duplicates and that I didn't opt-out
[22:41] <rickspencer3> seb128, I bet bryce could help you write those scripts
[22:41] <rickspencer3> then we could plug them into bughugger
[22:41] <seb128> one means reading quickly through new emails and opt-in things
[22:42] <rickspencer3> when you wake up in the morning it could load that list for you while you sip coffee and chat
[22:42] <seb128> the other one would mean being confident in the system to raise common or important issues
[22:42] <rickspencer3> then you can operate on the list of bugs in batches
[22:42]  * bryce reads scrollback
[22:43] <rickspencer3> seb128, that
[22:43] <rickspencer3> s a tough point to automate
[22:43] <rickspencer3> but again, I think bryce does a pretty good job at that for xorg
[22:43] <seb128> yes
[22:43] <seb128> we should really look at making extra use of bryce scripts over other components
[22:44]  * rickspencer3 chuckles
[22:44] <bryce> re: rude users... yeah my feelings exactly.
[22:46] <bryce> what gets really annoying is if you close it with some snarky reply, and then the bug gets linked to by some online journalist
[22:46] <bryce> they never seem to go for the vast number of bug reports where you've shown kindness
[22:46] <rickspencer3> bryce, speaking from experience?
[22:47] <rickspencer3> tbh. the rude users I feel sorry for usually, it's the link bait writing bloggers that get a bit under my skin
[22:47] <rickspencer3> "Ubuntu Dumps the Gimp"
[22:47] <rickspencer3> *sigh*
[22:48] <rickspencer3> bryce, how about generalizing those xorg scripts though, there's some goodness there I think
[22:48] <rickspencer3> how could we go about that?
[22:49] <bryce> yes.  experience.  bleah.
[22:49] <bryce> rickspencer3, sure
[22:49]  * rickspencer3 pats bryce on the shoulder
[22:50] <bryce> rickspencer3, first thing we need is a definition of a list of packages to run the scripts on
[22:50] <rickspencer3> bryce, you do such an awesome job for so many users
[22:50] <rickspencer3> bryce, I think bdmurray has that for the whole desktop team
[22:50] <rickspencer3> but for seb128, I think the list of packages that the ubuntu-desktop-team subscribes to would be right
[22:50] <bryce> for X I screenscrape this page to get the package list:  https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs
[22:51] <seb128> it's similar for desktop, use the desktop-bugs team on launchpad
[22:52] <bryce> ok, so with that in hand, several scripts like my expire script, will work unmodified
[22:53] <bryce> for others, I generally write up a bit of text to explain to them what's going on, and that is X specific but could be replaced or adapted without too much work
[22:53] <bryce> probably the most useful script for you guys also has the most domain knowledge built in, and that's the "new bug processor", which checks for appropriate files to be attached, etc.
[22:54] <bryce> that one really helps sort the wheat from the chaff
[22:54] <bryce> but deciding what you think is wheat would take some of your own know-how
[22:55] <Amaranth> dang chromium user scripts are broken again
[22:55] <rickspencer3> bryce, don't you have some scripts that detect "ripeness"?
[22:55] <seb128> bryce, I should have a look to those
[22:55] <rickspencer3> like this one has duplicates and has a patch and has all the necessary logs, I should tell bryce about it?
[22:55] <seb128> but most desktop bugs don't require apport infos
[22:56] <rickspencer3> sort of like bug heat + bug tractability
[22:56] <bryce> rickspencer3, yes I have some reporting tools which you'd also find useful
[22:56] <seb128> and we don't do extensive use of apport hooks for now
[22:56] <seb128> bryce, where are your tools stored? in a public place?
[22:56] <seb128> is there some documentation on what tools you use and what they do?
[22:56] <rickspencer3> seb128, when you look for a bug that seems that it is addressable, what do you look for?
[22:57] <rickspencer3> or do you just look for "heat" (seems to be a problem)?
[22:57] <seb128> rickspencer3, open upstream bugs about the issue or the code?
[22:57] <seb128> or in which context do you mean?
[22:57] <bryce> there is also one for applying symptom tags which is *really* handy but also extremely xorg-specific, with regex's to match key phrases in descriptions, e.g. "blank screen" "fonts too big", etc. You'd want to come up with your own list of regex's
[22:57] <bryce> seb128, yeah it's in the 'arsenal' bzr tree, I'll give you a link
[22:57] <seb128> bryce, thanks
[22:57] <bryce> ogasawara made a branch where she keeps her versions that are customized for the linux kernel
[22:58] <seb128> I think I will have a look to what you have there first so we can make a list of what could be useful for other things
[22:58] <seb128> or for desktop at least
[22:58] <bryce> https://code.edge.launchpad.net/arsenal
[22:58] <seb128> rickspencer3, my main issue right now is getting useful bugs out of the noise
[22:58] <rickspencer3> seb128, so if you had a script that told you "this bug is linked to an upstream bug, and that upstream bug has a patch with it" that would save you effort?
[22:58] <seb128> I've given up on deleting noise
[22:58] <bryce> seb128, yeah me too
[22:58] <rickspencer3> seb128, okay, so what makes it useful?
[22:59] <seb128> I want to know:
[22:59] <seb128> - bugs which annoy many users
[22:59] <seb128> - import issues
[22:59] <bryce> lately I've been pondering making a report tool that lists only bugs from reporters with karma >= $threshhold
[22:59] <seb128> important
[22:59] <seb128> - regressions (especially in the stable updates)
[23:00] <bryce> another report, which folks at UDS liked seeing - bugs with patches attached, across all X components, sortable by patch age:  http://www2.bryceharrington.org:8080/X/Reports/patches.html
[23:00] <seb128> and then I guess:
[23:00] <seb128> - bugs with enough informations to be useful directly
[23:00] <seb128> - bugs which would be easy to fix and make a difference (hundredpapercut somewhat try to address that one)
[23:00] <rickspencer3> - bugs which annoy many users = seems easily scriptable (look for dupes and comments)
[23:01] <rickspencer3> sorry, thought you were done
[23:01] <seb128> I'm done
[23:01] <seb128> agreed, that is somewhat what we discussed at uds with bug heat
[23:02] <seb128> bryce, that seems useful too
[23:02] <rickspencer3> seb128, yeah, I think you want heat + addressability
[23:02] <seb128> right
[23:02] <seb128> + random side lists would be nice
[23:02] <seb128> like bugs with patches
[23:02] <seb128> bugs fixed upstream
[23:02] <bryce> I have also done a report which includes some of that info, although this link is rather old - http://www2.bryceharrington.org:8080/X/Milestones/milestones_20080708.html
[23:02] <rickspencer3> these all seem scriptable, and I
[23:02] <seb128> bugs with patches in upstream bug trackedr
[23:02] <seb128> tracker
[23:02] <bryce> it's on my todo list to turn that into something more directly useful
[23:02] <rickspencer3> m betting that bryce has 80% of the functionality you need alread
[23:02] <bryce> but you can see it's easy to show stuff like #comments, #dupes, etc. etc. and sort by that
[23:02] <rickspencer3> maybe pedro could help us generalize these tools
[23:03] <seb128> yes, I will to him
[23:03] <seb128> I think one issue we will run into is the server side
[23:03] <rickspencer3> I'd like to get them baked into bughugger, because then you can tell engineers:
[23:03] <rickspencer3> "get bughugger then run the following commands"
[23:03] <rickspencer3> to spread the bryce goodness faster
[23:03] <bryce> yeah I would love to have help in generalizing this stuff, I mean to myself, just that X keeps me too busy sometimes
[23:04] <rickspencer3> bryce, right, it's hard to run your rather large project, and also do meta work on top of it
[23:05] <bryce> rickspencer3, otoh it keeps me focused on what is _really_ useful
[23:05] <seb128> ups
[23:05] <rickspencer3> yes, the critical "Important/Not Urgent" quadrant
[23:06] <rickspencer3> the more work you do there, the less ends up in the dreaded "Important/Urgen" quadrant
[23:06] <bryce> I am going to set up a new launchpad account for running the scripts as cronjobs under
[23:06] <bryce> I'd be happy to include cronjobs in that which run on more than just X stuff, as people are interested
[23:07] <rickspencer3> btw ... https://edge.launchpad.net/~bughuggers/+archive/bughugger
[23:08] <rickspencer3> thanks bryce that would be great
[23:08] <seb128> bryce, noted, thanks
[23:09] <seb128> rickspencer3, I will check out bughugger again when I've some free slot
[23:09] <seb128> ie next time I do bug triage
[23:09] <seb128> I've done almost none this week
[23:09] <rickspencer3> seb128, thanks
[23:13] <pitti> good night everyone
[23:13] <seb128> 'night pitti
[23:14] <seb128> pitti, btw you can cross gst-plugins-good from you list now
[23:14] <seb128> pitti, I've synced on debian which uses the udev configure option
[23:14] <pitti> yay you
[23:14] <pitti> seb128: dropped hal build/binary deps?
[23:14] <robert_ancell> pitti, night
[23:15] <seb128> pitti, hum in fact not it uses both, I wil check with slomo tomorrow
[23:16] <seb128> 'night pitti
[23:16] <pitti> seb128: ah, let's keep bug 430099 open until it's gone then
[23:16] <seb128> right
[23:17] <seb128> robert_ancell, oh, forgot to keep replying about time sinks that are syncs before
[23:17] <seb128> indeed takes longer to do those that update for me too
[23:17] <seb128> that's good to try to do it once a cycle at least though
[23:17] <seb128> it somewhat forces us to send changes we can send to debian or upstream
[23:17] <seb128> and sometime debian has interesting changes
[23:18] <seb128> if packages are too much different I don't bother though
[23:18] <seb128> ie gdm or gnome-games in karmic
[23:18] <seb128> still good to have a look to what debian changed and cherry pick interesting things if there is any
[23:18] <pitti> seb128: related to that, evo dropped hal stuff a while ago, so evo's b-dep on libhal-dev can probably go, too
[23:19] <seb128> pitti, ok, I will have a look next time I do an upload
[23:19] <pitti> http://git.gnome.org/cgit/evolution/commit/?id=5a80f92d37e7e8a814f70f826b7b33f5d21b0f72
[23:19] <robert_ancell> seb128, the bug I open with Debian the most is "please list the dependencies on multiple lines to make diffing easier :)"
[23:19] <pitti> but not urgent at all
[23:21] <seb128> hum
[23:21] <seb128> the current source still has ipod-sync
[23:21] <seb128> and it's built
[23:21] <seb128> but I guess we can stop doing that
[23:21] <pitti> seb128: perhaps that was done after 2.28?
[23:21] <seb128> yes
[23:21] <seb128> and we said we would stay on 2.28
[23:21] <pitti> anyway, it'll just come with the regular updates
[23:21] <pitti> oh, right
[23:21] <seb128> but the plugin is pretty useless I think
[23:22] <pitti> seb128: nevermind; it's just the library, and I don't think there's any urgency to get rid of it in lucid
[23:22] <seb128> I will clean it during lucid cycle
[23:34] <garrythefish> not enough drilling. that's what's the problem with the lesbos at #ubuntu-women
[23:35] <garrythefish> see ya :)
[23:36] <chrisccoulson> pah, gconfd provides a way of toggling debug mode on/off in an already running daemon, but it doesn't work unless you started it with debug, as it routes stdout to /dev/null