[14:33]  * kenvandine_wk learned the difference between a . and ~ in a version :)
[14:35] <didrocks> seb128: any reason why gnome-user-share is still 2.25.92?
[14:35] <seb128> didrocks: nobody bothered doing the upgrade I guess
[14:35] <kenvandine_wk> didrocks: i think it was late for 2.26.0
[14:35] <seb128> kenvandine_wk: ?
[14:36] <kenvandine_wk> i don't think the tarball was ready on time
[14:36] <seb128> kenvandine_wk: we did GNOME updates today still so I don't think it was that late
[14:36] <didrocks> seb128/kenvandine_wk: do you want I update it (to have a FFe)
[14:36] <kenvandine_wk> so it wasn't in your queue :)
[14:36] <kenvandine_wk> oh... not that late
[14:36] <seb128> it's rather in universe so I don't list it
[14:36] <kenvandine_wk> i meant last time
[14:36] <kenvandine_wk> ah
[14:36] <kenvandine_wk> i looked during the last bump, and it wasn't done
[14:36] <seb128> it's up for MOTU or whoever cares about it
[14:36] <seb128> I'm tracking ubuntu-desktop updates
[14:37] <seb128> didrocks: feel free to do the update, thanks
[14:37] <didrocks> seb128: ok, doing it now
[14:37] <seb128> thanks
[14:37] <didrocks> seb128: y/w
[14:48] <kenvandine_wk> asac: so how is the gwibber review?  what can we do?
[14:48] <kenvandine_wk> asac: and anything i can do to help?
[14:51] <superm1> seb128, wanted to ping you re bug 272083. upstream hasn't been responsive looking at the upstream bug report. how do you (and other -desktop) folk feel about pulling in a patch that just fixed it in the glade file?
[14:55] <asac> kenvandine_wk: well. i think its too late for gwibber. we should file this upstream as lesson learned :)
[14:56] <asac> for me the UI regressed. also it didnt even start -> https://code.edge.launchpad.net/~asac/gwibber/xdg_data_dirs_typo/+merge/5516
[14:56] <kenvandine_wk> we really want the indicator support though... perhaps we can just back port those changes?
[14:56] <kenvandine_wk> hehe
[14:56] <asac> kenvandine_wk: doesnt reawlly speak for the quality and seems liek more testing is needed
[14:56] <kenvandine_wk> the extra _
[14:56] <asac> kenvandine_wk: so yeah. if we can come up with a minimal indicator patch that would work
[14:57] <kenvandine_wk> ok
[14:57] <kenvandine_wk> asac: i can do that at least
[14:57] <kenvandine_wk> jorge says there are some pretty important bug fixes too... but i guess we should make them justify bug fixes we pull in
[14:57] <asac> kenvandine_wk: but that has to be easy to see that its safe ;) ... not sure if there were infrastructure fixes required - which would make this harder to do in a safe fashion
[14:57] <asac> kenvandine_wk: we can pull in bug fixes after release as SRU
[14:57] <kenvandine_wk> asac: the MI is easy
[14:58] <kenvandine_wk> i will get a patch this morning :)
[14:58] <asac> kenvandine_wk: "easy" always feels risky ;)
[14:58] <asac> great
[15:04] <jcastro> kenvandine_wk: that twitter patch needs to go in for sure
[15:04] <jcastro> it doesn't work otherwise
[15:04] <kenvandine_wk> good point
[15:04] <kenvandine_wk> i'll do that separate
[15:05] <seb128> you guys are still discussing gwibber?
[15:05] <seb128> I've the impression you are discussing that for weeks now ;-)
[15:05] <kenvandine_wk> hehe
[15:06] <kenvandine_wk> it's a mess :/
[15:06] <seb128> just drop the thing for jaunty if it doesn't work
[15:06] <seb128> that will teach upstream to ship code which is working maybe next time ;-)
[15:09] <seb128> superm1: I've no real opinion about that change and it's late for jaunty now, is that creating issues in visible situations?
[15:11] <jcastro> seb128: well, they did have to wait for the indicator stuff to land
[15:11] <jcastro> but yeah, it took too long
[15:11] <kenvandine_wk> jcastro: 2 weeks ago in my ppa :)
[15:11] <superm1> seb128, for mythbuntu it's making a bad situation, that if you launch mythtv-setup, when it closes, it uses zenity to ask to make some changes, but it comes up behind the application you launched mythtv-setup from, and the application you launched it from is blocked in the UI
[15:11] <seb128> we shouldn't have pushed the indicator changes if they were too late then
[15:12] <seb128> superm1: and nobody noticed until today?
[15:12] <seb128> superm1: how did you do before?
[15:12] <superm1> seb128, no we knew about it for a while, but we thought it was an xfwm4 bug
[15:13] <superm1> xfwm4 was doing focus entirely wrong on 8.10, and w/ the update-manager changes they fixed that bug and this showed up w/ higher visibility
[15:13] <seb128> I'm not familiar enough with the map on focus behaviour to comment and mvo is on holidays still today
[15:13] <seb128> so ask slangasek or wait for him to come back tomorrow that will not be for rc anyway
[15:14] <superm1> yeah it's post install that it is a problem, so after RC is fine
[15:25] <asac> kenvandine_wk: there is supposed to be a twitter fix on trunk too; can you see if we can cherry pick that too?
[15:26] <kenvandine_wk> asac: already done
[15:26] <asac> kenvandine_wk: its 285
[15:26] <asac> ah cool
[15:26] <asac> kenvandine_wk: do you have your own team or are you in gwibber-team?
[15:26] <asac> err your own branch i mean
[15:27] <kenvandine_wk> no... just creating a debdiff
[15:27] <asac> okay
[15:27] <asac> kenvandine_wk: isnt it a full source branch? if thats the case cherry picking in bzr directly would make sens
[15:28] <asac> (imho)
[15:28] <kenvandine_wk> oh... didn't look
[15:28] <kenvandine_wk> but i can do that
[15:28] <kenvandine_wk> actually
[15:28] <kenvandine_wk> not that simple
[15:28] <kenvandine_wk> i am having to tweak the patches from bzr
[15:28] <asac> kenvandine_wk: its bzr merge -c 285
[15:28] <kenvandine_wk> because of other changes sprinkled in there
[15:28] <kenvandine_wk> i am pulling bits from 4 revisions
[15:29] <asac> yeah. still bzr might be smart when merging new upstream and eliminate it
[15:29] <kenvandine_wk> the twitter one is just one rev
[15:29] <asac> (not sure if its that smart though ;))
[15:29] <kenvandine_wk> i had to make manual changes... not just merge related
[15:29] <asac> kenvandine_wk: yeah one rev is merge -c REVISION
[15:29] <asac> k
[15:29] <kenvandine_wk> so is the packaging in bzr?
[15:29] <asac> what does control suggest ;)?
[15:30] <kenvandine_wk> yeah... :)
[15:30] <kenvandine_wk> i hadn't looked there yet
[15:30] <asac> kenvandine_wk: its https://code.edge.launchpad.net/~gwibber-team/gwibber/packaging
[15:30] <kenvandine_wk> got it
[15:30] <asac> fta: can you cut off a stable branch for revision 50 ?
[15:30] <asac> kenvandine_wk: there is more ...revision 50 is what we have in archive
[15:30] <kenvandine_wk> ok
[15:31] <asac> fta: is the python-xdg depend needed for 0.8 or only after that?
[15:32] <asac> kenvandine_wk: ok revision 51 is what you should start on
[15:32] <kenvandine_wk> ok
[15:32] <asac> except that the changelog is bumped there
[15:32] <asac> which seems to be a mistake
[15:39] <kenvandine_wk> asac: so why rev 51?
[15:39] <kenvandine_wk> since rev 50 is existing version in universe?
[15:42] <asac> kenvandine_wk: i wanted rev 51 for the python-xdg fix
[15:42] <kenvandine_wk> ah
[15:42] <kenvandine_wk> ok, so that is real
[15:42] <asac> kenvandine_wk: well. just cut off rev 50
[15:42] <asac> and do the python-xdg on that stable branch i would say
[15:42] <kenvandine_wk> ok
[15:42] <tedg> pitti: Thanks for sponsoring and uploading the bug fixes on indicator-applet.
[15:42] <kenvandine_wk> just add the dep?
[15:42] <pitti> hey tedg; you're welcome
[15:43] <asac> kenvandine_wk: yeah. bump changelog to next revision and UNRELEASED and commit python-xdg dep
[15:44] <juanje> hi, guys. Does anyone know if there is any standard for menu entries? some spec, doc, wiki or something?
[15:44] <juanje> I mean the way of putting the names and descriptions
[15:45] <dobey> juanje: there's the fd.o desktop and menu specifications
[15:45] <dobey> desktop file rather
[15:45] <juanje> dobey: yeah, I know. It is not what I meant.
[15:46] <dobey> well name should be the name of your app, and description should be a very short (few words) description of what it does
[15:46] <juanje> I mean the names like: "Description App name"
[15:46] <juanje> or "App name"
[15:46] <juanje> or "Description (App name)"
[15:47] <juanje> dobey: yes, but the problem is that I don't see any standard way to fill the field "Name=" on .desktops
[15:47] <dobey> name, genericname, and description seem like straightforward descriptions of what they should be, to me
[15:47] <juanje> some apps put just descriptions
[15:48] <dobey> juanje: all apps put their name there
[15:48] <dobey> what apps put descriptions there?
[15:48] <juanje> others add also a description
[15:48] <juanje> dobey: let me search one...
[15:49] <dobey> some put both name and genericname inside name
[15:49] <dobey> which is wrong really
[15:49] <dobey> epiphany does that
[15:51] <dobey> the point of them being separate is to allow whatever is displaying the menus to handle that in some preferred way
[15:51] <mclasen> them being separate is broken, i18n-wise, though
[15:52] <juanje> dobey: here some examples:
[15:52] <juanje> /usr/share/applications/transmission.desktop:Name=Transmission BitTorrent Client
[15:52] <juanje> /usr/share/applications/tsclient.desktop:Name=Terminal Server Client
[15:52] <juanje> /usr/share/applications/vino-preferences.desktop:Name=Remote Desktop
[15:52] <juanje> /usr/share/applications/xsane.desktop:Name=XSane Image scanning program
[15:52] <juanje> /usr/share/applications/brasero.desktop:Name=Brasero Disc Burner
[15:52] <juanje> /usr/share/applications/alacarte.desktop:Name=Main Menu
[15:52] <juanje> some has name, some not
[15:52] <juanje> some description, some just the description
[15:52] <juanje> and there are much more
[15:52] <juanje> all are from the last Jaunty
[15:53] <dobey> mclasen: not really
[15:54] <mclasen> yes, it is
[15:54] <dobey> having N apps all translate the same text N times is broken, i18n-wise
[15:54] <dobey> for most apps, Name shouldn't be translated at all
[15:55] <mclasen> if you want to be able to display a combination of name and generic name in the menu, that combination needs to be translated as one
[15:56] <juanje> dobey: but should be a standard about what to put as Name
[15:56] <dobey> we shouldn't be putting generic name in anything anyway
[15:56] <dobey> and name and generic name shouldn't be concatenated
[15:57] <juanje> somethines devs don't put the app name, others yes
[15:57] <dobey> juanje: i think you're just confusing some of them because "preferences" items are also in /usr/share/applications
[15:58] <dobey> so alacarte just says "Main Menu", which it isn't, but which it modifies
[15:58] <juanje> dobey: not, if you see the apps in the menu you can see they are different
[15:59] <juanje> my problem is this is very heterogeneous and cofusing for the normal users
[15:59] <dobey> i didn't say others weren't broken
[15:59] <dobey> i said for the general case, name is the app's name
[15:59] <juanje> ok
[15:59] <juanje> I just need to know if there is any policy or spec about it in Ubuntu
[15:59] <dobey> or apparently in a lot of cases it is "appname genericname" which is broken
[16:00] <juanje> ummm
[16:01] <juanje> so, the normal way should be something like: Name=Epiphany  and GenericName=Web Browser
[16:01] <tedg> juanje: I'm pretty sure that the accepted standard is to use "Appname Functionality"
[16:01] <juanje> so you concatenate the names if you whish
[16:01] <tedg> Whether or not dobey thinks it's broken :)
[16:01] <dobey> tedg: it's broken
[16:02] <dobey> the accepted standard is more like 'do whatever the hell you feel like'
[16:02] <juanje> dobey:  I think it's important and should be fixed...
[16:02] <juanje> :-/
[16:02] <dobey> yes it should be fixed
[16:02] <juanje> the users can get very confused
[16:02] <dobey> but you'll find people will prefer to pain the shed, rather than fix it
[16:02] <juanje> and it's madnes for documentation
[16:03] <juanje> dobey: where you think is the better place to talk that? I mean, to make a spec and trying to do something?
[16:04] <dobey> i think making another spec would be redundant and pointless
[16:04] <juanje> I'm working on Guadalinex (a Ubuntu derivative) and we need to fix for us, but we like to help to be fixed upstream (I mean Ubuntu)
[16:05] <dobey> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys
[16:05] <dobey> that clearly specifies what name/genericname/comment should be
[16:05] <juanje> dobey: but there is already a lot of things Ubuntu change on the packages (for example the X-GETTEXT.... on .desktops)
[16:05] <dobey> sure
[16:06] <juanje> ummmm
[16:06] <juanje> so we can change them in the same way, I guess...
[16:07] <dobey> if you want to maintain additional patches, sure
[16:07] <dobey> it would be best to get it fixed in proper upstream though
[16:07] <juanje> yes, of course
[16:08] <juanje> with official applications from GNOME or others big projects should be easier...
[16:09] <seb128> juanje: what do you want to add?
[16:09] <juanje> dobey: ok, thanks, so much for the info. I'll give it a though...
[16:09] <dobey> filing bugs with patches that are "foo does not adhere to the desktop file standard" are probably a good approach to it
[16:09] <juanje> seb128: I just like to have standard names for all the menu entries
[16:10] <seb128> "standard"?
[16:10] <juanje> not like now
[16:10] <dobey> seb128: "not a cluster of random different whatever the developer decided to shove in a desktop file"
[16:10] <juanje> seb128: yes, now there are some like "App_name description", other like "App_name" and other like "Description"
[16:11] <seb128> the HIG has recommendations and most applications are using those
[16:11] <juanje> seb128: and which is that recomendation?
[16:11] <seb128> the appname is there when that's not the standard application to do something
[16:11] <seb128> gedit is "text editor"
[16:11] <seb128> for example
[16:12] <juanje> aha
[16:12] <dobey> ugh, the HIG is broken
[16:12] <seb128> but gtkedit would be "gtkedit text editor"
[16:12] <seb128> so you don't confuse both
[16:12] <dobey> the gnome hig is
[16:12] <juanje> ummmm
[16:12] <seb128> there has been several GNOME discussions about that already
[16:12] <juanje> seb128: that is confusing for the userws and documentation
[16:12] <seb128> and how to handle the case where you have several applications for the same function
[16:13] <dobey> yeah, but GNOME isn't the only thing on the block
[16:13] <seb128> well there is no easy way around it
[16:13] <seb128> you don't want to put the application name in each menu entry that's ugly
[16:13] <juanje> seb128: mostly if yuo don't have the same "official" apps, as the Derivatives cases
[16:13] <seb128> but when you have several text editors you still want to be able to make the difference
[16:13] <dobey> well yes
[16:14] <juanje> seb128: but that is many times useful for documentation purposes
[16:14] <dobey> you don't want 10 text editors all called "Text Editor"
[16:14] <dobey> and having "Foo Text Editor" is almost as bad, since it's just blatently redundant
[16:14] <dobey> and it doesn't fit with the freedesktop spec
[16:15] <seb128> juanje: what do you suggest changing to make it better?
[16:15] <juanje> seb128: putting the name somehow
[16:15] <didrocks> re
[16:15] <seb128> wb didrocks
[16:16] <seb128> juanje: in every item? that would look ugly compared to what we have now
[16:16] <seb128> and titles would be harder to parse
[16:16] <dobey> no, every item shouldn't have app name as name
[16:16] <juanje> seb128: "Text edit (Gedit)"
[16:16] <seb128> that's not nice looking
[16:16] <mclasen>  eek
[16:16] <dobey> there needs to be more heuristic evaluation of it
[16:17] <dobey> ie, only things that are OnlyShowIn should have a generic name as Name
[16:17] <juanje> seb128: I know it is not the better option, but something must be
[16:17] <dobey> so gnome-calculator should be Calculator
[16:17] <seb128> that was discussed somewhere some time ago
[16:17] <dobey> but epiphany should be Epiphany
[16:17] <seb128> I think vuntz suggested adding the name if there was several option for the same function
[16:18] <seb128> I will probably not find the discussion now
[16:18] <seb128> that was either on the GNOME desktop devel list or the xdg one
[16:18] <dobey> but having GenericName at all seems pointless and a waste of time
[16:18] <dobey> it was almost certainly on a gnome list
[16:19] <juanje> seb128: I said that because on Guadalinex we have thousands of users which use the applications everyday on schools and other centers and they need lots of time to know the name of some application and the documentation, recipes and technical support need to know which app are they running...
[16:19] <dobey> because the gnome hig differs from the freedesktop spec
[16:19] <juanje> seb128: It's not easy guess which apps they are running some times... :-/
[16:19] <dobey> also, having menu names that differ from what's in "About" is annoying
[16:19] <seb128> http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00165.html
[16:19] <tedg> juanje: Depending on how your docs are built, it might be good to pull those from the .desktop files.  So if they change, your documentation gets updated.
[16:19] <seb128> ^ that was the discussion
[16:20] <dobey> yes, that was the gnome discussion that only considered gnome :)
[16:20] <seb128> still it has some suggestions and arguments
[16:20] <juanje> tedg: when you need to guide to a very end user through menues and options, you need to know...
[16:20] <seb128> ie useful to read before starting the discussion from scratch
[16:21] <seb128> juanje: well the documentation should match what you install
[16:21] <seb128> juanje: read the url I copied there
[16:22] <juanje> seb128: I'm goint now... But it's not just about the documetnation, also the technical support and more stuff
[16:22]  * juanje reading....
[16:22] <seb128> juanje: I don't say there is not a problem, you are arguing the wrong way
[16:23] <seb128> ie don't try to convince me there is an issue
[16:23] <seb128> but rather try to find a good solution
[16:23] <juanje> seb128: What do you mean?
[16:23] <juanje> ok
[16:23] <seb128> well you are trying to explain that the current situation is not ideal
[16:23] <seb128> we know about that, there is just no obvious better way right now
[16:23] <seb128> but we are open to suggestions
[16:24] <juanje> seb128: don't get me wrong, I don't try to convince you, I was just asking for a standard or for place to discuss and try to find solution. I haven't the solution at all
[16:24] <seb128> the xdg list would be a good place to start I guess
[16:24] <seb128> but such issues have already been discussed
[16:25] <seb128> so better to come with a good suggestion if you want to get things moving ;-)
[16:25] <dobey> well, even in the context of only gnome, the result of that discussion isn't the best
[16:26] <juanje> seb128: In Guadalinex we were changing all the .desktops to fit with "Description (app_name)" for all our defaults apps, but we like to try doing better and working with upstream
[16:27] <seb128> what are you trying to solve exactly?
[16:27] <seb128> make the job easier for phone debugging?
[16:27] <juanje> in part
[16:27] <juanje> and to have all the entries in the same way
[16:27] <juanje> no some with names and others without them
[16:28] <seb128> that doesn't bring any value
[16:28] <seb128> just makes those look less nice
[16:28] <juanje> and if the people goes to a forum and somebody says something about one app they know which one is
[16:28]  * asac runs to get some before before the meeting
[16:29] <juanje> seb128: well, at least looks more homogeneous...
[16:29] <seb128> they look less nice too
[16:29] <seb128> "Text Editor"
[16:29] <juanje> seb128: I know, it isn't nicer, but less heterogeneous
[16:29] <seb128> "Image Editor"
[16:29] <calc> juanje: are you doing it via GenericName (Name) or something else?
[16:29] <seb128> that's better than
[16:29] <seb128> "Text Editor (Somename)"
[16:30] <calc> seb128: not when you have more than one Text Editor installed :)
[16:30] <seb128> juanje: who cares about heterogeneous, what you aim at is easy to use
[16:30] <seb128> calc: cf backlog
[16:30]  * calc looking
[16:30] <seb128> "Text Editor" is the standard editor
[16:30] <juanje> seb128: heterogeneous get the users confused...
[16:30] <seb128> other alternative have the name specified
[16:31] <seb128> juanje: I fail to see why "Text Editor" would be confusing to users
[16:31] <juanje> seb128: that not
[16:31] <dobey> seb128: if you set "Text Editor" to something other than gedit in preferred applications
[16:31] <seb128> we don't do that
[16:31] <kenvandine_wk> asac: bug 361120
[16:31] <juanje> seb128: to have "Text Editor" and toher entry like "Foo for doing somwthing"
[16:31] <kenvandine_wk> asac: mind taking a look?
[16:32] <dobey> seb128: we don't, but if some user does
[16:32] <kenvandine_wk> asac: none of the source files are in the branch... so i couldn't use bzr-buildpackage... first one i have run into like that
[16:32] <dobey> oh, i guess 'text editor' was removed from default app preferences
[16:33] <juanje> seb128: Ok, Ubuntu and GNOME use some apps as defaults, but maybe other derivatives use others apps instead
[16:33] <dobey> and default app prefs is some awful ui too
[16:33] <kenvandine_wk> asac: gwibber seems fine
[16:34] <calc> i stopped reading once seb128 mentioned the the Gnome HIG specifically tells developers to violate the standard
[16:34] <seb128> (on the phone)
[16:34] <calc> so this issue is because Gnome is braindamaged once again :\
[16:35] <calc> imho it should have the correct values in the various areas and detect in the menu display code if it needs to display more such as "Name GenericName" such as for the gtkedit Text Editor case
[16:35] <calc> but then a lot of what Gnome does seems way out in space :\
[16:35] <dobey> i don't think i agree with that
[16:35] <dobey> but the HIG is definitely braindamaged
[16:36] <calc> dobey: well if you don't want all programs to always display such as Name GenericName then there has to be some sort of autodetection... or violation of the spec
[16:36] <calc> dobey: which is what i think they ended up saying f*ck the spec instead of doing the autodetection
[16:37] <calc> of course if you autodetect you also run into the problem of program names in the menu changing if you install more than one of the same type app
[16:37] <seb128> juanje: if you change "Text Editor" that's your issue as a distributor, you should not be doing that or update your documentation
[16:37] <dobey> nah, there is a better way to do it
[16:37] <calc> eg "Text Editor" becomes Gedit Text Editor magically if you install another one (from the user perspective)
[16:37] <dobey> "Text Editor" should be calling gnome-text-editor
[16:38] <calc> dobey: ah yea :) well for this one case that is true
[16:38] <seb128> calc: GNOME doesn't do any autodetection
[16:38] <dobey> at least, on deb/ubuntu/etc...
[16:38] <seb128> calc: they just use Name
[16:38] <calc> seb128: i know.. they tell people to violate the spec instead
[16:38] <seb128> calc: no they don't
[16:38] <calc> seb128: did you just say that they tell people to put in Name what they want displayed instead of the actual Name of the app?
[16:38] <dobey> seb128: yes they do. the HIG specifically says "don't do what the spec says, but do this instead"
[16:38] <dobey> without mentioning anything about the spec
[16:38] <calc> "Text Editor" is not the real name of Gedit
[16:39] <dobey> "text editor" is hardly a sufficient description of gedit anyway
[16:39]  * calc notes this is one of those things about Gnome that has annoyed him a long time, unless KDE has changed it actually used to use the values correctly
[16:41] <seb128> calc: KDE allow to customize the format using Name and GenericName I think
[16:41] <seb128> ie you can use "Name - GenericName"
[16:41] <seb128> or "Name"
[16:41] <seb128> or whatever
[16:41] <calc> yes and so they don't violate the spec either
[16:41] <calc> gnome decided we'll take the file format for desktop files and then just ignore the rest of the spec
[16:41] <seb128> who cares about the stupid spec ;-)
[16:42] <calc> Gnome == MSFT? :)
[16:42] <juanje> seb128: ummm... But, now, which is used in GNOME for the menus entries? Name or GnericName?
[16:42] <calc> juanje: Name
[16:42] <seb128> calc: the spec has been mostly written by GNOME people
[16:42] <calc> seb128: so even better they are preceding microsoft's OOXML efforts of documenting something that they don't even use properly themselves ;-)
[16:42] <seb128> calc: there is just a disagrement on the naming, your anti-GNOME comments are not really constructive there
[16:43] <dobey> seb128: actually, i think it was mostly written by waldo, and the gnome people just made minor changes/patches to it
[16:43] <calc> seb128: its very clear what is supposed to go into Name otherwise there would be no GenericName field at ALL
[16:43] <seb128> calc: ok, really constructive trolling, I will just ignore you there I think
[16:43] <seb128> I'm fine discussion the issue
[16:43] <seb128> but that's not the chan for trolling
[16:43] <seb128> discussion -> discussing
[16:44] <calc> seb128: explain why GenericName exists at all if Gnome supposeldy wrote the spec themselves... when they 1. don't use GenericName, and 2. Stick generic names into Name
[16:44] <juanje> well people, calm down... please...
[16:44] <seb128> calc: the spec is not all about Name
[16:45] <seb128> calc: you focus on one line of the spec
[16:45] <calc> of course its not, but that is one of the main features of the spec as it is primarily for menu items
[16:45] <dobey> calc: GenericName shouldn't exist (but neither should it be appended to Name)
[16:45] <seb128> calc: there is just disagrement on what Name should be
[16:46] <calc> ok
[16:47]  * calc notes this also causes Ubuntu to decide it needs to rewrite the Name fields for all OOo packages and properly other distros for other programs since we can't just stick to Name="Real Name" GenericName="what it is"
[16:47] <calc> s/properly/probably/
[16:47] <juanje> ummmm.. So the problem here is what the Name field should be?
[16:49] <calc> since apparently no one can agree (or knows?) what should be in the two fields distributions end up having to hack up the files themselves to make the menu entries look the way they want them to.... EPIC FAIL
[16:49] <juanje> I thought the rule was follow the spec... and the problem was some apps that were broken that rule... I guess I was wrong...
[16:49] <calc> the whole concept of this was to make menus less trouble to deal with and it hasn't really acheived... works for the mime half (afaik) but not well for the menus
[16:49] <mclasen> following the spec to the letter doesn't lead to workable menus
[16:50] <calc> mclasen: not workable according to the HIG i suppose? It seems to work well for KDE
[16:50] <juanje> mclasen: so, why the spec then?
[16:50] <asac> kenvandine_wk: please add LP: #358341 to the twitter changelog entry
[16:50] <mclasen> but menus are not really a very good solution for the problem in the first place
[16:50] <juanje> calc: How is KDE doing that?
[16:51] <seb128> juanje: how you want, they let you pick the field to use and the order
[16:51]  * asac waits for some dents to arrive to see how well indicate works with gwibber
[16:51] <kenvandine_wk> asac: ij
[16:51] <calc> juanje: i don't remember anymore, its been a few years since i maintained KDE
[16:51] <seb128> juanje: which probably doesn't make your documentation job any easier
[16:51] <juanje> calc: but they use Name and GenericName?
[16:52] <calc> juanje: afaik they use them depending on what you set in the config
[16:52] <calc> juanje: can be Name (GenericName) GenericName (Name) and maybe various other combinations
[16:52] <calc> some years ago i wrote menu-xdg, back when i still maintained KDE
[16:52] <asac> kenvandine_wk: to earn extra credits you could refer to the revision you cherry picked/ported either in patch description or in changelog
[16:53]  * asac still waiting for new dents ;)
[16:53] <juanje> seb128: ummmm... I don't know...
[16:53] <kenvandine_wk> asac: pushed changes
[16:53] <kenvandine_wk> asac: ok, i can add revnos :)
[16:54] <asac> either URL to revisions or revno + branch reference ;)
[16:55]  * calc stops discussing something that will never be solved, no point in hoping they start following standards
[16:55] <asac> kenvandine_wk: bug 359885 and bug 360468 are dupes, right?
[16:55] <calc> juanje: basically you will probably need to patch all desktop files you want to change yourself... we already do that in Ubuntu to make the OOo "Name"s generic
[16:55] <juanje> seb128: the problem with the documentation, support and users is that usually people like to have names for calling to the things their use and not all the apps have the same menus, options, configurations and so. And when an user google for a problem on Guadalinex/Ubuntu usually found stuff like "open Gedit and do something" or "run appX" and so on...
[16:55] <rcmorano> i don't see the bad point in following the [obsolote-or-not]spec
[16:55] <rcmorano> at least we'd have smth standard...
[16:56] <rcmorano> not a mess
[16:56] <asac> kenvandine_wk: hmm first seems to be rate related. so i guess only the 36.. one is dupe
[16:56] <calc> rcmorano: the spec isn't obsolete its that Gnome just choooses to ignore what those two fields are actually for
[16:56] <seb128> rcmorano: there is no mess right now, the ubuntu menus are quite easy to use, the entry are described by their function
[16:56] <calc> rcmorano: which leads to people having to rewrite the desktop files for various apps because they don't like the way they look
[16:57] <kenvandine_wk> asac: yes, that's right
[16:57] <calc> rcmorano: in Ubuntu's case if they were done properly we could just use GenericName instead of Name for all apps
[16:57] <asac> kenvandine_wk: so 359885 is a regression from the the GET/POST fix (of course not easily fixable, so ok imo)
[16:57] <kenvandine_wk> yeah
[16:58] <dobey> calc: what would GenericName for gnometris be? :)
[16:58] <juanje> seb128: I know is a bit uglier to have "GenericName (Name)" or similar, but it is worst to have some in that way, others "Generic Name", others "Name - GnericName", and much muro.. options in the same menu...
[16:58] <calc> dobey: that one is tough as its already nearly infringing on a trademark
[16:58] <rcmorano> seb128: not every application uses the same naming style
[16:58] <dobey> calc: and following the gnome hig would be stupid "Gnometris Tetris" ?
[16:58] <dobey> heh
[16:58] <calc> dobey: i think they used the trademark in the genericname field for kde's version at least for a while
[16:59] <seb128> we can go round for hours on this discussion, I stop there
[16:59] <asac> kenvandine_wk: when is the indication supposed to happen? only when i get replies?
[16:59] <seb128> GNOME already had it several times
[16:59] <rcmorano> so for me it's kinda a mess and an extra job to re-rewrite the names for our distro
[16:59] <kenvandine_wk> asac: yes
[16:59] <asac> kenvandine_wk: can you dent me something ;)?
[16:59] <kenvandine_wk> well
[16:59] <juanje> seb128: Ok, GNOME menu it's very easy to use and I love that, but there are a lot of not GNOME apps the people install or need, which follow different ways
[16:59] <kenvandine_wk> do you have python-indicate installed?
[16:59] <dobey> GNOME having a discussion is only partly useful
[16:59] <asac> kenvandine_wk: i would think so ;)
[16:59] <calc> dobey: well putting "Tetris" anywhere in it would be stupid yes... since you don't want to get sued :)
[16:59] <asac> kenvandine_wk: let me check
[16:59] <seb128> having "Description - Name" for every entry is just not nice looking and wouldn't be any better
[16:59] <pitti> I'm off now, for dinner; see you tomorrow!
[16:59] <kenvandine_wk> oh... i should add that as a recommends
[16:59] <asac> kenvandine_wk: yes. i mean gwibber appears in the applet.
[16:59] <kenvandine_wk> pitti: later!
[16:59] <seb128> pitti: no team meeting for you?
[16:59] <asac> kenvandine_wk: its just i dont get any messages indicated there
[16:59] <kenvandine_wk> asac: ok... let me dent you
[17:00] <rcmorano> why to have "Description - Name" just in some apps ?
[17:00] <dobey> calc: having the game at all with any name similar to tetris is probably grounds for getting sued
[17:00] <asac> kenvandine_wk: yeah. once i saw this working, we should add it as recommends
[17:00] <calc> seb128: if you installed all desktop apps in universe i think your idea of what looks nice vs the way they currently look might change
[17:00]  * kenvandine_wk does that
[17:00] <seb128> calc: we optimize for default installation
[17:00] <calc> seb128: i'd imagine if you did that GenericName - Name (properly done) would look much better
[17:00]  * asac keeps gwibber in tray (not open) and waits for indication
[17:00] <dobey> GenericName needs to FOAD
[17:00] <calc> seb128: aka we don't care about anything other than a very small set of programs
[17:00] <asac> kenvandine_wk: nope :(
[17:01] <asac> kenvandine_wk: only got your bubble
[17:01] <asac> no indication
[17:01] <seb128> calc: is that new to you?
[17:01] <Amaranth> I haven't seen any apps in my menus with Generic Name - Name
[17:01] <calc> seb128: so whether it looks good in the general case... we actually don't care about
[17:01] <dobey> you don't see people having this discussion in windows
[17:01] <seb128> calc: that's why we have main and universe
[17:01] <calc> seb128: no but arguing that it looks good currently is myopic
[17:01] <kenvandine_wk> asac: humm... it's working for me...
[17:01] <dobey> "Oh, What should we call Word?" I know "MS Word Word Processor"
[17:01] <kenvandine_wk> asac: dent me
[17:01] <asac> kenvandine_wk: define "working" ;)
[17:01] <asac> kenvandine_wk: ok
[17:02] <rcmorano> word :>
[17:02] <juanje> dobey: Not, but people know what is Word, they don't say "Word Processor"...
[17:03] <rickspencer3> dobey: actually,  you can't call the game Tetris, but you can have the exact same game play and call it something similar, but not exactly "Tetris"
[17:03] <dobey> juanje: yes. and we're too afraid as a competing OS to suggest that users might quickly discover that "Foo" is the word processor to use
[17:03] <juanje> dobey: people know apps names, not just functionallities
[17:03] <calc> dobey: we don't have word :) and generally i think with the name generic name setup it would be done like "Word Processor (AbiWord)\n Word Processor (MS Word)\n Word Processor (OpenOffice.org Writer)"
[17:03] <rickspencer3> thus the large number of clones
[17:03] <juanje> unless we would like it
[17:03] <dobey> calc: we have AbiWord
[17:03] <calc> dobey: yes... i meant about how it would be displayed
[17:04] <rcmorano> calc: you just described guadalinex menu entries :]
[17:04] <dobey> a) GenericName should FOAD and not be in the desktop file at all
[17:04] <asac> meeting o'clock ?
[17:04] <asac> @now
[17:04] <asac> hmm
[17:04] <kenvandine_wk> asac: humm... perhaps not...
[17:04] <asac> @time
[17:04] <dobey> b) Generic Name should be programmatically determined from the Categories in the desktop
[17:04] <rcmorano> and we may say users feel _pretty_ confortable with that
[17:04] <asac> kenvandine_wk: i had the same issue with gajim
[17:04] <asac> kenvandine_wk: it shows up, but never indicates
[17:05] <rcmorano> dobey: from categories??
[17:05] <dobey> c) "menu items" should probably be "Name\n<small>$determined_generic_name</small>"
[17:05] <asac> kenvandine_wk: so now that more apps get this issue, it seems like a indicate bug (e.g. maybe it doesnt like the order we use?)
[17:05] <dobey> rcmorano: yes, that places where generic name is repeated anyway
[17:05] <seb128> asac: in half an hour?
[17:05] <calc> rcmorano: yea he did as well by saying "MS Word Word Processor"
[17:05] <dobey> GNOME;Internet;WebBrowser
[17:05] <kenvandine_wk> asac: yeah... that gajim bug showed up with libindicate 0.1.5
[17:05] <calc> rcmorano: and its actually already displayed in that manner if you enable the option in KDE (for 3.x anyway)
[17:05] <dobey> for example
[17:05] <kenvandine_wk> asac: my example python script still works...
[17:05]  * kenvandine_wk looks at the code
[17:06] <asac> kenvandine_wk: yeah. the example python code works. only difference i could see in gajim was the order of adding indication and caling "show
[17:06] <dobey> and yeah, for most use cases, a "menu" is the wrong solution
[17:06] <asac> "
[17:06] <rcmorano> i think $determined_generic_name wont mean the same for me and for you
[17:06] <calc> aren't categories still defined in the spec... so you can't easily generate a genericname out of a short list of categories
[17:06] <calc> er a userful genericname
[17:06] <rcmorano> ok, i got it, that would be ok
[17:06] <asac> kenvandine_wk: i didnt look further, because whole gajim trunk fell apart and i had other things to do.
[17:06] <kenvandine_wk> asac: oh... interesting
[17:06] <dobey> calc: apps should specify their categories properly
[17:06]  * kenvandine_wk tests 
[17:07] <rcmorano> since categories are already in some specs
[17:07] <rcmorano> i think
[17:07] <rcmorano> :>
[17:07] <dobey> calc: and if new categories need to be added, then they should be added
[17:07] <dobey> categories are specified in the menu spec, yes
[17:07] <calc> dobey: with sufficiently expanded list of categories that might work
[17:07] <rcmorano> anyway getting functionality from categories
[17:08] <rcmorano> would be problematic
[17:08] <rcmorano> since you don't know which one is the functionality from all of them
[17:08] <rcmorano> you just have a way to sort 'em in menus
[17:09] <juanje> in here: /usr/share/applications/totem.desktop:Categories=GTK;GNOME;AudioVideo;Player;Video;
[17:09] <juanje> which do you choose?
[17:09] <juanje> I mean, usually there are a few
[17:09] <kenvandine_wk> asac: can you dent me again?
[17:10] <asac> kenvandine_wk: ;)
[17:11] <asac> done
[17:11] <dobey> juanje: well, frankly, the spec is broken wrt audio/video player categories i think
[17:11] <calc> juanje: the list is documented so it should be doable programatically (i think)
[17:12] <dobey> juanje: so the solution would be to fix the spec, and then fix the totem.desktop :)
[17:12] <calc> juanje: also it is a hierarchy for the most part
[17:13] <kenvandine_wk> asac: very weird... i am seeing the replies in trunk... but not in the patched 0.8
[17:13] <rcmorano> for the most part hehe
[17:14] <asac> kenvandine_wk: add some printf's to see if the indication is actually added
[17:14] <asac> maybe some infrastructure code is missing and that code path isnt run or so
[17:14] <kenvandine_wk> gonna just drop to the debugger :)
[17:14] <kenvandine_wk> yeah
[17:14] <asac> kenvandine_wk: whats the best python debugger?
[17:14] <kenvandine_wk> epdb
[17:15] <kenvandine_wk> it is in gafton's ppa :)
[17:15] <juanje> dobey, calc: so that is a start :-)
[17:15] <juanje> :-P
[17:15] <dobey> i wonddr if gnome-main-menu is still maintained
[17:16] <juanje> I really don't dislike the idea of "GenericName - Name" or similar if everybody use as it's defined, but I it's necessary to fix the spec, let's do it
[17:16] <juanje> if it's broken....
[17:17] <juanje> it is just a spec
[17:17] <juanje> we can change it, can't we?
[17:17] <kenvandine_wk> asac: ... ok... again please?
[17:17] <kenvandine_wk> there should be a test service out there :)
[17:17] <kenvandine_wk> like ekiga's echo test
[17:18] <rcmorano> what's freedesktop for then :P
[17:19] <rcmorano> gtg
[17:19] <rcmorano> cya mates :]
[17:20] <juanje> ok, guys, thanks
[17:20] <juanje> bye
[17:21] <kenvandine_wk> asac: nm... i got a way to test
[17:21] <asac> kenvandine_wk: done. maybe its easier to delete cache of read dents or so and startup will then automatically reindicate stuff?
[17:21] <asac> ok cool.
[17:21] <asac> did you remove cache?
[17:22] <kenvandine_wk> no... just used a different account :)
[17:22] <asac> hehe ;)
[17:22] <kenvandine_wk> ok, figured it out... it is never getting into that code
[17:22] <kenvandine_wk> i must have missed a method
[17:23] <asac> that makes a bit of sense
[17:23] <kenvandine_wk> that doesn't explain gajim :)
[17:23] <asac> (compared to gajim
[17:23] <asac> lol
[17:24] <asac> let me start gajim ... maybe it works better today
[17:24] <rickspencer3> I thought getting Gwibber ready was "easy"
[17:24] <kenvandine_wk> it is :)
[17:24] <kenvandine_wk> testing is harder
[17:24] <asac> 15:58 < asac> kenvandine_wk: "easy" always feels risky ;)
[17:25] <asac> kenvandine_wk: whats your jabber id?
[17:25] <rickspencer3> desktop team meeting in 5 minutes
[17:26] <kenvandine_wk> asac: ken@vandine.org
[17:26] <asac> kenvandine_wk: ok added you
[17:30] <calc> hi
[17:30] <Nafallo> ehrm
[17:30] <rickspencer3> Team meeting?
[17:30] <ArneGoetje> hi
[17:30]  * asac waves
[17:30] <Nafallo> indication-applet just jumped from the left side of the screen to the right after a reboot...
[17:31] <rickspencer3> asac ArneGoetje bryce calc seb128
[17:31] <seb128> hello rickspencer3
[17:31] <asac> Nafallo: heh. its supposed to be right afaik ;)
[17:31] <rickspencer3> pitti is off celebrating the inevitable grinding away of his youth
[17:31] <rickspencer3> :)
[17:31] <seb128> ;-)
[17:31] <rickspencer3> kenvandine seems to be missing in action, something I said?
[17:31] <rickspencer3> tkamppeter: hi
[17:32] <tkamppeter> rickspencer3: hi
[17:32] <bryce> morning
[17:32] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-04-14
[17:32] <rickspencer3> let's roll
[17:32] <rickspencer3> actions from previous meeting - nothing to discuss I think, please read the wiki
[17:33] <rickspencer3> we'll figure out team meeting and cohesiveness issues via the email thread I suspect
[17:33] <rickspencer3> okay, so kenvandine_wk owns that action item
[17:33] <rickspencer3> j/k
[17:33] <kenvandine_wk> hehe
[17:33] <asac> :)
[17:33] <Nafallo> asac: doesn't mean it should move on me.
[17:33] <tkamppeter> bryce, some good news for you: I organized the OpenPrinting Summit in SF last week and my laptop worked perfectly with two projectors!
[17:33] <kenvandine_wk> i enabled jabber just in time to crash pidgin for the meeting
[17:33] <bryce> tkamppeter: good to hear :-)
[17:33] <asac> :)
[17:34] <rickspencer3> okay, moving on ...
[17:34] <rickspencer3> -intel
[17:34] <bryce> shoot me now
[17:34] <calc> is there a intel gnome screensaver related issue?
[17:34] <rickspencer3> bryce, you mentioned greedy, but I thought a general discussion might be in order
[17:34]  * calc waits until after rickspencer3 is done with his issues :)
[17:34] <rickspencer3> bryce: what's the status and what can we do to help ?
[17:35] <bryce> there are two major issues
[17:35] <bryce> first is a freeze that I think I've narrowed to the mesa 7.3 -> 7.4 upgrade
[17:35] <bryce> which occurred April 3rd, and seems to correlate to when people (i965 users only) started seeing it
[17:36]  * rickspencer3 nods
[17:36] <bryce> unfortunately the freeze occurs only after several hours (24 hrs in some cases) use
[17:36] <asac> would reverting to 7.3 be an option?
[17:36] <bryce> so we could use help at this time from people with i965 to reproduce the freeze and verify reverting solves it
[17:36] <bryce> asac: yes
[17:36] <asac> bryce: what is 7.4 vs. 7.4? how many commits are there?
[17:37] <rickspencer3> bryce: are there instructions for revering somewhere?
[17:37] <asac> 7.3 vs. ..
[17:37] <seb128> in which conditions does it freeze?
[17:37] <bryce> asac: more likely, I think we'd revert all the -intel changes, since mesa 7.4 also carries unrelated fixes we don't have trouble with
[17:37] <bryce> asac, a lot, but for -intel it's mostly DRI2 stuff that we don't use by default yet
[17:37] <asac> hmm
[17:37] <asac> ok
[17:37] <bryce> seb128: it is not tied to particular steps to reproduce
[17:38] <bryce> people use the word "randomly" to describe it, but I hate that word for describing bugs ;-)
[17:38] <rickspencer3> bryce: does anyone hit the freeze if they've turned off desktop effects? in other words, does turning off desktop effects avoid the problem
[17:38] <rickspencer3> ?
[17:38] <bryce> compiz either triggers it or makes it much more likely to be triggered
[17:39] <asac> bryce: whats the bug number?
[17:39] <rickspencer3> can we revert to 7.3 in an SRU?
[17:39] <seb128> well if you don't use compiz you don't use 3d a lot usually
[17:39] <bryce> bug 359392
[17:39] <seb128> bug #359392
[17:40] <bryce> I'm embarrassed to admit it, but I've never reverted a package to an older version before, so don't actually know the procedure
[17:40] <bryce> I mean, not in the archive
[17:40] <seb128> it's easy, bump the version
[17:40] <rickspencer3> good
[17:40] <calc> bryce: well assuming no library changes requiring everything above it be recompiled then you just have to bump the version fooreallybar
[17:40] <seb128> 7.4.is.7.3
[17:41] <bryce> rickspencer3: for a user to revert to 7.3, you just need to locate the corresponding 7.3 deb on an archive.  there's also links from the bug
[17:41] <bryce> seb128: ok
[17:41] <rickspencer3> bryce: ack on the instructions
[17:41] <rickspencer3> so reverting in an SRU sounds like a possibility
[17:41] <bryce> so that's the freeze issue
[17:41] <asac> bryce: so plan is backout intel changes from mesa and getting testing on PPA?
[17:41] <bryce> the other issue is  a performance regression
[17:42] <seb128> for what is worth I'm running a igm965 and didn't run into the bug
[17:42] <superm1> can we not just back out all the way to 7.3 instead of just the intel changes?
[17:42] <bryce> superm1: for the freeze issue, I think backing out the intel changes would be sufficient
[17:42] <bryce> however there is another bug superm1 is concerned about which appears to be in some of the other mesa changes
[17:42] <seb128> I doubt  slangasek will accept downgrading mesa before jaunty now
[17:42] <rickspencer3> agreed
[17:43] <rickspencer3> I think anything we do now is SRU
[17:43] <rickspencer3> (if that's what you meant seb128)
[17:43] <seb128> SRU means we have some time to isolate the buggy commit or fix the bug
[17:43] <rickspencer3> right
[17:43] <rickspencer3> reverting is an option, but we might still find a better solution
[17:43] <rickspencer3> bryce: do you want to talk about the other issue?
[17:43] <bryce> I'm waiting on tjaalton for a plan of attack... I'd like to be able to isolate the patch that causes the breakage, and just revert that, if possible
[17:44] <bryce> rickspencer3: yes
[17:44] <seb128> I don't think we should start by considering downgrading mesa to 7.3 before spending some extra time on the issue
[17:44] <bryce> the other issue is a performance regression issue on -intel
[17:44] <bryce> a lot of people are complaining a lot about this
[17:44] <seb128> all cards?
[17:44] <bryce> seems a random assortment, mostly seen with compiz enabled
[17:44] <asac> bug id?
[17:45] <bryce> bugs 252094, 359600, 349992
[17:45] <rickspencer3> bryce: I'm guessing from the Kubuntu bug, that it's more *noticeable* with compiz, but shows up in other areas as well
[17:45] <bryce> one recent suggestion on 359600 is to re-enable the "greedy" migration heuristic (remember that?)
[17:45] <asac> when did we disable it?
[17:46] <bryce> several people report it solves the problem on EXA just fine
[17:46] <seb128> (no?)
[17:46] <bryce> asac: intrepid (2.4.1 -intel)
[17:46] <bryce> it was disabled principally due to a crash bug it caused
[17:46] <asac> bryce: the rational was bugginess?
[17:46] <bryce> and secondarily because (at the time) it was no longer needed
[17:47] <asac> ok
[17:47] <bryce> in recent testing, the _patch_ still causes the crash
[17:47] <bryce> however if people set the option manually in xorg.conf it works
[17:47] <asac> how bad is the performance issue? could we do that as a well tested SRU too?
[17:47] <rickspencer3> asac: it's very bad
[17:47] <bryce> so not sure what's wrong there; presumably something with the order stuff is done in the patch
[17:48] <asac> hmm
[17:48] <bryce> anyway
[17:48] <asac> bryce: whats that patch about? just flipping the default for the existing greedy option?
[17:48] <bryce> slangasek reported just this morning that even with the manual settings, it breaks firefox badly
[17:49] <bryce> (black firefox window where page should be)
[17:49] <rickspencer3> hmm
[17:49] <rickspencer3> didn't for me
[17:49] <rickspencer3> I think I would have noticed that ;)
[17:49] <bryce> asac: correct, it's pretty minimal
[17:49] <rickspencer3> still, no easy answer there
[17:49] <asac> black windows in ffox sounds like a blocker
[17:49] <bryce> so my question is, should I still pursue this greedy approach?  (It's a complete hack)
[17:50] <bryce> or should I focus efforts on the freeze + other solutions to perf
[17:50] <asac> i think we can definitly call for testing if you have it in a ppa
[17:50] <seb128> I'm not sure what greedy is
[17:50] <seb128> but that seems to much of a change at this stage
[17:50] <rickspencer3> asac: he already did, and got back segfault reports
[17:50] <seb128> too
[17:50] <asac> but for now i feel like we should take extra care given that slangasek reported black windows in ffox
[17:50] <rickspencer3> (regerssion)
[17:50] <bryce> seb128: it prevents pixmaps from being migrated to the back buffer, thus preventing various acceleration algorithms from running
[17:50] <rickspencer3> seb128: I think we all understand that we are talking SRUs now, right?
[17:50] <bryce> seb128: in cases where those algorithms are busted, preventing them from running actually makes performance better
[17:51] <seb128> rickspencer3: right
[17:51] <bryce> but can cause various other problems
[17:51] <seb128> rickspencer3: but even for sru, rendering issue and crashes doesn't sound good
[17:51] <rickspencer3> seb128: agreed
[17:51] <asac> good so lets put that high on the SRU list and move on
[17:51] <asac> SRU list == investigate whats going on and come up with a real fix
[17:51] <rickspencer3> asac: agreed
[17:51] <seb128> +1
[17:51] <bryce> alrighty
[17:52] <rickspencer3> I think bryce was asking if people had thoughts about what to continue to investigate?
[17:52] <rickspencer3> the greedy hack sounds like a bit of a rat hole to me
[17:52] <asac> finding the regression window/package
[17:52] <seb128> I don't know enough about xorg and intel to have an advice there
[17:52] <seb128> I would spend efforts on the mesa issue first
[17:52] <rickspencer3> For my part, I talked to Yingying last night, and will be talking to Ken Edwards later today to see if we can get more focus from Intel engineers to help debug these issues for Jaunty SRUs
[17:52] <seb128> we can probably isolate the buggy change with some work on this one
[17:53] <bryce> rickspencer3: sounds like I should just proceed with what I've been doing, and not try to cram something in for the release.  Which I'm glad for - shoving something in at this point I worry could risk causing more problems than it solves
[17:53] <asac> right find the regression window/source ... before we know that we cannot do much about it imo
[17:53] <rickspencer3> I would like to see them be a bit more hands on helping us with these, but there minds are elsewhere as they are in ship mode with something right now
[17:53] <bryce> I've documented the greedy workaround in the release notes for now (could use some wordsmithing though)
[17:53] <rickspencer3> yes
[17:53] <rickspencer3> I think lost of release notes, and ideally the SRU will be ready ...
[17:53] <seb128> right, a note about it and work for sru updates later sounds good
[17:53] <rickspencer3> at or soon after Jaunty is available
[17:54] <rickspencer3> bryce: thanks for your tireless efforts here
[17:54] <bryce> yep
[17:54] <rickspencer3> moving on ...
[17:54] <rickspencer3> Gwibber
[17:54] <rickspencer3> saw you guys discussing this morning
[17:54] <rickspencer3> is this really SRU worthy? Is this the most important thing to be working on right now?
[17:55] <rickspencer3> heh
[17:55] <seb128> gwibber is in universe I'm not sure to understand why we spend so much efforts on it
[17:55] <asac> its a pet project
[17:55] <rickspencer3> seb128: I think that Mark would like it to have good indicator-applet integration
[17:55] <kenvandine_wk> i have it fixed now
[17:56] <rickspencer3> lol
[17:56] <kenvandine_wk> seb128: we want as many proof points as possible for the indicator stuff
[17:56] <asac> i think if kenvandine_wk has it fixed it can go in (he did minimal backports of indicate api)
[17:56] <rickspencer3> how many times have I heard that in my life
[17:56] <seb128> ok
[17:56] <rickspencer3> :)
[17:56] <asac> i still want to check/verify it though
[17:56] <kenvandine_wk> asac: i will push my branch in a few
[17:56] <asac> great
[17:56] <rickspencer3> thanks guys, but remember to keep your eye on the big picture
[17:56] <kenvandine_wk> twitter shut me down for testing :)
[17:57] <rickspencer3> Translations
[17:57] <asac> kenvandine_wk: really?
[17:57] <kenvandine_wk> refreshed to many times
[17:57] <rickspencer3> ArneGoetje: where are we at?
[17:57] <ArneGoetje> final full export from Rosetta for the language-packs is currently running
[17:57] <ArneGoetje> expect it to be done sometime tomorrow.
[17:57] <kenvandine_wk> no string changes for gwibber
[17:58] <rickspencer3> (it's all about Gwibber)
[17:58] <rickspencer3> jono: are you back?
[17:58] <seb128> gwibber is in universe so no language pack anyway
[17:59] <rickspencer3> ok, I think jono is on a call, but I was hoping he could tell us a little about the new role on his team for translations
[17:59] <rickspencer3> perhaps when he gets off
[17:59] <jono> rickspencer3, hey
[17:59] <jono> I am here
[17:59] <jono> in-between calls :-)
[17:59] <rickspencer3> kewl
[18:00] <jono> hi everyone
[18:00] <ArneGoetje> hi jono
[18:00] <jono> so David Planella started on my team on Monday
[18:00] <jono> hey ArneGoetje :-)
[18:00] <jono> David's role is primary divided into a few areas:
[18:00] <jono>  * to help grow and extend our extensive translations community
[18:01] <jono>  * to work with translations teams to help build best practice around great translations
[18:01] <kenvandine_wk> jono: what is David's irc nick?
[18:01] <jono>  * to work with upstreams to ensure we can participate as effectively as possible with translations
[18:02] <jono> kenvandine_wk, dpm
[18:02] <kenvandine_wk> thx
[18:02] <jono>  * to provide a resource inside Canonical to report to other teams the status of translations
[18:02] <rickspencer3> dpm: we;re talking about you
[18:03] <seb128> who will be in charge of looking at translation template import, doing moderation for those, etc?
[18:03] <rickspencer3> seb128: still ArneGoetje for the time being, but we haven't finalized that yet
[18:03] <jono> seb128, rickspencer3 and I are still discussing this
[18:03] <seb128> ok
[18:03] <rickspencer3> seb128: are you volunteering?
[18:03] <rickspencer3> j/k
[18:04] <seb128> ;-)
[18:04] <ArneGoetje> seb128: I think this will stay with me for a while, but I'd like to shift this off to some trusted community members if possible.
[18:04] <jono> it should be stressed that dpm is very much here in a similar vain to the other horsemen - to build buzz, best practise and growth in community
[18:04] <seb128> no, but I want to know where I can complain when they are stucked ;-)
[18:04] <jono> not really here to do direct engineering
[18:04] <seb128> (that happens every cycle since we use rosetta)
[18:04] <jono> seb128, hehe
[18:04] <jono> seb128, I think David should be helping to grow community participation there
[18:04] <rickspencer3> ArneGoetje: right, and hopefully dpm will be helping to speed up that transition
[18:05] <ArneGoetje> rickspencer3: +1
[18:05] <rickspencer3> seb128: I think figuring out how to avoid those bottlenecks is part of dpm's charter
[18:05] <jono> I have to run off to a call now
[18:05] <jono> anything else before I go?
[18:05] <jono> rickspencer3, indeed
[18:06] <rickspencer3> don't think so
[18:06] <rickspencer3> except that I would encourage dpm to join the discussin in this channel
[18:06] <jono> yeah, I have asked him to be part of these major channels
[18:06] <jono> rickspencer3, I think he should be at your team meetings too
[18:07] <rickspencer3> k
[18:07] <jono> rickspencer3, I will ask him to
[18:07] <rickspencer3> thanks jono
[18:07] <jono> thanks rickspencer3
[18:07] <jono> bye folks!
[18:07] <rickspencer3> moving on ...
[18:07] <seb128> bye jono
[18:07] <rickspencer3> UDS Topics
[18:08] <rickspencer3> we need to have a list of UDS topics by eow next week, I think
[18:08] <rickspencer3> I got a start here:
[18:08] <rickspencer3> https://wiki.ubuntu.com/UDSKarmic/Prep/Desktop
[18:08] <rickspencer3> please just add them there, I suppose
[18:08] <rickspencer3> we can discuss more during the week
[18:08] <seb128> rickspencer3: do you have a pool of ideas or similar already?
[18:09] <seb128> or is that the list already on this wikipage?
[18:09] <rickspencer3> there's a bunch of stuff on the page
[18:09] <rickspencer3> but it's not done with team or community participation yet, just me putting things there as they came across my desk
[18:10] <seb128> right, they seem rather categories than specific topics
[18:10] <rickspencer3> seb128: I'm especially interested in GNOME 3.0
[18:10] <rickspencer3> could be
[18:10] <rickspencer3> it's not fleshed out at all, it was just a place to park things so I didn't forget
[18:11] <rickspencer3> how do you all want to handle getting your topics ready?
[18:11] <rickspencer3> I think we just need a list of topics, not blueprints, etc...
[18:12] <seb128> I agree than having topic is better than blueprint, we can use blueprint later to track specific karmic work
[18:12] <rickspencer3> ok
[18:12] <asac> i think that depends on personal preference; adding your topics to that wiki pages makes sense to get started
[18:12] <seb128> let's collect ideas and discuss those during the next meeting?
[18:12] <rickspencer3> okay
[18:12] <rickspencer3> ACTION: everyone put UDS topics on the wiki
[18:12] <asac> rickspencer3: how did you get the headings you already added?
[18:13] <rickspencer3> everytime someone said "we should discuss foo at UDS" I put off on the list
[18:13] <asac> rickspencer3: where is the "font" topic ;)?
[18:13] <rickspencer3> s/oof/foo
[18:13] <rickspencer3> okay, everytime I remembered to do it :)
[18:13] <asac> hehe. okay
[18:13] <calc> asac: its there in a really tiny font ;-)
[18:14] <asac> lol
[18:14] <ArneGoetje> asac: which font topic?
[18:14] <seb128> asac: I'm not sure there is much to discuss there, just make it work? ;-)
[18:14] <asac> seb128: you won't lead the discussion ;)
[18:14] <rickspencer3> I would propose that people have a bias for inclusion ... I think it will be easier to remove items than to add them
[18:14] <seb128> good ;-)
[18:14] <asac> seb128: i think there are various things to discuss
[18:15] <rickspencer3> seb128: you'll be leading the GNOME 3.0 topic(s) I hope
[18:15] <seb128> yes
[18:15] <rickspencer3> so you'll probably have enough to worry about :)
[18:15] <rickspencer3> move on?
[18:15] <asac> ArneGoetje: a few font topics I found as lacking something; you can add your own or we can also have a call ;)
[18:15] <rickspencer3> Release Bugs/Release Status
[18:15] <seb128> what about topic which should be worked but are probably candidate for the design team work?
[18:15] <ArneGoetje> asac: ok
[18:16] <rickspencer3> seb128: put them on the list
[18:16] <seb128> alright
[18:16] <rickspencer3> design will need a lot of help from us, as they seem not to be too sure what UDS is, and what it's for
[18:16] <rickspencer3> Riddell: bug #355814
[18:16] <asac> rickspencer3: will design team share track with us again?
[18:16] <asac> or will they have their own?
[18:16] <rickspencer3> asac: yes, but we have two rooms this time
[18:17] <asac> ok great. i found it was quite a tight schedule last time already
[18:17] <rickspencer3> so basically, I will be track lead for desktop/dx/design
[18:17] <asac> and now there are probably even more topics
[18:17] <rickspencer3> seb128: bug #338982
[18:17] <rickspencer3> (skipping x bugs as we already discussed)
[18:18] <seb128> rickspencer3: that's an universe package, should it be set as blocker still?
[18:18] <rickspencer3> seb128: I don't think so
[18:18] <ArneGoetje> rickspencer3: that bug should have been fixed for some time now. There was a lot of template reshuffling going on regarding KDE translations during the past weeks.
[18:18] <seb128> having mapi working would be nice for exchange users but I've neither a clue about exchange not access to a server
[18:18] <seb128> not->nor
[18:18] <rickspencer3> ArneGoetje: could you please confirm with Riddell
[18:18] <ArneGoetje> rickspencer3: will do
[18:19] <rickspencer3> seb128: do you have time to check in and see if it's fixed, will be fixed, if we should be doing something?
[18:19] <seb128> rickspencer3: I will discuss options with the server team and slangasek, I think fixing that would require an openchange update
[18:19] <rickspencer3> meantime, not sure why it's a relaase blcoker if it's a universe package
[18:19] <rickspencer3> seb128: thanks
[18:20] <rickspencer3> some of our users depend on that, but as a user I always found it not to work too well
[18:20] <seb128> well, evolution-exchange is the one used by default
[18:20] <rickspencer3> oh
[18:20] <seb128> evolution-mapi is the new connector using openchange and supposed to work on exchange 2007
[18:20] <rickspencer3> I see
[18:21] <seb128> so it's nothing which was working and got broken, it's new code
[18:21] <seb128> but I will see if we can get it working, at least in a sru
[18:21] <rickspencer3> seb128: thanks
[18:21] <rickspencer3> asac: I see the "homepage is always in English" bug is off the list
[18:22] <rickspencer3> sweet
[18:22] <asac> rickspencer3: i fixed all i had
[18:22] <rickspencer3> bug #353924
[18:22] <rickspencer3> love to see the word "Fix" in the status :)
[18:22] <asac> yeah i have to close the upstrewm task
[18:22] <asac> its fix released
[18:22] <rickspencer3> thanks asac, you finished out Jaunty very strong
[18:23] <rickspencer3> everybody sent or posted their activity reports, so thanks
[18:23] <rickspencer3> note that calc is starting his rotation on OEM services on May 1!
[18:23] <rickspencer3> any other business?
[18:24] <seb128> no
[18:24] <rickspencer3> great
[18:24] <kenvandine_wk> :)
[18:24] <rickspencer3> bryce: remember that ati and nvidia are working great ...
[18:24] <rickspencer3> and intel users aren't exactly dropped to a CL :)
[18:24] <seb128> and intel is working great for some of us too ;-)
[18:24] <seb128> <- happy intel user since the user switching bug has been fixed
[18:25] <rickspencer3> so I think all in all we are in good shape for Jaunty
[18:25] <jcastro> I have 2 intel laptops sitting on my desk if you want me to test anything bryce
[18:25] <rickspencer3> I have i965, and it works well for me
[18:25] <rickspencer3> compiz is slow, but that's such not  a deal breaker (plus it goes fast when I enable greedy)
[18:25]  * calc has 945 and 4500
[18:25] <bryce> rickspencer3: :-)
[18:26] <seb128> rickspencer3: slow when doing what?
[18:26] <rickspencer3> seb128: cover flow is the most noticible
[18:26] <seb128> I'm only using alt-tab and workspace switching but that's fast here
[18:26] <bryce> rickspencer3: I'm chatting with kernel team at their meeting regarding sorting out freeze bugs
[18:26] <rickspencer3> okay
[18:26] <dpm> rickspencer3: I've just read jono's explanation on my new role earlier on. I basically wanted to say that I'm around, but I haven't got anything to add at this point -other that I'm looking forward to work with you guys and to ask if you've got any questions
[18:26]  * kenvandine_wk should try user switching again... but has been scared
[18:26] <rickspencer3> bye bryce!
[18:26] <bryce> kenvandine_wk: think it should be fixed now
[18:26] <kenvandine_wk> dpm: great to meet you!
[18:26] <seb128> bryce: can people still ssh the box when they get the freeze?
[18:26] <bryce> kenvandine_wk: save your work and try it :-)
[18:26] <ember> seb128 mind if i take the brasero update?
[18:26] <rickspencer3> dpm: welcome!
[18:26] <kenvandine_wk> bryce: i love the confidence
[18:27] <rickspencer3> meeting adjourned?
[18:27] <bryce> cya
[18:27] <seb128> ember: jaunty is frozen so it will probably not be accepted but you can do it
[18:27] <seb128> rickspencer3: yes
[18:27] <ember> -proposed then?
[18:27] <dpm> kenvandine_wk: rickspencer3: thanks!
[18:27] <rickspencer3> thanks all
[18:27] <ArneGoetje> thanks
[18:27] <seb128> ember: correct
[18:27] <seb128> rickspencer3: thanks
[18:28] <asac> thx
[18:28] <kenvandine_wk> oh.. bryce it worked!
[18:28] <bryce> :-)
[18:28] <kenvandine_wk> bryce: do have that bug number handy? i want to see what the fix was :)
[18:28] <seb128> brb
[18:28] <bryce> I don't remember the bug number offhand, but the fix was reverting a patch... uh
[18:29] <DBO> is here a good place to mention a couple odd things in the default compiz config?
[18:29] <kenvandine_wk> bryce: an intel patch or kernel?
[18:29] <bryce> https://bugs.edge.launchpad.net/ubuntu/+bug/348428
[18:29] <bryce> that's it
[18:30] <DBO> hi bryce =)  you are everywhere
[18:30] <kenvandine_wk> great
[18:30] <kenvandine_wk> thx
[18:30] <bryce> heya DBO
[18:31] <bryce> DBO, uh lost track of your questions, one sec
[18:31] <DBO> so I wanted to report that there are some CPU wasters in the default compiz config
[18:31] <bryce> uh "CPU wasters"?
[18:31] <DBO> namely the fading windows plugin does the same thing as the animations plugin, so its doubling up the fade code, adds a bit of cpu there
 bryce, I dont know if you remember talking to me or not, but I though I would mention I fixed my render performance issue simply by dropping the up_threshold on the OnDemand governor to 35 from its default
 my battery life shortened by about 10 minutes overall, but the usability difference is huge
