[06:55] <pitti> Good morning
[06:55] <pitti> dobey: hello
[07:27] <baptistemm> hi pitti
[07:28] <pitti> bonjour baptistemm! comment vas-tu?
[07:28] <baptistemm> I'm fine
[07:29] <baptistemm> you work early
[07:30] <baptistemm> perhaps I could ask you a question about a bluez problem that might be related to dbus
[07:31] <pitti> baptistemm: I'm not very bluez literate, but I'll try :)
[07:33] <baptistemm> about bug 533730, I don't understand why the reporter has the error "Method "RegisterAgent" with signature "os" on interface "org.bluez.Adapter" doesn't exist" this method should exist on the default adapter
[07:38] <pitti> baptistemm: it might be a race condition on dbus activation?
[07:38] <pitti> baptistemm: (I assume that the signature is correct?)
[07:39] <pitti> baptistemm: it'd be worth trying to launch bluezd manually in a foreground terminal, ensure that it's running, and then run bluetooth-applet -d
[07:39] <pitti> and check if it's still the same error
[07:40] <baptistemm> perhaps I should use dbus-monitor to trace dbus traffic?
[07:41] <baptistemm> I tried to play with it yesterday but I didn't succeed to have sensible so I end up using 'dbus-monitor | grep org.bluez' :)
[07:43] <pitti> you can do that, but at this point it rather looks like a startup problem
[07:44] <baptistemm> yeah, okay, I thought I already asked to do that, but apparently i mixed up with another bug
[07:44] <baptistemm> thanks
[08:14] <seb128> mvo, opening duplicates, no tea for you today!
[08:15] <baptistemm> hello seb128
[08:15] <pitti> hey seb128
[08:15] <seb128> lut baptistemm
[08:15] <seb128> pitti, guten tag
[08:15] <seb128> pitti, did you move updates to -updates?
[08:15] <pitti> yes, a few
[08:15] <seb128> <cool
[08:16] <seb128> I was not sure I though we still had one day to go for those
[08:16] <seb128> thanks ;-
[08:16] <seb128> ;-)
[08:16] <pitti> np :)
[08:18] <seb128> mvo, the issue you are having seems to be bug #553162
[08:18] <seb128> bug #575591
[08:19] <seb128> pitti, did you spent some time looking to those LANG LANGUAGE mismatch issues?
[08:19] <pitti> not yet
[08:19] <pitti> it's not a regression, after all
[08:20] <pitti> just something not perfectly working yet
[08:21] <seb128> pitti, not sure, it seems people get half english half their locale desktop where they used to have a proper translated GNOME before updating to lucid
[08:21] <seb128> see the bug from mvo there
[08:22] <pitti> seb128: which is mvo's?
[08:22] <seb128> pitti, bug #575591
[08:24] <mvo> seb128, pitti: happend on my wifes machine
[08:24] <seb128> mvo, how many wifes do you have now? ;-)
[08:24] <seb128> mvo, scnr
[08:24]  * seb128 hugs mvo
[08:24] <mvo> she was using german before the upgrade and after the gnome bits are english
[08:24] <mvo> *pfff* ;)
[08:24] <pitti> mvo: what is your $LANGUAGE?
[08:25] <pitti> gdm isn't supposed to change $LANGUAGE, it doesn't have controls for it
[08:25] <seb128> it's not clear to me if the issue is language selector or gdm
[08:25] <mvo> pitti: LANGUAGE=en_DK (that is the system wide setting and what I use)
[08:25] <pitti> it's something that we added to language-selector, and once you do that you have to keep using it, I'm afraid
[08:25] <pitti> mvo: this is broken
[08:25] <seb128> but seems quite some users are being bitten by it
[08:26] <pitti> mvo: but if your LANGUAGE is "en", your desktop should be in English
[08:26] <mvo> so gdm can't unset/change LANGUAGE?
[08:26] <seb128> why did we made l-s set LANGUAGE?
[08:26] <pitti> seb128: it's language-selector and gdm beign differently flexible
[08:26] <mvo> well, I want my desktop to be english
[08:26] <mvo> but she does not want that
[08:26] <mvo> I also want the system wide default to be english
[08:26] <seb128> seems to me that l-s should let LANGUAGE alone tghere
[08:26] <pitti> for now she'd need to run language-selector herself to set LANGUAGES to "de"
[08:27] <pitti> seb128: it was a new feature in lucid, to be able to set $LANGUAGES separately
[08:27] <mvo> hrm, I know how to fix it, but that is not a good solution for everyone
[08:27] <pitti> (and it has been requested for ages)
[08:27] <mvo> especially since it was working in karmic
[08:27] <pitti> mvo: well, you couldn't set $LANGUAGE in the first place :)
[08:28] <pitti> karmic's gdm did set $LANGUAGE, yes
[08:28] <pitti> but that screwed up legitimate use cases
[08:28] <pitti> (it actually set it to something completely broken)
[08:28] <pitti> I don't currently see an easy solution for this, I'm afraid
[08:28] <mvo> I didn't do anything with lucid language selector
[08:28] <pitti> this requires a long and in-depth discussion
[08:28] <mvo> it used the karmic settings and did something with it
[08:29] <seb128> it seems that was "working" in karmic because gdm was overwritting LANGUAGE (in a buggy way though)
[08:29] <mvo> its a corner case setup, but for the people using it it is a regression IMO
[08:29] <seb128> not sure what to do on upgrade
[08:29] <pitti> seb128, mvo: FYI, gdm screwing up $LANGUAGE caused bug 407300
[08:30]  * mvo looks
[08:30] <pitti> LANGUAGE="$LANG"
[08:30] <pitti> no matter how you want to have the system work, but this was absolutely and entirely screwed
[08:31] <mvo> yeah, that is totally wrong
[08:31] <mvo> but https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/407300/comments/6 describes exactly the problem I have
[08:32] <pitti> one solution would be to add yet another widget to gdm to be able to change $LANGUAGES (but ugh complex)
[08:32] <mvo> could we simply "if GDM_LANG != LANG: unset(LANGUAGE)"?
[08:32] <pitti> another one to remove $LANGUAGES if you change it in gdm
[08:32] <pitti> something like that, yes
[08:32] <mvo> why another widget?
[08:33] <seb128> no other widget no
[08:33] <mvo> the user says "I want german, not english"
[08:33] <pitti> mvo: gdm doesn't have a languages selector
[08:33] <pitti> it has a locale selector
[08:33] <seb128> users don't know what a locale is
[08:33] <seb128> they use that as a language selector
[08:33] <pitti> they do, they just don't know the name for it :)
[08:33] <seb128> right ;-)
[08:33] <pitti> users complain very loudly if their date for numbers are misformatted
[08:34] <pitti> or paper formats, etc :)
[08:34] <seb128> well they want the standard set for their country
[08:34] <pitti> right, so you need a country as well
[08:34] <seb128> ideally you need a country "only" no "as well"
[08:34] <seb128> not
[08:34] <pitti> you also need a language
[08:34] <pitti> seb128: you currently are in a country where that matters a lot :)
[08:35] <seb128> grumpf, yes ;-)
[08:35] <seb128> I'm wondering how other os-es deal with that
[08:35] <pitti> seb128: langpack solution #6, I say
[08:35] <seb128> well ideally you want one list
[08:35] <mvo> I still don't get it (sorry). LANGUAGE is useful beyond the ability to give a fallback language? in gdm I can choose "german (germany)" or "german (belgium)". so it will setup LC_* correctly, no?
[08:35] <seb128> with things like "Belgium - wallons (french speaking)"
[08:35] <mvo> why do I need LANGUAGE for anything other then the fallback ?
[08:36] <pitti> mvo: $LANGUAGES is useful if you want a different desktop translation than locale
[08:36] <pitti> mvo: e. g. most Scandinavian folks, or even you, want their desktop to be in English
[08:36] <pitti> but still want a correct sv_SE or de_DE locale for paper format, time, etc.
[08:36] <pitti> (this is also a very popular setup in the CJK areas)
[08:37] <mvo> but shouldn't these people use language-selector than? because they know they want something that is not covered by the widget in gdm?
[08:37] <pitti> the other use is that you can define different fallbacks
[08:37] <pitti> if I speak French better than English, I can set $LANGUAGES=de:fr:en
[08:37] <mvo> whereas people like me do not know this?
[08:37] <pitti> mvo: exactly
[08:37] <pitti> those people have set $LANGUAGES in the past at some point
[08:37] <pitti> which karmic and earlier didn't provide an UI for
[08:39] <pitti> mvo: I think the GDM_LANG != LANG -> unset LANGUAGES is a reasonable approach
[08:39] <mvo> aha, I get it now
[08:40] <pitti> mvo: so in your case it would have probably been more polite to set LANGUAGES in your ~/.profile only, not system-wide
[08:40] <mvo> pitti: yeah, because when we do this, most users with the previous setup that manually added LANGUAGE will not affected
[08:40] <mvo> pitti: the odd thing is that I never touched the lucid version of language-selector
[08:40] <mvo> pitti: so either it was there before
[08:40] <mvo> pitti: or it wrote/updated it on upgrade
[08:40] <pitti> mvo: right, I suppose it was there way before
[08:40] <pitti> by default l-s also just writes to ~/.profile
[08:41] <mvo> pitti: I do want it the system wide default, just not for my wife :)
[08:41] <pitti> and en_DK is an invalid value, too
[08:41] <mvo> heh :)
[08:41] <mvo> joy!
[08:41] <pitti> mvo: then set it in ~wife/.profile ?
[08:41] <pitti> mvo: for your wife that workaround wouldn't even help then, though
[08:41] <mvo> right, *I* know how to fix it, but I doubt most other users will know
[08:41] <pitti> since I suppose she also uses de_DE.utf8
[08:41] <mvo> yes
[08:41] <pitti> thus GDM_LANG == LANG
[08:42] <mvo> I did not setup anything for her in her  ~/.profile
[08:42] <mvo> I used the GUI for all language releated settings
[08:42] <mvo> gdm for german
[08:42] <mvo> and l-s for the system default
[08:42] <mvo> so the workaround should work
[08:44] <didrocks> lool: ok, I'll see if there is something conflicting in the schedule and see with ogra
[08:44] <ogra> didrocks, awesome, thanks
[08:46] <mvo> pitti: thanks for updating the bug, I assume you are at somehands, so if you are too busy I'm happy to look into this and prepare a SRU (if the unset solution looks good enough)
[08:46] <pitti> mvo: I duped your bug and currently updating the master one
[08:46] <pitti> mvo: SH> I will be
[08:46] <pitti> I'm still in Leuven at some friends of mine
[08:46] <pitti> I'll come over around noon
[08:46] <mvo> aha, ok, even better :)
[08:47] <mvo> just let me know if your time does not permit it and I will try to make room for it
[08:48] <pitti> mvo: I did a braindump to the bug now
[08:49] <pitti> https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/553162/comments/10
[08:55] <mvo> seb128: what do you think about a "use compiz-from-debian" session?
[08:55] <mvo> seb128: or blueprint, not sure we need a session
[08:56] <seb128> mvo, blueprint, no session
[08:56] <seb128> it's a matter of just doing it I think
[08:56] <mvo> yeah,
[08:56] <mvo> i think its uncontroversial
[08:56] <pitti> . o O { not-use-compiz ? }
[08:57] <seb128> pitti, who need a wm when you can switch between nice kms vts?
[08:58] <pitti> seb128: once you finally upload gtk-asciiart, we won't :)
[08:58]  * pitti remembers those Turbo Vision times
[09:05] <seb128> mvo, https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-overriding-defaults-on-upgrade
[09:05] <seb128> mvo, you might want to subscribe to this one?
[09:06] <mvo> seb128: thanks, done. isn't that more of a gconf problem? i.e. if you set your preference back to default should it still be a user pref or should it considered "unset" again
[09:07] <mvo> seb128: do we have good examples ?
[09:07] <seb128> mvo, themes?
[09:08] <seb128> mvo, it might be mainly gconf yes, but I want to use the session to discuss how we handle cleanly user config changes on upgrade
[09:08]  * mvo nods
[09:08] <seb128> mvo, ie like adding indicators to gnome-panel
[09:08] <mvo> lets add some examples
[09:08] <mvo> theme
[09:08] <mvo> indicators
[09:08] <mvo> etc
[09:08] <seb128> I don't like the current "add an autostart which check a gconf key until end of time or later"
[09:08] <seb128> mvo, feel free to edit the summary ;-)
[09:09] <mvo> no permissions, but I can edit the whiteboard
[09:12] <seb128> oh, let me add the examples
[09:13] <seb128> you did in the whiteboard, seems good enough
[09:24] <chrisccoulson> good morning everyone
[09:25] <pitti> hey chrisccoulson
[09:25] <chrisccoulson> hey pitti, how are you?
[09:25] <pitti> I'm great, thanks
[09:29] <seb128> hey chrisccoulson
[09:30] <chrisccoulson> hey seb128, how are you too?
[09:30] <seb128> chrisccoulson, I'm good thanks!
[09:30] <seb128> chrisccoulson, how are you?
[09:31] <chrisccoulson> seb128 - yeah, i'm good too thanks
[09:32] <seb128> getting ready for uds? ;-)
[09:32] <chrisccoulson> mvo - did asac ask you whether we are still concerned about making hardy->intrepid->jaunty->karmic->lucid upgrades work, or just hardy->lucid?
[09:32] <seb128> thanks for doing some desktop bug triage yesterday btw
[09:32] <chrisccoulson> seb128 - sort of ;)
[09:32] <chrisccoulson> yeah, i've got loads of bug mail i need to work through at some point
[09:32] <mvo> chrisccoulson: he did not
[09:33] <mvo> chrisccoulson: what is the context? I mostly care about karmic->lucid and hardy->lucid currently, but if there is a specific issue or low-hanging fruit I'm open
[09:34] <chrisccoulson> mvo - i'm working on the ff3.6 backport for hardy currently. if we only care about hardy->lucid upgrades, then that makes my job for hardy much easier
[09:34] <chrisccoulson> but if not, then i'll have to do the work for karmic, jaunty and intrepid first
[09:34] <chrisccoulson> which complicates things ;)
[09:34] <chrisccoulson> and i'd rather not do anything on intrepid
[09:36] <mvo> chrisccoulson: I can not see why someone would want to upgrade from hardy to intrepid at this point really, we should not even offer the upgrade anymore
[09:36] <chrisccoulson> mvo - that's what i want to hear :)
[09:36] <chrisccoulson> thanks
[09:36] <mvo> chrisccoulson: I will check that now (that we don't actually offer the upgrade)
[09:37] <chrisccoulson> thanks
[09:37] <mvo> well, in a little bit, need to prepare a SRU first :)
[10:02] <milanbv> ugh... I hope I'm wrong, but...
[10:03] <milanbv> isn't our /etc/dbus-1/system.d/xorg-server.conf completely wrong with interfaces?!
[10:03] <milanbv> <allow send_interface="org.x.config.display0"/> will allow this interface on *all* objects
[10:03] <milanbv> that was bug 318753...
[10:20] <qense> Is there really no way of passing a Python list over DBus that contains lists containing both integers and strings?
[10:22] <qense> Ah, 'v´
[10:59] <nigelbabu> seb128: whats you're take on bug 508632? Are we going to include the patch for maverick?
[10:59] <seb128> nigelbabu, no
[10:59] <seb128> it's not a bug it's an upstream decision
[11:00] <nigelbabu> seb128: can you comment on it so I can reject the patch?
[11:00] <seb128> I already did
[11:00] <nigelbabu> then close to wont fix?
[11:00] <seb128> not recently but I don't see the point to keep arguing with users who don't want to listen
[11:00] <seb128> I don't care enough to start a bug closing war, we will get the change if upstream does it
[11:01] <nigelbabu> what would you want me to do? ask the patch author to forward upstream and hear their take? (it sounds kinda ironic)
[11:08] <nigelbabu> seb128: thank you, I came across this during patch review
[11:09] <nigelbabu> since you commented on it, I just wanted your take :)
[11:09] <seb128> nigelbabu, it's up to you to know what you want to do
[11:09] <seb128> nigelbabu, I would just stay out of the discussion
[11:09] <nigelbabu> I've directed everything upstream
[11:10] <seb128> use whatever tag is not used to say we are not going to use the change unless upstream does
[11:10] <nigelbabu> ok :)
[11:10] <pitti> I'm off now for going to La Hulpe; see you there!
[11:10] <pitti> seb128: you are at the sprint, I take it?
[11:11] <pitti> (for saying hello, etc.)
[11:12] <seb128> pitti, yes, but feel free to jump in when you arrive
[11:12] <pitti> seb128: ok, I'll go back to IRC once I'm there, and prod you :)
[11:12]  * pitti waves
[11:12] <seb128> pitti, ok, have a safe trip, see you soon
[11:15] <baptistemm> hmmm, I've no sound in mysession, and the sound capplet lists me no audio device, just a dummy one
[11:15] <seb128> baptistemm, buy a soundcard ;-)
[12:58] <asac> mvo: the question was really: do we still offer the upgrade path to intrepid
[12:58] <asac> i hoped we didnt but wanted to get a confirm on that one
[12:59] <mvo> asac: we do right now, but I want to fix this today and give people lucid instead
[12:59] <asac> mvo: isnt intrepid already moved out of the archive?
[12:59] <asac> to old releases or somehting?
[12:59] <mvo> not yet
[12:59] <mvo> but it will be very soon I expect
[12:59] <asac> yeah. ok
[13:00] <asac> please make that happen quickly ;) ...
[13:00] <asac> otherwise we have to roll everything at once ... now we can just upgrade hardy to 3.6 and leave jaunty/karmic at 3.5 which is still supported for a few weeks
[13:03] <mvo> jaunty will be support for 6 more month and karmic for 12m, no?
[13:08] <asac> mvo: right
[13:09] <asac> mvo: situation is like this: hardy has ffox 3.0 -> EOL upstream ... jaunty/karmic have 3.5 -> still supported ... lucid has 3.6
[13:09] <asac> so fi upgrade path through jaunty is still supported we first have to update jaunty/karmic before we can update 3.0 to 3.6
[13:09] <asac> if not, we can focus on hardy for now ... which would be much better
[13:09] <baptistemm> seb128, I do have one
[13:09] <mvo> asac: aha, it would be nice to support jaunty, but its not super important
[13:09] <mvo> karmic we definitely need to support
[13:10] <baptistemm> seb128, it is listed as alsa layer but not at pa layer
[13:10] <mvo> asac: intrepid EOL, so no worries
[13:10] <asac> mvo: we are supporting that ;) ... its just that we dont need to hurry and upgrade jaunty/karmic to 3.6 in order to upgrade hardy if we dont offer upgrades to intrepid anymore
[13:10] <asac> mvo: or do you want to offer hardy -> jaunty upgrades?
[13:10] <asac> i would hope just lucid
[13:14] <chrisccoulson> asac - jaunty also has 3.0 (3.5 is only in universe) :(
[13:15] <mvo> asac: no, just hardy->lucid
[13:16] <asac> yeah
[13:16] <asac> chrisccoulson: bummer thats bad :/
[14:08] <milanbv> how are users supposed to configure their serial/usb 56k old-style modems in Lucid? network-admin lost its tab to do it, and ModemManager doesn't support them?
[14:08] <milanbv> who's supposed to know how all of this works? ;-)
[14:09] <milanbv> if that's the case, we may need to bring back network-admin's tab...
[14:27] <milanbv> asac_: thoughts on this? ^
[14:29] <asac> milanbv: network-admin doesnt exist anymore, does it?
[14:29] <asac> we definitly dont want to have that installed by default
[14:29] <milanbv> no, it's not installed by default
[14:30] <milanbv> and the Connections tab has been removed
[14:30] <milanbv> the problem is,
[14:30] <milanbv> 1) docs still mention it for modems
[14:30] <milanbv> 2) there doesn't seem to be a way to configure traditional modems in Lucid anymore
[14:33] <asac_> milanbv: yeah. modemmanager should get plain modem support. its not a big deal, but noone does that as the amount of users that need it seems to be really smallish
[14:33] <asac_> contributions welcome
[14:34] <benjamintheyon> Didn't see it in the channel info - is this the Desktop team as in desktop release of ubuntu or graphical desktop? I'm a new jack,  tryna find my way around.
[14:34] <milanbv> asac_: sure, in the long run we want modem-manager
[14:35] <milanbv> but for lucid, what's the best solution: completely lose modem support and remove the docs, or bring back the Connections tab?
[14:35] <milanbv> (UbuntuStudio seems to require that tab too)
[16:06] <rodrigo_> kenvandine, around?
[16:08] <rodrigo_> seb128, pitti: I seem to not have permissions to push to lp:~ubuntu-desktop/couchdb-glib/ubuntu/, I thought I got permissions now that I had upload rights?
[16:13] <seb128> rodrigo_, no, you are not in the ubuntu-desktop team
[16:13] <seb128> rodrigo_, we should move that to the canonical location I think
[16:13] <rodrigo_> seb128, ah, so still need to propose branches for merging?
[16:13] <seb128> we should change the bzr to not be in our team I guess
[16:13] <seb128> I don't think it's going to happen this week though
[16:14] <seb128> since people are travelling and some going to somehand etc
[16:15] <rodrigo_> ok, np, I've got instructions from kenvandine on how to upload, and he told me to push to trunk once uploaded
[16:15] <rodrigo_> I'll propose the branch for merging
[16:15] <rodrigo_> seb128, another question :) where are the karmic package branches?
[16:15] <seb128> depends, we don't have a strict policy, often we don't bother doing a stable serie
[16:16] <seb128> ie we just do change and upload to ubuntu without using a vcs
[16:16] <seb128> or we use trunk as long as there is not a newer version
[16:18] <rodrigo_> for couchdb-glib, trunk already refers to maverick, so I guess it was branched?
[16:30] <Nafai> morning
[16:48] <rodrigo_> seb128, so, lp:~ubuntu-branches/ubuntu/karmic/couchdb-glib/karmic has the tarball's source code, isn't there a similar karmic branch with just debian/ dir, as lp:~ubuntu-desktop/couchdb-glib/ubuntu?
[16:48] <seb128> rodrigo_, no idea, I don't work on this source
[16:49] <seb128> the first one is an auto import of uploads I guess
[16:49] <rodrigo_> pitti, ^^ ?
[16:49] <seb128> the second one is the packaging one
[16:49] <rodrigo_> seb128, ah
[16:49] <seb128> ie what we work on
[16:50] <rodrigo_> seb128, yes, but I need to submit a change to karmic package, so looking for the package branch
[16:50] <rodrigo_> doesn't seem to exist, or can't find it
[16:50] <seb128> as said before we often don't bother doing a stable vcs
[16:50] <seb128> especially that we didn't upload anything yet newer that lucid
[16:50] <seb128> oh karmic
[16:51] <seb128> well usually we get the source, do the change and upload
[16:51] <rodrigo_> seb128, ah
[16:51] <seb128> we not have a common defined workflow for stable series
[16:51] <seb128> some people might make stable series
[16:51] <seb128> we usually don't bother for desktop, stable doesn't change a lot
[17:02] <cjohnston> thanks sabdfl !
[17:02] <sabdfl> cjohnston: that was entertaining :-)
[17:02] <cjohnston> I missed half of it.. :-/ at work today
[17:03] <cjohnston> looks like all went well though
[17:16] <jcastro> mdeslaur, what was that gwibber bug again?
[17:17] <mdeslaur> jcastro:: 552227
[17:17] <Nafai> jcastro: should I attempt to re-register or should I wait?
[17:17] <jcastro> Nafai, yeah try now please
[17:17] <jcastro> Nafai, sorry for the inconvenience
[17:19] <Nafai> no prob :)
[18:08] <Nafai> lunch / errands
[18:10] <Nafai> I just checked the UDS schedule before I left
[18:11] <Nafai> someone scheduled my two sessions (from my assigned blueprints) back to back! :)
[19:34] <Nafai> back
[23:44] <RAOF> Morning funky people.
[23:56]  * bryceh waves