[07:15] <pitti> Good morning
[07:16] <pitti> gabaug: hal> not completely removed from the archive, of course; there are still many rdepends (KDE is the biggest one)
[07:16] <didrocks> hello pitti :)
[07:16] <didrocks> how are you?
[07:17] <pitti> bonjour didrocks! I'm great, thanks!
[07:17] <pitti> it's just effing cold outside :-(
[07:17] <pitti> we have snow since Saturday
[07:18] <didrocks> same here. Snow in Paris on Sunday! :) The only counter-part is that I've waited for my bus yesterday evening for 40 min in the cold :/
[07:24] <didrocks> netvertheless, I had the time to resubmit a new patch to bug #496301. If you have some time today... we will get an une desktop session :)
[07:24] <didrocks> hope it's good this time :)
[07:26] <bryce> heya guys
[07:26] <didrocks> hey bryce
[07:27] <didrocks> you were on vacations, weren't you?
[07:27] <bryce> yes, for 1 week
[07:28] <pitti> hey bryce, good morning
[07:28] <pitti> or, evening
[07:28] <pitti> enjoyed your time off?
[07:28] <bryce> unfortunately had a cold and was sick for most of it, so not so much :-/
[07:29] <pitti> ugh, what a bad timing :(
[07:29] <pitti> I usually don't mind so much having a cold when working, but during holidays it sucks
[07:29] <bryce> with remainder, did xmas decoration/shopping/partying/etc.
[07:30] <bryce> yeah, wasn't too bad of a cold, but made me too tired to do anything productive
[07:32] <bryce> pitti, looks like xserver 1.7 is all in; still awaiting the new -wacom to get into debian
[07:40] <pitti> bryce: yeah, I'm totally happy that we could push that into alpha1!
[08:33] <chrisccoulson> good morning everyone
[08:35] <seb128> hey
[08:36] <chrisccoulson> hey seb128
[08:36] <seb128> hello chrisccoulson
[08:36] <chrisccoulson> how are you today?
[08:37] <seb128> good I think
[08:37] <seb128> let me go through another round of coffee before confirming ;-)
[08:37] <seb128> how are you?
[08:38] <chrisccoulson> yeah, i'm ok. quite tired though, as i ended up having quite a late night last night
[08:38] <chrisccoulson> coffee sounds like a good idea :)
[08:39] <didrocks> salut seb128, ça va?
[08:39] <didrocks> hey chrisccoulson
[08:39] <chrisccoulson> hey didrocks, how are you?
[08:39] <seb128> lut didrocks
[08:39] <didrocks> chrisccoulson: the weather is cold, but I'm fine, thanks :-) and you? tired apparently?
[08:40] <chrisccoulson> heh, yeah. the weather is starting to turn cold here too
[08:40] <chrisccoulson> snow forecast this week (hopefully)
[08:45] <seb128> oh, pitti starts rocking early in the day, thanks for the indicator-application newing and the sru review
[08:47] <pitti> seb128: bonjour
[08:47] <seb128> hey pitti
[08:47] <pitti> seb128: I source/binary-NEWed it into main
[08:47] <seb128> thanks
[08:47] <seb128> I was going to ask about main next
[08:47] <pitti> packaging is fine now, and a MIR wouldn't give us additional information really *shrug*
[08:47] <seb128> dunno if you read backlog from yesterday or not
[08:47] <pitti> "yet another indicator"
[08:47] <pitti> I'm rather interested in how it affects startup speed :)
[08:47] <seb128> right, new package, like no security record, upstream tracker to watch or debian packaging, etc
[08:47] <seb128> I'm about to do daily charts
[08:48] <seb128> the mini just finished upgrade
[08:49] <pitti> after today's dist-upgrade, the message and user indicator just say "no notifications" (literally, in the panel), hmm
[08:50] <seb128> pitti, you got indicator-applet 0.3?
[08:50] <seb128> kenvandine and tedg don't know about Breaks apparently
[08:50] <pitti> seb128: no, I don't have that yet, I just NEWed it
[08:50] <seb128> at least tedg didn't before I explained yesterday
[08:51] <pitti> oh, sorry, no; I NEWed i-application
[08:51] <pitti> I have i-applet 0.2.0
[08:51] <seb128> indicator-applet is an upgrade"
[08:51] <seb128> it was about to build when I went to bed
[08:52] <seb128> pitti, what arch?
[08:52] <pitti> amd64
[08:52] <seb128> the amd64 built finished 4 hours ago
[08:52] <seb128> weird
[08:52] <seb128> did you just upgrade?
[08:52] <seb128> do you use a mirror?
[08:52]  * pitti upgrades again
[08:52] <pitti> no, this morning, and I'm using archive.u.c.
[08:53]  * pitti got up two hours ago already, though
[08:53] <seb128> 4 hours ago, with publishing etc it might have been one round after your upgrade
[08:53] <pitti> right, there it comes
[08:53] <pitti> merci
[08:53] <seb128> de rien ;-)
[08:55] <chrisccoulson> hey pitti - do you want me to look at the g-p-m update (or do you plan to look at it today)?
[08:55] <pitti> chrisccoulson: please go ahead if you want
[08:55] <chrisccoulson> pitti - cool, i'll take that one then
[08:55] <pitti> thanks!
[08:55] <seb128> urg, ctrl-w on the wrong screen agai
[08:55] <seb128> +n
[08:57] <seb128> note to self, the focus is not always on the screen you look at
[08:57] <pitti> haha, trapped in dual-screen? :-)
[08:57] <seb128> I'm wondering if I should unset ctrl-w in xchat-gnome
[08:57] <seb128> pitti, yes, I've IRC on one screen and webbrowser on the other
[08:58] <seb128> and I keep closing IRC tabs instead of firefox ones
[09:01] <seb128> chrisccoulson, good work on the gnome-python-extras update ;-)
[09:02] <chrisccoulson> seb128 - i should probably not do disruptive updates late at night next time ;)
[09:02] <chrisccoulson> it turned in to quite a late one in the end
[09:36]  * seb128__ kicks his dsl line today
[10:24] <seb128> re
[10:24] <seb128> Keybuk, it's weird, your bootchart are over 2 seconds off compared to mines there
[10:24] <seb128> and I reinstalled my box with alpha1 yesterday and upgraded
[10:24] <seb128> so I should have no custom changes
[10:25] <seb128> the mark is around 18s there
[10:25] <seb128> and yours is over 20s
[10:26] <pitti> wow, seems the new kernel reduced boot time quite a bit
[10:27] <Keybuk> seb128: which are yours?
[10:27] <Keybuk> pitti: yeah I'm hoping it will
[10:27] <seb128> Keybuk, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091215-1.png
[10:27] <pitti> 4.2 vs. 2.8 seconds
[10:27] <seb128> Keybuk, see the xorg activity
[10:27] <seb128> it takes some 1.5 seconds and 3 seconds for you
[10:27] <Keybuk> seb128: yours has -8 :-)
[10:28] <Keybuk> -8 is full of patchy goodness
[10:28] <Keybuk> including patches to the i915 driver
[10:28] <Keybuk> mine from yesterday still have -7
[10:28] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091214-max.png
[10:28] <Keybuk> (and on a completely different mini)
[10:28] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091214-ratchet.png
[10:28] <seb128> I think my charts were already under 20 seconds yesterday
[10:29] <seb128> but I wiped those in the reinstall now
[10:29] <Keybuk> depends when yesterday
[10:29] <Keybuk> live fs builds are basically over night
[10:29] <seb128> ok
[10:29] <Keybuk> so yesterday's charts were really "the night before's" distro
[10:29] <seb128> it might be it then
[10:29] <seb128> where is your current guess-time btw?
[10:29] <Keybuk> there isn't a current one
[10:29] <seb128> your desktop count seems different from the ones I get with the version you gave me some time ago
[10:29] <Keybuk> I merged all that code back into bootchart
[10:30] <seb128> guess-time give me desktop times between 10.3 and 10.8
[10:30] <seb128> and your marks are over 11 seconds
[10:30] <Keybuk> right, the current code is a bit more strict
[10:30] <Keybuk> http://people.canonical.com/~scott/make-bootchart
[10:30] <Keybuk> ^ that's a good script ;)
[10:30] <seb128> thanks
[10:31] <Keybuk> it'll output the times on stdout in the order total, time-to-kernel, time-to-x, etc.
[10:31] <Keybuk> desktop is the total minus time to gdm-session-worker starting, etc.
[10:31] <Keybuk> you can also do NO_PRUNE=1 make-bootchart ...
[10:31] <Keybuk> to get much more detail
[10:37] <seb128> Keybuk, for CHART_TGZ do?
[10:38] <seb128> should that be with a "in ...;"
[10:38] <seb128> ?
[10:38] <Keybuk> that's the argument on the command-line
[10:38] <Keybuk> for FOO means "for each argument"
[10:38] <seb128> oh ok
[10:39] <seb128> (I hate touchpads)
[10:39] <seb128> (keep clicking without wanting to while typing)
[10:41] <tseliot> seb128: you can disable clicks when typing
[10:42] <seb128> tseliot, that option is on by default in karmic and lucid
[10:42] <seb128> but that seems to be a fail for me on the mini10v
[10:42] <seb128> dunno if I let my hands laying around for a second after typing or something
[10:42] <seb128> or if that's buggy
[10:43] <tseliot> seb128: are you saying that you can still click when typing?
[10:43] <seb128> no, I'm saying I keep having jumping cursor
[10:43] <seb128> random selections
[10:43] <hyperair> syndaemon was configured with too long a delay in karmic iirc.
[10:43] <seb128> and I'm only using the keyboard, I've an external mouse
[10:44] <seb128> ie I must be touching the touchpad with my palms or something
[10:44] <hyperair> when you pause typing for a while and then shift a little, you could accidentally trigger the touchpad
[10:44]  * hyperair has the same issue
[10:44] <seb128> yes
[10:44] <seb128> or when I place my hands over the keyboard before starting typing
[10:44] <seb128> I touch the touchpad on the way
[10:44] <hyperair> the delay is half a second, which is too short.
[10:44] <seb128> and it mess cursor before I start typing
[10:45]  * seb128 wants the option to disable touchpad back
[10:45] <tseliot> seb128: that can be done
[10:45] <hyperair> isn't there a hardware button to disable it?
[10:45]  * hyperair has some fn key for it
[10:45] <tseliot> yes, on some laptops
[10:45] <hyperair> hmm not all eh
[10:46] <tseliot> seb128: if that change is welcome I'll do it
[10:46] <seb128> tseliot, that would be great
[10:47] <Keybuk> tjaalton: any idea when that xkbcomp patch will be fixed?
[10:47] <seb128> Keybuk, seems you are almost on target for the non desktop part of boot now
[10:47] <seb128> 18 seconds, 11 being desktop
[10:48] <tseliot> seb128: ok then
[10:48] <seb128> which means you use 7 seconds with a 6 seconds target?
[10:48] <seb128> tseliot, thanks
[10:48] <tseliot> what happened to the xkbcomp patch?
[10:48] <Keybuk> it's broken and tjaalton disabled it
[10:48] <Keybuk> seb128: right, though that's without a splash screen
[10:49] <Keybuk> which will add time
[10:49] <seb128> good point
[10:49] <Keybuk> you might think that having it disabled at the moment is deliberate to prove just how much boot time having a splash screen adds ;)
[10:49] <tseliot> Keybuk: let me check, I think I can adapt it to the new X
[10:49] <Keybuk> tseliot: if you can, that would be awesome
[10:53] <tjaalton> yep, it's quite big and I don't have much time this week
[10:54] <tjaalton> tseliot: enable it & build, see how it fails
[10:55] <tseliot> tjaalton: I've applied the patch and it fails to patch configure.ac (which is trivial to fix) and xkb/ddxLoad.c (only two hunks)
[10:55] <tjaalton> tseliot: uh, it should apply, just fails to build
[10:56] <tjaalton> right, applies here
[10:56] <tseliot> tjaalton: do you have a link to that patch? (in case I'm using the wrong one)
[10:57] <tjaalton> tseliot: yes, git clone git://git.debian.org/git/pkg-xorg/xserver/xorg-server :)
[10:57] <tjaalton> or apt-get source
[10:57] <tjaalton> it hasn't changed since bryce updated it to apply
[10:58] <tseliot> ah, right you only removed the patch from the series file
[10:58] <tjaalton> yes
[11:00] <tjaalton> but you have commit rights, fix it in git
[11:01] <tjaalton> hmm, seems that you don't
[11:02] <tseliot> I don't
[11:02] <tjaalton> create an account on alioth, and we'll sort it out
[11:02] <tjaalton> (.debian.org)
[11:03] <tseliot> ok
[11:07] <Keybuk> seb128: ugh, dkms screwed up the boot totally
[11:07] <Keybuk> 4s :-/
[11:07] <Keybuk> and do you know what it took that 4s to do?
[11:07] <Keybuk> figure out that it had *nothing* to do
[11:08] <seb128> :-(
[11:08] <tseliot> tjaalton: when I click on the URL to activate my account I get an error: "Error Could Not Get User"
[11:08] <seb128> Keybuk, btw do you know if the gdm to gnome-session 0.8 seconds are due to the udev-acl.ck?
[11:08] <seb128> the bar for that process seems to just fit in the gap between those
[11:09] <Keybuk> seb128: yes, likely
[11:09] <tjaalton> tseliot: filled all the mandatory fields?
[11:09] <seb128> Keybuk, is that something you plan to look at?
[11:09] <tjaalton> tseliot: -> #u-x
[11:10] <tseliot> tjaalton: username and password were the only fields that I could see
[11:10] <tseliot> ok
[11:10] <Keybuk> seb128: it's not directly on my list, pitti might want to though
[11:10] <seb128> pitti, ^
[11:10] <Keybuk> it's the ck bit
[11:10] <seb128> it's almost a quarter of our login budget
[11:10] <pitti> seb128: haven't looked at this one yet; mind adding a work item for me? (sorry, busy ATM)
[11:10] <seb128> a fifth to be exact
[11:11] <seb128> pitti, ok, will do
[11:24] <sabdfl> Keybuk: is there an equivalent of ureadahead for the post-login pieces?
[11:25] <Keybuk> sabdfl: ureadahead covers them
[11:25] <Keybuk> if you mean things like gnome-panel
[11:25] <sabdfl> assuming the same person logs in
[11:30] <Keybuk> of course
[11:30] <Keybuk> there is that assumption
[11:31] <tseliot> Keybuk: I have fixed the xkbcomp patch
[11:32] <Keybuk> tseliot: \o/
[11:32] <tseliot> :-)
[11:33] <Keybuk> pitti: I have fixed dkms ;)
[11:33] <Keybuk> I copied the logic from update-initramfs into it
[11:33] <pitti> yay you
[11:33] <Keybuk> module package postinst will rebuild the module for the "right" kernel version
[11:33] <Keybuk> installing a newer kernel later will rebuild the modules
[11:34] <Keybuk> if you boot an older kernel, you probably won't have the newer module, but that's probably *right*
[11:34] <Keybuk> (one assumes you're booting the older kernel because you had a problem)
[11:34] <tseliot> what if you don't have a module for the old kernel?
[11:35] <Keybuk> tseliot: then you didn't have a module for the old kernel before either
[11:35] <Keybuk> so it will work just as well as the last time you used that kernel :p
[11:35] <tseliot> Keybuk: right but the module should me built on boot in that case
[11:35] <Keybuk> no it shouldn't
[11:36] <Keybuk> your booting an old kernel
[11:36] <Keybuk> things should not be rebuilt for it
[11:36] <Keybuk> because it might be that very thing that broke
[11:36] <Keybuk> the only reason to ever keep an old kernel around is to be able to go back to *something that worked*
[11:37] <tseliot> ok good point
[11:46] <Keybuk> tseliot: fixed xkbcomp patch => can you upload or do you need someone else to?
[11:52] <tjaalton> I can do that
[11:52] <Keybuk> please do
[11:52] <Keybuk> I'm eager to get a "perfect bootchart" of the current set of updates
[11:52] <Keybuk> before I ruin it by turning plymouth on :p
[11:52] <tjaalton> hehe
[11:58] <tseliot> Keybuk: sure, I'll push changes
[12:05] <tseliot> pitti: do you think we can discuss the nvidia name schemes at the desktop meeting?
[12:27] <pitti> tseliot: sure, if you think you can benefit from more input
[12:29] <tseliot> pitti: yes, I would like to discuss that and an idea that superm1 and Sarvatt had about reducing the number of packages that each nvidia source package generates
[12:29] <tjaalton> which one was that?
[12:34] <Keybuk> tjaalton, tseliot: did you upload that new xkbcomp patch yet?
[12:34] <tjaalton> Keybuk: on the way
[12:34] <tseliot> Keybuk: tjaalton will do that for me
 :D
[12:34] <Keybuk> AWTY!
[12:35] <tseliot> tjaalton: basically they suggested that we have something like nvidia-190 (which includes glx, kernel-source, vdpau), modaliases and nvidia-190-dev
[12:36] <tjaalton> tseliot: they all are needed anyway=
[12:36] <tjaalton> ?
[12:36] <tseliot> tjaalton: the first two are always installed
[12:36] <tjaalton> and what occured to me was that the "current" source package can be just "nvidia-graphics-drivers" without any version
[12:37] <tseliot> yes, that's a separate part of the plan
[12:37] <tjaalton> that way there's no need to shove all the bugs to a new version
[12:37] <tjaalton> yes, but that would still build nvidia-XXX
[12:38] <tseliot> ???
[12:38] <tjaalton> binary package
[12:39] <tseliot> aah, you were referring to the source package
[12:39] <tjaalton> as a bug triager the only benefit to rename the package to something that doesn't change is that the bugs are always filed to the same package
[12:39] <tjaalton> right
[12:39]  * tseliot nods
[12:39] <tjaalton> doesn't matter what binaries it produces
[12:40] <tseliot> yes and I was thinking about not needing the package to be in NEW when nvidia bumps the release number
[12:40] <tjaalton> and I can't see a way to make upgrades robust enough without having the major version in the binary name
[12:40] <tjaalton> that too
[12:40] <tseliot> which I'm sure the archive admins will appreciate
[12:40] <tjaalton> unless of course, the package is removed on upgrade :)
[12:41] <tjaalton> since I went through a bunch of crashers and some of them occured during a dist-upgrade
[12:41] <tseliot> tjaalton: what if the version in written in the modalias file?
[12:41] <tseliot> and we use nvidia-common to handle the transition
[12:42] <tseliot> (with update manager)
[12:42] <tjaalton> it was just an idea, probably too radical anyway ;)
[12:43] <tseliot> we can discuss it at the desktop meeting
[12:43] <tjaalton> when was that?
[12:44] <tjaalton> Keybuk: "no" ;)
[12:44] <tseliot> tjaalton: today at 17:30 CET
[12:44] <Keybuk> tjaalton: hmm?
[12:44] <tseliot> I assume that we're in the same time zone
[12:44] <tjaalton> Keybuk: thin Homer (S.)
[12:44] <tjaalton> thinK
[12:45] <tjaalton> tseliot: nope, EEST here ;)
[12:45] <tseliot> d'oh
[12:45] <tjaalton> oh wait, that summer time
[12:45] <tjaalton> anyway, 18:30
[12:45] <seb128> tjaalton, 16:30 utc
[12:46] <tjaalton> yep
[12:46]  * tseliot uses google calendar so that he doesn't have to deal with time zones
[12:47] <Keybuk> that works up until the point you realise that google calendar doesn't deal with time zones either
[12:49] <tseliot> Keybuk: ???
[12:49] <Keybuk> tseliot: it gets daylight savings time very horribly wrong
[12:49] <pitti> actually that seems to work quite well nowadays
[12:49] <tseliot> it has always worked for me but I have used it only since I joined Canonical
[12:49] <pitti> either that, or Rick uses CET for all his calendaring activity :)
[12:50] <tseliot> heh
[12:53] <tjaalton> Keybuk: uploaded
[13:02] <Keybuk> \o/.
[13:02] <Keybuk> I shall have lunch while that builds
[13:10] <chrisccoulson1> whoa, only 6 people in here?
[13:10] <chrisccoulson1> ah
[13:10] <pitti> seb128: do you have a minute to check out https://wiki.ubuntu.com/DesktopTeam/Developers ?
[13:10] <pitti> seb128: that's the proposed policy for adding new ubuntu-desktop members, similar to what you wrote by email the other day
[13:14] <seb128> pitti, ok looking
[13:15] <seb128> pitti, looks great, thank you for writting it and keeping paperwork level low there ;-)
[13:16] <pitti> yay
[13:18] <pitti> seb128: are you still actually using https://wiki.ubuntu.com/DesktopTeam/TODO ?
[13:18] <seb128> pitti, no
[13:18] <pitti> seb128: I'm inclined to drop that and remove TODO and WeeklyTodo (which is a nonexisting page) from https://wiki.ubuntu.com/DesktopTeam
[13:18] <pitti> we have versions.html now
[13:18] <seb128> right
[13:18] <seb128> I use the title urls
[13:19] <seb128> versions and milestoned bug tasks
[14:14] <kwwii> mvo: hey, I am trying to get charlines computer up to the latest usable software-center (the one with all the apps)
[14:14] <kwwii> mvo: I added the ppa to her sources and updated but it still seems the same, does she need to use the daily-build?
[14:15] <kwwii> mvo: erm, ignore that
[14:16] <kwwii> sorry
[14:53] <pitti> tseliot, ArneGoetje, bryce, ccheney, Riddell, kenvandine, seb128: please add your weekly report to https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-12-15 ; thanks!
[14:53] <kenvandine> pitti, will do
[14:53] <tseliot> sure
[14:53] <seb128> oh wiki page is there now ;-)
[14:54] <pitti> just created it
[14:54] <Riddell> pitti: activity report?
[14:54] <pitti> right
[14:54] <seb128> pitti, no rickspencer3 today?
[14:54] <pitti> seb128: he'll be in a meeting at that time
[14:54] <seb128> kenvandine, hey
[14:54]  * fake_rickspencer makes whip cracking noises
[14:54] <kenvandine> hey seb128
[14:55] <kenvandine> hehe
[14:55] <fake_rickspencer> you will all get a payrise, btw
[14:55] <seb128> kenvandine, is rb supposed to install the indicator-application binary?
[14:55] <seb128> pitti, ;-)
[14:55] <rickspencer3> :)
[14:55] <seb128> I'm supposed to have my weekly call with rick before meeting
[14:55] <kenvandine> seb128, you mean as a dep?
[14:55] <seb128> I wonder if that will skip too
[14:55] <kenvandine> libappindicator?
[14:55] <seb128> hey rickspencer3
[14:55] <pitti> seb128: should be fine
[14:55] <seb128> kenvandine, well I just upgraded, the new lib got installed
[14:55] <pitti> seb128: I'm doing the meeting so that you can have your call :)
[14:55] <rickspencer3> pitti, thank you for covering for me this morning
[14:55] <seb128> and now I've no indicator icon nor notification
[14:55] <rickspencer3> you are truly the best
[14:56] <pitti> rickspencer3: no problem :)
[14:56] <kenvandine> seb128, humm
[14:56] <seb128> kenvandine, I reboot if that makes a difference
[14:56]  * rickspencer3 has meetings all during today
[14:56] <seb128> rickspencer3, our weekly call is still on?
[14:56] <rickspencer3> ^sympathy is not inappropriate at this time
[14:56] <kenvandine> well, the indicator-applet will need to restart if that service just got installed
[14:56] <rickspencer3> seb128, yes, that is one of the meetings ;)
[14:56]  * seb128 hugs rickspencer3
[14:56] <seb128> ok, good
[14:56] <kenvandine> seb128, let me know how it goes :)
[14:57] <seb128> kenvandine, I rebooted
[14:57] <kenvandine> oh, no luck?
[14:58] <kenvandine> seb128, so when you start rb it should add an icon to the right of the indicator-applet
[14:58] <kenvandine> which has a menu when you click on it, play, next, prev, quit
[14:59] <seb128> no icon
[14:59] <kenvandine> what version of indicator-applet?
[14:59] <seb128> you are sure that the indicator-application binary is not required?
[14:59] <seb128> 0.3
[14:59] <kenvandine> hummm... it is actually
[15:00]  * kenvandine looks to see what is wrong
[15:00] <kenvandine> so you didn't get indicator-application installed?
[15:00] <seb128> I got the lib
[15:00] <seb128> not the binary
[15:00] <seb128> dunno if that's what is expected
[15:00] <seb128> if the binary is of any use there
[15:01] <kenvandine> it is, the service itself is in that package
[15:01] <kenvandine> ok, i'll fix it
[15:01] <seb128> ok so you need a depends or recommends somewhere
[15:01] <seb128> and fallback is not working
[15:02] <kenvandine> yeah
[15:02] <kenvandine> ok
[15:02]  * kenvandine wonders why the folks testing on karmic from the ppa didn't catch this
[15:02] <kenvandine> :/
[15:06] <seb128> kenvandine, did you read my comment about breaks too?
[15:06] <seb128> the one I let yesterday
[15:06] <kenvandine> yeah
[15:06] <seb128> ok good
[15:06] <kenvandine> thx
[15:06] <seb128> np
[15:13] <czajkowski> kenvandine: mind if I ask you something in pm?
[15:13] <kenvandine> sure
[15:14] <Keybuk>  1749 scott     20   0  594m 2264 1448 R   40  0.1 100:33.56 pulseaudio
[15:14] <Keybuk> *hate*
[15:16]  * Amaranth wonders what these 'exe' processes are
[15:16] <Amaranth> oh, silly chrome
[16:13] <seb128> kenvandine, is fixing the indicator-application thing blocking or anything now?
[16:13] <seb128> ie, do you need sponsoring or do you want to discuss where to put the recommends?
[16:13] <kenvandine> perms to upload :)
[16:13] <seb128> just ping on the channel when you need sponsoring
[16:13] <seb128> especially for things which are broken
[16:14] <kenvandine> one min, on phone
[16:14] <seb128> what needs sponsoring? the indicator-application bzr?
[16:14] <seb128> ok
[16:16] <czajkowski> mvo: aloha, do you happen to know of a bug, where on karmic, the software center is missing,  but the add/remove functionality is back ??
[16:17] <rickspencer3> pitti, kenvandine, seb128 can you guys discuss some ways of marking bugs as "blockers" or similar?
[16:17] <rickspencer3> the idea being that we can identify bug_tasks that are blocking packages from getting integrated before the release?
[16:18] <rickspencer3> for instance ... gtk?
[16:18] <bryce> rickspencer3, you thinking like a tag?
[16:18] <rickspencer3> bryce, right, I think you might already have such a thing, right?
[16:20] <rickspencer3> bryce, sorry I couldn't get the wiki set up for you yesterday
[16:20] <kenvandine> bryce, i think just release tags
[16:20] <kenvandine> so we can tag bugs as release blockers
[16:20] <kenvandine> i think we have those already
[16:20] <kenvandine> seb128, yeah indicator-application needs sponsoring
[16:21] <kenvandine> i asked pitti in a PM to give perms to ubuntu-desktop, but he seems busy atm
[16:21] <rickspencer3> what I would like is to be able to dynamically generate a list of bug_tasks that are keeping packages from getting uploaded to lucid
[16:21] <rickspencer3> it should be a short list ;)
[16:21] <kenvandine> seb128, i just made it a Depends, i don't think it is really optional
[16:22] <kenvandine> seb128, if you would rather it be a Recommends I can drop it down to that
[16:23] <kenvandine> seb128, and i subscribed you to a rb bug i filed for the lack of a fallback to the status icon
[16:23] <kenvandine> and assigned it to bratsche :)
[16:27] <pitti> re
[16:28] <bryce> rickspencer3, I don't have a tag for this, but if there was a specific tag for such bugs it'd be easy to create a query.  The trick would be to ensure people set the tags where applicable
[16:28] <seb128> kenvandine, sorry I was away
[16:29] <seb128> kenvandine, I've no strong opinion Depends or Recommends
[16:29] <seb128> theorically it's a Recommends since the lib is a depends but you can uninstall the service and use fallback
[16:29] <seb128> like rhythmbox depends on the lib
[16:29] <bryce> rickspencer3, kenvandine: or if release tags were used, a report could be made of those as well, however I guess we wouldn't be able to distinguish between "normal" release blockers, and these
[16:30] <seb128> but if you just dislike indicators you can remove the binary
[16:30]  * pitti rings the bell
[16:30] <pitti> Desktop Team Meeting
[16:31] <pitti> tseliot, ArneGoetje, bryce, ccheney, Riddell, kenvandine, seb128: here?
[16:31] <Riddell> oh aye
[16:31]  * kenvandine waves
[16:31] <bryce> heya
[16:31] <seb128> pitti, there
[16:31] <pitti> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-12-15
[16:31] <kenvandine> seb128, i'll change it to a recommends
[16:32] <seb128> kenvandine, thanks
[16:32] <pitti> welcome to the "Christmas" meeting edition
[16:32] <seb128> kenvandine, let me know when you commit so I can sponsor
[16:32] <pitti> = Outstanding actions from last meeting =
[16:32]  * Riddell strings up some sparkly lights around the channel
[16:32]  * pitti lights three candles
[16:32] <pitti> = Outstanding actions from last meeting =
[16:33] <pitti> ArneGoetje to talk to Robert about scanner failure in simple-scan
[16:33] <pitti> ArneGoetje: I noticed you talking to Robert; what was the result?
[16:33] <pitti> Everyone to add their conference interests
[16:33] <pitti> seems that nobody did this, so
[16:33] <Riddell> I did!
[16:34]  * pitti hands Riddell a gold start
[16:34] <pitti> star, sorry
[16:34] <ArneGoetje> pitti: problem solved
[16:34] <pitti> Robert did, too
[16:34]  * tseliot1 missed the beginning of the meeting because of some weird issue with freenode
[16:34] <pitti> ArneGoetje: sweet!
[16:34] <pitti> tseliot1: not much lost
[16:34] <pitti> so, let's just carry this forward, I'll mail the team (better than IRC)
[16:35] <pitti> ACTION: pitti to send reminder about conference attendence
[16:35] <kenvandine> tseliot1, freenode has been having issues :)
[16:35] <pitti> I'll set up a wiki page again
[16:35] <pitti> = Partner Update =
[16:35] <kenvandine> ok
[16:35]  * pitti bows to kenvandine
[16:35] <tseliot> ok
[16:35] <kenvandine> a bunch of DX uploads last thursday
[16:35] <kenvandine> start of the weekly releases from DX for lucid
[16:35] <kenvandine> https://wiki.ubuntu.com/DesktopExperienceTeam/LucidWeeklyReleases
[16:36] <kenvandine> for info
[16:36] <kenvandine> all the application-indicator related packages are also uploaded to a ppa for karmic
[16:36] <kenvandine> for use by upstream projects that want to port their application to use the app indicator
[16:36] <kenvandine> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
[16:36] <kenvandine> for information on that
[16:37] <kenvandine> rhythmbox has been ported already
[16:37] <kenvandine> more to come
[16:37] <pitti> what does that mean exactly? (didn't try it yet)
[16:37] <kenvandine> thanks everyone for testing the gtk patches for cs-deco and rgba
[16:37] <seb128> what should we do with those?
[16:37] <pitti> app menus now moving to panel?
[16:37] <seb128> what should we do with bugs about those?
[16:37] <kenvandine> pitti, no
[16:37] <seb128> rather
[16:37] <seb128> do you want a team subscribed?
[16:37] <seb128> a tag?
[16:37] <kenvandine> pitti, moving apps from status icons to indicators
[16:37] <kenvandine> so they all behave the same
[16:37] <pitti> aah
[16:37] <pitti> nice
[16:37] <seb128> I expect somebody will want to track bugs due to those changes
[16:37] <kenvandine> left click does the same thing
[16:37] <kenvandine> etc
[16:38] <kenvandine> yeah
[16:38] <seb128> upstream dx task?
[16:38] <kenvandine> seb128, assign all those bugs to me
[16:38] <kenvandine> i will redirect them to dx :)
[16:38] <seb128> I would prefer a way which allow to query those
[16:38] <seb128> so anybody can know where we stand
[16:38] <kenvandine> i will talk to dbarth about a tag to use
[16:38] <seb128> thanks
[16:39] <seb128> I will assign to you meanwhile
[16:39]  * kenvandine will email the desktop list
[16:39] <kenvandine> that is all i have
[16:39]  * kenvandine hands mic back to pitti
[16:39] <pitti> thanks Ken; questions anyone?
[16:39] <pitti> = Kubuntu Update =
[16:40] <Riddell> * alpha 1 out in typically alpha 1 shape
[16:40] <pitti> ladies and gentlemen, the famours Mr. Riddell
[16:40] <Riddell> * qt and kdelibs built on arm now, packages higher up the stack are getting done
[16:40] <Riddell> * polkit-qt-1 just gone into archive
[16:40] <pitti> yay
[16:40] <Riddell> * KDE SC 4.4 beta 2 due to be tagged tomorrow, no rest for us!
[16:40] <pitti> Riddell: does "arm" also mean "other ports" like ppc?
[16:40] <pitti> polkit-qt-1> !
[16:40] <pitti> great to see
[16:40] <asac> \o/
[16:41] <pitti> Riddell: do you know how many apps need to be ported for this?
[16:41] <Riddell> pitti: I've not checked those, it's hard enough making sure arm works
[16:41] <Riddell> pitti: kpackagekit is the main user and it has a version due which uses polkit-1
[16:41] <pitti> Riddell: ports> nevermidn, was just curious
[16:41] <pitti> Riddell: ah, that was 0.5, which is already out for a while, right?
[16:41] <Riddell> yes
[16:41] <Riddell> pitti: other KDE bits should just work, they all use KAuth API
[16:42] <pitti> shouldn't be too hard either way
[16:42] <pitti> rocking
[16:43] <pitti> Riddell: any RC bugs which should be on the release radar? https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus is suspiciously free of KDE bugs
[16:43] <pitti> (not that I'm complaining)
[16:43] <Riddell> pitti: there's probably a bunch that should be tagged, alpha 1 wasn't exactly bug free
[16:44] <Riddell> you may action me for that :)
[16:44] <pitti> it's a recurring task anyway :)
[16:44] <pitti> thanks for the update, great progress
[16:45] <pitti> ccheney: AYT?
[16:45] <pitti> ok, let's skip this
[16:45] <pitti> = All -- Setting goals for next cycle =
[16:45] <pitti> not sure whether you got mail from allhands.c.c (I didn't)
[16:45] <pitti> but the system shuold be open for entering your goals for the next cycle
[16:45] <seb128> didn't either
[16:46] <kenvandine> no mail :/
[16:46] <tseliot> +1
[16:46] <ArneGoetje> +1
[16:46] <pitti> that needs to be done by Mid-January, so the free days should be good for some reflections about your next plans :)
[16:47] <seb128> those plans are for lucid no?
[16:47] <seb128> ie this cycle?
[16:47] <pitti> well, not exactly
[16:47] <pitti> for the next "Canonical" period
[16:47] <pitti> they don't align
[16:47] <seb128> right, but that pretty much cover lucid
[16:47] <pitti> right
[16:47] <seb128> oh
[16:47] <pitti> half lucid, half maniac
[16:47] <seb128> I usually make those goal match the ubuntu cycle
[16:48] <ArneGoetje> pitti: maniac?
[16:48] <pitti> 10.10 will be "Maniac Mansion", won't it? :-)
[16:48] <seb128> pitti likes to play guessing next version names
[16:48] <seb128> ;-)
[16:48] <ArneGoetje> LOL
[16:48] <kenvandine> hehe... maniac :)
[16:48] <pitti> mumbling monkey, whatever
[16:48] <kenvandine> we could have fun with that
[16:48] <pitti> = Release Bugs/Release Status =
[16:48] <kenvandine> our next crack release :)
[16:49] <pitti> alpha-1 went out reasonably well, not much to say here
[16:49] <pitti> someone has some specific concerns here?
[16:49] <pitti> https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus has a few bugs only so far
[16:50] <pitti> = Nvidia packages name schemes  =
[16:50] <pitti> tseliot: floor's your's
[16:50] <tseliot> ok
[16:50] <tseliot> actually there are 2 ideas I would like to discuss with you
[16:51] <tseliot> the 1st idea is to reduce the number of binary packages that the nvidia source generates
[16:51] <tseliot> the 2nd idea is about changing name schemes
[16:51] <tseliot> let's begin with the former
[16:51] <pitti> like integrating vdpau etc. into the main package?
[16:52] <tseliot> currently one source package generates a few binaries
[16:52] <tseliot> yep
[16:52] <tseliot> nvidia-185-kernel-source
[16:52] <tseliot> nvidia-185-libvdpau
[16:52] <tseliot> nvidia-185-libvdpau-dev
[16:52] <tseliot> nvidia-185-modaliases
[16:52] <tseliot> nvidia-glx-185
[16:52] <tseliot> nvidia-glx-185-dev
[16:52] <pitti> and perhaps merging all the -dev?
[16:52] <tseliot> now, after the cure we would get something like this
[16:52] <tseliot> nvidia-190 (contains glx, kernel-source, vdpau)
[16:52] <tseliot> nvidia-190-modaliases
[16:52] <tseliot> nvidia-190-dev
[16:52] <tseliot> and vdpau-dev in Lucid lives in a separate source
[16:53] <tseliot> named libvdpau
[16:53] <pitti> is vdpau backwards compatible with older driver versions?
[16:53] <tseliot> superm1 worked on libvdpau
[16:53] <tseliot> pitti: older driver versions don't support vdpau AFAIK
[16:53] <tjaalton> it's split now
[16:53] <tseliot> therefore this won't be an issue
[16:54] <tjaalton> libvdpau has all the common bits
[16:54] <pitti> sweet
[16:54] <tseliot> tjaalton: right, as I said above
[16:54] <pitti> from my naive view, it seems that there's about zero reason to install e. g. kernel-source without the glx bits
[16:54] <tseliot> having fewer binary packages should help us a bit with dependency problems
[16:54] <tjaalton> the drivers then ship the support for the lib
[16:54] <tseliot> pitti: exactly
[16:54] <bryce> probably was like that for historical reasons mostly
[16:54] <tseliot> right
[16:55] <tseliot> yes, this is correct
[16:55] <tseliot> we inherited that from the old days of the l-r-m
[16:55] <pitti> so, that seems settled?
[16:55] <tseliot> I think we all agree
[16:56] <tseliot> the next point will be a bit more controversial ;)
[16:56] <tseliot> shall I proceed?
[16:56] <pitti> go ahead
[16:56] <tseliot> ok
[16:57] <tseliot> we discussed this at the UDS without coming to an agreement
[16:57] <tseliot> the idea was to put the latest nvidia driver
[16:57] <tseliot> i.e. the one which supports vdpau and has all the new features
[16:57] <tseliot> in one source package
[16:58] <tseliot> which doesn't contain the version of the driver in its name
[16:58] <tseliot> something like nvidia-graphics-driver-current
[16:58] <pitti> this is pretty much what we had earlier, isn't it?
[16:58] <tseliot> which in turn would generate nvidia-current, nvidia-current-modaliases nvidia-current-dev
[16:58] <tseliot> yep
[16:58] <pitti> with -legacy, etc.
[16:58] <tseliot> right
[16:58] <pitti> and we abandoned it due to insurmountable upgrade issues
[16:59] <tseliot> yes, I thought so
[16:59] <tseliot> but I think we would have to use nvidia-common either way
[16:59] <tseliot> in dist-upgrades
[17:00] <tseliot> and changing the names would save us from having new source packages every time nvidia bumps the version of a driver
[17:00] <tseliot> which in turn would mean that we won't have to put the new source in NEW
[17:00] <tseliot> i.e. less work for archive admins
[17:00] <pitti> hm, I think we should take a step back here
[17:00] <tseliot> and easier bug tracking
[17:00] <tseliot> ok
[17:01] <pitti> and define what the behaviour on upgrades should be
[17:01] <pitti> do we prefer (1) upgrading to the latest driver or (2) staying with the current version if it is still supported?
[17:01] <pitti> (1) -> potentially better performance, but also total breakdown if your card isn't supported any more
[17:01] <pitti> well, that can probably be alleviated with the changes we put into X
[17:01] <pitti> (like fallback to nouveau)
[17:02] <tseliot> when dist-upgrading through update manager we would ask nvidia-common to make a choice
[17:02] <pitti> (2) -> safe approach, but needs special handling for obsoleted versions
[17:02] <pitti> tseliot: I'd actually think that this would make bug triage harder, since you'd mix different versions into the same lists?
[17:02] <pitti> bry... ugh, netsplit again?
[17:02] <tseliot> obsolete drivers should be removed as we cannot guarantee compatibility with the kernel and with X
[17:03] <kenvandine> yeah... freenode has been really sucking since last night
[17:03] <tseliot> pitti: the same source will have different versions in lucid and lucid+1 though
[17:04] <pitti> tseliot: so, I take it you favor the -current approach?
[17:05] <tseliot> pitti: yes. If we need to check the version of the driver (for dist-upgrades) we can always use the modaliases (which is what nvidia-common does)
[17:05] <seb128> note to self, focus is not always on the screen you use
[17:05] <seb128> (ie ctrl-R is reconnect on IRC)
[17:05] <pitti> tseliot: how would you name the older versions, still keeping the number?
[17:05] <tseliot> pitti: yes, maybe
[17:06] <tseliot> or we could use -legacy and something else
[17:06] <pitti> so, my gut feeling is that this approach is more aggressive, but potentially more beneficial wrt. performance
[17:06] <tseliot> avoiding names which are confusing ;)
[17:06] <tjaalton> the drivers then ship the support for the lib
[17:06] <pitti> I think it needs to go along with more robust driver detection
[17:06] <tjaalton> oops
[17:06] <pitti> i. e. not putting "nvidia" into xorg.conf any more, but autodetect it instead
[17:07]  * tseliot nods
[17:07] <pitti> to at least have a safety net for apt-get dist-upgrade, etc.
[17:07] <pitti> but that's on the plan anyway, right?
[17:07] <tseliot> yes, I guess so. I think bryce will work on that
[17:08] <tseliot> I'll deal with the alternatives stuff soon
[17:08] <pitti> tseliot: well, I think bryce and you should have consensus on this; you are the best persons to make the decision eventually
[17:08] <pitti> but we should revist the reasons why we used a number-based schema in the past
[17:08] <tseliot> ok, I think bryce agrees with this change but we can double check it when he's back
[17:08] <pitti> archive NEW is really a no-op here, it's almost zero work
[17:09] <tjaalton> the fallbacks don't work if there is an xorg.conf
[17:09] <tjaalton> that could be fixed, though
[17:09] <pitti> tjaalton: that would be the other fallback (bulletproof-x, vesa, etc.)?
[17:09] <tseliot> tjaalton: yes, I guess so
[17:09] <bryce__> sorry, freenode fell over, what'd I miss?
[17:10] <tseliot> bryce or bryce__: are you ok with changing nvidia's name schemes?
[17:10] <bryce__> regarding moving to something like nvidia-common - I favor this idea, it simplifies several things we currently have to fuss about with each time the number changes
[17:10] <tjaalton> pitti: yes, server autodetection. uses different codepath if xorg.conf exists
[17:10] <bryce__> tseliot, yup
[17:10] <tseliot> bryce__: nvidia-current, nvidia-legacy (or nvidia-173), etc.
[17:10] <pitti> bryce__: we discussed the change from version-based to "-current" naming schema for nvidia
[17:11] <tjaalton> tseliot: uh, no legacy mess again :)
[17:11] <tjaalton> could it be just nvidia-foo without -current?
[17:12] <tseliot> tjaalton: or nvidia-current and nvidia-173 and nvidia-96
[17:12] <pitti> so, at this point I feel we should move it to mail or after meeting, since it becomes a bit too technical now
[17:12] <tseliot> ok
[17:12] <bryce__> sounds good
[17:12] <pitti> thanks for the heads-up
[17:12] <pitti> bryce__: I can send you scrollback if you need
[17:12] <bryce__>  nvidia-current and nvidia-173 and nvidia-96 would be fine; I'm open to alternate ideas to using numbers as well
[17:12] <bryce__> pitti, thanks!
[17:13] <pitti> anyway, it's the end of the agenda
[17:13] <pitti> = AOB =
[17:13] <pitti> ?
[17:13] <kenvandine> yes
[17:13] <kenvandine> rick wanted me to bring up tracking of blocking bugs, perhaps using release tags
[17:13] <kenvandine> everyone agree with that?
[17:13] <kenvandine> i think that is just what we have always done :)
[17:13] <pitti> blocking what eexactly?
[17:13] <pitti> release tasks/milestones are for release blockers
[17:13] <kenvandine> release blockers, so we can quickly see what bugs need to be addressed
[17:14] <pitti> but I thought he had something special in mind
[17:14] <pitti> like "this bug blocks the adoption of package foo"?
[17:14] <bryce__> pitti, that's what I gathered as well
[17:14] <kenvandine> like the immediate need is a way to see things like the broken rgba patch for gtk
[17:14] <pitti> hm, that's a rather intricate concept
[17:14] <kenvandine> visibility for stuff that won't land until they are fixed
[17:15] <kenvandine> pitti, probably just the release milestones
[17:15] <bryce__> it sounded like he wanted a way to flag bugs on packages that should go in but haven't yet, from other general release bug tasks
[17:15] <pitti> couldn't we just use an early milestone and track it on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus ?
[17:15] <kenvandine> sigh... another netsplit
[17:15] <kenvandine> pitti, yeah
[17:15] <kenvandine> that is what i am thinking
[17:15] <kenvandine> he just wanted us to all agree on a method
[17:15] <pitti> -ENOSEB
[17:15] <kenvandine> so anyone against?
[17:15] <pitti> meh, this is really ugly
[17:16] <pitti> kenvandine: it seems straightforward, and in line what we already do, and should work AFAICS?
[17:16] <kenvandine> yeah, seb128 you ok with using release milestones for blockers like rick mentioned?
[17:16] <pitti> kenvandine: you could also create  milestones on the ayatana project
[17:16] <kenvandine> and track them on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[17:16] <pitti> seb128: wb
[17:17] <kenvandine> and there he is again :)
[17:17] <pitti> seb128: I wanted to ask you whether you have similar situations
[17:17] <pitti> like, you need a bug fixed before we can add package foo
[17:17] <seb128> re
[17:17] <seb128> sorry, split
[17:17] <seb128> I'm out of context I think
[17:17] <seb128> right, that happens
[17:17] <pitti> seb128: there's a bug report which you need fixed before we can upload/enable a package foo
[17:18] <pitti> any particular way to track/mark/tag it?
[17:18] <seb128> not right now
[17:18] <seb128> that doesn't happen often
[17:18] <seb128> upstream roll tarballs when they are confident the code is ready for users
[17:18] <pitti> we were proposing to just using an early milestone and tracking it on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[17:18] <kenvandine> pitti, i think tracking this at the lucid milestone level is fine
[17:18] <seb128> hum
[17:18] <seb128> works for me I guess
[17:18] <kenvandine> i think alpha-2 is fine
[17:19] <kenvandine> nothing more granular
[17:19] <pitti> ok, great
[17:19] <kenvandine> imho
[17:19] <pitti> kenvandine: well, if you need more granularity, create ayatana milestones :)
[17:19] <kenvandine> at least all the bugs are easy to find and rick can quickly see what is outstanding
[17:19] <kenvandine> hehe
[17:19] <kenvandine> sure
[17:19] <pitti> or the good old IRC poke "*nnng* need this now"
[17:20] <bryce__> wee freenode
[17:20] <pitti> ok, we are done anyway, and with half of the team constantly appearing and disappearing it's no fun
[17:20] <pitti> == end meeting ==
[17:20] <pitti> thanks everyone!
[17:20] <kenvandine> ok, thanks all :)
[17:20] <ArneGoetje> thanks
[17:20] <seb128> ok, thank you
[17:20] <bryce__> thanks
[17:20] <seb128> I've things I want to discuss but I can do that out of meeting
[17:20] <seb128> it doesn't really require full team
[17:21] <pitti> bryce__, tseliot: so, as I said the two of you should eventually decide whether or not to rename the packages to -current/-legacy
[17:21] <pitti> I'm just concerned about reintroducing the upgrade problems which made us use version-based packages in the first place..
[17:21] <pitti> bryce__: (there wasn't much new input in the discussion, I think)
[17:22] <bryce__> pitti, well the thinking was we could retain the numbers for the legacy drivers, and just move the latest one to nvidia-current
[17:22]  * tseliot nods
[17:22] <bryce__> that'd solve 95% of the issues we care about, without opening the old -legacy can of worms
[17:23] <bryce__> and we'll have to rename -190 to -195 or whatever anyway, so switching to -current instead shouldn't be any more work than we'd already be doing anyway
[17:23] <tseliot> right
[17:24] <bryce__> and then in theory we'd never need to do renames again, unless nvidia spawns another legacy driver
[17:24] <tseliot> and I wanted to discuss this today because I'm working on the new packages
[17:24] <tseliot> and that would be just an additional nvidia-whatever_version package
[17:25] <bryce__> tseliot, what were the arguments against this rename?  I forget who raised issues at UDS
[17:25] <tseliot> bryce__: I *think* it was pitti
[17:26] <tseliot> the argument was how are dist-upgrade going to work?
[17:26] <bryce__> ok
[17:26] <pitti> bryce__: automatically upgrading users to a potentially unsupported driver, and mixing major versions in bugs
[17:26] <bryce__> but really that would be of no greater difficulty than what we already have going from -190 to -200 or whatever, yeah?
[17:27] <tseliot> my reply was that we'll have to use nvidia common to make the right choice about drivers in dist-upgrades either way
[17:27] <bryce__> pitti, ah right mixing major versions for bug reports
[17:27] <tseliot> that's the point on which I have more doubts
[17:28] <bryce__> on that point, I tend to feel with -nvidia that the differences from one major version to another are not as significant as with other software.  -185 to -190 is sort of like a 0.18.5 to 0.19.0 in a normal project
[17:29] <bryce__> in other words, a lot of bugs that affect -185 still are there in -190
[17:29] <tseliot> true :-/
[17:30] <bryce__> I fussed with doing scripts to have people re-test and re-file bugs when we went from -170 to -180 or some such, and it worked but mostly all the same bugs were there, and was a collosal time suck for everyone
[17:30] <bryce__> on the plus side, it made the bug reports shorter (at expense of some history), but we ended up with just as many bugs if not more
[17:31] <bryce__> also, using source package renames to indicate version changes doesn't seem like the right way to do things in launchpad...  with -intel for instance we keep track of versions on the drivers without changing the source package name; seems we ought to be able to track -nvidia versions just the same
[17:31] <tseliot> if bryce__ says so (and he did much more bug triaging that I did with nvidia), I have no further doubts on this
[17:32] <tseliot> pitti: ^^
[17:32] <pitti> fair enough
[17:33] <pitti> bryce__: if we get the x.org driver autodetection patches, then apt-get dist-upgrading to a driver which doesn't support your card will at least not be the end of the world
[17:34] <tseliot> bryce__: do the autodetection patches use the nvidia modaliases?
[17:34] <tseliot> if not we could make it do so
[17:34] <Keybuk> pitti: if only we had X hotplug drivers ;)
[17:34] <bryce__> for evidence you can make it out on http://www2.bryceharrington.org:8080/X/Graphs/totals.svg - there is a small yellow blotch on the left for -177 which I closed out with a script, but you can see the -180 bugs start coming in at the same time, and soon we had just as many bugs (and today about 4x as many as we used to
[17:35] <Keybuk> it could listen in on graphics and drm subsystem events as well as input
[17:35] <Keybuk> and then you could hotplug graphics cards
[17:35] <Keybuk> (or switch between drivers by using ACTION=change)
[17:37] <tseliot> Keybuk: if the kernel supported that
[17:37] <Keybuk> it does
[17:37] <Keybuk> it's X that doesn't
[17:37] <tseliot> oh
[17:38] <pitti> bryce__, tseliot: I updated https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-12-15 with a short summary; please feel free to elaborate/correct me
[17:38] <bryce__> pitti, thanks
[17:39] <tseliot> pitti: perfect. Thanks a lot
[17:51] <seb128> kenvandine, the rhythmbox application indicator not good
[17:51] <seb128> for one thing I've a not found icon
[17:52] <seb128> and for the other thing I'm unable to open rhythmbox because I closed it minimized previous run
[17:52] <seb128> and I don't know how to un-iconify it from there
[17:52]  * seb128 opens bugs
[17:53] <seb128> mvo, xapian is weird ;-) synaptic doesn't find "indicator-application" when typing "indicator-applicatio"
[17:53] <seb128> or anything before you enter the entire word
[17:53] <seb128> once you type the "n" it's listed
[18:19] <jcastro> kenvandine: is the rb-indicator thing supposed to work in lucid yet or not?
[18:19] <jcastro> I get no icon at all
[18:22] <kenvandine> jcastro, there was a missing dep
[18:22] <kenvandine> fix is uploaded
[18:22] <kenvandine> you need indicator-application
[18:23] <seb128> kenvandine, did you get what I wrote before?
[18:24] <seb128> kenvandine, I get no icon either
[18:24] <kenvandine> now i did
[18:24] <seb128> or a broken icon
[18:24] <kenvandine> the icon thing we know about
[18:24] <seb128> ok
[18:24] <kenvandine> hidden i hadn't seen
[18:24] <seb128> I opened a bug
[18:24] <kenvandine> thx
[18:24] <seb128> it's not specific to upgrade
[18:24] <seb128> if you have the gconf key to hide on close
[18:24] <kenvandine> yeah, i can see that
[18:24] <kenvandine> that should be an easy fix
[18:25]  * kenvandine will try to fix it without waiting for cody :)
[18:37] <rickspencer3> desktop team below the trendline!!
[18:37] <rickspencer3> yeah
[18:37] <bryce__> I had a productive day yesterday :-)
[18:39] <rickspencer3> thanks bryce__
[18:39] <rickspencer3> does this mean you have extra capacity and I can assign you more work?
[18:39] <rickspencer3> j/k
[18:41] <bryce__> :-P
[18:41] <jcastro> do people typically try to get ahead before a long break so they don't get hosed when they come back?
[18:41] <jcastro> because that's what I am trying to do
[18:42] <rickspencer3> just make sure loose ends are tied up and you've done all the things you told people  you would do
[18:42] <rickspencer3> getting ahead is for suckers
[18:43] <rickspencer3> "work is infinite, time is finite, etc..."
[18:43] <rickspencer3> jcastro, ^
[18:43] <jcastro> I see
[18:43] <kenvandine> seb128, i have a fix for the hidden thing... just not sure what mpt would think :)
[18:43] <dobey> time is an illusion
[18:44] <jcastro> kenvandine: is rhythmbox app indicator in lucid supposed to work yet or not?
[18:44] <seb128> kenvandine, display an extra item in the menu for it?
[18:44] <kenvandine> yeah
[18:45] <seb128> jcastro, it does if you install indicator-application
[18:45] <kenvandine> same as what the icon did before
[18:45] <seb128> jcastro, will be installed for you after next publishing I guess
[18:45] <seb128> if the update is not published yet
[18:45] <seb128> jcastro, and yes, it "works"
[18:45] <seb128> ie it has a broken icon and don't allow you to unhide rhythmbox
[18:45] <seb128> if you are one of those who map close to hide in the notification...
[18:45] <kenvandine> seb128, should i upload this fix?
[18:46] <seb128> kenvandine, yes
[18:46]  * kenvandine thinks this is critical :)
[18:46] <seb128> kenvandine, we can tweak later
[18:46] <jcastro> hah, mine starts minimized, so I can't unhide rb.
[18:46] <kenvandine> jcastro, exactly :)
[18:46] <seb128> jcastro, dito
[18:46] <kenvandine> i have a fix
[18:46] <jcastro> and the icon fix is cody's todo right?
[18:46] <seb128> kenvandine, is there a bug for the broken icon btw?
[18:47] <kenvandine> not sure, jcastro ^^?
[18:47] <kenvandine> i will take a quick look at the icon
[18:47] <seb128> rickspencer3, btw it made me think about a question I had for the meeting
[18:47] <seb128> rickspencer3, do we have a policy for adding work items?
[18:47] <seb128> would doing that break the trend estimation?
[18:48] <seb128> like I could add a bunch of items for login speed
[18:48] <seb128> things we figured are slowing boot on the way
[18:49] <jcastro> I don't think there's a bug for the icon
[18:50] <jcastro> seb128: kenvandine: I file file a bug on it now
[18:50] <seb128> jcastro, thank you, do you know where to file it?
[18:51] <seb128> is that a client or server issue?
[18:51] <jcastro> I was going to file it under rhythmbox(ubuntu) and tag it
[18:51] <seb128> ok
[18:51] <seb128> maybe subscribe ted to it
[18:51] <seb128> in case that's a libdbusmenu thing
[18:52] <jcastro> I was going to sub cody to it, he wrote the patch and was aware it was broken
[18:52] <jcastro> but then he left for a sprint
[18:52] <seb128> jcastro, ok
[18:53] <dobey> hrmm
[18:53] <dobey> how do i tell bzr builddeb which e-mail to sign the packages with?
[18:54] <rickspencer3> dobey, I don't much abotu this, but I suspect you want DEBMAIL=
[18:54] <jcastro> seb128: https://bugs.edge.launchpad.net/ubuntu/+source/rhythmbox/+bug/497095
[18:54] <seb128> jcastro, thanks
[18:54] <seb128> rickspencer3, so you are around and just ignore my questions ;-)
[18:55] <dobey> rickspencer3: want it where? i usually just pass -k to debbuild
[18:55] <seb128> -- -option
[18:55] <dobey> ah
[18:55] <jcastro> seb128: the planet is netsplitting so I am missing all sorts of parts of the conversation
[18:55] <rickspencer3> hi seb128
[18:55] <seb128> jcastro, right I noticed
[18:55] <seb128> hey rickspencer3 ;-)
[18:55] <rickspencer3> yes you are in my /ignore list
[18:55] <dobey> or not
[18:55] <seb128> rickspencer3, didn't get my question 10 minutes ago?
[18:55] <rickspencer3> actually, no
[18:56] <dobey> bzr did not like me doing -- -k 'email'
[18:56] <dobey> "No such file or directory: email"
[18:56] <seb128> dobey, bzr-buildpackage -- option
[18:56] <rickspencer3> for some reason my irc client shows everyone disconnected from the channel and then reconnected it
[18:56] <seb128> it's the key number usually
[18:56] <seb128> not the email
[18:56] <rickspencer3> and then it scrolled your question off the top of the list
 rickspencer3, btw it made me think about a question I had for the meeting
