[08:18] <vila> goood morning all !
[08:18]  * vila facepalms, wrong channel ;) 
[08:30] <tsdgeos> Saviq: do you run proposed?
[08:30] <tsdgeos> Mirv: do the Qt 5.5 packages contain the debian/patches/add_qdeclarative_playlist.patch patch?
[08:37] <Mirv> tsdgeos: yes, although only to the extent it has been upstreamed. I'm waiting for the approvals in upstream for the rest.
[08:38] <Mirv> so eg moveItem is missing
[08:39] <tsdgeos> Mirv: Saviq was complaining that he didn't get Playlist for example :S
[08:40] <Mirv> tsdgeos: it should be no worse than Qt 5.4 on xenial, since there was no landing of the latest features in xenial anyway
[08:40] <Mirv> tsdgeos: so the patch is now this upstream http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/tree/debian/patches/Added-new-playlist-QML-type.patch?h=ubuntu from August
[08:41] <Mirv> tsdgeos: I think though that because the media-hub etc haven't landed on xenial in a long time, the QML Playlist patch is "too new" as media-hub would possibly be using the obsolete API features (also gone from vivid-overlay now)
[08:41] <Mirv> vivid-overlay is where Jim has switched to the approved upstream API + additions he's upstreaming, while xenial is stuck with the legacy API since there has been no landing
[08:42] <tsdgeos> that's bad
[08:43] <tsdgeos> we're supposed to be able to develop on xenial
[08:43] <seb128> things are not supposed to not land in the current serie
[08:44] <seb128> the packages from the ppa should be copied over to xenial
[08:47] <Mirv> tsdgeos: yeah, there was no good options since xenial is outdated anyhow. now that the silo 009 finally landed to vivid-overlay, I think you could ask Jim to handle xenial next
[08:48] <tsdgeos> Mirv: also the imports are different
[08:48] <tsdgeos> vivid+overlay package exports the new classes as part of 5.4
[08:48] <tsdgeos> and the xenial as 5.6
[08:48] <tsdgeos> not nice either
[08:48] <tsdgeos> or at least http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/tree/debian/patches/Added-new-playlist-QML-type.patch?h=ubuntu does
[08:48] <Mirv> tsdgeos: ok, I don't know about what has been landed in vivid+overlay, I've just tried to push very hard for upstreaming to avoid similar problems that we had with audio role
[08:49] <tsdgeos> not sure what xenial does
[08:49] <Mirv> tsdgeos: the git is what's now in xenial (and in upstream)
[08:49] <tsdgeos> yes but if we start lying the version the code was introduced in a distro patch
[08:49] <Mirv> tsdgeos: two weeks ago I diff:d the vivid+overlay landing and asked for upstreaming the remaining features that were neither in xenial Qt 5.4 nor in upstream
[08:50] <tsdgeos> we can't change that version in the next release
[08:50] <tsdgeos> and pretend we never introduce the feature earlier
[08:50] <tsdgeos> how am i again supposed to maintain compatibility if the things under me change
[08:50] <Mirv> tsdgeos: can you file a bug and assign that to Jim? I try to help where I can, but he needs to know what is still to-do.
[08:51] <Mirv> he's now done a good job switching vivid-overlay to "almost upstream", but xenial is totally unworked currently
[08:56] <Mirv> for any next new multimedia feature, it'd be nice to revert the current landing process "1. vivid-overlay, 2. xenial, 3. upstream (rejected)" to "1. upstream (accept), 2. xenial, 3. vivid-overlay" as it should be.
[08:57] <Mirv> the former happened with audio overlay and also with playlist except that we're still stuck in the point "1." partially
[08:57] <Mirv> audio role, I mean
[08:59] <Mirv> tsdgeos: if you want me to do something with the existing options, the choices are current near-upstream API but media-hub have not seen xenial landings, or the now obsolete API that is compatible with what's in xenial but incompatible with vivid-overlay. the latter is what was there before the Qt 5.5 landing.
[09:00] <tsdgeos> Mirv: i'll open a bug and see how we can proceed with this mess :/
[09:00] <Saviq> tsdgeos, no, I installed silos 12 + 59 (which is ~equivalent to running proposed today)
[09:00]  * Saviq reads uo
[09:00] <Saviq> *up
[09:01] <Mirv> tsdgeos: thanks
[09:02] <tsdgeos> Saviq: you installed those silos on phone or pc?
[09:02] <tsdgeos> don't think it matters i guess
[09:03] <Saviq> tsdgeos, both
[09:03] <Saviq> ok so we're fooked, can't land inline audio anyway
[09:03] <Saviq> grrr
[09:05] <Saviq> tsdgeos, you filing a bug?
[09:05] <tsdgeos> yeah i will
[09:05] <Saviq> tsdgeos, ok, let me know I'll escalate
[09:10] <tsdgeos> Saviq: will take a bit want to flash the phone and check a few things first
[09:12] <Saviq> ack
[09:21] <deenlee> o_O
[09:45] <tsdgeos> Saviq: does the bug description make sense to you? https://bugs.launchpad.net/ubuntu/+source/qtmultimedia-opensource-src/+bug/1523407
[09:57] <Saviq> tsdgeos, while the description makes sense, I wonder what would the correct solution be... I've a feeling when we're backporting features from future, we should only export them at the version it's ultimately going to land at... otherwise we'll have to carry a patch forever, exporting at more than one version
[09:59] <tsdgeos> hmm
[10:00] <tsdgeos> yeah, that's what probably makes more sense, i agree
[10:00] <tsdgeos> Saviq: want me to assign that bug to Jim?
[10:00] <Saviq> tsdgeos, I'll take care
[10:00] <tsdgeos> oki
[10:01] <Saviq> Mirv, what do you think ↑↑?
[10:02] <tsdgeos> mzanetti: Saviq: need your input in https://code.launchpad.net/~aacid/unity8/drag_with_quicklist/+merge/279420 as what you think the scope of the MR is
[10:03] <Saviq> tsdgeos, yeah fine with me, was wondering that myself
[10:04] <mzanetti> need to test it to see the issue
[10:04] <Saviq> mzanetti, it's just that there's no fade-{out,in} of the two quicklists
[10:05] <mzanetti> ah ok...
[10:05] <mzanetti> don't touch that yet
[10:05] <mzanetti> the quicklist will get new visuals
[10:05] <mzanetti> tsdgeos, ^
[10:05] <tsdgeos> k
[10:14] <Saviq> tsdgeos, in that case I'm moving all the audio-card-unrelated MPs into silo 22 and give silo 4 back to Paweł
[10:15] <tsdgeos> ok
[10:15] <tsdgeos> we were so close :/
[10:17] <Mirv> Saviq: I'm not sure with regards to the declared versions - was tsdgeos' async image loading feature done in any better way? I mean, what happens with that when we hit 5.6 proper.
[10:17] <Saviq> Mirv, you drop the patch
[10:17] <Saviq> Mirv, and everything Just Works
[10:17] <Saviq> Mirv, assuming the backport is actually API-compatible with upstream, which your "upstream first" approach should ensure, right?
[10:18] <Saviq> Mirv, ultimately, all's fine when we do this with "private" APIs that we can control the use of
[10:20] <Mirv> Saviq: yes the async image loading was certainly backported only after tsdgeos had upstreamed it. I just was asking if there's anything from there for Jim to learn, how to handle the backports from 5.6/5.7.
[10:20] <Mirv> the current qtmultimedia proposals Jim is trying to get upstreamed will go to Qt 5.7 so we will live with backports for a while.  https://codereview.qt-project.org/#/q/project:qt/qtmultimedia,n,z
[10:26] <Saviq> Mirv, I *think* the async image providers were kinda different in that they're not directly used by apps usually
[10:26] <Saviq> Mirv, so we get the dpkg dependency chain we want
[10:26] <tsdgeos> yeah it's not even exported to QML
[10:26] <tsdgeos> so it's indeed a bit different in that regard
[10:27] <Saviq> well, that doesn't mean they can't compile against it, but yeah, more care is needed anyway
[10:27] <Saviq> for anything that's exposed to apps, public API that we want to commit to, we need to have a plan going forward
[10:40] <Mirv> Saviq: right, so these multimedia feature are probably the only ones we've contributed as really new public facing features
[10:41] <Saviq> Mirv, the other one comes to mind are multimedia roles
[10:42] <Saviq> Mirv, while not meant for public consumption on our platform, still it's API we've published
[10:42] <Saviq> and had to do #ifdefs and other hutzpahs around
[10:42] <Mirv> Saviq: I missed one "s" but I meant these multimedia features, audio roles and playlist
[10:44] <Mirv> Saviq: which is why I said that the next multimedia feature would be nice on the track of 1. upstream (accepted) 2. xenial 3. vivid-overlay - but even with that there would need to be a plan on how to handle the actual backport, the core of the tsdgeos's bug.
[10:45] <Saviq> Mirv, agreed, and we seem to agree that this should be exported into QML as the version it will end up on in the long run
[10:45] <Saviq> Mirv, only way we can drop the patch after we get to that version, 'innit? otherwise we'd need to keep a patch porting it back to 5.4/5.5 or whatnot
[10:46] <Mirv> Saviq: yes, your comment #1 in that bug is correct
[11:37] <cimi> tsdgeos, do we have a silo with all filters?
[11:37] <tsdgeos> cimi: yes
[11:37] <tsdgeos> let me find it
[11:38] <tsdgeos> cimi: https://requests.ci-train.ubuntu.com/#/ticket/506
[11:38] <tsdgeos> but status doesn't look good :S
[11:38] <tsdgeos> give it a try
[11:38] <tsdgeos> pawel is out today it seems
[11:38] <tsdgeos> ah yeah he needed to go to the embassy
[12:09] <cimi> tsdgeos, this seems like a simple approve, anything I am missing? https://code.launchpad.net/~aacid/unity8/thread_warning/+merge/279276
[12:09] <tsdgeos> cimi: i'd say no, but it's my code D:
[12:09] <tsdgeos> i mean the point of the RR is someone else thinking of something i may have nto tought
[12:10] <cimi> indeed, so seems fine for me :)
[12:15] <mzanetti> cimi, hey, wanna test/review this? https://code.launchpad.net/~mzanetti/unity8/launcher-updates/+merge/278567
[12:19] <cimi> mzanetti, sure
[12:19] <cimi> mzanetti, I read was wip, I can go
[12:20] <tsdgeos> mzanetti: dednick: Saviq: do we have any bug about "press indicators bar to go back to live call not working"?
[12:20] <tsdgeos> i'm looking at the code and seems it broke at some point
[12:21] <tsdgeos> onPressedChanged in __showDragHandle doesn't seem to trigger with pressed = true
[12:23] <Saviq> tsdgeos, don't think we've a bug
[12:24] <tsdgeos> ok, i'll try to reproduce the thing on the meizu and present MRs about it
[12:25] <tsdgeos> basically i just have to call and swipe the phone app to not be the focused on, right?
[12:25] <tsdgeos> or there's something else needed for that to be supposed to work?
[12:51] <dednick> tsdgeos: hm. havent seen it. maybe some of the work ltinkl was doing on desktop indicators may have broken it. i havent done much in there in ages
[12:51] <dednick> tsdgeos: thats it. just unfocus phone (eg open dash) and it should sho
[12:52] <ltinkl> hmm, might be me yes :/
[12:52] <ltinkl> tsdgeos, ping me if you find something ood
[12:57] <davmor2> ltinkl: found something ood for you https://demonsrun.files.wordpress.com/2013/09/planet-of-teh-ood.png
[12:57] <ltinkl> :)
[13:17] <dandrader> greyback, something I've been wanting to do for a long time now https://code.launchpad.net/~dandrader/qtubuntu/loggingCategory/+merge/279629
[13:40] <greyback> dandrader: nice!!!
[13:42] <jhodapp> tsdgeos, what's the issue?
[13:42] <tsdgeos> jhodapp: xenial code is different from vivid code
[13:43] <jhodapp> tsdgeos, yeah, we're working on porting to GStreamer 1.6.x for both codebases and then we can dual land everything media
[13:45] <tsdgeos> dandrader: ltinkl: it works for some reason I read the code like it wouldn't but testing shows it works
[13:45] <tsdgeos> jhodapp: i see
[13:46] <ltinkl> tsdgeos, good
[13:47] <dandrader> tsdgeos, missing context
[13:47] <dandrader> tsdgeos, what's that about?
[13:47] <tsdgeos> dandrader: it wanted to say dednick, sorry
[13:47] <dandrader> right. the good old autocomlete issue :)
[13:48] <dednick> huh :)
[13:48] <tsdgeos> we need to architecture teams in a way in which only a given letter for a team member :D
[13:48] <tsdgeos> dednick: the call hint thing, it works fine
[13:48] <dednick> hehe
[13:48] <dednick> tsdgeos: ok.
[13:49] <dednick> yeah. get rid of duplicate people rather than changing names.
[13:53] <ltinkl> tsdgeos, just got an idea, now that the UITK has its own native bottom edge component, why not use it in dash?
[13:53] <dednick> meh. silo out of space again...
[13:54] <dednick> mzanetti: ^
[13:54] <ltinkl> tsdgeos, it's nice that it's clickable here, but then I can't swipe it with my finger :)
[13:54] <ltinkl> tsdgeos, the AddressBook app has it correct, it works with both things
[13:55] <tsdgeos> ltinkl: sounds good, i'm doing something similar with the DirectionalDragArea -> SwipeArea
[13:55] <tsdgeos> ltinkl: open a bug or a trello card
[13:55] <tsdgeos> ltinkl: or do a branch :D
[13:55] <ltinkl> tsdgeos, yea, will do something :)
[14:04] <mzanetti> dednick, ack, pinged the trainguards
[14:10] <tsdgeos> dandrader: what do you think of https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/swipeAreaPressedSignal/+merge/279780 ?
[14:10] <mterry> Anyone else seeing the latest rc-proposed image not booting?
[14:12] <dandrader> tsdgeos, need to add a test
[14:16] <tsdgeos> dandrader: sure, was just asking about the general idea
[14:16] <tsdgeos> looks ok?
[14:17] <dandrader> tsdgeos, think so. still downloading the branch to take a better look
[14:17] <tsdgeos> k
[14:17] <dandrader> tsdgeos, this web diff kinda crappy
[14:17] <tsdgeos> will add the test
[14:41] <tsdgeos> dandrader: is this http://bazaar.launchpad.net/~aacid/ubuntu-ui-toolkit/swipeAreaPressedSignal/revision/1734 the kind of test you wanted?
[14:45] <dandrader> tsdgeos, yeah
[14:55] <jhodapp_> tsdgeos, btw, you can also track the syncing between vivid+overlay and xenial in this silo: https://bugs.launchpad.net/ubuntu/+source/qtmultimedia-opensource-src/+bug/1523407
[14:55] <jhodapp_> tsdgeos, wrong link, one sec
[14:55] <jhodapp_> https://requests.ci-train.ubuntu.com/#/ticket/751
[14:55] <tsdgeos> jhodapp_: makes sense ahving this link in the trello card?
[14:56] <jhodapp_> tsdgeos, absolutely if it's not there already
[14:56]  * tsdgeos checks
[14:56] <jhodapp_> it is
[14:56] <tsdgeos> :)
[14:56] <jhodapp> tsdgeos, any other issues that are blocking this landing that you're aware of?
[14:57] <tsdgeos> jhodapp: no, it seemed to work good enough in vivid+overlay
[14:57] <jhodapp> tsdgeos, excellent news
[14:57] <jhodapp> tsdgeos, after we sync gstreamer versions, we'll be able to dual land just about everything in the media stack
[14:57] <tsdgeos> awesome :)
[14:58] <jhodapp> which will avoid this issue for the future
[15:42] <mterry> Saviq, I saw that my wakelock fix MPs were marked superceded -- there was a new branch needed?  some bug fix or something?
[15:42] <Saviq> mterry, conflict with multiSurfaceApp
[15:43] <mterry> ah
[15:43] <Saviq> mterry, so yeah, you might wanna look at the diffs if I broke something
[15:43] <Saviq> when resolving
[15:43] <mterry> ah I'm sure it's fine, but sure I'll look
[15:52] <tsdgeos> dandrader: have a sec?
[15:53] <dandrader> tsdgeos, yep
[15:54] <tsdgeos> dandrader: so the new Swipe area doesn't have sceneDistance property just distance, is there any easy way to port a code that is using one to the other? I'm specially strugging with the EdgeDragEvaluator of DragHandle
[15:55] <tsdgeos> seems like the distance is reset while the sceneDistance continues to grow (if testing with DDA)
[15:55] <dandrader> tsdgeos, IIRC, SwipeArae::distance == DirectionalDragArea::scenedistance
[15:58] <tsdgeos> hmmm
[15:58] <tsdgeos> ok i'll triple check
[22:19] <enes> halp unity8 wont load
[22:19] <enes> on ubuntu 15.10