[05:03] <pitti> Good morning
[05:11] <TheMuso> Morning pitti.
[05:15] <pitti> hey TheMuso, how are you?
[05:15] <TheMuso> pitti: Not too bad thanks, yourself?
[05:15] <pitti> pretty good, looking forward to releasing A1 today
[05:16] <pitti> TheMuso: do you have a sec for some bug questions?
[05:16] <TheMuso> pitti: Sure.
[05:16] <pitti> TheMuso: so it seems bug 790240 made some progress, there's just one package left
[05:16] <ubot2> Launchpad bug 790240 in java-access-bridge "at-spi needs demotion for precise (at-spi2-core in main)" [High,Confirmed] https://launchpad.net/bugs/790240
[05:16] <pitti> java-access-bridge
[05:16] <pitti> do you know the status of getting that to at-spi2?
[05:16] <TheMuso> pitti: java-atk-wrapper replaces java-access-bridge.
[05:17] <pitti> ah, so we need to MIR that
[05:17] <TheMuso> I filed an MIR< and it was approved.
[05:17] <pitti> nice
[05:17] <TheMuso> It just needs something to depend on it, i.e openjdk.
[05:17] <pitti> TheMuso: can openjdk-6-jre be changed to use that then?
[05:17] <pitti> it currently depends on libaccess-bridge-java-jni
[05:17] <pitti> and so does openjdk-7-jre
[05:18] <TheMuso> So far as I understand, yes. I'd need to find some java app that works via accessibility to be sure.
[05:18] <TheMuso> pitti: Yeah I believe that java-atk-wrapper is a drop-in replacement.
[05:18] <pitti> TheMuso: nice! are you on this and coordinating with doko?
[05:19] <TheMuso> pitti: I've talked to doko about it, but no actino has been made on this yet.
[05:20] <pitti> TheMuso: we just need to swap the dependency?
[05:20] <TheMuso> pitti: Yes.
[05:21] <pitti> TheMuso: ok, thanks
[05:21] <TheMuso> np
[05:27] <pitti> TheMuso: my other question is about bug 810721
[05:27] <ubot2> Launchpad bug 810721 in at-spi "at-spi-registryd crashed with SIGSEGV in gconf_client_get_default()" [High,Triaged] https://launchpad.net/bugs/810721
[05:27] <pitti> this is apparently fixed in at-spi2
[05:27] <pitti> but it sounded like the fix could be adapted to at-spi as well
[05:28] <pitti> it's probably not that important for precise any more, though?
[06:26] <didrocks> good morning
[06:30] <pitti> hey didrocks
[06:31] <didrocks> guten morgen pitti, how are you?
[06:31] <pitti> I'm quite fine, thanks! how about you?
[06:31] <pitti> looking forward to releasing A1
[06:34] <didrocks> I'm fine, thanks! I think I finally almost got over the flu. Was quite sticky this time :)
[06:40] <pitti> eek, that took a looong time!
[06:43] <didrocks> indeed, I guess all this busy week-end didn't help to cure
[06:43] <didrocks> but since the week before UDS, I will have my first real week-end now :)
[06:51] <pitti> eek, that took a looong time!
[06:51] <pitti> oops, -EFOCUS
[08:40] <chrisccoulson> good morning everyone
[08:46] <pitti> hey chrisccoulson
[08:46] <chrisccoulson> hi pitti, how are you?
[08:46] <pitti> quite fine, thanks!
[08:50] <didrocks> good morning chrisccoulson!
[08:50] <didrocks> how are you?
[08:50] <chrisccoulson> hi didrocks
[08:51] <chrisccoulson> i'm good thanks, how are you?
[08:51] <didrocks> chrisccoulson: I'm fine thanks :)
[08:51] <chrisccoulson> ooh, todays firefox daily is built already. time to upgrade and hopefully it's usable again :)
[08:53] <didrocks> chrisccoulson: btw, I see a lot of changes in thunderbird theme right now
[08:53] <didrocks> like, the left treeview is grey now
[08:53] <chrisccoulson> didrocks, yeah, that's intentional
[08:53] <chrisccoulson> there aren't any other changes are there?
[08:53] <didrocks> ok, just to ensure :)
[08:54] <didrocks> well, thread with new messages are underlined
[08:54] <didrocks> instead of being bold
[08:54] <didrocks> I think this is a new thunerbird feature
[08:54] <chrisccoulson> yeah, i noticed that too. i can't remember whether that was the case before though :)
[08:54] <chrisccoulson> i thought that something looked different in the thread pane
[08:54] <didrocks> it wasn't I guess
[08:54] <didrocks> as I've been shocked as well :)
[08:55] <chrisccoulson> didrocks, you're on precise now aren't you?
[08:55] <didrocks> chrisccoulson: indeed
[08:55] <chrisccoulson> ok, so you're running the same version as me :)
[08:56] <chrisccoulson> i keep thinking about running thunderbird daily builds, but i'm not sure i'm brave enough yet
[08:56] <didrocks> chrisccoulson: not on precise yet? :)
[08:56] <didrocks> heh
[09:07] <TheMuso> pitti: Not for precise, no.
[09:09] <seb128> hey
[09:09] <pitti> hey seb128
[09:10] <seb128> pitti, howdy, how are you?
[09:11] <pitti> seb128: I'm great, thanks!
[09:14] <chrisccoulson> when can i start uploading again? :)
[09:14] <chrisccoulson> i've got new firefox and thunderbird beta releases to do
[09:15] <pitti> waiting for a kubuntu alternate result, but will time out for that RSN
[09:16] <pitti> chrisccoulson: I think I'll do a cut in two hours and lift the freeze
[09:16] <chrisccoulson> pitti - cool, thanks
[09:18] <seb128> chrisccoulson, hey, how are you?
[09:18] <chrisccoulson> hi seb128. yeah, i'm good thanks, how are you?
[09:19] <seb128> I'm good thanks!
[09:22] <TheMuso> pitti, seb128, is the GTK 3.3/3.4 API anywhere close to being frozen yet? I think I may need to propose an extension to the GtkMenuItem API to help with some dbusmenu a11y work I'm doing.
[09:23] <seb128> TheMuso, no quite close
[09:23] <seb128> TheMuso, you should talk to desrt, he's working on landing the gmenu stuff upstream and make it used in gtk
[09:24] <TheMuso> seb128: Right, will catch him in the morning then.
[09:24] <seb128> TheMuso, which is going to be used then in dbusmenu (but probably not for the lts)
[09:24] <TheMuso> Right.
[09:25] <seb128> pitti, did you look at,fix the retracers?
[09:25] <pitti> seb128: oh, are they broken again? I didn't get amil
[09:25] <pitti> mail
[09:26] <seb128> pitti, they don't seem so but I'm looking at a i386 apport bug opened 8 hours ago which is not retraced yet and I was wondering why
[09:26] <seb128> pitti, do we retrace precise yet?
[09:26] <pitti> ah, I think I know why
[09:26] <pitti> ERROR: KernelCrash processing not implemented yet
[09:27] <pitti> 12/01/11 09:17:07: retracing #897539 failed with status: 99
[09:27] <pitti> seb128: yes, since day 1 :)
[09:27] <seb128> retrace pool now: set([897539, 898501, 898207, 898155, 898412, 898171, 897747, 898423, 898456, 898043, 898431])
[09:27] <seb128> pitti, it doesn't go to the next one? just bail out on the kernel one?
[09:27] <pitti> apparently so
[09:28] <seb128> pitti, ok, so I've my reply ;-)
[09:28] <seb128> pitti, should I just untag that or do you want to properly look at the "bug" to make it skip the kernel bug and continue with the next one rather than bailing out?
[09:28] <pitti> seb128: already at it
[09:28] <seb128> pitti, thanks!
[09:28] <pitti> aaaand committed
[09:28] <seb128> lol
[09:29] <seb128> that's efficient ;-)
[09:29] <pitti> and pulled
[09:29] <pitti> next run should be good
[09:29] <seb128> pitti: "made of awesome" ;-)
[09:29] <pitti> "no time like the present" :)
[09:29] <pitti> seb128: fortunately a1 looks pretty good, so I'm currently working on stable+1 stuff
[09:29] <pitti> seb128: http://people.canonical.com/~pitti/tmp/main-promotions.svg FYI
[09:29] <seb128> pitti, oh, right, you start your rotation today
[09:29] <seb128> enjoy!
[09:30] <pitti> to make http://people.canonical.com/~ubuntu-archive/component-mismatches.txt easier to read
[09:30] <pitti> seb128: thanks!
[09:30] <seb128> pitti, nice one ;-)
[09:31] <seb128> pitti, that could probably be ueful for pedro as well, he's working on a dashboard for the desktop team, I suggested that he could include the packages not building and the components mismatch for desktopish packages on it
[09:53] <glatzor> hello seb128 pitti and mvo
[09:54] <glatzor> mvo: I prepared a patch for the akward aptdaemon dialog sizes https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/892607
[09:54] <pitti> hey glatzor, how are you?
[09:54] <ubot2> Launchpad bug 892607 in aptdaemon "Details window poorly resizes on expanded details" [High,Confirmed]
[09:54] <glatzor> pitti, Having a cold. but otherwise fine! yourself?
[09:54] <pitti> glatzor: I'm great
[09:54] <pitti> thanks
[10:05] <mvo> glatzor: awsome, thanks! I take care of this now
[10:08] <seb128> hey glatzor, mvo
[10:08] <mvo> glatzor: precise upload will have to wait for alpha1, but oneiric is fine for a SRU
[10:10] <mvo> glatzor: hm, does not seem to apply cleanly against the oneiric version, lets see
[12:30] <pitti> @ALL: soft freeze lifted, upload away
[12:30] <pitti> mvo, seb128 ^
[12:30] <seb128> pitti, danke!
[12:30] <pitti> chrisccoulson: ^
[12:30] <didrocks> go go go :)
[12:31] <chrisccoulson> pitti, excellent, thanks
[12:31] <mvo> cool! thanks!
[12:43] <nessita> hello everyone!
[12:43] <mpt> mvo, hi, do you think <https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-improve-upgrade-experience> should be targeted for P?
[12:43] <pitti> hey nessita, how are you?
[12:43] <nessita> pitti: pretty good! you? :-)
[12:43] <pitti> nessita: I'm fine, thanks!
[12:44]  * mpt waves to nessita
[12:44] <nessita> hi mpt!
[12:48] <mvo> mpt: yes, but someone from the desktop team should approve it if its a desktop spec
[12:49] <mvo> mpt: should be all really reasonable
[12:49] <mpt> mvo, as in jasoncwarner_?
[12:49] <mvo> mpt: yeah, jason or maybe pitti
[12:50] <mpt> pitti has the advantage of being here now :-)
[12:53] <pitti> mvo: accepted for precise, set myself as approver (I generally approve desktop-* stuff); once you are happy with it, please set it to "review" or "pending approval"
[12:54] <seb128> well, approving is one thing, having somebody working on it is another... mvo? ;-)
[12:54] <pitti> yes, the WIs are between mvo and mpt
[12:54] <pitti> mvo: NB that there is a rather invalidly looking Work item "- If the OS is no longer supported, "Don't Upgrade" does the same thing as..."
[12:58] <pitti> Sweetshark: you said that you had a precise libo for sponsoring? I don't see it in ~bjoern/
[12:58] <pitti> Sweetshark: freeze is lifted now, so we can upload
[12:58]  * pitti -> lunch
[13:05]  * rodrigo_ lunch
[13:11] <GunnarHj> seb128, pitti: Hi guys! Any news about accountsservice, region property and GNOME?
[13:12] <seb128> hey GunnarHj, hum, no, but good that you are there earlier than the other days ;-)
[13:12] <seb128> we can probably catch pitti when he's back from lunch and then mclasen
[13:14] <GunnarHj> seb128: Ok. I haven't much time today, though, just half an hour or so.
[13:15] <seb128> GunnarHj, well, thanks for the reminder, pitti just went for lunch but I will talk to him about that when he's back
[13:15] <GunnarHj> seb128: Great. Can you please ping me then?
[13:15] <seb128> GunnarHj, will do
[13:25] <Sweetshark> pitti: uploading
[14:03] <pitti> re
[14:07] <pitti> chrisccoulson: mozjs going to universe is ok?
[14:08] <chrisccoulson> pitti, yeah, that's fine by me :)
[14:11] <nessita> is mterry coming today?
[14:12]  * nessita is desperately chasing patch pilots
[14:18] <Sweetshark> pitti: upload finished
[14:18] <pitti> Sweetshark: thanks! (BTW, you don't need the orig.tar, they are already in the archive)
[14:21] <dobey> what's with all these mails on devel-discuss about unity and classic?
[14:21] <dobey> nessita: what do you need a sponsor for?
[14:22] <nessita> dobey: the qt4reactor initual packaging branch
[14:23] <dobey> oh
[14:24] <seb128> nessita, hey, you managed to summon him it seems :p
[14:24] <dobey> hehe
[14:24] <nessita> seb128: pathc pilots run away from me :-.
[14:24] <nessita> :-/
[14:25] <dobey> pitti: can you push the libubuntuone in oneiric-proposed to oneiric-updates? it's been sitting in proposed for 5 weeks, apparently due some confusion on the bug between it and banshee, as the fix is 2-part :(
[14:25] <seb128> nessita, did you hear back from skaet or mdeslaur yesterday about the license issue?
[14:26] <nessita> seb128: nopes, last thing was that skaet was gonna check, but no news on that front
[14:26] <pitti> Sweetshark: thanks, uploaded
[14:26] <seb128> nessita, check with skaet maybe then before chasing a sponsor, that license issue needs to be sorted first
[14:27] <nessita> seb128: right
[14:27] <dobey> what is the license issue?
[14:27] <pitti> dobey: bug 851044 hasn't been formally verified, but I guess it's been tested enough now, and the other bug is; moving
[14:27] <ubot2> Launchpad bug 851044 in libubuntuone "Banshee.exe crashed with SIGABRT in g_cclosure_marshal_VOID__VOID() / while using Ubuntu 1 Store." [High,In progress] https://launchpad.net/bugs/851044
[14:28] <dobey> pitti: ah, that bug was also fixed in webkit; but i also changed libubuntuone to not crash, when the webkit fix isn't present
[14:29] <dobey> and i had forgotten that bug was also linked to the update; i got pinged about the other bug yesterday, and didn't realize it was still sitting in proposed :(
[14:30] <mdeslaur> dobey: twisted is MIT, qt4reactor is MIT, but pyqt is GPL
[14:30] <mdeslaur> dobey: twisted doesn't ship qt4reactor because they say it's a licensing issue
[14:30] <dobey> oh
[14:31] <dobey> so qt4reactor needs to be GPL; and either way twisted can't ship it
[14:31] <seb128> mterry, welcome back!
[14:31] <dobey> which is odd
[14:32] <mterry> seb128, :)  Don't load me up yet though, I'm on pilot duty today
[14:32] <mdeslaur> dobey: it's complicated because it's python, but a library, and can be a "derivative work", etc.
[14:32] <pitti> mvo: can you please change software-center's depends for python-gobject -> python-gi? (upload isn't urgent at all, storing to bzr is fine)
[14:32] <seb128> mterry, yeah don't worry, feel free to ping if you need or want work though, I've plenty of small things and bugs, I'm sure you can like some of those ;-)
[14:33] <cyphermox> howdy
[14:33] <dobey> mdeslaur: right, though i think the GPL is clear in it's viral nature; if pyqt changed to LGPL, it wouldn't be a problem though
[14:34] <cyphermox> seb128: same thing, any small things/small bugs you want me to look at before I dive into NM to start my work items?
[14:34] <mterry> seb128, I need to also catch up on my own work items from being a month away.  I probably will not pursue extra work for a bit.  But I can gladly grab things for you if you have an excess
[14:34] <dobey> pitti: i take it that's a debian change, not an upstream package renaming?
[14:34] <nessita> dobey: why qt4reactor needs to be GPL? it import pyqt on a try-except, and it defaults to pyside if pyqt is not present
[14:34] <mdeslaur> dobey: yep, but pyqt isn't going to do that :) that's why there's pyside
[14:34] <pitti> dobey: right; it only ships the "gi" module now, so it's more appropriate and actually adheres to the python policy
[14:34] <seb128> cyphermox, hey, I didn't even notice you were in +1 until yesterday when pitti said you were coming back ;-)
[14:35] <dobey> mdeslaur: right
[14:35] <cyphermox> I know...
[14:35] <pitti> dobey: also, this will actually allow us to see which packages still need GI migration
[14:35] <cyphermox> but then is that good or bad? ;)
[14:35] <dobey> nessita: because pyqt is GPL; try/except doesn't really matter
[14:35] <seb128> cyphermox, mterry: you guys should do an after +1 blog post of summary or something, I would be interested to know what +1 did during its first month ;-)
[14:35] <pitti> seb128: cjwatson sent a summary, but only to some people in private; perhaps he should re-send that to u-devel@
[14:35] <pitti> it was really interesting, but of course I don't want to send it on his behalf
[14:36] <dobey> pitti: yeah; would be nice if GI actually provided all the API though. and if upstream weren't so obnoxious
[14:36] <pitti> heh
[14:36] <seb128> pitti, ok, thanks, I would be really interested to see what people are doing then, I guess it would be useful as well for other who consider doing a rotation there ;-)
[14:36] <seb128> cjwatson, ^
[14:37] <nessita> dobey: ok, so I'm lost. The qt4reactor code itself is MIT, so we can't change it to GPL. You mean the packaging code I'm adding should be GPL?
[14:37] <dobey> nessita: i mean upstream needs to fix the licensing problem
[14:38] <dobey> nessita: and technically, we can actually release it as GPL; but it really should be done as an upstream change
[14:38] <dobey> nessita: or well, it can just drop pyqt and only use pyside, but i'm sure you wouldn't like that :)
[14:38] <mdeslaur> dobey: but then it's used by twisted, which is MIT, so you just move the problem to twisted
[14:39] <nessita> dobey: I still don't see the licensing issue to escalate it to upstream, they need the reactor code (which they write) to be compatible with twisted
[14:39] <nessita> dobey: they just import pyqt, and handle it not being there
[14:39] <nessita> so pyqt is not strictly a dependency
[14:39] <nessita> dobey: so, for example, our code that uses both, is GPL, which is correct
[14:40] <nessita> because MIT + GPL => GPL
[14:40] <dobey> mdeslaur: not quite; at that point it's a plug-in; it's still hairy but apps using qtreactor would need to be GPL, though twisted wouldn't necessarily.
[14:40] <mdeslaur> nessita: pyqt is probably considered to be "bindings" by the GPL FAQ
[14:40] <mterry> seb128, I feel like cjwatson did some interesting infrastructure stuff.  But I mostly just fought with various ftbfs  :)  not glamorous enough for a post I think
[14:40] <dobey> nessita: it doesn't matter if they handle it not being there with the try/except or not
[14:40] <nessita> dobey: apps using qt4reactor and pyside do not need to be GPL
[14:40] <nessita> mdeslaur: ^
[14:40] <dobey> nessita: yes it's annoying, and yes it's hairy
[14:41] <mdeslaur> nessita: so, if you patch the pyqt4 import out of qt4reactor, problem is solved
[14:41] <mdeslaur> nessita: but I suspect that's not what you want to do
[14:41] <dobey> no, we use pyqt
[14:41] <nessita> mdeslaur: not at all, since we use that :-)
[14:41] <dobey> so that doesn't help :)
[14:41] <nessita> mdeslaur: and we're GPL, which is fine
[14:41] <nessita> we == Ubuntu Onre
[14:41] <nessita> One*
[14:42] <mvo> pitti: sure, fixed in bzr
[14:42] <pitti> mvo: danke
[14:42] <pitti> I've done the same for a few other packages, but don't upload anything except computer-janitor (as there I might just forget to upload it later)
[14:43] <dobey> nessita: basically, it seems upstream needs to change the license to GPL, or drop pyqt support
[14:44] <nessita> dobey: I know I'm not a licensing expert, but I think that too strict. I still don't see why qt4reactor has to deal with the gpl-ity pf pyqt
[14:44] <nessita> is a responsibility of the users os qt4reactor
[14:44] <nessita> of*
[14:44] <dobey> nessita: because they use it
[14:44] <nessita> dobey: they don't use it necessarily
[14:44] <nessita> dobey: the code can work without it, using pyside
[14:44] <dobey> nessita: it's not a plug-in.
[14:45] <nessita> dobey: let's make it be a plugin
[14:45] <dobey> nessita: if it was a plug-in system with the pyqt support being another package, that might be fine
[14:45] <nessita> dobey: let's split that then, should be fair simple, no?
[14:45] <dobey> i suspect not, no
[14:45] <nessita> dobey: why not?
[14:46] <nessita> mdeslaur: would you please link me to what you mentioned re: bindings?
[14:46] <mdeslaur> nessita: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
[14:46] <nessita> mdeslaur: I'm reading the FAQ and what I found about bindings is related to running programs on GPL interpreters
[14:47] <nessita> mdeslaur: right, I'm reading that, and I don't think that applies to this case, no?
[14:47] <nessita> our interpreter is not GPL
[14:48] <dobey> nessita: the interpreter (python) license is irrelevant in that statement about bindings
[14:48] <mdeslaur> the interpreter is python, pyqt is the binding between python and QT. Since pyqt is GPL, apps that use pyqt need to be GPL also.
[14:48] <dobey> nessita: the bindings statement is purely about what is being interpreted
[14:48] <nessita> mdeslaur: agreed, so Ubuntu One is GPL. But qt4reactor does not necessarily uses pyqt...
[14:49] <mdeslaur> but, I'm not the one that is knowledgeable about these things. All I wanted to do yesterday was figure out who in Ubuntu gets to make the licensing decision.
[14:49] <nessita> mdeslaur: right, so skaet is the person to ask details about this, then?
[14:49] <dobey> what does the DFSG say?
[14:50] <nessita> dobey: can you please check?
[14:51]  * dobey prefers to just assume the world will end in 386 days anyway, so it probably doesn't really matter
[14:52] <mdeslaur> hehe
[14:53] <nessita> mdeslaur: so, shall we re-ask someone in ubuntu-release or shall we ping someone in particular?
[14:54] <mdeslaur> nessita: wait a bit, skaet just arrived, let's see what she says.
[14:55] <nessita> mdeslaur: right :-)
[14:57] <dobey> nessita: a simple solution would be to just have upstream dual-license it
[14:58] <nessita> dobey: how does double licensing work? I mean, what they need to do?
[14:58] <mdeslaur> dobey: well, MIT is GPL compatible...it doesn't need to be specifically GPL licensed I don't think
[15:00] <mdeslaur> not that I know anything about this :P
[15:00] <dobey> mdeslaur: it's GPL compatible (GPL apps can use MIT code), but it doesn't work the same the other way 'round. MIT apps can't use GPL code (since GPL requires anything linked to GPL to be GPL, save the system lib clause, which pyqt doesn't fall under)
[15:00] <mdeslaur> dobey: ah! that makes sense
[15:01] <dobey> but a dual license here would help (if you use pyqt it's GPL, if you use pyside it's MIT); though i don't know if upstream is willing to do it
[15:02]  * mdeslaur nods
[15:03] <dobey> if not, the next best solution might be to just ship it as GPL, which i think is perfectly fine legally so long as we maintain (c) notice in the code
[15:16] <jincreator> pitti: Hi. Do you remember my bug report about ttf-nanum?
[15:16] <pitti> hey jincreator; sure
[15:16] <pitti> or fonts-nanum as it is called these days
[15:17] <jincreator> pitti: Yes, Package name is changed.
[15:19] <jincreator> pitti: And also fonts-nanum-coding include fontconfig setting. But both fontconfig snippet is not working at Ubuntu in my test.
[15:21] <jincreator> So, I was thinking about remove 69-language-selector-ko-kor.conf and patch fontconfig-config package.
[15:23] <jincreator> But if Japanese and Chinese users are agree and help, I think we can remove entire fontconfig hack for CJK users in language-selector by modify fontconfig-config. What do you think about it?
[15:23] <pitti> jincreator: is that known to not work in Debian as well?
[15:23] <pitti> jincreator: I wonder if language-selector's hacks destroyed the package's fontconfig file somehow
[15:23] <jincreator> pitti: In my test, it is working well in Debian.
[15:23] <pitti> so I guess we need to remove the hacks from language-selector then?
[15:24] <jincreator> pitti: I think "lang" option in fontconfig is not working at Ubuntu.
[15:27] <pitti> jincreator: strange, we have the same fontconfig version as in Debian
[15:28] <pitti> jincreator: so you already ruled out that language-selector installs an extra hack which breaks this?
[15:30] <jincreator> pitti: No, I don't mean language-selector destroy another package's fontconfig file.
[15:31] <jincreator> pitti: I don't know why it happen at only Ubuntu even it use same fontconfig version with Debian. And I didn't see bug report about it. But, bug 884645 looks like it is happening to ja locale.
[15:31] <ubot2> Launchpad bug 884645 in language-selector "Improvement for ja-jp conf (69-language-selector-ja-jp.conf): measure for ttf-unfonts-core side-effects" [Undecided,Fix released] https://launchpad.net/bugs/884645
[15:32] <pitti> jincreator: hm, I'm afraid I'm useless there as well; fontconfig is a mystery to me :(
[15:36] <jincreator> pitti: fonts-nanum's fontconfig snippet is only work when locale is "ko". But it looks this function is not working in Ubuntu. So I'm trying to remove this snippet and use another fontconfig(i.e fontconfig-config, language-selector, ...).
[15:36] <pitti> jincreator: so it seems we should really fix that function then
[15:37] <jincreator> pitti: Yes.
[15:37] <pitti> instead of moving around the conffiles and permanently diverging from debian
[15:37] <pitti> jincreator: note that we want to get rid of the l-s fontconfig hacks entirely
[15:37] <pitti> as we move to gnome-control-center
[15:39] <jincreator> Well, I think 69-language-selector-ko-kr.conf is no more needs anymore. Because I didn't see any Korean Ubuntu users notice bug 879069.
[15:39] <ubot2> Launchpad bug 879069 in ubiquity "language-selector doesn't automatically link fontconfig files for CJK users" [Undecided,Confirmed] https://launchpad.net/bugs/879069
[15:40] <jincreator> And actually fontconfig-config has almost same settings. So I think we can remove this file. But, I'm not sure about Chinese and Japanese fontconfig hack.
[15:43] <pitti> jincreator: ok, thanks; is there a bug for the non-working locale selection with a fool-proof description how to test this?
[15:44] <kenvandine> mterry, do you have time for another easy MIR review?  another requirement for empathy, bug 898693
[15:44] <ubot2> Launchpad bug 898693 in telepathy-farstream "[MIR telepathy-farstream" [Low,New] https://launchpad.net/bugs/898693
[15:45] <mterry> kenvandine, sure
[15:45] <pitti> jincreator: please feel free to subscribe me to that (sorry, need to run now)
[15:45] <kenvandine> mterry, thx :)
[15:46] <jincreator> pitti: Sorry, I didn't see any more bug report about it at now. But if I find, I will subscribe you.
[15:46] <pitti> jincreator: thanks; or just create one, we can dupe it later
[15:46] <pitti> so, good night everyone!
[15:46] <kenvandine> pitti, can you look at the gnome-keyring SRU again?
[15:46] <kenvandine> pitti, nevermind :)
[15:46] <kenvandine> good night!
[15:46] <jincreator> pitti: Good night!
[15:50] <cyphermox> seb128: bkerensa expressed interest in desktop work, I don't know if he has shown up in here before, but I suggested he did
[15:51] <seb128> cyphermox, I don't think he did, or not while I was around
[15:51] <cyphermox> aye
[15:51] <seb128> 'night pitti
[15:52] <seb128> cyphermox, re. small things to work on, do you want to get some bugs assigned or do you prefer to focus on NM to get the workitems cleaned earlier in the cycle and do bugs later in the cycle?
[15:53] <seb128> cyphermox, we have nothing urgent but enough bugs to keep busy (and help on merges is welcome as well)
[15:53] <seb128> mterry, ^ same for you, help on merging,upgrading stuff on versions which are not green is welcome
[15:53] <cyphermox> guess I'll sprint on my WIs, it's all small ones so with some luck I can have a good head start in a week
[15:55] <cyphermox> also, updating NM and nm-applet in precise will already get rid of two red items ;)
[15:56] <seb128> cyphermox, seems like a plan, if you get bored or want to do something easy on the side do a few merges on free slots and that should already be good help for us ;-)
[15:56] <cyphermox> sure
[15:57] <seb128> cyphermox, speaking of n-m do you know what are the upstream plans for this cycle? do you plan to track a new version or to stay behind as we do for GNOME?
[15:57] <cyphermox> tonight is ubuntu hour, if nobody shows up I'll have plenty of time for merges
[15:57] <cyphermox> plan is to stay on 0.9, but I think upstream isn't going all that aggressively either
[15:58] <cyphermox> but there's so many goodies I'd like to have in.. zone support (firewalls, etc.), vlan, bonding, etc.
[15:58] <seb128> cyphermox, ok, I was mostly mentioning it to make sure you know that we will default to stay on GNOME 3.2, in case you planed to track a new n-m which might try to force us to pull new GNOME components we didn't plan to update
[15:59] <seb128> cyphermox, we will update the platform, i.e glib, gtk probably (we need to sort some details for gtk)
[15:59] <cyphermox> modemmanager will probably also get updating to the latest crack, but since nothing but NM touches it, it's safe
[15:59] <cyphermox> ok, I'll keep that in mind
[15:59] <cyphermox> so generally, gnome-control-center is the most sensitive I think
[16:00] <seb128> yeah, and one of the most annoying one as well, I think we will default to backport what we need from 3.4 for it
[16:00] <cyphermox> I also already fixed up daily builds, so I can know in advance
[16:03] <seb128> great
[16:03] <seb128> lool, hey
[16:04] <seb128> lool, do you know about dh-autoreconf?
[16:04] <seb128> lool, we moved from autoreconf patches to that for ~ 1.5 years ;-)
[16:05] <seb128> lool, I'm just mentioning it, in case you didn't know, it has dh and a cdbs integration, so it's usually one rules like to change,add and a build-depends on dh-autoreconf (and often one on gnome-common as well for GNOME stuff)
[17:09] <seb128> tedg, hi, do you know if bug #785852 is a bug in indicator-application or libappindicator?
[17:09] <ubot2> Launchpad bug 785852 in indicator-application "Menu reordering does not work" [Low,New] https://launchpad.net/bugs/785852
[17:10] <tedg> seb128, I'd be surprised that doesn't work.... but, if so, it's a bug in dbusmenu-gtk
[17:11] <seb128> tedg, well I can confirm that the example from the bug has the issue
[17:11] <seb128> tedg, i.e https://bugs.launchpad.net/ubuntu/+source/indicator-application/+bug/785852/+attachment/2136524/+files/bugtest.cpp
[17:11] <ubot2> Launchpad bug 785852 in indicator-application "Menu reordering does not work" [Low,New]
[17:11] <seb128> but maybe gtk_menu_reorder_child () is a weird way to do it :p
[17:12] <seb128> tedg, ok, reassigning there then
[17:13] <tedg> seb128, Hmm, it should work... I'm confused why it wouldn't.  A signal must be getting compressed somewhere.
[17:13] <tedg> It sends a remove and an add on reorder.
[17:15] <seb128> tedg, thanks, it seems like a good bug for mterry to look at if he's getting bored after his sponsoring today ;-)
[17:16] <seb128> mterry, ^ do you want to take on this one? dbusmenu issue, menu not getting the right order in the indicator after a reorder()
[17:16] <tedg> Heh, I loose sleep at night worrying that mterry might get bored ;-)
[17:16] <seb128> lol
[17:18] <mterry> seb128, i can look a bit today yeah
[17:19] <seb128> mterry, no need to be today, I will assign it to you, thanks ;-)
[17:19] <mterry> tedg, seb128: guys, you are thinking about this too much.  I've got aisleriot, I'm fine, really
[17:19] <seb128> lol
[17:20] <seb128> just give a deck of cards to mterry, that's all he needs to be happy ;-)
[17:21]  * desrt notes GNOME copying papercuts
[17:24] <kenvandine> papercuts was a good idea
[17:24] <desrt> indeed
[17:24] <desrt> good ideas deserve copying :)
[17:24] <desrt> (and refinement)
[17:24] <seb128> desrt, sure, GNOME always copy Ubuntu after a few years ;-)
[17:24] <desrt> seb128: papercuts was obviously a copy of gnome-love :p
[17:25] <desrt> mfisch: hey
[17:25] <HOHOHaney> where is the current list of gnome external dependencies?
[17:25] <seb128> desrt, virtuous cycle? ;-)
[17:25] <HOHOHaney> is libproxy on it?
[17:25] <mfisch> desrt: hey
[17:25] <desrt> seb128: i like to think so
[17:25] <desrt> mfisch: what are you doing around these parts?
[17:26] <desrt> oh god.  do you work for canonical now?
[17:26] <mfisch> desrt: well I work for canonical now and do some ubuntu on the side
[17:26] <mfisch> desrt: but
[17:26] <mfisch> desrt: I have no idea who you are ;)
[17:26] <desrt> ya.  you're a different mfisch than i thought you were :)
[17:27] <mfisch> desrt: well, nice to meet you anyway
[17:27]  * desrt knows a matthew fisch who is 'mfisch' on efnet
[17:27] <desrt> nice to meet you too :)
[17:28] <seb128> HOHOHaney, good question, glib-networking is using it so I guess it's on the external dependencies list
[17:28] <seb128> not sure where they keep that list nowadays though
[17:29] <seb128> desrt might know
[17:29] <desrt> jjardon is more likely to know
[17:29]  * desrt isn't really a GNOME guy
[17:32] <seb128> HOHOHaney, desrt: there is a "meebey" who just asked the same question on #gnome-hackers
[17:32] <seb128> so let's see if somebody reply there ;-)
[17:40] <jjardon> seb128: HOHOHaney yeah, Its a external dep
[17:41] <jjardon> http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-deps-3.4.modules#n869
[18:08] <didrocks> ok, time for dinner and some rest!
[18:08] <didrocks> see you tomorrow (and on Monday seb128)
[21:17] <kenvandine> tedg, did you know that dbusmenu-bench is broken?
[21:17] <kenvandine> looks like it missed getting updated when there was an API change
[21:18]  * kenvandine guesses people don't actually use it :)
[21:42] <lool> seb128: dh-autoreconf > I've seen it around, but didn't actually trust it TDTRT  :-)
[21:42] <lool> seb128: I had recently a case once where it seemed to break the build unless I avoided certain things, but anyway, I should give it a try; thanks for the pointer
[21:42] <seb128> lool, we use it pretty much across the board for desktop for over a year if that brings any extra confidence
[21:43] <lool> Ok
[21:43] <desrt> seb128: how does dh-autoreconf interact with maintainer mode?
[21:43] <desrt> makes it irrelevent i guess?
[21:43] <seb128> yeah, pretty much
[21:43] <desrt> i like it!
[21:44] <seb128> lol
[21:44] <lool> :-)
[21:44] <seb128> you rather hate maintainer mode
[21:44] <seb128> that's different ;-)
[21:44] <desrt> i hate distros telling me to set it one way or another :p
[21:44] <desrt> so anything that allows distros not to care is a friend to me
[21:45] <lool> sadly, needing all the autotools at build time kind of makes the whole design useless :-/
[21:45] <desrt> would also be really extra cool if i could remove 1MB of shell from the glib tarball
[21:46]  * desrt replaces ./configure with a script that echos "autotools muckerfucker.  do you have it?"
[21:46] <TheMuso> desrt: You may have seen my conversation earlier with seb128 about GTK 3.4, and possibly needing to extend the MenuItem API to help with some a11y dbusmenu work I'm doing. Do you have a few minutes to talk about it? THis extension would also benefit a11y for upstream network-manager applet for one.
[21:46] <lool> plus all the Makefile.ins
[21:46] <TheMuso> c/
[21:47] <desrt> TheMuso: thanks for mentioning about 4 things that i'm interested in within a single sentence
[21:47] <desrt> TheMuso: does this have to do with the 'accessibility role' attribute that gets set differently depending on which menuitem subclass you have?
[21:48] <TheMuso> desrt: No, it has to do with setting an alternative accessible name if there is extra informatino that the menu item icon is conveying to the user, the network-manager network list being a prime usecase.
[21:48] <TheMuso> I.e network name as the menu item label, icon as signal strength/security.
[21:48] <TheMuso> We need a way to convey that textually to Orca users etc.
[21:48] <desrt> it strikes me that this doesn't have a whole lot to do with dbusmenu
[21:49] <TheMuso> No it doesn't, but I need to extend Dbusmenu's API to work with whatever the final solution is in any case.
[21:49] <desrt> understood
[21:49] <desrt> do you have a proposal?
[21:49] <desrt> "dlink [Insecure, 91% signal]" sort of thing?
[21:50] <TheMuso> That is what the desired end result is, yes.
[21:50] <desrt> sounds like you want an alt="" tag for the image
[21:50] <TheMuso> Is that possible with a menu item icon?
[21:51] <desrt> no
[21:51] <desrt> not for any particular reason -- we just didn't think about it
[21:51] <TheMuso> Didn't think so, which is essnetially what I'm getting at with needing to extend GtkMenuItem.
[21:51] <desrt> why not open a bug against gtk about it?
[21:51] <TheMuso> Ok will do.
[21:52] <desrt> TheMuso: you could also pop into #gtk+ to discuss it
[21:53] <TheMuso> Actually, I'm on gimpnet, I might do that.