[18:32] <DBO> oh that was something else
[18:32] <bryce> oh
[18:32] <DBO> I followed up in ubuntu-x about that
[18:32] <bryce> ok
[18:32] <DBO> i wasn't trying to cross channel stalk you =P
[18:32] <bryce> heh
[18:33] <DBO> i just came here to say that there are redundant plugins enabled in compiz, and they are causing us to waste CPU resources when we do window fades
[18:33] <djsiegel> hey DBO!
[18:33] <DBO> david! you stalker!
[18:33] <bryce> DBO, have you talked with the compiz maintainers about that?
[18:33] <djsiegel> hehe
[18:34] <DBO> bryce, well I used to be a maintainer of beryl... so I have a clue what I am talking about... but basically its a silly default and they never went over their defaults very well
[18:35] <seb128> DBO: usually "maintainer" there is "package maintainer", ie mvo in this case ;-)
[18:35] <bryce> DBO, yeah
[18:35] <DBO> oh the package maintainer
[18:35] <DBO> sorry, my bad :)
[18:35] <seb128> mvo is on holidays today but he will be there tomorrow
[18:35] <bryce> DBO, I'm happy to help if you have a specific change, although I'm fairly swamped up to my eyeballs in X.org package maintenance stuff at the moment
[18:35] <seb128> or if you have a bug reference let us the number I'll let him know
[18:36] <DBO> i'll file a bug since he is not here
[18:36] <bryce> DBO, also it is pretty late for changes to jaunty
[18:36] <seb128> ok thanks
[18:36] <seb128> late for jaunty but still good to know and possible to sru
[19:55] <asac> kenvandine_wk: +    self.add_msg_tab(self.client.responses, _("Replies"), show_icon = "mail-reply-all", add_indicator=True)
[19:55] <asac> is it right that that is unconditionally True?
[19:55] <asac> (havent looked in code context)
[19:55] <kenvandine_wk> yeah
[19:55] <kenvandine_wk> i think so
[19:56] <asac> kenvandine_wk: so that code is only run if indicate != None?
[19:56] <kenvandine_wk> even if add_indicator is True, it won't try to display the indicator of indicate isn't set
[19:56] <asac> ok
[19:56] <kenvandine_wk> i think it is run... just doesn't matter
[19:56] <asac> kenvandine_wk: ok, so that is the code path for "replies" ?
[19:57]  * kenvandine_wk looks
[19:58] <asac> kenvandine_wk: also is the "xid == topwindow" thing what we want? did you cherry pick that from trunk?
[19:59] <kenvandine_wk> i did
[19:59] <kenvandine_wk> checking to see if it is focused
[20:00] <asac> kenvandine_wk: ok. you didnt note where you cherry picked that from
[20:00] <asac> as with anything.
[20:00] <kenvandine_wk> :)
[20:00] <kenvandine_wk> i can go back and do that... it was just a pita
[20:01] <asac> no its fine. just to make it perfect ;)
[20:01] <asac> kenvandine_wk: you can still add the commit references to the patch doc
[20:01] <asac> ;)
[20:01] <asac> unless looking the comit up is the pita
[20:03] <asac> kenvandine_wk: seems the addition was
[20:03] <asac> 291.1.1
[20:03] <asac> kenvandine_wk: think you forgot this hunk then: http://paste.ubuntu.com/150996/
[20:09] <kenvandine_wk> asac: the is_gwibber_active was revno 294
[20:10] <asac> kenvandine_wk: err. here it was 291.1.1 ... whats the branch you are looking at?
[20:10] <kenvandine_wk> trunk
[20:10] <asac> kenvandine_wk: he. ok 294 is the merge ...t hecommit is 291.1.1
[20:10] <kenvandine_wk> oh... ok
[20:10] <kenvandine_wk> how did you see that?
[20:10] <asac> kenvandine_wk: anyway. the hunk above was forgotten
[20:10] <asac> kenvandine_wk: bzr log | less ;)
[20:10] <asac> bzr blame actually
[20:10] <kenvandine_wk> ah
[20:11] <kenvandine_wk> i think i might have changed that manually
[20:11] <kenvandine_wk> one sec
[20:12] <kenvandine_wk> ok...no i missed that
[20:12] <kenvandine_wk> what revision was that from?
[20:13] <asac> kenvandine_wk: bzr diff -c 291.1.1
[20:17] <kenvandine_wk> ok, fixed... not pushed yet though
[20:27] <kenvandine_wk> asac: so in my notes for the patch, should i reference 294 or 291.1.1?
[20:27] <asac> kenvandine_wk: well, best practices would be to have one patch for each revision you backported ;)
[20:28] <asac> kenvandine_wk: but yes, use 291.1.1
[20:28] <asac> kenvandine_wk: but also name the branch name you refer to (its not valid across branches)
[20:28] <kenvandine_wk> i hate patches that patch stuff from other patches...
[20:28] <asac> kenvandine_wk: if you want to see the global ids you can use bzr log --show-ids
[20:28] <kenvandine_wk> ok
[20:28] <asac> personally i use cherry-pick revno XXX from lp:~....
[20:29] <asac> kenvandine_wk: yeah well. but stacking cherry picks would be much easier to review and track for future
[20:29] <asac> e.g. find regressions and so on
[20:29] <kenvandine_wk> ok
[20:29] <kenvandine_wk> i'll remember that
[20:29] <asac> in this way there is a single lumped patch and nobody knows how that was produced ;)
[20:29] <asac> (except kenvandine_wk's black-magic ;))
[20:30] <asac> anyway. i think with that hunk it should be ok
[20:30] <asac> i found a different issue though
[20:30] <asac> but thats also on trunk
[20:30] <asac> its probably a theoretical issue, but wrong imo:
[20:31] <asac> so first a message runs this:
[20:31] <asac>       if hasattr(message, "gId"):
[20:31] <asac>         message.is_duplicate = message.gId in seen
[20:31] <asac>         message.first_seen = False
[20:31] <asac> then in the indicator code it runs:
[20:31] <asac>        if msg.first_seen and \
[20:31] <asac>             hasattr(msg, "is_unread") and msg.is_unread and \
[20:31] <asac>             hasattr(msg, "gId") and msg.gId not in self.indicator_items:
[20:31] <asac> i think logcally it needs hasattr(msg.first_seen) and ...
[20:31] <asac> or the first_seen needs to be moved after the "hasattr(msg, "gId")"
[20:32] <kenvandine_wk> looks like a bug
[20:32] <kenvandine_wk> but should be harmless
[20:32] <asac> heh
[20:32] <asac> yeah throws an uncatched exception
[20:32] <asac> ;)
[20:32] <kenvandine_wk> does it?
[20:32] <kenvandine_wk> it could yes... but i haven't seen it do it
[20:32] <asac> if you access msg.first_seen without it being defined it throws, right?
[20:32] <kenvandine_wk> yes
[20:33] <asac> so given that first_seen only gets defined if hasattr(message, "gId"): the second msg.first_seen can throw
[20:34] <asac> would only happen if !hasattr(msg, "gId") ... i looked and that seems to be an unlikely event
[20:34] <kenvandine_wk> right, it's a bug
[20:35] <asac> think we should check if undefined gId is really unlikely
[20:35] <kenvandine_wk> always better to check
[20:38] <huats> hey everyone
[20:38] <asac> kenvandine_wk: ok suggesting a merge on trunk anyway
[20:40] <seb128> lut huats
[20:40] <seb128> huats: how are you?
[20:41] <huats> seb128: hey
[20:41] <huats> I am fine!
[20:41] <huats> thanks !
[20:41] <seb128> still as busy?
[20:41] <huats> I tend to survive :)
[20:41] <huats> and I think am I getting to the end of the "busy" process
[20:41] <huats> so it is great
[20:41] <huats> :)
[20:42] <seb128> cool
[20:42] <seb128> jaunty is frozen so no need to worry about this one
[20:42] <huats> the good sign is that I am setting up my new computer to build deb :)
[20:42] <huats> ok
[20:42] <didrocks> seb128: huats told me yesterday that he was enjoying the sunshine on the beach :)
[20:42] <huats> LOL
[20:42] <seb128> I don't doubt of that
[20:43] <didrocks> ^^
[20:43] <seb128> we didn't get the gcalctool stable update in jaunty due to that
[20:43] <huats> I know toulouse is sunny BUT there is no beach
[20:43] <huats> seb128: hum I though that robert would do it ...
[20:43] <seb128> he's on holidays this week
[20:43] <didrocks> seb128: I could have done it, you know…
[20:43] <huats> ok
[20:44] <huats> seb128: I will prepare it if you want
[20:44] <huats> so that we can upload it as soon as the freeze is over
[20:44] <didrocks> (you have 4 packages ready to sponsor, btw)
[20:44] <seb128> didrocks: it was not especially needed so I let a chance to huats to grab it if he wanted to do an update
[20:44] <huats> seb128: sure
[20:44] <seb128> huats: there is no freeze over now
[20:44] <kenvandine_wk> asac: ok, i pushed changes
[20:44] <seb128> huats: ie it's a sru or nothing
[20:44] <huats> seb128: ok
[20:45] <huats> seb128: so I'll do the sru process...
[20:45] <seb128> didrocks: right, we are frozen so I need to discuss if those are to upload or to convert in sru uploads
[20:45] <didrocks> seb128: oki
[20:45] <seb128> huats: no hurry, we will not have srus accepted before a week I guess
[20:45] <huats> seb128: I'll do it by the week then
[20:46] <seb128> thanks
[20:46] <seb128> looking forward uds? ;-)
[20:46] <huats> no pb :)
[20:46] <huats> you have no idea how muh :)
[20:46] <didrocks> uds \o/
[20:47] <didrocks> seb128: we have to discuss at uds about the "package locking" for desktop packages
[20:47] <huats> and I just started to loe football... I would love to see barcelona with their team in the champions league final which is DURING the UDS :)
[20:47] <huats> s/loe/love/
[20:48] <seb128> didrocks: right, or maybe before UDS, for sure we want to have a nice summary and an easy way to assign updates next cycle
[20:48] <seb128> shouldn't be too hard to do
[20:48] <didrocks> seb128: you know now why huats can't work on ubuntu, he's watching football :)
[20:48] <huats> didrocks: nope
[20:48] <seb128> oh, football!
[20:48]  * seb128 runs the TV on
[20:48] <didrocks> seb128: yes, we just have to agree on the process :)
[20:48]  * seb128 turns the TV on
[20:48] <didrocks> hehe
[20:48] <huats> ;)
[20:50] <huats> seb128: I have been experiencing weird stuffs with my computer (fresh jaunty beta install) : a LOT of ext4corrputed FS...
[20:50] <huats> have you heard something like that ?
[20:50] <huats> (since the last update seems to be fixed)
[20:50] <seb128> no, but I stay away from new filesystem usually
[20:50] <huats> (and it is not an issue with the HD since I changed it)
[20:50] <huats> ok
[21:55] <Nafallo> asac, kenvandine_wk: any luck with gajim today?
[21:55] <Nafallo> asac, kenvandine_wk: I saw you guys working on it, but I didn't have time to join in the conversation unfortunally.
[21:55] <kenvandine_wk> Nafallo: haven't gotten to it yet
[21:55] <kenvandine_wk> it was gwibber actually
[21:55] <kenvandine_wk> but i plan to tonight
[21:56] <Nafallo> oh. I got lost of hilights on gajim ;-)
[21:56] <kenvandine_wk> :)
[21:59] <jcastro> hey Nafallo
[21:59] <jcastro> I think you should take the pidgin artwork and put it into gajim for us so it looks better
[22:00] <Nafallo> jcastro: hmm. sounds like karmic. file a wishlist bug please? :-)
[22:00] <jcastro> oh, yes, karmic for sure.
[22:06] <rickspencer3> kenvandine_wk: are you *still* working on Gwibber?
[22:06] <rickspencer3> maybe we should change "Jaunty Jackalope" to "Jaunty Gwibber"
[22:07] <rickspencer3> :)
[22:07] <kenvandine_wk> hehee
[22:07] <kenvandine_wk> no... been done with gwibber for hours now :)
[22:07] <kenvandine_wk> i am trying to figure out which compiz patch is causing that keybindings bug
[22:08] <kenvandine_wk> upstream says it is one of our patches
[22:08] <kenvandine_wk> jcastro: we should do the same for empathy!
[22:08] <kenvandine_wk> i hate those status icons in empathy
[22:15] <kenvandine_wk> so far these patches look need to just keep compiz from crashing
[22:16] <kenvandine_wk> s/need/needed
[22:28] <rickspencer3> kenvandine_wk: thanks for taking the compiz bug