[08:47] <paulliu> Saviq, https://code.launchpad.net/~paulliu/unity8/attribute/+merge/223242
[09:07] <greyback> dednick: hey, replied to your mail: are you getting crash reliably just with trust sessions, for basic support?
[09:09] <dednick> greyback: ah. didn't see that mail.
[09:10] <dednick> greyback: will it be a mir fix, or just that we shouldn't release surface?
[09:10] <greyback> dednick: yeah sorry. Application is deleting its MirSurfaceItem - that slipped in somehow
[09:11] <dednick> greyback: right. well i'm not sure if it will affect prompt sessions, since that has surfaces not attached to apps.
[09:11] <greyback> my plan would be to have MirSurfaceItem have a shared pointer to the Application, and Application is only deleted when it is removed from the AppMan list and all its surfaces destroyed
[09:12] <greyback> but I was going to leave that after we land qtcomp as it is now
[09:12] <greyback> dednick: I'm more asking: what do you need from me & qtcomp?
[09:12] <dednick> greyback: i think my problem is that i have a MirSurfaceItem hanging around after destroy_surface.
[09:13] <greyback> dednick: is release() being called on that surface ever?
[09:14] <dednick> greyback: er. don't know. i need to investigate it today.
[09:14] <greyback> dednick: let me know if I can help
[09:14] <dednick> greyback: ok. thanks
[10:11] <greyback> dednick: would this help at all? http://pastebin.ubuntu.com/7835202/
[10:11] <greyback> we were not disabling input to surfaces if their backing mir surface was destroyed
[10:12] <dednick> greyback: probably would. i am just about to start testing
[10:12] <dednick> greyback: can give it a test
[10:12] <greyback> do please
[10:13] <greyback> I think it was causing unity8 to crash for some AP tests
[10:27] <sogatori> Hello everyone. The application idndicators/status notifiers standard says that indicators with the "passive" property should/can be hidden. Is there any way in unity to interact with hidden indicators?
[10:32] <dandrader> greyback, I don't think it should be implemented like that as the enabled property of MirSurfaceItem is also controlled from the QML side.
[10:33] <greyback> dandrader: ok. What would you prefer.
[10:33] <greyback> dandrader: sadly it's not fixing the crash I'm getting anyway
[10:41] <facundobatista> Holas
[10:46] <greyback> sogatori: you would probably be more likely to get a reply by emailing the unity-dev mailing list (unity-dev@lists.launchpad.net)
[10:46] <sogatori> greyback: oh ok, I was about to try unity-design.
[10:46] <greyback> sogatori: that might do too.
[10:47] <sogatori> greyback: thanks
[11:07] <greyback> W: Failed to fetch gzip:/var/lib/apt/lists/partial/ddebs.ubuntu.com_dists_utopic_main_binary-armhf_Packages  Hash Sum mismatch
[11:08] <greyback> anyone getting that for ddebs.ubuntu.com recently?
[11:13] <dednick> greyback: works perfectly.
[11:14] <greyback> hmmm, wtf wrong on my end
[11:14] <dednick> greyback: don't know why it would be breaking unit tests though. surface item will be deleted for an application.
[11:15] <dednick> greyback: oh. sorry, i meant about the setEnabled :)
[11:15] <greyback> dednick: so I realised after :)
[11:15] <dednick> greyback: yeah, i can't get ddebs either :)
[11:16] <dednick> just tried a few minutes ago
[11:16] <greyback> dednick: it breaks unit tests? They pass here
[11:16] <dednick> sorry, autopilot
[11:18] <dednick> greyback: it was only my child surfaces that were the problem as far as i can tell.
[11:23] <dpm> pstolowski, on https://code.launchpad.net/~stolowski/dropping-letters/default-department-id-key/+merge/227576 - why is the department 'puzzles' instead of 'games'? Is it possible to add multiple departments? Is 'puzzles' already inside 'games'?
[11:29] <pstolowski> dpm, no multiple departments. and this is it's current department in Ubuntu Store
[11:30] <dpm> pstolowski, ok, thanks. So are departments nested? I.e. is 'puzzles' inside 'games'?
[11:30] <pstolowski> dpm, for now they are, but afair the final list of departments for initial launch will be flat
[11:30] <dpm> ok
[11:54] <mzanetti> greyback: we've got merge conflicts with trunk now... really weird... in code that didn't change
[11:55] <greyback> mzanetti: which project? unity8?
[11:55] <mzanetti> yeah
[11:55] <greyback> mzanetti: can I ask you to look after those?
[11:55] <mzanetti> greyback: yeah, I'll try...
[11:55] <greyback> thanks
[12:07] <Saviq> MacSlow|lunch, http://qt-project.org/doc/qt-5/qml-qtquick-item.html#forceActiveFocus-method
[12:11] <dandrader> mzanetti, greyback, I was going to do the merge but got diverted. one thing is you have to revert rev 1076 from mirCompositor
[12:12] <dandrader> as that fix is coming from a different commit in trunk
[12:12] <mzanetti> I'm not sure I'm able to merge this
[12:12] <dandrader> and it will merge silently without errors
[12:12] <mzanetti> without mterry at least
[12:12] <dandrader> but will leave a bogus end result
[12:13] <mzanetti> dandrader: we shouldn't have remove the underlayclipper :/
[12:13] <mzanetti> that introduces the issues in the tablet and causes every merge to be a pain
[12:13]  * mzanetti giving up on that merge
[12:16] <mzanetti> I don't even get why PhoneStage.qml is conflicting now
[12:16] <mzanetti> stupid bzr
[12:18] <dandrader> mzanetti, it's better to get a diff of what changed since the last merge to help understand what's actually happening
[12:19] <mzanetti> dandrader: yeah... I see mterry did bad things in the spread code
[12:19] <mzanetti> that branch shouldn't have been approved
[12:20] <dandrader> uh oh
[12:20] <Saviq> mzanetti, bad for qtcomp or in general?
[12:20] <mzanetti> general
[12:21] <Saviq> mzanetti, r1062?
[12:21] <mzanetti> Saviq: yes
[12:22] <mzanetti> still need to figure what the solution should be...
[12:23] <mzanetti> but as it is it a) makes things hard to maintain (well, harder than my stuff does it already) and b) breaks on tablet
[12:32] <mzanetti> Saviq: is mterry not at the sprint?
[12:32] <Saviq> mzanetti, next week
[12:32] <mzanetti> ah ok
[12:32] <Saviq> mzanetti, he'll be around soon
[12:32] <mzanetti> yep
[12:58] <mzanetti> mterry: good  morning
[12:59] <mzanetti> mterry: the dialer-above branch is conflicting with every line with qtcomp. I'm having troubles merging it...
[12:59] <mterry> mzanetti, hello!
[12:59] <mterry> mzanetti, oh :(
[12:59] <mzanetti> mterry: I think I need your help there
[13:00] <mzanetti> mterry: also, the changes in PhoneStage are not really what it should be imo... but still need to figure exactly how to solve that
[13:00] <mterry> OK, want me to have a go at merging or do you have a specific question?
[13:00] <mterry> mzanetti, oh, the disabling-edge-drag stuff for PhoneStage?
[13:00] <mzanetti> yeah
[13:01] <mzanetti> mterry: why is that required at all?
[13:01] <mterry> mzanetti, we show the dialer app, but the phone is still locked
[13:01] <mzanetti> mterry: are you displaying the real spread and just don't want the user to switch to another app?
[13:01] <mterry> mzanetti, we don't want the user to switch apps right
[13:02] <mzanetti> hmm... ok...
[13:02] <mzanetti> I guess we can have something like that the, however, 2 issues with it:
[13:02] <mzanetti> mterry: a) breaks on StageWithSideStage.qml/TabletStage.qml
[13:03] <kgunn> mterry: btw, silo6 has qtcomp if you need to integrate on it
[13:03] <mzanetti> mterry: b) given that the applicationsDisplayLoader basically loads the window management code its not always said to have a spread in there
[13:03] <mterry> mzanetti, yes, elsewhere we only allow this special dialer-above mode if in narrowMode, which is just punting the tablet problem down the road for a little bit
[13:03] <mzanetti> mterry: so it probably should be something like "appSwitchingDisabled" so a desktop implementation would disable alt+tab etc
[13:04] <mterry> mzanetti, yes we'd want to disable alt+tab too, true
[13:06] <mzanetti> mterry: so yes, if you could try to redo the changes in Shell.qml on top of QtComp, that would help a lot. I think merging is harder than redoing it on top the other branch
[13:07] <mzanetti> mterry: also one note on upcoming stuff (because that will be conflicting too):
[13:08] <mzanetti> mterry: when the dash becomes an app, there won't be such a thing as "stages.shown" any more
[13:08] <mzanetti> mterry: the stages will always be shown and can't be moved to the right any more
[13:08] <mterry> k
[13:09] <mterry> mzanetti, lp:~unity-team/unity8/mirCompositor is the relevant branch?
[13:09] <mzanetti> mterry: yep
[13:15] <greyback> mterry: can I get oyu to have a look at https://code.launchpad.net/~unity-team/ubuntu-system-settings/use-qtComp/+merge/225540 too please?
[13:15] <greyback> mterry: mzanetti reviewed the code, it is running in silo6 if you would like to test it
[13:15] <greyback> but need a team member to approve
[13:24] <tsdgeos> Wellark: you aware of the needs fixing in https://code.launchpad.net/~unity-api-team/unity8/modeminfo/+merge/225159 ?
[13:31] <mterry> mzanetti, here is a Shell.qml with dialer-above changes on top: http://paste.ubuntu.com/7836141/
[13:31] <mterry> mzanetti, did not test it, since I just did that file
[13:31] <mterry> mzanetti, but hopefully it's right or very close to it
[13:31] <mzanetti> mterry: cool, thanks. what do I need to do to test this?
[13:32] <mterry> mzanetti, to test the dialer-above stuff specifically?  Enable a password (still using the ~/.unity8-greeter-demo stuff for now) and click the Emergency Call button and make sure the 3 edges don't work
[13:33] <mterry> mzanetti, there is a qmluitest that does that too
[13:33] <mzanetti> mterry: ah, great
[13:33] <mzanetti> thanks
[13:41] <mterry> greyback, from a packaging pov, that branch is fine.  Is that what you wanted, or did you want me to look at the actual changes themselves?  They seem OK, but I'm not familiar enough with the mirCompositor changes to be sure it's all amazing.  Stuff like changing setTitle("Qml Phone Shell") to "Welcome Wizard" I'm unsure of -- we no longer need that hack?
[13:41] <greyback> mterry: that's why I got mzanetti to give him +1, he knows the C++
[13:42] <greyback> mterry: but neither of us have the ability to mark approved
[13:42] <greyback> yeah that old hack is unnecessary with qtcomp
[13:43] <mzanetti> mterry: I could only mark it as "Merged" directly, couldn't set it to "Approved"
[13:43] <mzanetti> not sure why :)
[13:44] <mterry> mzanetti, you're presumably not in the team -- but it's interesting that you could mark as Merged  :)
[13:44] <mzanetti> yeah, that's the "not sure why". It makes perfect sense that I can't approve it
[13:44] <greyback> mzanetti: it even calls you "Community" :)
[13:45] <mterry> greyback, what about the jenkins failures?
[13:46] <mterry> are they unrelated?
[13:46] <mterry> or just a lack of the other mirCompositor branches...
[13:47] <greyback> mterry: lack of the qtcomp branches. I wan the AP tests on my device and they gave me same results as without
[13:47] <mterry> greyback, cool
[13:47] <greyback> mterry: https://docs.google.com/a/canonical.com/spreadsheets/d/1W8yTODgOlYzUlxr_nbF5Bc9neThUmfRUWCNtmCRxiI8/edit#gid=0
[13:48] <greyback> mterry: I got 3 fails  with or without qtComp, so I guess it's ok
[14:32] <mzanetti> mterry: can you update me on the syntax of the unity8-greeter-demo file? I keep forgetting
[14:33] <mterry> [phablet]
[14:33] <mterry> password=pin
[14:33] <mterry> passwordValue=1234
[14:33] <mterry> mzanetti, ^
[14:33] <mzanetti> mterry: cheers
[15:32] <Saviq> mterry, hey, we almost landed locking hash in u8 and settings yesterday... but then realized it will "lock out" people out of their phones... do you have any plan for that?
[15:34] <mterry> Saviq, ah yes.  So please don't land those until https://code.launchpad.net/~mterry/livecd-rootfs/no-password/+merge/225560 lands -- which is in discussion.  That branch should have the side effect of changing everyone's password to blank upon upgrade to it
[15:39] <Saviq> mterry, oh good, should you add that branch to the silo?
[15:39] <Saviq> mterry, or does it need to go through manual upload?
[15:40] <mterry> Saviq, manual upload.  It also depends on a pam update I'm doing that will be manual too
[15:46] <Saviq> mterry, ok thanks
[15:47] <Saviq> mterry, btw, not really "your" bug, but unity-system-compositor started crashing recently in one of the unity8 tests
[15:47] <Saviq> mterry, because in that test unity8 was not started through upstart
[15:47] <Saviq> mterry, so it fought with u-s-c for hardware
[15:48] <Saviq> mterry, but apparently it was fine until recently...
[15:48] <Saviq> mterry, I'm fixing the test, but maybe you'd like details on the crash in any case?
[15:49] <mterry> Saviq, maybe a bug?
[15:49] <Saviq> mterry, I'll get some symbols and file it, yeah
[15:49] <Saviq> mterry, I'd actually *think* unity8 should fail to start when u-s-c is running...
[15:57] <Saviq> mterry, hmm it's actually an abort, can't see any message anywhere, though
[15:58] <greyback> mterry: I need to discuss https://code.launchpad.net/~mterry/qtmir/packaging-fixes/+merge/226693 with you, let me know when you've a few mins to spare
[15:59] <mterry> greyback, ah sure
[16:00] <mterry> greyback, so in my mind, I'm not actually changing any behavior with that branch
[16:01] <mterry> just cleaning things up
[16:01] <greyback> mterry: I'm pretty novice with packaging :)
[16:02] <greyback> mterry: I guess I just want to make sure it's possible to install only the *-android packages, or the *-desktop packages, and not mix & match them
[16:02] <mterry> greyback, right.  So I dropped some the -android or -desktop from the Conflicts/Replaces which makes you worried we can mix/match
[16:02] <greyback> mterry: but honestly, I might be better off asking someone else to review ;)
[16:03] <mterry> greyback, so qtubuntu or qtmir are virtual packages provided by the -android/-desktop versions.  If we Conflict/Replace on the virtual package, it will Conflict/Replace on anything that provides that virtual package.  So we should get the correct behavior
[16:03] <mterry> greyback, but maybe get a second opinion on this branch, yes
[16:11] <greyback> seb128: ping
[16:13] <seb128> greyback, hey
[16:13] <greyback> seb128: hey there, can I ask for 5 mins of your packaging expertise?
[16:13] <seb128> sure
[16:13] <greyback> seb128: https://code.launchpad.net/~mterry/qtmir/packaging-fixes/+merge/226693
[16:14] <greyback> I just don't know enough to feel comfortable approving it
[16:15] <seb128> if it comes from mterry it's probably right ;-)
[16:15] <seb128> let me review it still
[16:16] <mterry> seb128, I dunno man, virtuals give me a headache too  :)
[16:19] <seb128> mterry, " You can just provide the virtual names rather than specific ones, and apt will figure it out." ... you seem to know more than me ;-)
[16:23] <seb128> I've pinged mvo about it
[16:23] <seb128> I don't know if that claims about virtual and apt is true ;-)
[16:24] <seb128> mterry, I think that's going to be buggy
[16:24] <seb128> qtdeclarative5-qtmir-plugin depends on qtmir but -android/-desktop Conflicts qtmir
[16:24] <seb128> how can that work?
[16:25] <mterry> seb128, See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces (7.6.2)
[16:26] <mterry> seb128, it has an example of mail-transport-agent both providing and conflicting on its own virtual
[16:26] <mterry> seb128, I *think* it should work based on that
[16:26] <seb128> mterry, k, makes sense
[16:26] <mterry> seb128, but that's theory and memory of seeing it elsewhere.  I couldn't test in a PPA because the build is weird
[16:27] <mterry> seb128, so maybe if someone that has done this before can confirm that would be extra safe
[16:27] <seb128> mterry, what about the other issue?
[16:27] <seb128> mterry, I've pinged mvo about this one
[16:27] <mterry> seb128, which?
[16:28] <seb128> mterry, the :24 qtmir conflicts
[16:28] <seb128> C,R,P works as a "take that one as a replacement"
[16:28] <seb128> but the plugin depends on the name you C,R,P
[16:29] <mterry> seb128, oh right, you mean I should have a non-virtual there?  like "qtmir | qtmir-desktop" ?
[16:29] <mterry> That's fair
[16:29] <seb128> no
[16:30] <seb128> but if
[16:30] <seb128> qtdeclarative5-qtmir-plugin depends qtmir
[16:30] <seb128> and -android/-desktop conflicts it
[16:30] <seb128> it means -plugin can't be installed at the same time than -android/-desktop
[16:30] <seb128> is that what you want?
[16:30] <seb128> C,R,P is not a "provide the other name"
[16:31] <Saviq> elopio, would you have time to look at https://code.launchpad.net/~saviq/unity8/fix-autopilot-x11/+merge/227720 please?
[16:31] <seb128> it's a "take over the old name, be a replacement, ensure the old name is uninstalled"
[16:31] <elopio> Saviq: of course.
[16:31] <seb128> mterry, ^ so the C,R,P ensure there is no qtmir, which plugins wants one
[16:31] <mterry> seb128, well I think the CRP stuff is apt-magic.  It must treat them specially, since like that debian policy example shows, you can CPR on the same name and then other packages can reference your virtual fine (it would seem)
[16:32] <seb128> mterry, hum, right, CRP is usually "that's the new replacement of <name>"
[16:32] <seb128> can you check with mvo still?
[16:32] <seb128> I need to call it a day
[16:32] <mterry> seb128, sure no that's sensible to do
[16:32] <mterry> seb128, I'll bug mvo
[16:32] <seb128> thanks
[16:32] <mterry> seb128, see ya!
[16:32] <seb128> I can have another look tomorrow if you want
[16:33]  * mterry has to go grab lunch himself
[16:33] <Saviq> elopio, ok, no, that doesn't work yet :|
[16:33] <seb128> bye!
[16:34] <elopio> Saviq: this is to fix bug #1346819, right?
[16:46] <Saviq> elopio, yes
[16:49] <Saviq> mterry, any idea why I don't have MIR_SERVER in env on the phone?
[16:50] <Saviq> hmm hmm hmm
[16:51] <greyback> Saviq: what do you need it for?
[16:51] <Saviq> greyback, trying to find out whether usc is there
[16:51] <Saviq> greyback, my problem: unity8 launched outside of upstart
[16:52] <Saviq> greyback, fighting with usc for hardware
[16:52] <Saviq> (in ap tests)
[16:52] <greyback> Saviq: interesting. MIR_SOCKET would be set by the usc job if usc launched
[16:52] <Saviq> greyback, yeah, it is, in upstart
[16:53] <Saviq> greyback, not in shell... I just wonder if that's right, and HTH is it then possible to launch apps from console at all
[16:53] <greyback> Saviq: yeah it's a bit unfriendly, MIR_SOCKET should be set in the user's env
[16:54] <Saviq> greyback, any idea how apps can launch at all?
[16:54] <Saviq> (from the console I mean)
[16:54] <greyback> Saviq:you need "MIR_SOCKET=$XDG_RUNTIME_DIR/mir_socket" I think
[16:54] <Saviq> greyback, yeah, I don't, that's the thing :)
[16:55] <Saviq> greyback, they launch just fine without it
[16:55] <greyback> Saviq: so they're using the default mir socket, /run/mir_socket
[16:55] <Saviq> greyback, yeah, connecting to usc, hth do they show up in unity8? :D
[16:55] <greyback> is unity8 the nested or system comp?
[16:56] <Saviq> greyback, nested, of course
[16:56] <greyback> Saviq: then apps got smarter recently
[16:56] <greyback> I dunno :)
[16:56] <Saviq> greyback, maybe default is XDG_RUNTIME_DIR?
[16:56] <greyback> quite possibly
[16:57] <greyback> if you install mir-demos, and run a client with the help switch, it probably says so. In fact yeah, I think it does
[17:00] <Saviq> greyback, k, that explains a bit
[17:00] <Saviq> greyback, and also explains why unity8 doesn't die when starting when usc is running
[17:00] <Saviq> greyback, because usc creates /run/mir_socket when unity8 creates /run/user/32011/mir_socket
[17:01] <greyback> Saviq: correct
[17:01]  * Saviq needs to check [ -S /run/mir_socket ] then :|
[17:18] <Saviq> elopio, back to you again, https://code.launchpad.net/~saviq/unity8/fix-autopilot-x11/+merge/227720 works now
[17:19] <Saviq> thanks!
[17:24] <mterry> Saviq, just got back from lunch -- MIR_SERVER should be set by lightdm
[17:33] <elopio> Saviq: ok, I'll run it in my mako.
[17:55] <greyback> Saviq: have you EODed?
[18:13] <elopio> Saviq: your branch has a whitespace error.
[18:14] <elopio> I'm not sure what your whitespace script checks, but I see lin 29 on the diff with extra spaces. It might be that.
[18:14] <greyback> mzanetti: is this the spread bug you occasionally find? http://imgur.com/h0J7GbP
[19:03] <mzanetti> greyback: I've seen this once... will keep an eye on it
[19:04] <greyback> mzanetti: yea, not sure how I managed it. I think I opened about 8 apps, then went to spread, then open indicators and tapped a system setting option. Then when I wanted to go to spread again, I saw that
[21:06] <Saviq> greyback, back now if you still need me
[21:06] <Saviq> elopio, thanks, will fix
[21:06] <greyback> Saviq: I wanted to point you to https://code.launchpad.net/~saviq/qtmir/gles-sync-20140716/+merge/227000
[21:07] <Saviq> elopio, fixed
[21:07] <greyback> we'll hopefully soon have qtmir in a landing state, so that'll need to be updated to match the qtmir package version
[21:08] <greyback> but I've no idea about robru's comments
[21:08] <Saviq> greyback, I replied
[21:08] <Saviq> greyback, he put the comment both inline and in a regular comment, I replied in a regular comment
[21:09] <Saviq> greyback, will sync the version now
[21:09] <greyback> Saviq: ta. As long as you came to an agreement, I don't mind
[21:09] <Saviq> greyback, I'll poke him
[21:24] <Saviq> elopio, btw, had one more thing to ask you, would you consider expectFail() used like I did here https://code.launchpad.net/~saviq/unity8/dash-header-style/+merge/227652
[21:25] <Saviq> elopio, to be an abuse of what expectFail stands for? i.e. can expectFail be used as a correct, passing condition as opposed just to skip broken tests?
[21:29] <elopio> Saviq: for me, that's the correct use of expectFail, to check a negative test.
[21:29] <Saviq> elopio, cool
[21:44] <Saviq> elopio, if you could at least review that branch for py correctness, that'd be great, we'll tackle any other review steps if needed
[21:44] <Saviq> robru, hey, I replied to https://code.launchpad.net/~saviq/qtmir/gles-sync-20140716/+merge/227000/comments/548740