[08:40] <tsdgeos> larsu: who do i ping to get https://code.launchpad.net/~aacid/gsettings-qt/disconnect_signal_handler/+merge/278947 and https://code.launchpad.net/~aacid/qmenumodel/clazy_run/+merge/272788 landed?
[08:48] <larsu> tsdgeos: Saviq or seb128
[08:49] <seb128> Saviq! :-)
[08:49] <Saviq> sure, /me takes
[08:49] <seb128> thanks
[08:49] <larsu> hehe
[09:09] <zzarr> hello! Is there a way to try unity8 on a computer with a nVidia card?
[09:11] <dandrader> zzarr, hi, that's more like a question of whether Mir works with nVidia. ask in #ubuntu-mir
[09:12] <zzarr> okey, dandrader thanks, I will
[09:17] <tsdgeos> Saviq: maybe you can review https://code.launchpad.net/~aacid/unity8/dash_backgroud_source_size_rework/+merge/276157 ?
[09:17] <tsdgeos> gerry seems to have forgotten about it
[09:18] <tsdgeos> cimi: you were reviewing https://code.launchpad.net/~aacid/unity8/thread_warning/+merge/279276 ?
[09:24] <tsdgeos> mzanetti_: can you have a look at https://code.launchpad.net/~aacid/unity8/testIndicatorsMenuFix since i think you could also reproduce the problem?
[09:25] <dandrader> Saviq, so what was the end of that black frame issue you were seeing with qtmir/surfaceItemFillMode branch?
[09:57] <tsdgeos> Saviq: what was the fix for the black screen because gst got stuck?
[10:05] <tsdgeos> gst-inspect-1.0
[10:05] <tsdgeos> it seems
[10:05] <tsdgeos> it's funny because if you run that from a tty it also blocks
[10:05] <tsdgeos> maybe similar problem we have in unity8?
[10:16] <Saviq> tsdgeos, yes, see bug #1525285
[10:16] <tsdgeos> ah cool
[10:17] <Saviq> dandrader, every once in a while the focused app showed a black frame until I interacted with the phone
[10:17] <Saviq> dandrader, we've decided to just merge the fillMode bits until we find out what's wrong with the rest
[10:19] <Saviq> dandrader, the immediate cause was that in your changed code you bound 0 to the surface if hasBuffer() was false, which in itself is probably correct, but has a detrimental user-facing effect, and also suggests something's wrong in lower levels (mir?)
[10:20] <dandrader> Saviq, hmm.. so the theory is that the fillMode change just exposed a preexisting issue?
[10:22] <Saviq> dandrader, yes
[10:22] <Saviq> dandrader, well, not fillMode itself
[10:23] <Saviq> dandrader, this hunk https://code.launchpad.net/~dandrader/qtmir/surfaceItemFillMode/+merge/274750#diff-line-389
[10:24] <Saviq> dandrader, this is the extent of reverts we decided to go with from your branch
[10:24] <Saviq> http://bazaar.launchpad.net/~unity-team/qtmir/surfaceItemFillMode/revision/426
[10:27] <dandrader> Saviq, so this revision 426 reverts pretty much the whole thing
[10:28] <dandrader> Saviq, maybe only left the new API
[10:30] <Saviq> dandrader, https://code.launchpad.net/~unity-team/qtmir/surfaceItemFillMode/+merge/279757 is what landed
[10:30] <Saviq> dandrader, so as far as we understood implemented the actual PadOrCrop feature
[10:30] <Saviq> I didn't notice behavioural differences when resizing between that and your whole branch
[10:31] <dandrader> Saviq, the difference is that QML items will lag behind, will work with outdated surface geometry
[10:32] <dandrader> Saviq, eg, the window decorations will lag behind the surface size during resizes
[10:32] <dandrader> Saviq, but yes, the PadOrCrop feature remained
[10:33] <Saviq> dandrader, so yeah, resizing got improved, but we erred on the safe side with the remaining changes
[10:33] <Saviq> dandrader, we do want them, sure, just we couldn't have landed as it was
[10:33] <dandrader> right
[10:39] <tsdgeos> cimi: remember https://code.launchpad.net/~aacid/ubuntu-settings-components/standarizeImports/+merge/280303 too ;)
[10:39] <cimi> ok ok, that is a quick approve :)
[10:39] <Saviq> dandrader, btw, as far as I can tell, with or without those changes, when resizing vertically, I could see surfaces going up/down, as if they were anchored to bottom-left corner instead of top-left, that expected still?
[10:40] <Saviq> or would this actually be artifact of the reverts that we did?
[10:41] <dandrader> Saviq, expected. seems like a "problem" in qt redraw/relaying logic. like on the very first frame after a resize it would still paint the same layout but just fill the extra surface area with white. then on the next frame the relayouting would be done and the whole surface area would be covered. that was my understanding at least
[10:42] <dandrader> Saviq, the case that gone perfect was resizing by dragging the right border
[10:42] <Saviq> dandrader, ack
[10:42] <dandrader> Saviq, with the settings app for instance
[10:42] <Saviq> dandrader, yup, that was my test
[10:45] <cimi> tsdgeos, managed to need fixing it :D
[10:47] <tsdgeos> cimi: that code was only written in 2013, but whatever, i'm not sure we even have a copyright year policy
[10:47] <cimi> tsdgeos, really? ok leave it then
[10:47] <tsdgeos> cimi: so changed & pushed
[10:48] <cimi> tsdgeos, I was wondering why we put years anyway, since it doesnt make much sense we update every year...
[10:49] <tsdgeos> cimi: afaik it's how copyright works, you need to specify the last year you did something so that in X years your copyright can properly expire
[10:49] <tsdgeos> that if Disney ever lets copyrights expire again
[10:50] <cimi> :D
[10:50] <cimi> gonna add the year to my pasta recipe so it doesnt expire :D
[12:06] <tsdgeos> Saviq: can you add https://code.launchpad.net/~aacid/ubuntu-settings-components/standarizeImports/+merge/280303 to the next unity8 landing too?
[12:08] <Saviq> tsdgeos, ack
[12:20] <tsdgeos> greyback: have a sec?
[12:20] <greyback> tsdgeos: sure
[12:21] <tsdgeos> greyback: any idea where could i start with https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1524488 ?
[12:21] <tsdgeos> greyback: basically if you change the time flickables stop working
[12:21] <tsdgeos> i guess there's a timestamp stored somewhere that breaks stuff
[12:21] <tsdgeos> any guess of where i start having a look?
[12:23] <greyback> tsdgeos: hmmm, a mad guess might be the implementation of the QAbstractAnimationTimer
[12:23] <greyback> QTickAnimationProxy I think
[12:24] <tsdgeos> k
[12:24] <greyback> but I think it is monotonically increasing ticker, so currentTime shouldn't matter
[12:24] <tsdgeos> i wonder if we should worry much about this otoh
[12:25] <Saviq> tsdgeos, it would be good
[12:25] <greyback> QML_ANIMATION_TICK_DUMP is an env var to play with
[12:25] <Saviq> tsdgeos, there have been reports of people's RTC resetting to epoch
[12:25] <Saviq> tsdgeos, at which point the phone dies
[12:25] <Saviq> while the RTC reset is a problem in itself, it'd be good if the UI worked regardless :)
[12:26] <tsdgeos> ok, i'll have a look after food
[12:26] <tsdgeos> food!
[12:47] <Saviq> greyback, you need to bump changelog for -gles if upstream version changed
[12:48] <greyback> Saviq: ok, I thought train does that automagically
[12:48] <Saviq> greyback, not for upstream version, not yet
[12:48] <Saviq> greyback, it mangles everything past it
[12:48] <greyback> eeh, ok
[12:49] <greyback> I'm testing locally anyway first
[12:49] <Saviq> that's mostly because there's very little train does special about -gles
[12:49] <Saviq> the only thing, really, is requiring -gles automagically where it's meant to be there
[12:50] <corn_field> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1525893
[12:50] <corn_field> http://i.imgur.com/ExNbNHF.jpg
[12:50] <Saviq> then it treats it as any other thing, we're just relying on the fact that qtmir will always be built first (alphabetically)
[12:50] <Saviq> corn_field, thanks, I've noticed that briefly
[12:51] <corn_field> o/
[12:52] <Saviq> greyback, any idea what we broke ↑? /me worried qtubuntu/qtmir wrt. panel height
[12:53] <greyback> Saviq: grr, fullscreen state of camera app broken
[12:54] <Saviq> greyback, gallery behaves slightly different - panel goes away, but bottom, panel-high is white
[12:54] <Saviq> so http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/revision/300 most likely
[12:54] <greyback> Saviq: yeah
[12:56] <ltinkl> it was working with "my" panel hack :)
[12:57] <Saviq> yeah it's Daniel's patch on top most likely, /me confirms
[12:57] <ltinkl> with this https://code.launchpad.net/~lukas-kde/qtubuntu/panelHeight/+merge/278718 I'm pretty sure it was OK
[13:00] <Saviq> yeah this couldn't have resulted in the breakage
[13:44] <ltinkl> dednick, heyo, could you pls review https://code.launchpad.net/~lukas-kde/unity8/fixWifiAPIndicatorIcons/+merge/280442 when you get a chance? thx
[14:41] <tsdgeos> dandrader: i have no clue what FloatingFlickableHelper does :D
[14:41] <tsdgeos> it does what your code used to do, i just refactored it around, maybe you can help me with the documentation?
[14:41] <dandrader> tsdgeos, "FloatingFlickableHelper contains the CPP remnants of the previous pure-CPP implementation of FloatingFlickable" :)
[14:42] <tsdgeos> looks like a bad documentation
[14:42] <dandrader> tsdgeos, kidding
[14:42] <dandrader> tsdgeos, it synthesizes mouse events
[14:42] <dandrader> tsdgeos, sending them to the given qquickitem
[14:43] <dandrader> tsdgeos, could even rename the methods
[14:44] <Saviq> dandrader, this bug is looking at you sideways :/ bug #1525893
[14:44]  * Saviq just building qtubuntu to confirm
[14:44] <dandrader> tsdgeos, let's do it that way then: I come up with a patch and send/propose it to your branch
[14:45] <dandrader> Saviq, so that's top priority?
[14:46] <tsdgeos> dandrader: that works for me :)
[14:47] <Saviq> dandrader, yeah, this is breakage
[14:47] <Saviq> dandrader, I'm just confirming with qtubuntu without r300
[14:57] <Saviq> dandrader, seems same without r300, or I did something wrong when testing... trying to find a working image then
[14:57] <Saviq> greyback, ↑
[14:58] <greyback> Saviq: tbh I suspect camera app problem unrelated to qtubuntu
[14:59] <Saviq> greyback, not just camera... gallery doesn't behave well either
[14:59] <greyback> I know
[14:59] <Saviq> in a weirder way though
[15:00] <Saviq> greyback, honestly, panel not going away but app thinking it did, that doesn't seem like should be possible by app itself
[15:00] <greyback> dandrader: if you want my help, let me know
[15:01] <Saviq> u8, qtmir, qtubuntu landed in the most recent image, just flashing the one prior to that
[15:15] <Saviq> dandrader, greyback, it's between unity8 and qtmir, qtubuntu innocent
[15:16] <dandrader> Saviq, ack
[15:16] <ltinkl> dednick, got my latest msg?
[15:17] <dednick> ltinkl: sorry, missed it after reboot.
[15:17] <ltinkl> dednick, could you pls review https://code.launchpad.net/~lukas-kde/unity8/fixWifiAPIndicatorIcons/+merge/280442 when you get a chance? thx
[15:17] <dednick> ltinkl: uchar?
[15:18] <dednick> for what state?
[15:18] <Saviq> no idea which commit could be the problem :(
[15:18] <ltinkl> dednick, the AP signal strength
[15:19] <ltinkl> dednick, it's a difference between network-indicator (on phone) and nm-applet (on desktop)
[15:19] <ltinkl> dednick, quite nasty to pass the percentage integer as a single char (ASCII code really)
[15:19] <dandrader> Saviq, my bet is the multiple-surfaces branches
[15:19] <ltinkl> dednick, but that's what nm-applet does
[15:20] <Saviq> dandrader, think the fullscreen prop isn't picked up from lastSurface or something?
[15:21] <dandrader> Saviq, something of the kind. Application.fullscreen property doesn't make much sense in a multi-surface world
[15:21] <cimi> pstolowski, can we kick a rebuild of https://requests.ci-train.ubuntu.com/#/ticket/506 ?
[15:21] <Saviq> dandrader, true
[15:21] <dednick> ltinkl: u8 desktop going to  be using indicator-network no?
[15:21] <dandrader> Saviq, I though I had it covered/converted, but maybe not so
[15:21] <pstolowski> cimi, sure, doing
[15:21] <ltinkl> dednick, no idea but for the time being, this fixes both cases
[15:21] <Saviq> dandrader, ok, shall I be digging more or are you on it (obv. let me know when you need me)?
[15:22] <dednick> ltinkl: but there is no nm-applet for desktop :/
[15:22] <Saviq> dednick, there is, unity7 still uses nm-applet
[15:22] <ltinkl> dednick, ?
[15:22] <dednick> Saviq: yes, but unity7 doesnt use qml code
[15:22] <ltinkl> dednick, well it is the backend provider
[15:23] <dandrader> Saviq, I'm on it
[15:23] <dednick> which is what ltinkl is changing
[15:23] <Saviq> dednick, but they back the desktop network menu
[15:23] <dednick> Saviq: in u8?
[15:23] <Saviq> dednick, yes
[15:23] <Saviq> dednick, when in unity8-desktop-session-mir
[15:23] <ltinkl> dednick, not changing u7 :)
[15:23] <dednick> Saviq: i c. that's what my question was.
[15:23] <Saviq> dandrader, ack
[15:24] <dednick> why we have desktop profile then? shouldnt we just be using indicator-network? sigh... whatever.
[15:24] <Saviq> basically, outside of ubuntu-touch, since indicator-network does not have all the features nm-applet had, yet
[15:24] <dednick> yeah. ok. features.
[15:25] <Saviq> but yeah, we want to converge on indicator-network at some point
[15:25] <ltinkl> esp, since nm-applet is deprecated imo
[15:26] <cimi> mzanetti_, can you merge here? https://code.launchpad.net/~mzanetti/unity8/launcher-updates/+merge/278567
[15:26] <ltinkl> cimi, he on vacation :)
[15:26] <cimi> lucky :)
[15:26] <Saviq> back tomorrow
[15:26] <Saviq> when you're on vacation ;P
[15:29] <dednick> ltinkl: i'm interested. in u7 we get the indicators from the /usr/share/unity/indicators file list. how do we get the nm-applet in our indicators?
[15:30] <dednick> *in u8 we get
[15:30] <ltinkl> dednick, that's a good question :) dunno, let me find out
[15:30] <dednick> ltinkl: does it show up?
[15:30] <ltinkl> dednick, oh yes
[15:30] <ltinkl> dednick, start the u8 session and you'll see
[15:31] <cimi> Saviq, my vacation is buying xmas presents before is too late xD
[15:33] <dednick> eh. u8 being painful.
[15:37] <greyback> tsdgeos: actually, just had a thought: check the times of the input events. they could be screwed up, which would cause this
[15:39] <tsdgeos> greyback: as said, the events don't reach the flickable, need to go high enough to find where the mistake happens
[15:39] <greyback> tsdgeos: ok (I hadn't read up)
[15:57] <tsdgeos> greyback: what sends the touch events to a given app, is it qtmir? qtubuntu?
[15:59] <greyback> tsdgeos: events come from mir, are converted from MirEvent to QTouchEvent in qtmir, then converted back to MirEvent to be sent to client. Then Qtubuntu gets that MirEvent, and converts back to QTouchEvent
[15:59] <tsdgeos> k, tx
[16:01] <greyback> tsdgeos: qtmir uses category logging, QT_LOGGING_RULES="qtmir.*.debug=true" will enable all
[16:01] <greyback> that will print input events, but don't recall how detailed
[16:01] <greyback> if qtmir's initial conversion step has an error, that will screw up all Qt instances from then on
[16:08] <tsdgeos> oh noes, i need to wait 464967 to be able to unlock my phone
[16:09] <tsdgeos> i guess moving back the time was not a good idea while having the phone locked
[16:09] <tsdgeos> 464967 *minutes*
[16:09] <tsdgeos> :D
[16:09] <greyback> how convenient: just over 5 days
[16:10] <greyback> you're not getting early Xmas holidays like that! :D
[16:11] <tsdgeos> greyback: more like a year :D
[16:11] <greyback> oh minutes
[16:11] <greyback> heh, I thought it was seconds
[16:13] <Saviq> mterry, ↑↑
[16:14] <Saviq> tsdgeos, there's a thread on ubuntu-phone about that exactly (someone got reset to epoch)
[16:14] <tsdgeos> Saviq: welll i did the change myself, i'm to blame
[16:14] <Saviq> tsdgeos, you can use "date" in adb/recovery to put it back in the present
[16:14] <tsdgeos> but it's a bit of a pita i guess
[16:14] <mterry> Saviq, I have a branch that is a partial fix -- https://code.launchpad.net/~unity-team/unity8/lockout-time-travel/+merge/280206
[16:14] <mterry> tsdgeos, ^
[16:14] <tsdgeos> if you don't have devel access
[16:14] <mterry> meant to send to you
[16:14] <tsdgeos> mterry: i fixed it with date :D
[16:14] <mterry> tsdgeos, ok cool
[16:15] <Saviq> tsdgeos, yeah well, you always have devel access if you have the phone in your hands ;)
[16:15] <tsdgeos> Saviq: but you need to know it :D
[16:15] <Saviq> oh sure :)
[16:15] <tsdgeos> greyback: so the qtmir.mir.input output looks good, at least looks the same with "good date" and "bad date"
[16:16]  * tsdgeos keeps digging
[16:16] <greyback> tsdgeos: ok. Are the flickables are broken in the indicators/launcher?
[16:17] <tsdgeos> greyback: too many are
[16:17] <tsdgeos> greyback: the launcher/indicators seem to work fine
[16:18] <greyback> tsdgeos: ok, I would suspect the event conversion from unity8->qtmir->client->qtubuntu could be the culprit then
[16:18] <greyback> tsdgeos: please try MIR_CLIENT_INPUT_RECEIVER_REPORT=log
[16:18] <greyback> that enables mir's logging of input events to console
[16:19] <greyback> run an app with that set, and see if the input events times make sense
[16:19] <tsdgeos> greyback: i need that in the app or in unity8?
[16:20] <greyback> tsdgeos: I think app.
[16:20] <tsdgeos> k
[16:21] <tsdgeos> Received event:touch_event(when=1452933799600760000 (10.-540462 ms ago)
[16:21] <tsdgeos> what does "10.-540462 ms ago" mean :D
[16:22] <greyback> something bad I'd imagine
[16:22] <tsdgeos> in the "good" case it says
[16:22] <tsdgeos> Received event:touch_event(when=1450110049426985408 (3.013062 ms ago)
[16:22] <tsdgeos> i'm weirded by the - after the . :D
[16:23] <greyback> ok, then I'd encourage you to dig into qtmir, in src/common/timestamp *
[16:23] <greyback> overall story: MirEvents use 64bit timestamps. QEvents use 32bit timestamps
[16:24] <greyback> so some trickery is done in qtmir to try convert between the two without loosing data
[16:24] <greyback> trickery which involves currentTime
[16:24] <tsdgeos> k
[18:09] <mterry> @unity, if anyone has some time, I'd appreciate a quick review of (tiny) https://code.launchpad.net/~mterry/unity8/briefly-inactive/+merge/280492
[18:09] <mterry> It fixes a security-sensitive bug
[18:18] <mterry> Saviq, filling out the checklist for an MP once more made me wonder -- have we seen tags come back in a while?  Did we finally cure that disease?
[18:19] <Saviq> mterry, doubt it ;)
[18:19] <mterry> heh
[18:19] <Saviq> mterry, I'm considering adding a step after .pot update in the train
[18:19] <mterry> Saviq, ah that's smart
[18:19] <Saviq> mterry, but am worried that might not be enough, as ci train reuses branches per-silo
[18:20] <Saviq> I think it only --overwrites
[18:20] <Saviq> but that does not get rid of tags :D
[18:20] <mterry> Saviq, well maybe with a further 3 years of no tags, we can be confident
[18:21] <mterry> Saviq, we need a little "X days since a tags incident" whiteboard
[18:21] <Saviq> mterry, FWIW, unity8 is relatively free, but we've managed to contract them on UITK. qtmir...
[18:21] <mterry> Saviq, oh no really?  hah
[18:21] <Saviq> yeah it's fun
[18:21] <Saviq> time to move to git ;P
[18:21] <mterry> ...
[18:22] <mterry> I love bzr so much, but if that's what it takes...
[18:42] <Saviq> if only bzr was maintained...
[18:57] <mterry> ltinkl, looks like there's a new geonames timezone-completion kid on the block: https://bugs.launchpad.net/ubuntu/+source/geonames/+bug/1525156
[18:57] <mterry> ltinkl, seems to be what the desktop team wants to support going forward, although as I comment in that bug, I'm annoyed that they didn't seem to be aware of prior art that they obstensibly maintain...
[19:01] <ltinkl> mterry, yeah, good points raised, at least the dependency on the data package should be added
[19:02] <mterry> ltinkl, digging further, it appears libtimezonemap does use cities15000.txt for its initial database when doing completion, and then hits the network for more.  So I don't even get the motivation for the geonames package
[19:02]  * mterry awaits their reply
[19:03] <ltinkl> mterry, perhaps they want to avoid the network completely?
[19:03] <mterry> ltinkl, sure but then comment out like one line in libtimezonemap, don't make a new library  :)
[19:03] <ltinkl> mterry, NIH syndrome hitting hard? :)
[19:03] <mterry> ltinkl, we made both packages  :)
[19:04] <ltinkl> NIH^2
[19:04] <mterry> heh
[19:04] <ltinkl> mterry, the original one is a gnome thing right?
[19:04] <mterry> ltinkl, it's a copy of GNOME code that we made so we could share it among several components.  We tried to get GNOME to use it, but NIH stopped that
[19:24] <ltinkl> mterry, https://code.launchpad.net/~mterry/unity8/briefly-inactive/+merge/280492
[19:25] <mterry> ltinkl, ?
[19:25] <ltinkl> mterry, interesting, I think I've seen it today... quickly got access to the MTP drive window (nautilus) which I closed but it disconnected my phablet-shell session
[19:25] <ltinkl> mterry, could that fix it?
[19:26] <mterry> ltinkl, closing the window disconnecting your adb shell would be a different thing
[19:26]  * ltinkl tries again
[19:59] <pmcgowan> josharenson, I just figured out the root symptom of bug #1489323 if you want to check it
[20:02] <josharenson> pmcgowan: will take a look, thanks
[21:31] <mterry> mzanetti_, just saw your comment on lockout-time-travel MP about trusting ntp clock
[21:35] <Saviq> mterry, he's off today
[21:35] <mterry> curses.  Will reply in MP
[21:35] <Saviq> as in, the whole day
[21:35] <mterry> Saviq, thanks, forgot that
[22:35] <ljp> anyone here know what is listening to proximity sensor when dialer-app is on a call?
[23:06] <McintireEvan> Hi, I was wondering if someone could help me. I'm adding a shortcut to the overlay through CompizShortcutModeller.cpp, but it doesn't show up either due to a wrong plugin name or a wrong keybinding name. I'm really not sure where to go from here, I've tried several values for the shortcut names (from looking at the plugin in compiz) but I haven't had much luck. anyone got any ideas? The plugin in question is screenshot