[02:43] <kgunn> Saviq: still rotating & still seeing apps launch as mobile mode with that silo rebuild
[08:39] <tsdgeos> cimi: please remember of https://code.launchpad.net/~aacid/unity8/dash_reset_instead_of_fatal/+merge/274363
[10:19] <Saviq> greyback__, hey, had to pull Alan's branch from the silo, it doesn't build
[10:20] <greyback__> Saviq: conflicts? or ftbfs?
[10:20] <Saviq> greyback__, the latter
[10:20] <greyback> ok
[10:20] <Saviq> ah, Alan's just pushed a commit, let's see what ci says
[10:21] <Saviq> greyback, ↑
[10:21] <greyback> ack
[10:24] <Saviq> greyback, I also had to add --fail-missing back to qtmir-gles, not happy about it but meh, we'd need a custom target to install just the qpa plugin
[10:25] <greyback> ok
[10:33]  * tsdgeos finds and interesting bug/behaviour regarding bindings and properties
[10:33] <tsdgeos> will put a test up for people to confirm i'm not seeing ghosts in a minute
[10:36] <tsdgeos> Can you guys try http://paste.ubuntu.com/12988339/ and confirm that rect2 width is evaluated on every resize
[10:36] <tsdgeos> but that if you change cardWidth from var to real it is not evaluated on every resize anymore?
[10:36] <tsdgeos> @unity: ↑
[10:38] <mzanetti> tsdgeos, confirmed
[10:38] <mzanetti> don't ask me why tho
[10:39] <tsdgeos> mzanetti: i guess the engine stores var as an object and every "set" is a different object which maens the object changed even if the inner value is the same
[10:39] <tsdgeos> random guess
[10:40] <tsdgeos> this is good since this fix makes lots of reevaluations on the dash go away
[10:41] <mzanetti> nice!
[10:41] <mzanetti> yes, it does sound like it can't do an optimization with var
[10:41] <mzanetti> and iirc I've read somewhere that using property var is said to be slow, likely for this reason
[10:53] <Saviq> tsdgeos, nice one
[10:56] <Saviq> greyback, ok, put the test harness back, ci liked it
[10:56] <greyback> thanks!
[10:57] <cimi> mmm am I missing something? I just reinstalled rc-proposed on my krillin, and cannot enable developer mode from the system settings
[10:58] <cimi> I tap enable, but if I close and reopen system settings is always off
[11:01] <Saviq> cimi, any interesting logs in ~/.cache/upstart/*settings* ?
[11:02] <cimi> Saviq, I am flashing with --developer-mode, impatient
[11:02] <Saviq> cimi, --developer-mode only enables adb-when-locked, really
[11:03] <cimi> ah
[11:03] <Saviq> so likely won't have any impact
[11:10] <cimi> Saviq, it actually enabled adb out of the box
[11:10] <cimi> yay \o/
[11:10] <Saviq> right
[11:19]  * Saviq loves adt-run
[11:19] <Saviq> adt-run unity8 -o vivid --setup-commands "apt install --yes software-properties-common; apt-add-repository --yes --enable-source ppa:ci-train-ppa-service/landing-021; apt update" --- schroot vivid-overlay-amd64-shm
[11:19] <Saviq> adt-run unity8 -o xenial --setup-commands "apt install --yes software-properties-common; apt-add-repository --yes --enable-source ppa:ci-train-ppa-service/landing-021; apt update" --- schroot xenial-amd64-shm
[11:19] <Saviq> lo and behold, qml tests results from a silo :)
[11:24] <Saviq> I only need moar memories
[11:33] <Saviq> cimi, om26er just reported adb issues on arale on the phone ML, maybe you can relate?
[11:37] <cimi> Saviq, ty
[11:49] <Saviq> dandrader, Josh's new-fix-upsidedown needs a re-review after resubmitting, but it seems it also introduces a regression - phone app forces external display to rotate
[11:49] <dandrader> Saviq, interesting..
[11:50] <Saviq> dandrader, could you please work on a test for this, so we don't miss it?
[11:51] <Saviq> or well, you can work on a fix, too, it's ~unity-team by now anyway
[11:51] <dandrader> Saviq, Will talk to Josh
[11:51] <Saviq> tx
[11:52] <Saviq> I'd rather not pull it out of the silo because it's become prereq for others by now
[11:52] <Saviq> but it might happen
[11:52] <Saviq> /away
[11:53] <dandrader> Saviq, ah, that explains it :)
[11:54] <cimi> Saviq, anything in particular to look in silo 21?
[11:55] <cimi> I've been testing it around lately, found minor things on my preview branches, but most likely better to fix later separately
[14:02] <attente> greyback_: hey, have you had a chance to look at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1417655
[14:16] <dandrader> attente, changes are needed in multiple places for that. for qtubuntu we have this https://code.launchpad.net/~albaguirre/qtubuntu/use-mir-surface-apis/+merge/267228
[14:17] <greyback_> attente: hey, we have branches up which add basic support for that. But when I say basic, I mean basic. We need to add more advanced window management yet, which is next thing on my list
[14:21] <attente> ok, will it also fix it on the phone? because right now creating a second surface restarts the unity 8 session
[14:22] <dandrader> attente, there's https://code.launchpad.net/~dandrader/unity8/multiSurfaceApp/+merge/271613 for that
[14:22] <Saviq> cimi, well, any bugs/branches from https://requests.ci-train.ubuntu.com/#/ticket/564
[14:23] <Saviq> attente, "fix" in the sense that unity8 won't crash, yes, "supported", no
[14:23] <Saviq> attente, phone is supposed to be single surface per app, per design
[14:28] <attente> Saviq: i'm wondering how that's supposed to work with gtk apps which need to be able to pop up menus and dialogs
[14:32] <Saviq> attente, not really planned to be supported on the phone, again, per design
[14:35] <Saviq> attente, ultimately, when we have the window management code for desktop, we might allow some of that working on the phone, too, but that's definitely not a priority
[14:36] <Saviq> attente, apps on phone are meant to be confined to a single, full-screen window, so there's no real reason why they couldn't just render everything internally
[14:36] <attente> Saviq: ok, i guess we'll try to fake it then
[14:40] <Saviq> attente, toolkits, if they want to be cross-platform, need ultimately gain a single-surface mode, where they don't split the UI into multiple surfaces, it's not like we're the only mobile platform putting that requirement on apps
[14:41] <attente> Saviq: yeah, that's not unreasonable
[14:41] <attente> i'll try to make do
[14:53] <josharenson> greyback_: If you have a minute, can you take a look at the changes to ShellApplication.cpp in https://code.launchpad.net/~josharenson/unity8/slim_greeter_real_lightdm and let me know if you think that will present any multi monitor issues?
[14:54] <josharenson> greyback_: I know its a hack, but setting fullscreen wasn't working
[15:00] <greyback_> josharenson: am curious why fullscreen wouldn't just work
[15:00] <josharenson> greyback_: I suppose that is a better question...
[15:07] <kgunn> anyone else notice getting bt mouse to connect suddenly got wonky in latest image ?
[15:07] <kgunn> or just me
[15:08] <greyback_> josharenson: fullscreen should just be reading the geometry of the screen the window is on, and setting the window size to that geometry. As qtmir is the source of the screen geometry, it may have a problem. Can you investigate further?
[15:08] <josharenson> greyback_: sure
[15:15] <Saviq> mterry, there are DesktopStage failures in silo 21 http://pastebin.ubuntu.com/12990194/
[15:16] <Saviq> or mzanetti ↑?
[15:16] <mterry> hrm
[15:16] <mterry> might be good to determine which branch did that
[15:16] <kgunn> mzanetti: ltinkl ok, the no buttons issue is better...but then i got this (with silo21)
[15:16] <kgunn> http://www.youtube.com/watch?v=NQi33Jpv3oQ
[15:17] <mzanetti> mterry, hmm... thsoe are the ones I had after my merge
[15:17] <kgunn> might have been the rotation
[15:17] <mzanetti> hmm
[15:17] <mzanetti> kgunn, will look into it... as a temp workaround you probably want to wipe the windowstatestorage
[15:17] <mterry> mzanetti, oh shoot, I thought the test failure was in the test added by my merge, so that's all I checked after doing my rebasing
[15:18] <ltinkl> kgunn, looks like an issue with the spread
[15:18] <ltinkl> kgunn, can you alt-tab to it?
[15:18] <mzanetti> ltinkl, no... the spread is fine... the windows is located somewhere outside the screen
[15:18] <mzanetti> -s
[15:18] <ltinkl> mzanetti, aha, so the storage
[15:18] <mterry> Saviq, mzanetti: I will look at that test failure today.  I assume it isn't urgent?
[15:19] <kgunn> mzanetti: ltinkl where is the storage ? could i inspect ? and confirm it's offscreen ?
[15:19] <mzanetti> mterry, I thought those were were the ones you added :/ my bad I guess
[15:19] <mzanetti> kgunn, sqlite3 ~/.cache/unity8/windowstatestorage.sqlite
[15:20] <mzanetti> kgunn, call, ".tables" to see the available tables
[15:20] <mzanetti> and then "select * from <table>"
[15:20] <mzanetti> not sure what the name is... I think it's state
[15:20] <ltinkl> mzanetti, ew, why do we store the config in ~/.cache? :)
[15:20] <Saviq> mterry, well, getting a silo in a releasable state is generally urgent, yes ;)
[15:20]  * ltinkl was looking into ~/.config
[15:20] <mzanetti> ltinkl, because its not a config
[15:21] <ltinkl> right, you can erase it
[15:29] <Saviq> josharenson, dandrader, did you talk about the rotate-external-screen issue?
[15:29] <Saviq> kgunn, oh btw, I'm not sure what you meant by "still seeing apps launch as mobile mode"
[15:31] <dandrader> Saviq, not yet. think he just got online
[15:31] <kgunn> Saviq: well, they launch full screen, and they have no buttons present in the panel - but that seems fixed now
[15:31] <kgunn> in silo 21
[15:31] <josharenson> Saviq: no, but I was planning on looking into it today. I don't have a BT keyboard/mouse because the post office lost mine and was going to buy one today
[15:31] <Saviq> kgunn, right, that might've been due to missing qtmir rebuild
[15:32] <dandrader> Saviq, still fighting with my nexus 7. could not reproduce no a laptop with fake orientations
[15:32] <Saviq> ack
[15:33] <kgunn> Saviq: happy to consider that fixed...now just gotta stop that rotation :)
[15:34] <Saviq> ack
[15:40] <Saviq> hmm /me goes to xenial then
[15:40] <kgunn> mzanetti: actually it was 'geometry' and curious...
[15:40] <kgunn> should those values change as i click ?
[15:40] <mzanetti> kgunn, no, only when you close a window
[15:40] <kgunn> e.g. i can rerun select *
[15:41] <mzanetti> had a fight over it with daniel :D I wanted to save them all the time at first, but he didn't approve the branch :D
[15:41] <kgunn> mzanetti: fwiw dash showing geom of 0 0 0 0
[15:41] <Saviq> oups
[15:41] <mzanetti> yeah... there's something going on...
[15:41] <Saviq> wonder how that happened
[15:41] <mzanetti> kgunn, if you happen to find a way to reproduce, that'd be great
[15:41] <mzanetti> I'll dig into it
[15:41] <kgunn> k, will continue to break things
[16:18] <mterry> mzanetti, Saviq: looks like lp:~unity-team/unity8/lp1475678.surface-occlude is the branch that broke the DesktopStage tests
[16:18] <kgunn> mzanetti: yikes, i delete the windowstorage.sql and i still have no dash
[16:18] <kgunn> it's acting the same way
[16:18] <Saviq> dednick, ↑
[16:18] <Saviq> ↑↑rather
[16:21] <dednick> mterry: where is it broken? looking at the silo build
[16:22] <mterry> dednick, running xvfbtestDesktopStage
[16:23] <Saviq> @unity I think I saw someone mention broken kinetic scrolling
[16:23] <Saviq> who was that?
[16:23] <Saviq> in spread
[16:24] <kgunn> mzanetti: btw, this is odd... http://www.youtube.com/watch?v=yaSekyLd0bk
[16:24] <kgunn> i see scopes in the top left corner show up, if i kill dash when it's in this state
[16:25] <dandrader> Saviq, there's a bug about it
[16:25] <Saviq> dandrader, oh good
[16:25] <dandrader> Saviq, greyback_ is on it I think
[16:25] <Saviq> right
[16:26]  * Saviq thought the touch compression could do it, but doesn't seem like it
[16:26] <greyback_> nope, is something else
[16:26] <greyback_> dunno what yet
[16:26] <dandrader> Saviq, https://bugs.launchpad.net/qtmir/+bug/1510571
[16:26] <Saviq> dandrader, thanks
[16:30] <kgunn> ok, positive i deleted the windowstorage.sql twice now...on the second time/reboot i now have dash back
[16:33] <kgunn> hmmm...clock rotates the shell also
[16:33] <kgunn> silo21
[16:34] <Saviq> kgunn, likely same problem
[16:35] <dednick> mterry: eh. my branch passes tests, but i guess it's something in the merges
[16:36] <mterry> dednick, I just tried your branch all by itself and it failed tests
[16:36] <mzanetti> kgunn, right... is that how you reproduce it?
[16:36]  * mzanetti tries
[16:36] <Saviq> dednick, mterry, FWIW https://code.launchpad.net/~ci-train-bot/unity8/
[16:36] <mzanetti> that totally does look like it's positioning it into 0,0,0,0
[16:36] <mterry> dednick, try installing the other packages in the silo, they may be affecting you
[16:36] <Saviq> and `citrain host-upgrade 21` to get the dependencies (on vivid, or xenial)
[16:37] <mterry> Saviq, oh those pre-generated branches are nice
[16:37] <mterry> bookmarking
[16:38] <Saviq> courtesy of bug #1348531
[16:38] <greyback_> naice
[16:40] <mzanetti> Saviq, nope... The issue is happening not only in spread, also in the launcher for example... and I've tried reverting the touch compression thing too. no avail
[16:40] <mzanetti> it still seems to work for apps tho... so must be qtmir it seems
[16:40] <dednick> mterry: :/ the u8 tests shouldnt be dependent on other packages, but i'll give it a go
[16:41] <mterry> dednick, I don't know, I'm just trying to guess why it fails for me but not you
[16:41] <mterry> dednick, I'm also on xenial
[16:43] <Saviq> mzanetti, yeah indeed
[16:44] <dednick> oh. i'm on wily
[16:44] <mzanetti> good you found out :)
[16:44] <dednick> mterry: ^
[16:44] <dednick> Saviq: silos not building branches for wily?
[16:44] <mterry> dednick, I don't know if that's THE difference though.  Note that the silo builds on vivid and xenial, but not wily
[16:45] <Saviq> dednick, wily is done'n'dusted
[16:45] <dednick> sigh. i just upgraded to wily a few weeks ago!
[16:45] <mterry> dednick, what took you so long!
[16:45] <mzanetti> I'm still on v+o :)
[16:45]  * mterry shakes head
[16:45] <mzanetti> Saviq, how's xenial by now?
[16:46]  * Saviq just did `do-release-upgrade -d`, need to reboot
[16:46] <mterry> I haven't rebooted yet either  :)
[16:46] <mzanetti> ok, you guys reboot and I'll do the vivid dance
[16:47]  * Saviq does, will see you on the other side o/
[16:48] <dednick> *grumble* /me upgrades
[16:48] <Saviq> seems it didn't kill me
[16:49] <Saviq> dednick, wily was never really a target for us, just a means to not grow tech debt for when we rebase on 16.04
[16:51] <Saviq> aah my terminal has a custom byobu icon now...
[16:51] <dednick> well i guess i'll go eat something while this is happening. happy days
[16:56] <mterry> pmcgowan, I can confirm that silo 21 has odd shutdown dialog behavior.  I assume I'm the cause and am looking into it  :)
[17:15] <mterry> greyback_, QInputEvent timestamps on Mir seem... unreliable.  Looks like it's 0 for the power button press that turns off the screen.  And looks like it's overflowing easily
[17:16] <mterry> I know there's a mismatch between Mir's 64bits and Qt's ulong
[17:18] <greyback_> dandrader|bbl: that mean anything to you ^^
[17:19] <greyback_> mterry: can you noticed if the mir input event timestamps are good or not?
[17:19] <greyback_> just to identify if the qtmir workaround for the 32/64bit timestamp is broken or not
[17:19] <mterry> greyback_, I haven't checked the timestamps directly, but haven't noticed any odd behavior
[17:20] <mterry> greyback_, the workaround of dividing by 1000000?
[17:20] <greyback_> mterry: yeah
[17:21] <mterry> greyback_, Mir is in... nanoseconds?
[17:21] <greyback_> mterry: yeah
[17:21] <mterry> So if we are stuffing into 32 bit... we'd only overflow in 2032?
[17:21] <mterry> Because we use ms for Qt
[17:22] <mterry> greyback_, pressing the power button twice in a row gave me timestamps of 345,399,000 and 1,640,287,000
[17:23] <mterry> short delay between
[17:23] <mterry> (Qt timestamps) -- unless I'm reading qt timestamps wrong...
[17:23] <greyback_> yeah that's wrong
[17:23] <mterry> Let me double check my code that grabs the timestamp  :)
[17:24] <greyback_> mterry: can you set MIR_CLIENT_INPUT_RECEIVER_REPORT=log and compare the printed mir timestamps with qt's ones
[17:24] <greyback_> mterry: also set QT_LOGGING_RULES="qtmir.*.debug=true" to enable qtmir input event logging
[17:24] <mterry> k
[17:25]  * greyback_ loves category logging
[17:25] <mterry> agreed
[17:29] <mterry> greyback_, here's a log snippet:  this is me pressing the power button a few times, then holding it down: https://pastebin.canonical.com/142915/
[17:29] <mterry> greyback_, the MIKE logs are true/false if it's an autorepeat event, then the next number is the timestamp Qt shows
[17:29] <mterry> If my code isn't mucking it up
[17:30] <greyback_> mterry: looks wrong to me
[17:31] <mterry> greyback_, yeah, Qt and Mir aren't increasing at same rate
[17:31] <greyback_> timestamps should not be so huge
[17:31] <greyback_> I thought the qt timestamps are to start at 0 at program start too
[17:32] <mterry> greyback_, it seems to hit 0 multiple times for me
[17:33] <greyback_> mterry: which means we overflowed
[17:33] <mterry> greyback_, well it hits 0 back to back presses at the beginning
[17:33] <greyback_> mterry: what you testing on? pc?
[17:33] <mterry> greyback_, mako
[17:34] <mterry> greyback_, I'm not convinced my qt timestamp reporting isn't somehow bogus.  I'm using this code: https://code.launchpad.net/~mterry/unity8/shutdown-dialog-on-resume/+merge/275240
[17:35] <mterry> greyback_, is there an easy way to test this without using a modified u8?
[17:36] <greyback_> mterry: yes. If you can print the timestamps in qml, just create a simple qml file which does it. Then "stop unity8" and run that qml file instead of unity8 with MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver qmlscene yourQmlFile.qml
[17:37] <mterry> greyback_, the timestamp isn't exported to qml
[17:37] <mterry> That's why I had to export it myself in that branch
[17:38] <greyback_> ah boo
[17:39] <greyback_> well you can make a simple qml file that just imports that qml plugin
[17:47] <mterry> greyback_, well that doesn't solve my problem of trying to get my code changes out of the way  :)  It might be good if qtmir had a test that confirmed qt timestamps were being exported as expected
[17:48] <mterry> Just a future improvement maybe.  I'm going to see if I can workaround needing Qt timestamps for now
[17:48] <mterry> Else I'll have to dig deeper
[17:48] <greyback_> mterry: we have to fix that, please log qtmir bug
[17:49] <mterry> greyback_, oh for sure, if it's broken now, we have to fix it.  I'm just still trying to confirm it's actually broken
[17:49] <greyback_> mterry: the output you supplied has convinced me
[17:50] <mterry> Yeah but my reporting code could mess it up.  I want a nice tight cpp test or something, without so many layers.  But I can file bug while we investigate
[17:51] <greyback_> mterry: we have tests in qtmir for the compression. but something not right
[17:51]  * mterry has to run out for a sec, will file bug and look into cpp test when back
[18:43] <mterry> Ok am back
[18:47] <mterry> saviq, fyi my shutdown-dialog branch is problematic / unreliable.  If you're looking to keep silo in releasable state, might make sense to drop that for now.  I'm setting to WIP until I can root-cause it
[19:03] <Saviq> mterry, ac
[19:03] <Saviq> k
[19:18] <kgunn> Saviq: so i just caught (by sight) my n7 reboot
[19:19] <kgunn> what were some logs beside syslog to look at? or capture
[19:38] <Saviq> kgunn, logcat, but not sure how/if it's possible to find the right moment
[19:56] <mterry> greyback_, I think I found a source of timestamp confusion, and a possible fix.  Will file soon
[21:04] <Saviq> kgunn, btw, unity8 in silo21 rebuilt a few mins ago, should not rotate any more
[21:06] <kgunn> thank goodness
[21:06] <kgunn> super annoying
[22:32] <Saviq> kgunn, those "Browser" and "Scopes" strings are splash screen
[22:33] <Saviq> in a 0,0,0,0 window
[22:33] <Saviq> spinner, too, just a different version of the splash screen
[23:08] <kgunn> figured as much