[18:56] <rickspencer3>  rickspencer3, do we have a policy for adding work items?
[18:56] <seb128> rickspencer3, that's ok ;-)
[18:56] <dobey> seb128: i only have one key
[18:57] <seb128> dobey, it should use the email in the changelog then, and your key should have that email
[18:57] <dobey> seb128: but i sign packages with different e-mail addresses depending
[18:57] <dobey> seb128: my key does have that e-mail, but dpkg always fails unless i pass -k
[18:57] <seb128> dobey, well I use bzr-buildpackage -- option
[18:57] <seb128> and that works there
[18:57] <seb128> I do sponsoring this way
[18:57] <chrisccoulson> dobey - setting DEBSIGN_KEYID=key_id in ~/.devscripts should work also, if you want to use 1 key to sign packages
[18:58] <dobey> and bzr-buildpackage gives me the same error
[18:58] <seb128> did you try without the space?
[18:58] <seb128> before the email
[18:58] <dobey> chrisccoulson: i only HAVE 1 key
[18:58] <dobey> oh right
[18:58] <chrisccoulson> dobey - then defining it in ~/.devscripts is probably what you want ;)
[18:58] <chrisccoulson> you won't have to pass -k every time then
[18:59] <dobey> oh that's evil
[18:59] <dobey> bzr-builddeb stripped the quotes
[18:59] <seb128> the number of key is not revelant
[18:59] <seb128> it's just trying to match changelog and key
[18:59] <seb128> if it fails you can specify the key number you use
[18:59] <dobey> seb128: but it's failing
[18:59] <seb128> or an email
[18:59] <dobey> seb128: no idea why it's failing, it just always does... it shouldn't
[19:00] <seb128> having only one key doesn't prevent you to specify that's the one you want
[19:00] <seb128> because it doesn't find a key matching the changelog entry?
[19:00] <seb128> if you specify you want to use your only key number if will do it
[19:00] <seb128> I'm doing that when sponsoring for example
[19:00] <dobey> huh
[19:00] <dobey> for some reason it still failed when i passed the email with -k
[19:00] <seb128> what error do you get?
[19:00] <dobey> but it works when i do debuild -S -k elsewhere
[19:01] <seb128> you can use debsign after build
[19:01] <dobey> it says secret key not available
[19:01] <dobey> which makes no sense to me
[19:01] <seb128> bzr-buildpackage --source
[19:01] <seb128> and design .changes ...
[19:02] <seb128> try unsetting GPG_AGENT_INFO
[19:02] <seb128> in case that would be the agent breaking things
[19:02] <cj> is there anything special I need to do in order to do audio over HDMI?
[19:04] <dobey> for some reason it doesn't like "Name <email>" but "email" is fine
[19:04] <dobey> i guess debsign is looking it up wrong
[19:04] <seb128> ok
[19:04] <seb128> dinner time there
[19:04] <seb128> bbl
[19:04] <dobey> bon appetit seb128
[19:05] <dobey> thanks
[19:26] <seb128> rickspencer3, so did you get the work item question?
[19:27] <rickspencer3> seb128, yes, i was waiting for you guys to finish
[19:27] <rickspencer3> so, I don't have a policy
[19:27] <seb128> should we be adding items or not?
[19:27] <rickspencer3> I think if you are doing the work, you should add it to the work item list
[19:27] <seb128> I think the trend line will not update
[19:27] <seb128> ok
[19:27] <rickspencer3> and I trust your judgment regarding whether you should be doing the work in the first place
[19:27] <seb128> right, my concern was rather the trend impact
[19:28] <rickspencer3> seb128, ah yes
[19:28] <seb128> since the line is based on initial count
[19:28] <rickspencer3> in that case, my policy is that you should add work items
[19:28] <seb128> and will not change with count updates
[19:28] <rickspencer3> seb128, right, but that's ok
[19:28] <seb128> ok thanks
[19:28] <rickspencer3> if we didn't account for all of our work, then we should see that for what it is
[19:28] <rickspencer3> thanks seb128
[19:28] <seb128> ;-)
[19:29] <dobey> jpds: are you around?
[19:29] <seb128> I don't plan to add many items anyway
[19:29] <seb128> just some granularity to login tasks
[19:57] <pitti> kenvandine: indicator-application upload should work for you now
[20:03] <kenvandine> thx
[20:03]  * pitti waves good night
[20:46] <baptistemm_> pitti, is it safe to remove hal in lucid system?
[20:51] <chrisccoulson> baptistemm_ - i don't think that anything depends on it by default anymore
[20:51] <chrisccoulson> so you should be ok to remove it now
[20:52] <baptistemm_> okay, just sound-juicer depends on it
[20:52] <baptistemm_> I asked because I feared some deps were missing
[20:52] <chrisccoulson> that's not on the default install is it?
[20:53] <baptistemm_> perhaps not but I upgraded from some versions so I cary some old packages
[20:53] <chrisccoulson> baptistemm_ - yeah, sound-juicer is not on the default install, but is pulled in by one of the gnome desktop meta-packages
[20:54] <baptistemm_> hey, I have weird notifcation bubbles
[20:54] <chrisccoulson> baptistemm_ - that's normal ;)
[20:54] <baptistemm_> ah okay
[20:55]  * baptistemm_ just upgraded to lucid
[20:55] <chrisccoulson> notify-osd is running in debug mode for the development period
[20:55] <baptistemm_> so wireframes are normal
[20:55] <chrisccoulson> baptistemm_ - are you running lucid on real hardware?
[20:56] <baptistemm_> yep
[20:56] <chrisccoulson> you have a spare machine then, or do you use it on your production machine?
[20:56] <baptistemm_> I that sound crazy
[20:56] <baptistemm_> no no I just have a laptop and nothing else
[20:57] <chrisccoulson> i only have one computer here, so i have to stick with karmic, or risk being told off by my girlfriend ;)
[20:57] <chrisccoulson> i really need to invest in some new hardware
[20:58] <baptistemm_> I don't have enough space to have another computer
[20:59] <bryce__> only one computer?
[20:59]  * bryce__ boggles
[20:59] <chrisccoulson> heh, me neither, but i would just remove some furniture from our spare bedroom and convert it to office space instead
[20:59] <chrisccoulson> bryce - yeah, only one computer here :(
[20:59] <chrisccoulson> i can't really justify buying another at the moment ;)
[21:00] <chrisccoulson> and my employer is too tight to give me a laptop too
[21:00] <bryce> I have 8 just here in the room I'm in currently
[21:00] <baptistemm_> I had had an office space which is now my son room
[21:00] <bryce> not counting ones in various state of disassembly ;-)
[21:01] <chrisccoulson> bryce - i bet it must get warm in there!
[21:01] <baptistemm_> and what about global warming !!!!
[21:01] <bryce> yep, but rarely do I have more than 3 on at once
[21:01] <chrisccoulson> i would have them all on at once!
[21:02] <chrisccoulson> :)
[21:02] <bryce> baptistemm, I justify it figuring if it helps me more quickly eliminate one power saving bug that is affecting all of ubuntu than it more than pays for itself ;-)
[21:11]  * didrocks tries to restart hoping the nvidia binary driver stuff had been fixed with the 8 bryce's computers :)
[21:12] <baptistemm_> chrisccoulson, whaaaat you have a child with your gf, you're not married !!!
[21:12]  * baptistemm_ is just kidding
[21:13]  * baptistemm_ is in the same situation
[21:13] <chrisccoulson> heh, yeah, marriage is far too expensive :P
[21:13] <chrisccoulson> and i don't like spending money
[21:14] <chrisccoulson> ;)
[21:14] <baptistemm_> same thing
[21:14] <baptistemm_> and girls are becoming dead-crazing with marriage
[21:14] <baptistemm_> s/crazing/crazy/
[21:16] <dobey> marriage is cheap
[21:16] <dobey> weddings are expensive
[21:17]  * baptistemm_ is pllainning some free time during christmas week for ubuntu and gnome hacking
[21:17] <chrisccoulson> dobey - yeah, that's what i meant
[21:17]  * baptistemm_ is  confused about marriage and wedding 
[21:17] <bryce> weddings don't have to be expensive ;-)
[21:17] <dobey> they don't have to be
[21:17] <chrisccoulson> one of our friends spent £20000 on their wedding ceremony, which is just crazy
[21:18] <bryce> baptistemm, wedding is the ceremony where you become married
[21:18] <chrisccoulson> that's basically a nice car :)
[21:18] <dobey> but the bride and her mother generally want them to be
[21:38] <rickspencer3> bryce, here is the promised JSON format for bughugger
[21:38] <rickspencer3> please note that I haven't actually implemented using this spec yet
[21:38] <rickspencer3> https://wiki.ubuntu.com/Bughugger/JSONformat
[21:38] <bryce> got it
[21:39] <rickspencer3> could you please let me know when you get around to doing it so I can hook it all up?
[21:39] <rickspencer3> it shouldn't take me long to implement, but will be waaay easier with some data
[21:46] <bryce> rickspencer3, sure.  I'm in the middle of redoing the signal handling code so we can get apport handling X crashes again with xserver 1.7.  Probably won't be until tomorrow that I get a chance to hammer on arsenal some more
[21:46] <rickspencer3> bryce, understood
[21:46] <rickspencer3> that is appropriate privatization, thanks for letting me know
[21:51] <chrisccoulson> bah, freenode fail
[21:53] <TheMuso> Freenode has been failing a fair bit lately it seems. :)
[21:54] <chrisccoulson> yeah, it's been terrible all day
[21:54] <bryce> -christel- [Global Notice] Hi all, as the europeans among us are already aware from earlier, we are experiencing heavy DDoS directed at several locations. For further information please /mode yournick +w or join #freenode. Thank you for your patience.
[21:54] <chrisccoulson> i thought that maybe my employer was blocking me from accessing it ;)
[21:55] <robert_ancell> TheMuso, welcome back
[21:56] <chrisccoulson> hey robert_ancell
[21:56] <robert_ancell> chrisccoulson, hey
[21:56] <chrisccoulson> how are you?
[21:57] <robert_ancell> chrisccoulson, good.  trying to get everything done before the holidays though :)
[21:57] <chrisccoulson> robert_ancell - when do you finish for the holiday?
[21:58] <rickspencer3> hi robert_ancell
[21:58] <rickspencer3> is TheMuso here as well?
[21:58] <robert_ancell> I'm off from Thursday next week
[21:58] <chrisccoulson> robert_ancell - still a few more days left yet then ;) i'm off from thursday next week too, but a lot of my colleagues finish this week
[21:59] <chrisccoulson> i should have saved some vacation ;)
[21:59] <TheMuso> rickspencer3: Yes.
[21:59] <robert_ancell> chrisccoulson, quiet offices can be good :)
[21:59] <rickspencer3> hi TheMuso, welcome back
[22:00] <rickspencer3> can we start the Eastern Edition like 5 minutes late?
[22:00] <TheMuso> rickspencer3: Sure, and thanks.
[22:00] <rickspencer3> for no better idea than I started brewing some coffee and I want to go get it :/
[22:00] <rickspencer3> ^worse excuse ever
[22:01] <chrisccoulson> rickspencer3 - that's a good excuse really. you should never let coffee go cold ;)
[22:01] <rickspencer3> well ... to make your friends wait for you while you go brew coffee is probably a pretty common thing in Seattle
[22:01] <TheMuso> And if I could indulge all of you in here to please read this, and take action as suggested, to protest against the Australian government's net filter legislation being planned. http://bethesignal.org/blog/2009/12/15/black-out-your-avatar-to-protest-nocleanfeed/
[22:01] <rickspencer3> but not sure how it plays in au
[22:02] <TheMuso> I am not going to spam this everywhere, but thought I'd bring it up with my team mates at least. If you read planet Ubuntu, you should also have seen it there.
[22:04] <robert_ancell> rickspencer3, we're pretty laid back in au
[22:04] <rickspencer3> hehe
[22:04] <rickspencer3> robert_ancell, TheMuso, ready?
[22:04] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-12-15
[22:04] <robert_ancell> go!
[22:04] <rickspencer3> this should be quite fast
[22:05] <rickspencer3> so, let's get those conference interests updated
[22:05] <rickspencer3> actually, I suppose TheMuso wasn't here for this
[22:05] <rickspencer3> TheMuso, please add your conference attendance plans as per the wiki
[22:06] <rickspencer3> robert_ancell, same for you, though I suppose it's a bitter pill hearing about this from now ;)
[22:06] <rickspencer3> next up was the partner update, mostly Ux was covered
[22:07] <rickspencer3> the key thing to be aware there is that weekly releases are every Thursday, just like in Karmic and also that the client side deco work is still hitting some pretty significant bugs, so seb128 is holding the line on letting those get uploaded
[22:07] <TheMuso> ok
[22:07] <rickspencer3> Kubuntu status seems to be par for the course
[22:08] <rickspencer3> release status only looked at work this week, not bugs
[22:08] <rickspencer3> our burndown chart looks good, we are under the trend line
[22:08] <robert_ancell> but christmas is coming...
[22:08] <rickspencer3> robert_ancell, yup
[22:08] <rickspencer3> I expect we will be well above the trend line when we get back from break ;)
[22:09] <rickspencer3> there as an xorg discussion regarding nvidia
[22:09] <rickspencer3> since i wasn't at the main meeting, I missed the discussion, so if you are interested, please look at the wiki and at logs
[22:10] <TheMuso> hrm ok will do.
[22:10]  * TheMuso is interested since he uses NVIDIA hardware.
[22:10] <rickspencer3> TheMuso, I'll paste the notes, hold on
[22:10] <rickspencer3> Currently the source produces a lot of different binaries, mainly for historical reasons. They will be changed to just produce three packages (nvidia-190, nvidia-190-modaliases, nvidia-190-dev). libvdpau will become a version-independent separate source.
[22:10] <rickspencer3> There was some discussion about going back from version number based package names to -current/-legacy (or a mix). Both approaches have their pros and cons, but it was determined that fixed package names are easier to maintain (both the packages themselves as well as the bug reports). nvidia-common needs to be used during upgrades either way, and with the planned X.org autodetection changes, apt-get dist-upgrade'ing into a new dr
[22:10] <rickspencer3> iver version which does not support your card any more should not be the end of the world any more.
[22:11] <rickspencer3> robert_ancell, we need to meet this week for performance review
[22:11] <rickspencer3> are you available this morning?
[22:11] <robert_ancell> rickspencer3, sure
[22:11] <rickspencer3> TheMuso, we need to meet also, can we use our regularly scheduled call tomorrow morning?
[22:12] <TheMuso> rickspencer3: That was my plan, so yes thats fine.
[22:12] <rickspencer3> great
[22:12] <rickspencer3> any other business?
[22:12] <robert_ancell> no
[22:13] <TheMuso> no
[22:15] <rickspencer3> ok
[22:15] <rickspencer3> great
[22:15]  * rickspencer3 taps gavel
[22:19] <seb128> hello robert_ancell
[22:24] <robert_ancell> seb128, hey, in meeting
[22:24] <seb128> ok
[22:25] <seb128> robert_ancell, there is no hurry I just wanted to ask if,when you think you will look at gnome-panel speed issues
[22:26] <seb128> just to not dup work before looking at those
[22:26] <robert_ancell> seb128, yes, been looking at them. lets discuss in 10 mins ok?
[22:26] <seb128> I'm not having lot of luck on nautilus so far and I might have a look at gnome-panel for a change
[22:27] <seb128> robert_ancell, ok
[22:27]  * seb128 goes back to some nautilus strace reading
[22:39] <rickspencer3> robert_ancell, here's what I am trying to do, and maybe you can help
[22:39] <rickspencer3> essentially, I want to build TreeViews that have columns typed appropriately BUT ...
[22:40] <rickspencer3> I don't know what the columns will be at  design time, I need to discover them at run time
[22:40] <robert_ancell> seb128, http://paste.ubuntu.com/342197/
[22:40] <rickspencer3> but TreeView ListStores are instantiated with a series of types as arguments, not as a list
[22:41] <robert_ancell> rickspencer3, so you want the columns to be visible but filled with data at a later point?
[22:41] <seb128> robert_ancell, did you figure anything using those?
[22:41] <robert_ancell> (and the type of data is not known until a later point)
[22:42] <seb128> robert_ancell, I did something similar for nautilus
[22:42] <seb128> (ie following federico blog)
[22:42] <robert_ancell> seb128, the things that stand out is - the widgets are being loaded in series which seems inefficient
[22:42] <robert_ancell> seb128, some, especially indicator-applet take a long time for the binary to load (and it is started last)
[22:42] <seb128> right, the indicator applet issue is known
[22:42] <robert_ancell> seb128, yes, this is a modified federico patch, and I updated his time plotter
[22:43] <seb128> they have to optimize their code
[22:43] <seb128> I stopped using the plotter
[22:43] <seb128> I read strace logs now...
[22:43] <robert_ancell> seb128, also connecting to gnome-session is really expensive
[22:43] <robert_ancell> seb128, man, you're in deep
[22:44] <seb128> heh
[22:44] <robert_ancell> rickspencer3, you there?
[22:44] <seb128> you mean reading .ICEauthority etc?
[22:44] <rickspencer3> robert_ancell, yeah, was just waiting for you to finish up with seb128
[22:44] <rickspencer3> robert_ancell, so ...
[22:44] <seb128> rickspencer3, that could be a long discussion, you guys just cut me there
[22:45] <rickspencer3> ?
[22:45] <seb128> rickspencer3, the login speed discussion could take a while
[22:45] <rickspencer3> seb128, ok
[22:45] <seb128> ie don't bother waiting for it to be done
[22:45] <seb128> there is no hurry there
[22:45] <robert_ancell> seb128, gnome_client_connect()
[22:45] <seb128> we can move to query if that flood the channel
[22:45] <rickspencer3> may I go on? I think robert_ancell may be able to help me rather more quickly
[22:45] <seb128> sure
[22:45] <robert_ancell> rickspencer3, yeah, I can do both
[22:45]  * rickspencer3 picks robert_ancell'
[22:46] <rickspencer3> s gtk brain
[22:46] <robert_ancell> rickspencer3, heh, you have the apostrophe/enter problem too
[22:46] <rickspencer3> ok, so robert_ancell the issue is that I don't know how many columns or the types needed at run time
[22:46] <rickspencer3> so, I handle it like this currently: col_types = [gobject.TYPE_STRING for i in xrange(col_count)]
[22:46] <rickspencer3>         col_types[len(self.keys)] = gobject.TYPE_PYOBJECT
[22:46] <rickspencer3>         self.list_store = gtk.ListStore(*col_types)
[22:47] <rickspencer3> I guess I could iterate the col_types, check it against the some hint list passed in, and then change the type before passing the pointer to the list_store
[22:47] <rickspencer3> so like
[22:48] <rickspencer3> for col_type in col_types:
[22:48] <rickspencer3>  if matches some test:
[22:48] <rickspencer3>    col_type = new_type
[22:48] <rickspencer3> thoughts?
[22:50] <robert_ancell> rickspencer3, right, I think you really need to implement a new TreeModel
[22:50] <rickspencer3> you mean derive from ListStore?
[22:50] <rickspencer3> what would that buy me?
[22:51] <rickspencer3> just cleaner code?
[22:51] <robert_ancell> rickspencer3, so your saying what you do currently is make a model with essentially void pointers and lots of columns and hope the user doesn't dynamically add too many columns
[22:51] <robert_ancell> rickspencer3, well neither ListStore or TreeStore allow dynamic changing of columsn
[22:52] <rickspencer3> robert_ancell, the user can't add columns
[22:52] <rickspencer3> the problem is just setting up the column types when I don't know them at design time
[22:52] <rickspencer3> I infer the columns from the data that the TreeView is trying to present
[22:53] <rickspencer3> so I can just use TYPE_STRING, except then numbers don't sort correctly
[22:53] <robert_ancell> rickspencer3, do you have an example program?
[22:53] <rickspencer3> robert_ancell, yes, this is the dictionary_grid widget in Quidgets
[22:53] <rickspencer3> however, after explaining it to you, I think I may have hit upon a solution (in classic problem solving style)
[22:54]  * rickspencer3 tries
[23:00] <rickspencer3> robert_ancell, I am on track to solving this problem ... BUT
[23:00] <rickspencer3> man I hate gtk TreeViews
[23:01] <robert_ancell> rickspencer3, yeah, they're a bit of a mess...
[23:01] <rickspencer3> they are just so rigid
[23:02] <robert_ancell> rickspencer3, so looking at dictionary_grid.py, I'm not sure of the problem, you create the list_store in __reset_model() and you have the dictionary at that point so you can work out what the coulmns need to be by scanning the dictionary (though it may be inconsistent)
[23:02] <rickspencer3> to make this robust I will need to store the array of goject types for the columns, and then test each value and cast it as appropriate
[23:03] <rickspencer3> robert_ancell, right, that's essentially what I am doing
[23:03] <rickspencer3> by default, they will be strings, unless the key is named by a conventional name, like "id"
[23:03] <robert_ancell> seb128, so I will look at the gnome-panel stuff again today but don't let that stop you working on it.  Just email me if you make any progress
[23:04] <seb128> robert_ancell, I'm not likely going to look at it this week
[23:04] <rickspencer3> and I will allow the consumer to pass in "type hints" to tell the grid what types to use for certain columns
[23:04] <rickspencer3> *sigh*
[23:04] <seb128> but maybe a bit during holidays if I'm bored
[23:04] <robert_ancell> seb128, _really_ bored
[23:04] <seb128> robert_ancell, I've been stracing nautiilus a lot for a week
[23:04] <robert_ancell> seb128, anything low hanging?
[23:05] <robert_ancell> rickspencer3, that's the problem with dynamic languages - it's hard to not treat the data all as strings
[23:05] <seb128> not really
[23:05] <seb128> I've found one thing that alex fixed quickly this week
[23:05] <rickspencer3> robert_ancell, well ... this is an API issue
[23:05] <seb128> .gtk-bookmarks was rewritten 5 times at login
[23:05] <rickspencer3> if I were doing this in C I would have the same issue
[23:05] <robert_ancell> seb128, so I'm thinking with gnome-panel we should at least be able to start all the applet processes at the same time but I don't think it's going to be a simple patch
[23:06] <seb128> otherwise it's hard to find slow code, alex is writting good code and has been cleaning nautilus regularly with gvfs, etc migrations
[23:06] <seb128> I'm not sure it's going to help much
[23:06] <seb128> those are starting in 3 seconds on my laptop and it's 2 years old now...
[23:06] <seb128> the mini is very cpu limited
[23:07] <robert_ancell> seb128, yeah, I'm thinking there's not much more that 0.5-1 second to gain from all this
[23:07] <seb128> the cpu is at 100% during whole loading
[23:07] <seb128> we need to do less, not to shuffle when
[23:08] <seb128> nautilus is though, like one my laptop one full second is ld loading
[23:08] <seb128> 70 libs to load = 1 second
[23:08] <robert_ancell> seb128, the other thing is the panel keeps getting laid out by gtk while loading - it should only do that at the end.  But that looks really hard to modify in the existing code
[23:08] <seb128> 1 second is icon caches loading
[23:08] <seb128> 1 second is fontconfig
[23:09] <seb128> then you get mimetype database loading
[23:09] <seb128> some icons reading
[23:09] <seb128> gtk pixbuf loaders init
[23:09] <seb128> pango init
[23:09] <seb128> translations opening
[23:09] <seb128> there is not much to reduce that I can find so far
[23:10] <seb128> out of reducing our number of installed themes, fonts, etc
[23:11] <dtchen> seb128: I take it those actions are all user-specific?
[23:11] <robert_ancell> seb128, I'm really surprised how inefficient the kernel is at loading libraries.  I don't get why it takes so long
[23:11] <seb128> dtchen, not really but disk is not the limiting part there, ie preloading is already done
[23:11] <dtchen> seb128: ah, cpu-bound
[23:11] <robert_ancell> (or ld if that is the slow part of loading libs)
[23:11] <seb128> yes
[23:11] <seb128> the mini has a ssd drive
[23:12] <seb128> disk is really not an issue
[23:12] <seb128> robert_ancell, dunno what is the slow part, I just strace and look to it
[23:12] <seb128> ie
[23:12] <seb128> $ echo 3 | sudo tee /proc/sys/vm/drop_caches
[23:12] <seb128> and strace -tt nautilus
[23:13] <seb128> it takes almost one second on cold cache with my hdd
[23:13] <seb128> it takes some 0.3 seconds on mini ssd
[23:14] <seb128> robert_ancell, one other thing is x11, libice reads .ICEauthority twice
[23:14] <robert_ancell> seb128, well it might have changed in 0.1s :)
[23:15] <seb128> one for xsmp one for ice
[23:15] <seb128> but the second loading is actual quick since it's in cache
[23:16] <seb128> but the first read takes some 0.5 seconds
[23:17] <seb128> robert_ancell, see http://people.canonical.com/~seb128/nautilus
[23:17] <seb128> robert_ancell, those are notes from me reading through nautilus strace on the mini at login
[23:17] <robert_ancell> seb128, right
[23:17] <seb128> ie I changed the .desktop to run it under strace
[23:18] <seb128> so I've login cache conditions etc
[23:18] <robert_ancell> ah good idea
[23:19] <seb128> another thing taking half of a second is the wallpaper
[23:19] <seb128> but I don't see a way around it, it needs to load and display an image
[23:19] <seb128> and that takes a bit of time
[23:21] <robert_ancell> seb128, yeah, you could cache the image in a decompressed format I guess?
[23:23] <seb128> robert_ancell, right, that would be nice
[23:24] <seb128> I'm wondering if nautilus does that already
[23:24] <robert_ancell> seb128, I don't think so
[23:30] <rickspencer3> robert_ancell, so I have run time col type setting basically working
[23:31] <chrisccoulson> if xsplash comes back, is there any chance that backround pixmap created by xsplash could be used as the wallpaper? (or is that even possible?)
[23:31] <chrisccoulson> that would save on reading image / sending to server etc
[23:31] <rickspencer3> so now I'll program in some robustness by trying to detect the type and cast values passed in as the correct type at runtime
[23:31] <robert_ancell> rickspencer3, cool, committed?
[23:31] <rickspencer3> robert_ancell, in the bughugger code, but not in Quidgets yet
[23:31] <robert_ancell> rickspencer3, ok
[23:31] <rickspencer3> let me add it to Quidgets, will take 5 mins
[23:33] <seb128> chrisccoulson, that's a good question and I don't know
[23:34] <chrisccoulson> seb128 - yeah, it was just a thought. i'm not sure how easy that would be to do though
[23:34] <chrisccoulson> but re-using server-side pixmaps must save a little bit of time :)
[23:35] <rickspencer3> robert_ancell, pushed, not that I don't have the tests written yet
[23:35] <robert_ancell> rickspencer3, pulling
[23:37] <robert_ancell> rickspencer3, makes sense
[23:37] <seb128> chrisccoulson, right
[23:38] <robert_ancell> rickspencer3, the hinting is a bit annoying from an API point of view but there's no schemas to get this info from couch right?
[23:39] <rickspencer3> robert_ancell, this is dictionary_grid, the backing store is just a dict
[23:39] <rickspencer3> the hinting is annoying, but that's because TreeView is annoying
[23:39] <robert_ancell> rickspencer3, right, so the CouchGrid will be simpler to use
[23:39] <rickspencer3> I could use test() to infer the types
[23:40] <rickspencer3> robert_ancell, not really, the APIs will be similar, just some extra stuff for CouchGrid
[23:40] <rickspencer3> the hinting is optional though
[23:41] <rickspencer3> robert_ancell, the thing is, the user can add a list of dictionaries, and then add new rows too
[23:41] <rickspencer3> there is no way to guarantee that every value for each key will always be the same type
[23:42] <robert_ancell> rickspencer3, yeah, but in normal use it will be
[23:42] <rickspencer3> robert_ancell, so you are saying, infer the type from the first row of values passed in, and then just be robust against the cases where that assumption is violated?
[23:43] <rickspencer3> I can keep the hinting for the rare case where an override is needed
[23:43] <rickspencer3> I could extend that logic to filters as well
[23:43] <rickspencer3> the other option is to go the rails route
[23:43] <rickspencer3> use naming conventions
[23:43] <rickspencer3> so id is always an int unless overriden, etc...
[23:44] <rickspencer3> anything that ends with count, etc..
[23:44] <robert_ancell> rickspencer3, well, no I'm more saying there's not a good match between user expectations and what the API can handle.  The user could be thinking "column x is all integers - it should automatically treat them like integers" but there's no scalable way to do that automatically
[23:44] <rickspencer3> robert_ancell, convention over configuration can
[23:44] <rickspencer3> that's scalable and can set expecations
[23:45] <rickspencer3> than the hinting can be used to override the conventions (like when ID is a string)
[23:45] <robert_ancell> rickspencer3, right, I haven't used rails so I'm still a little unsettled by this convention stuff :)
[23:45] <rickspencer3> mmm
[23:45] <rickspencer3> well, if robert_ancell finds it unsettling, it must be good stuff ... so that's decided
[23:45] <robert_ancell> lol
[23:46] <rickspencer3> so if it ends in "count" I can make it an int
[23:47] <rickspencer3> if it is "price" or "cost" I can make it a float
[23:47] <rickspencer3> then when rows are added, I iterate through each and ensure it is a type that will be accepted by the column so the user doesn't get those pesky errors from the TreeView
[23:49] <rickspencer3> I should support checkboxes in the views too
[23:49] <rickspencer3> and all this will have to be modified so that it can be translated, I suppose