[03:25] <robert_ancell> RAOF, did I fail to do any convincing on the simple-scan SRU?
[03:28] <RAOF> I wasn't super-convinced.
[03:29] <RAOF> It was still big and ugly, and I ran out of activation energy for SRUs.
[03:29] <robert_ancell> yay for processes
[03:30] <RAOF> Yeah, sorry.
[03:31] <robert_ancell> it's not that big and ugly - it's really a 300 line vala change
[03:31] <robert_ancell> The .c stuff is just a distraction
[03:31] <RAOF> Hm. Time to check errors.ubuntu.com, I thikn.
[03:32] <robert_ancell> it wont show up there because it wont actually crash
[03:33] <RAOF> No, to see if there are any crashes reported in the new code.
[03:33] <robert_ancell> ah true
[03:33] <RAOF> Because that's in 14.04.
[03:34] <robert_ancell> yep
[03:35] <robert_ancell> I only see one crash
[03:35] <RAOF> And it's not in the new code.
[03:35] <RAOF> Of course, we don't have a denominator :/
[03:35] <robert_ancell> and it's a crash in the genesys driver. Which would be helped by an autosave ;)
[03:36] <robert_ancell> RAOF, how many people run -proposed? I suspect that would be a better litmus test than trusty
[03:38] <RAOF> Not *that* many run -proposed.
[03:38] <RAOF> But the lack of crashes in trusty is somewhat reassuring.
[03:42] <RAOF> robert_ancell: Enjoy your meal
[03:42] <robert_ancell> RAOF, aw yeah :)
[06:15] <ritz> morning
[06:16] <ritz> hi, I see https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1051921 as fix committed
[06:16] <ubot2> Launchpad bug 1051921 in Unity 5.0 "lens-bar-keynavigation periodically writes to /tmp/wut.png" [Medium,Fix committed]
[06:16] <ritz> I dont see this anywhere
[06:17] <ritz> nearest thing, I do see https://launchpad.net/unity/+milestone/5.26.0
[06:22] <pitti> Good morningt
[06:23] <Mirv> ritz: it's indeed fix committed, ie. it's int he code branch but it's not released yet. the latest tested and released fix was the July's bug nr. 1195730 fix
[06:23] <Mirv> ritz: I don't unfortunately know when the next 12.04 unity update planned
[06:24] <ritz> hmm, thanks
[06:24] <ritz> where is the branch code, I am unable to locate this bit
[06:24] <Mirv> ritz: https://code.launchpad.net/~unity-team/unity/5.0
[06:27] <ritz> Mirv thanks , found it proposed with a different bug
[06:28] <ritz> which was rejected
[06:28] <ritz> hmmm
[06:33] <Mirv> ok right, but it's there anyhow at the ocmmit 2423. what I do know is that the XIM commits there are a topic of discussion, and I don't know how it has progressed, ie. should they be included or not in the next update.
[08:49] <seb128> good morning desktopers
[08:54] <mlankhorst> Hello, world!\n
[08:56] <didrocks> salut seb128, ça va?
[08:57] <seb128> didrocks, lut, ouais, et toi ?
[08:57] <didrocks> ça va bien :)
[09:04] <Laney> morning chaps and chapettes
[09:08] <seb128> hey Laney
[09:08] <seb128> how are you?
[09:10] <Laney> good thank you, went back to see my parents at the weekend which was nice
[09:10] <Laney> you?
[09:11] <seb128> I'm good thanks
[09:11] <seb128> I had a nice relaxing w.e without too much omputer
[09:11] <seb128> computer even
[09:11] <seb128> and I'm happy that vUDS is over, I might be able to get some work done this week :p
[09:12] <Laney> haha
[09:13] <Laney> that'd be good :P
[09:13] <seb128> though the week start with arguing/discussions with some of the GNOME guys
[09:13] <seb128> going to be fun
[09:15] <mlankhorst> the heater here is burning through some plastic seal, so I can choose stench or cold. :/
[09:16] <Laney> arguing?
[09:16] <Laney> actually, maybe I don't need to know ...
[09:16] <Laney> mlankhorst: moar jumpers
[09:16]  * mlankhorst wrapped himself in blankets
[09:17] <seb128> Laney, I opened some bugs about "would be nice to have a standard menubar and display it in non gnome-shell environments"
[09:17] <Laney> oh, those ...
[09:17] <seb128> Laney, which some upstream took well, the file-roller guy even commited a patch friday to do it
[09:17] <Laney> yeah that's to be expected a little bit
[09:17] <seb128> but some of the others guy came with "that's not the GNOME design, we don't care about non shell environments"
[09:18] <Laney> I thought someone had discussed it upstream
[09:18] <mlankhorst> of course they don't :s
[09:18] <mlankhorst> but that's no ground to veto
[09:20] <Laney> xnox: neat, thanks for thunderbird
[09:20] <Laney> you checked it doesn't need any changes?
[09:21]  * seb128 bets he didn't
[09:21] <seb128> chris seemed to think there would be changes needed
[09:22] <xnox> Laney: the dependency is a bit artificial, it doesn't link against eds.... And well thunderbird needs .1 upload. Plus the dependencies need better detection. as there is now 3 types: precise, quantal - saucy, trusty+
[09:22] <xnox> yeah, i was expecting chris to change it "properly".
[09:22]  * xnox is just pushing for libav transition, it was down to a handful of packages over the weekend.
[09:22] <seb128> xnox, it dlopens it I think
[09:23] <xnox> hm.
[09:27] <Laney> I think it only dlopens ebook directly
[09:27] <Laney> which didn't actually change abi
[09:28] <Laney> nope, I lie
[09:28] <Laney> debian/eds/res/libs/eds.jsm
[09:50] <xnox> that i did not spot.
[13:15] <mdeslaur> seb128: who can I subscribe to bug 1253532?
[13:15] <ubot2> Launchpad bug 1253532 in unity-greeter (Ubuntu) "Clicking Time and selecting top menu item (current date) launches evolution configuration wizard" [Undecided,New] https://launchpad.net/bugs/1253532
[13:16] <seb128> mdeslaur, http://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.10/revision/282
[13:16] <seb128> bug #1246812
[13:16] <ubot2> Launchpad bug 1246812 in indicator-datetime (Ubuntu Trusty) "Can open Evolution in greeter mode" [Undecided,New] https://launchpad.net/bugs/1246812
[13:16] <seb128> mdeslaur, ^ you want that fix
[13:16] <mdeslaur> seb128: oh cool, thanks
[13:16] <seb128> mdeslaur, yw
[13:17] <seb128> we should have SRUed it when we landed the commit
[14:26] <attente> seb128, hey
[14:27] <seb128> attente, hey, how are you?
[14:27] <attente> good good, and you?
[14:29] <seb128> I'm good thanks
[14:30] <attente> seb128, what are your thoughts about ibus vs fcitx for the lts?
[14:31] <seb128> attente, ibus is not problematic enough that I would consider switching it, for a solution we have no user feedback on, during the lts cycle
[14:31] <seb128> attente, what do you think?
[14:33] <seb128> attente, it would be nice to make replacing our stuff by fcitx as easy as possible though, since that's what Kylin is doing ...
[14:33] <seb128> attente, also if Chinese users prefer fcitx and get it through Kylin, that works for us and for them
[14:35] <attente> happyaron said it might not be too much work to switch to fcitx, but i have a couple of concerns about how that works regarding ibus on gnome-shell and fcitx on unity
[14:38] <attente> like what happens to the region panel under gnome-shell if fcitx is enabled
[14:38] <seb128> attente, well, switching might not be too much work, but we have almost no feedback on it from non Chinese users, I think it's fine for Kylin but we should stay on what we know (ibus) for the LTS on the Ubuntu side
[14:39] <seb128> attente, what happens under gnome-shell is a GNOME issue, I guess that session should force ibus since GNOME doesn't support/intend to support other frameworks
[14:41] <attente> seb128, ok, i guess it isn't an issue either if we default with ibus either
[14:42] <seb128> attente, you think it would be better to have a look at changing before the LTS?
[14:42] <attente> seb128, possibly, but you're right that we don't have enough feedback from non-cjk users about if this works for them or not
[14:43] <popey> xnox: guessing bug 1254742 is well known, but I couldn't find a bug for it
[14:43] <ubot2> Launchpad bug 1254742 in ubiquity (Ubuntu) "Can't login to Ubuntu One during installation due to 2-factor auth requirement" [Undecided,New] https://launchpad.net/bugs/1254742
[14:43] <seb128> attente, that and we have issues, like brandon said that fcitx is supported through xim for unity and that it leads to windows placement issues with the dash for example
[14:44] <xnox> popey: yes, "2fa" is not supported.
[14:45] <xnox> popey: can you check, that e.g. 2fa is required to actually add/sync UbuntuOne panel? I think it somehow connected without 2fa, but I haven't verified since.
[14:45] <attente> seb128, ok, you've got me sufficiently worried enough...
[14:46] <seb128> lol
[14:47] <seb128> attente, no need to worry there, our stuff works (mostly) and fcitx is available for those who prefer it ...
[14:48] <seb128> attente, speaking about our stuff, how do we get about uploading was is in your ppa to the archive?
[14:48] <attente> seb128, sure. i know they were pushing pretty hard for fcitx in the lts
[14:48] <seb128> attente, I guess we need to sync unity/g-s-d changes?
[14:49] <seb128> attente, well, Kylin defaults to fcitx which I guess is going to be good enough...
[14:49] <popey> xnox: sure
[14:50] <attente> seb128, i need to get the compiz changes in first, then we can do unity and g-s-d
[14:50] <seb128> attente, the compiz changes are not going to create any conflict if they land without the other bits?
[14:50] <attente> seb128, the compiz changes strictly are adding functionality that is currently not used as far as i can tell
[14:50] <popey> xnox: it doesn't need 2fa. I loggedin via the panel and it used user/pass and no 2fa. I can see my cloud files in the control panel thing
[14:51] <seb128> attente, ok, great, let's start by that then ;-)
[14:51] <seb128> attente, can you merge propose those this week?
[14:51] <attente> seb128, i already did last week, but need to test some stuff and get back to them
[14:51] <seb128> ok
[14:54] <xnox> popey: right, i'd like that to be raised with u1 devs than. Because either it should then work for ubiquity as well, or 2fa should be mandatory in the panel.
[14:54] <xnox> popey: thanks for the test.
[15:03] <seb128> bregma, Trevinho: do you guys have an opinion on https://bugs.launchpad.net/ubuntu/+source/gnome-control-center-unity/+bug/1168409 ?
[15:03] <ubot2> Launchpad bug 1168409 in gnome-control-center-unity (Ubuntu) "Min slider value for launcher icon size needs to be updated" [Low,In progress]
[15:03] <seb128> bregma, Trevinho: cf my comment there, we can update the GUI to go down to 8 but the launcher has some bugs then (e.g the badges don't scale as they should)
[15:09] <bregma> seb128, I find anything below about 18 unusable, so I would have no problem setting the minimum at something like 12 to prevent scaling bugs
[15:10] <bregma> there's also a bug somewhere about how odd sizes (23, 25, etc) cause aliasing on the icon corners
[15:11] <seb128> is that a request to make the slider only go on even values? ;-)
[15:11] <bregma> I've though about it, I'm not sure if that would just call for bugs about not being able to set odd values
[15:12] <seb128> I doubt that would really annoy any users
[15:12] <seb128> they mostly want to set a size that fits their screen
[15:12] <cyphermox> seb128: so, you know that indicators are blocked by the libav transition? this is making indicator-datetime not installable because of evolution-data-server that didn't migrate from proposed yet
[15:12] <seb128> they probably don't care about 1 pixel precision
[15:12] <cyphermox> seb128: I've tested it all and it works, and I'd publish now and work on libav next
[15:13] <seb128> cyphermox, hey, I don't know about the "not installable" part ... why is that?
[15:13] <cyphermox> indicator-datetime needs libecal
[15:13] <seb128> cyphermox, #ubuntu-release is working on libav, maybe check with them
[15:13] <cyphermox> ok
[15:13] <seb128> cyphermox, well, everything should be in trusty-proposed
[15:13] <cyphermox> yeah, It will be in a minute when I press the button :)
[15:13] <seb128> or did we get e-d-s to migrate without indicators? (how could that happen)?
[15:14] <seb128> cyphermox, oh, https://launchpad.net/ubuntu/+source/indicator-datetime/13.10.0+13.10.20131023.2-0ubuntu2
[15:14] <cyphermox> no
[15:14] <Laney> you are about to publish one built against the release pocket?
[15:14] <cyphermox> no
[15:14] <Laney> why are we guessing?
[15:15] <Laney> also, canvas api :(
[15:15] <seb128> you are sure? ;-) (I though daily builds were not using proposed)
[15:15] <seb128> Laney, canvas api?
[15:15] <cyphermox> I'm sure, i-d is using the new libecal
[15:15] <Laney> charge graph
[15:15] <cyphermox> otherwise it would be installable from the PPA
[15:15] <Laney> trying to do smooth lines
[15:15] <seb128> Laney, what are you ... oh, ok
[15:15] <seb128> cyphermox, the ppa is not using trusty-proposed?
[15:16] <Laney> http://www.codeproject.com/Tips/562175/Draw-Smooth-Line-through-points-with-HTML5-Canvas
[15:16] <Laney> like this thing
[15:16] <cyphermox> seb128: it is, but that doesn't mean the packages from proposed get added to your sources when you add the ppa
[15:17] <seb128> cyphermox, I see ... anyway, we need to finish that transition indeed
[15:17] <cyphermox> yes, that was my point :)
[15:17] <Laney> I wouldn't call that uninstallable
[15:17] <seb128> cyphermox, not sure how much is missing, xnox was trying to finish it over the w.e apparently
[15:17] <cyphermox> Laney: as things are, indicator-datetime is not installable from the PPA -- that tells me stuff's broken
[15:18] <seb128> the ppa setup is broken yeah
[15:18] <cyphermox> no
[15:18] <Laney> if your PPA is using proposed then you need to use proposed to guarantee to be able to install stuff from it
[15:18] <cyphermox> PPAs are working as they should
[15:18] <Laney> it's not broken
[15:18] <seb128> right
[15:19] <cyphermox> what I mean is, I'm not going to enable proposed on my system. what this allows me to say is that packages would be blocked in proposed, that's it
[15:19] <Laney> anyway, seems there are a few packages left for the transition
[15:19] <Laney> fgrun, kmediafactory, kx11grab, mytharchive, octave-psychtoolbox-3, psychtoolbox-3-dbg
[15:19] <xnox> seb128: "* i386: fgrun, kmediafactory, kx11grab, mytharchive, mythplugins, octave-psychtoolbox-3, psychtoolbox-3-dbg, samba4, samba4-clients, samba4-common-bin, samba4-testsuite, winbind4"
[15:19] <cyphermox> yeah
[15:20] <cyphermox> I have an idea about those, I had already started looking into it
[15:20] <seb128> great
[15:20] <xnox> seb128: which is actually "remove fgrun, kmediafactory, kx11grab, fix mythtv & octave-psychtoolbox & server team to provide compat/dummy/transitional packages"
[15:20] <Laney> remove?
[15:21] <xnox> Laney: fgrun/kmediafactory/kx11grab are dead upstream, not ported to libav9, non-trivial to port, leave packages, low usage.
[15:21]  * seb128 is not starting the remove discussion again today
[15:21] <Laney> haha
[15:21] <Laney> you saw where I was going to go
[15:21] <seb128> ;-)
[15:21] <xnox> Laney: unless you want to port them to libav9 =) there were already a few removals / demotions done from trusty to trusty-proposed as part of this transition.
[15:22] <Laney> no, I was going to refer to something else
[15:22] <Laney> doesn't matter
[15:22] <xnox> ah, ok.
[15:25] <Laney> forgot to have lunch
[15:25] <Laney> brb
[16:34] <kenvandine> seb128, who was going to work on getting uss to run out of a source checkout?
[16:35] <seb128> kenvandine, you?
[16:35]  * kenvandine wants to know who to bribe to get that done sooner ;)
[16:35] <kenvandine> ha
[16:35]  * seb128 tries that trick :p
[16:35] <kenvandine> i don't remember it that way :)
[16:35] <kenvandine> i thought larsu maybe
[16:35] <seb128> haha
[16:35] <kenvandine> somebody volunteered in OAK :)
[16:35] <seb128> I said I would talk to mardy about it
[16:36] <kenvandine> ah
[16:36] <seb128> thanks for the reminder
[16:36] <kenvandine> :)
[16:36] <seb128> I was planning to resume settings work this week
[16:36] <kenvandine> it really is soooo frustrating
[16:36] <seb128> I'm going to have a look to that tomorrow
[16:36] <kenvandine> i'm working on the background panel
[16:36] <seb128> yeah, it's annoying
[16:36] <seb128> hint, symlink from the system location to your builddir :p
[16:37] <happyaron> attente: do you think we still need a plan as discussed last Sat?
[16:37] <kenvandine> oh... that's evil... but worth it :)
[16:37] <Laney> I usually comment it out then copy stuff around if I can't be bothered to build :(
[16:37] <Laney> that or edit the installed files
[16:37] <Laney> pretty bad
[16:37] <kenvandine> i keep copying the qml files
[16:37] <kenvandine> which i hate
[16:37] <seb128> yeah, I usually have a "make; sudo cp ...; system-settings <name>" command line
[16:38] <seb128> and I keep doing "<up> <enter>"
[16:38] <attente> happyaron, i asked seb128 about it a bit earlier today
[16:38] <seb128> but that sucks
[16:38] <attente> happyaron, for the most part, i think we're still pretty hesitant to switch to fcitx for the lts
[16:38] <happyaron> attente: I read that just now
[16:39] <attente> happyaron, what are your thoughts?
[16:39] <seb128> happyaron, I though the vUDS consensus was that after LTS would be good enough/that changing in the middle of a LTS cycle was a bit crazy
[16:39] <seb128> ?
[16:39] <happyaron> we'll need a plan either for 1) keep ibus 2) switch to fcitx.
[16:40] <seb128> well, we said during vUDS that we shape details for 1) for the LTS and have another session
[16:41] <happyaron> seb128: I understand, but I cannot come up with a reasonably complete plan for keeping ibus, at the point of a everyday user of input method
[16:41] <happyaron> so I had some more discussions with attente.
[16:41] <seb128> what's wrong with ibus?
[16:43] <happyaron> the drawbacks that we went over at vUDS, and that make it quite not convenient to use, :)
[16:44] <happyaron> stability and code quality is another issue, but yeah, usability under Ubuntu/Unity is also a question.
[16:45] <attente> happyaron, most chinese users will be using kylin though, right?
[16:45] <happyaron> attente: no
[16:45] <happyaron> attente: better say most OEM products.
[16:47] <happyaron> Kylin is still too young, and of course too new for Chinese users.
[16:48] <seb128> that topic makes me want to bang my head again the desk :-(
[16:48] <happyaron> :-(
[16:48] <attente> :(
[16:48] <seb128> fcitx makes me really nervous
[16:49] <happyaron> understand
[16:49] <seb128> would it only be because it's maintained by some students, where ibus is maintained by people at RedHat and Google
[16:49] <seb128> no offense to anyone
[16:49] <seb128> but one of those groups gives more confidences in available resources to move the project forward
[16:50] <seb128> then, we don't have any real feedback from fcitx users, especially non Chinese users
[16:50] <seb128> and we learnt in 13.10 that assuming than things are working good enough is not something we can do
[16:51] <happyaron> do you think the maintenance of ibus done by RH and Google is really decent for non-RH or non-Google products, ;-)
[16:52] <seb128> well, they probably care about the quality of the framework and the engines
[16:52] <seb128> even if they have different UI
[16:52] <happyaron> most engines are maintained by thrid-party, though...
[16:52] <seb128> sorry to go again over that
[16:53] <happyaron> but yes I fully understand your concerns.
[16:53] <seb128> but what do you see as the current main blocker with our ibus solution?
[16:53] <seb128> blockers*
[16:54] <happyaron> maintainability
[16:54] <happyaron> and of course plus features, which you may care less, though.
[16:56] <happyaron> ibus is sure maintained by RH/Google, and it's serving their products well, but we are in a possition to adapt to their big/small changes all the time, and we have little to do to influence it.
[16:57] <seb128> right
[16:57] <seb128> the issue is that fcitx probably needs some work
[16:57] <seb128> we need some direction and to put resources on it to shape it in the way we want
[16:57] <seb128> that's not going to happen before the LTS though, those things take time
[16:58] <seb128> but that's a bit orthogonal
[16:58] <seb128> let's say we release trusty today, with attente's ppa (which fixes some of the grabbing issues we still have)
[16:58] <attente> even if we did it, we don't really know how it'll pan out for non-cjk
[16:58] <seb128> what would be the experience like for a Chinese user
[16:58] <happyaron> to be rude but sincere, ibus in 13.10 doesn't really work for cjk, though it may work for non-cjk.
[16:58] <seb128> if the response is "not good", can you give specific of what is the most frustrating
[16:59] <seb128> what doesn't work?
[16:59] <seb128> I've added qwerty/pinyin to my indicator
[16:59] <attente> i'm a bit curious too... because i've been using ibus just fine
[16:59] <seb128> and I can cycle between french and it without issue
[16:59] <attente> 大家好！
[16:59] <seb128> I'm sure I'm overlooking what it means to be a cjk user
[16:59] <seb128> but I want to understand
[17:00] <attente> i understand that fcitx adds a lot more features, but i don't see how it makes ibus unusable tbh
[17:01] <attente> (i guess i'm using it really superficially though)
[17:01] <happyaron> it's crashing (fixable), its shortcut does not work (fixable), it does not support per-window context (not going to work in 1.5), shortcuts aren't comfortable (upstream decision). So that able to type characters doesn't mean it work. It's technically working, but just like you won't bear it when you have a hard-to-use keyboard...
[17:02] <seb128> right
[17:02] <seb128> hum
[17:02] <seb128> per-window context should be working in Unity
[17:02] <seb128> indicator-keyboard is doing it, it's working for me
[17:02] <happyaron> ok
[17:02] <seb128> the conflict/non reliability are issues that should be fixed in trusty with attente's ppa
[17:03] <seb128> compiz is doing the grabbing in a reliable way there
[17:03] <seb128> what do you mean "shortcuts aren't comfortable"
[17:03] <seb128> is that the shortcut to cycle?
[17:03] <attente> seb128, i think happyaron meant that some extra settings reset between windows, even if the input source does switch properly
[17:03] <seb128> that's an user setting and we can change the default
[17:04] <kenvandine> i really dislike the GridView
[17:04] <kenvandine> so hard to work with...
[17:04] <kenvandine> in theory it should make things easier
[17:04] <seb128> kenvandine, it's nice when you have a simple case/a model to throw at it
[17:05] <kenvandine> i've never had any success with it
[17:05] <kenvandine> things end up awkward and hacky...
[17:07] <happyaron> seb128: well, makes me feel a bit difficult to describe, but hell, if it's that is easy to understand by non-cjk user then it won't be so much complicated.
[17:09] <seb128> happyaron, well, the bottom line is that "we try to not do such changes in the cycle before a LTS", so I'm trying to see what way out/option we have
[17:10]  * happyaron would use a longer story to describe. 
[17:11] <attente> we have to fix some things related to shortcuts with fcitx too just for the record
[17:12] <happyaron> people here (assume non-cjk and/or not using IME for critical work) may think an IME is working means: does not crash, shortcut works, characters popups to text entries correctly.
[17:12] <happyaron> am I correct?
[17:13] <seb128> no
[17:13] <happyaron> then add you opinion, :)
[17:13] <seb128> working is = good enough that people relying on the feature can do their work without too much frustration
[17:14] <seb128> e.g that's where we need to be for the LTS
[17:14] <seb128> I'm trying to figure out if we can bridge the gap with ibus to be there
[17:14] <seb128> or if there is some flaws that we feel like we can't address
[17:14] <happyaron> so what's the standard of "can do their work without too much frustration"?
[17:14] <seb128> but to answer that question we need a list of the issues
[17:14] <seb128> so we can go one by one and see what options we have and how much work they are
[17:15] <seb128> there is no "standard"
[17:15] <seb128> you are the team member that has the most experience about using a IME
[17:15] <seb128> so we need you to make that list of issues
[17:16] <seb128> so we can have a pragmatic look at how much work would "fixing ibus to be good enough" involve
[17:16] <seb128> and how much work is "switching to fcitx"
[17:16] <happyaron> I once though about letting you guys try out some IME on Windows... and MS-provided input method has all the features available on ibus - but very few people are using it.
[17:17] <attente> what if we did the work concurrently, try to polish what we have right now as best we can, and do the migration work to fcitx in a separate ppa?
[17:17] <happyaron> it's really a long research project to answer this question, which cost Sogou spend years of hundreds engineers to do.
[17:17] <attente> that way we know we can always fall back onto ibus
[17:17] <happyaron> I agree with such a solution.
[17:18] <attente> at some point, if we can get some user testing of the ppa by non-cjk users, we might be in a better position to know if we should outright switch to it or not
[17:18] <happyaron> seb128: and I was talking with attente to create a plan like you want, while I come here and see that you told him your tension of switching, :)
[17:19] <jasoncwarner_> happyaron seb128 it seems the most prudent LTS solution would be to not switch inputs at this time for ubuntu. Kylin could, though. Then we could look at switching inputs in 14.10? and in the mean time use the PPA approach that attente suggests (or some other type of mechanism like that)
[17:19] <seb128> happyaron, yeah, we should try to have team discussions there rather than 1-1 discussions between people
[17:20] <seb128> happyaron, jasoncwarner_: do we have any user testing data on IME with ibus and/or fcitx?
[17:21] <happyaron> seb128: only available one I know is from Kylin people, they did quite a bit research (but informal comparing to design team's ones) to decide to divert from us.
[17:22] <seb128> attente, happyaron, I've to go in 10 minutes, but +1 on a "migration ppa" to see how that goes
[17:22] <seb128> we also need a list of issues with fcitx that needs to be resolved
[17:23] <seb128> like the dash using xim which leads to incorrect UI placement from fcitx
[17:23] <happyaron> jasoncwarner_: I agree with the PPA approach, and understand from risk management it's better to stay with ibus for LTS, so that's the starting line and we would need to more research...
[17:23] <happyaron> seb128: so I think we'll need create two plans, 1) continue with ibus 2) switch to fcitx
[17:25] <happyaron> that'd better help us understand the swot of both choices. I can do that with attente, do you think it's worth doing?
[17:25] <happyaron> seb128 jasoncwarner_ ^
[17:25] <sil2100> seb128: hi! You leaving soon for today? :)
[17:26] <attente> happyaron, count me in :)
[17:27] <seb128> sil2100, hey, yes, I've sport on monday nights now
[17:27] <sil2100> seb128: ah, then nevermind! Have fun! I have a package that needs a preNEW review, but it can be done later when you have more time - I'll send you the info by e-mail, would be grateful ;)
[17:28] <seb128> sil2100, sure, thanks
[17:29] <seb128> happyaron, attente: +1 for the ppa, but we need a list of known problems for both solutions so we can work our way down those
[17:30] <happyaron> then I'll start doing the homework
[17:30] <attente> seb128, ok
[17:30]  * happyaron and won't forget to pull in attente, ;-)
[17:31] <attente> happyaron, it's pretty late for you right now, right?
[17:31] <happyaron> yup...
[17:32] <seb128> attente, happyaron: let's talk a bit about that again tomorrow during the team meeting (or before/after)
[17:32] <attente> sure
[17:32] <happyaron> ok
[17:32] <attente> happyaron, let's start a google doc listing the issues that need to be fixed on both sides
[17:33] <seb128> sounds good
[17:33] <attente> happyaron, or we can use the one you started for the uds session
[17:33] <happyaron> attente: I prefer creating another one, and copy&paste if necessary
[17:33] <attente> happyaron, ok
[18:15] <gsedej> Hi! I have question about "non-native" resolutions in xrandr
[18:15] <gsedej> I wish xrandr/ubuntu screen manager aplication add more availible resolutions
[18:15] <gsedej> is here good place to ask?
[18:20] <sarnold> gsedej: O
[18:21] <sarnold> gsedej: I'm certainly no expert, but I believe both those tools simply report the values that the monitor's edid supports that are within the capabilities of the video card.. see some more information here: http://en.wikipedia.org/wiki/Extended_display_identification_data
[18:24] <gsedej> sarnold, problem is if you wish to connect typical 1366x768 laptop to HD display
[18:26] <gsedej> HD monitors usualy dont have 1366x768 option
[18:27] <gsedej> but it works if you do "xrandr --addmode 1366....
[18:27] <sarnold> gsedej: and you've got a display where that works? I didn't expcet that..
[18:28] <gsedej> http://pastebin.com/ea8H9ZFY
[18:28] <gsedej> yes, it works