[09:21] <tsdgeos> Saviq: are we going to land stuff soon ? https://code.launchpad.net/~unity-team/unity8/trunk/+activereviews is getting crowded again
[09:21] <Saviq> tsdgeos, yeah, I'll prep a silo today
[09:21] <tsdgeos> :)
[09:53] <Saviq> pstolowski, hey, you had a silo for bottom edge in dash didn't you?
[09:54] <Saviq> damn mterry has all the tags again
[09:54] <mzanetti> :)
[09:55] <Saviq> pstolowski, hmm or was it kgunn's silo
[09:55] <Saviq> in any case, what's the status there from your PoV?
[10:08] <pstolowski> Saviq, I had last week, but had to pull that feature off for a moment from that silo
[10:08] <Saviq> pstolowski, ok
[10:08] <pstolowski> Saviq, because of the issues with search (and we had to unblock and land other stuff)
[10:08] <Saviq> pstolowski, I'm landing unity8 soon, but without the bottom menu then
[10:09] <pstolowski> Saviq, we're waiting for green light fro search changes from design today. when we get it, i'll request a new silo
[10:09] <pstolowski> Saviq, ok, sure
[10:09] <Saviq> pstolowski, yup, I should be hopefully done by then
[11:10] <tsdgeos> Cimi: https://code.launchpad.net/~cimi/unity8/fix-1368778-2/+merge/242942 ?
[11:10] <tsdgeos> mzanetti: why are you marked as reviewer in https://code.launchpad.net/~mzanetti/unity8/spread-opacity-changes/+merge/242915 ?
[11:10] <tsdgeos> MacSlow: how is https://code.launchpad.net/~macslow/unity8/swipe-dismiss-snap-decisions/+merge/233347 going?
[11:11] <mzanetti> tsdgeos: wrong click in launchpad... I wanted to "request another review" but accidentally clicked on "claim review"
[11:11] <tsdgeos> mzanetti: ah, ok
[11:11] <tsdgeos> i'll top approve then
[11:11] <mzanetti> tsdgeos: cool, thanks
[11:13] <MacSlow> tsdgeos, almost...I'll poke you when it's ready
[11:13] <tsdgeos> MacSlow: cool :)
[11:14] <tsdgeos> Saviq: why didn't CI run in https://code.launchpad.net/~nick-dedekind/unity8/lp1385331.led/+merge/241417 ?
[11:14] <Saviq> tsdgeos, good queston
[11:15] <Saviq> +i
[11:15]  * Saviq needs to talk to fginther
[11:15] <tsdgeos> Saviq: if you have the vpn setup can you trigger it?
[11:15] <Saviq> tsdgeos, yeah doing
[11:15] <tsdgeos> tx
[11:15] <Saviq> tsdgeos, ah, think I found the reason...
[11:15] <Saviq> tsdgeos, jobs are blocked for 2 days now
[11:15] <tsdgeos> oh
[11:16] <Saviq> on autopilot
[11:16] <tsdgeos> all to the red!
[11:16] <Saviq> yeah
[11:16] <tsdgeos> that's bad :/
[11:29] <tsdgeos> Saviq: so what do you want to do with https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1384776 ? The root cause is fixed in Qt but we can still make it "better" (i.e. less dbus handling) with https://code.launchpad.net/~aacid/unity8/networkingstatus in our side
[11:29] <tsdgeos> want to keep it open or just mark it as invalid?
[11:29] <tsdgeos> since it isn't really an unity8 bug?
[11:29] <Saviq> tsdgeos, invalidated
[11:29] <facundobatista> Holas
[11:30] <tsdgeos> Saviq: oki
[11:30] <tsdgeos> Saviq: hola hola
[11:31] <Saviq> tsdgeos, ?
[11:31] <tsdgeos> er
[11:31] <tsdgeos> facundobatista: hola hola
[11:31] <tsdgeos> Saviq: wrong mind autocompletion
[11:31] <Saviq> tsdgeos, "hola hola" is ~"waaaait a minute" in PL ;D
[11:31] <facundobatista> tsdgeos, :)
[11:31] <tsdgeos> Saviq: really?
[11:31] <tsdgeos> lol
[11:32] <Saviq> tsdgeos, yeah, it's a sound you'd make when someone would get ahead of themselves
[11:32] <Saviq> not a real word I think
[11:33] <Saviq> actually it is, means "stop doing that!" according to the dictionary
[11:36] <alan_g> greyback: as promised I've been hacking at qtmir - would you take a look at https://code.launchpad.net/~alan-griffiths/qtmir/new-migrate-to-mir-Server-API/+merge/243177 when you have the time?
[11:37] <greyback> alan_g: certainly
[11:38] <mzanetti> Saviq: hey, seeing you unassign RTM targets from yourself, should I stop assigning them to you?
[11:39] <Saviq> mzanetti, yeah, someone else might be landing after all
[11:39] <mzanetti> ok
[11:39] <Saviq> mzanetti, I'll be leaving them New until we know when to land, Triaged when they have a milestone into RTM, and assign them, and make In Progress, when I actually want to silo them
[11:39] <mzanetti> ok
[11:43] <Cimi> tsdgeos, fixed
[11:44] <tsdgeos> Cimi: ok
[11:45] <mzanetti> dandrader: what's the ETA for the rotation stuff?
[11:50] <dandrader> mzanetti, I guess late next week.
[11:52] <dandrader> mzanetti, code is pretty much done. but the last 3% can be slow. like coordinating changes with SDK
[11:52] <tsdgeos> Cimi: why all that commenting code?
[11:52] <Cimi> tsdgeos, because mzanetti says we will need something similar for desktop
[11:52] <mzanetti> dandrader: well, I hoped that desktop stuff would have landed a week ago... by now it's so many branches chained that I stopped working on it because it's becoming a pain
[11:53] <mzanetti> Saviq: is there something that prevents us from landing the desktop stuff?
[11:53] <Cimi> tsdgeos, we have option of making the timer do nothing (but still running it), or comment code
[11:53] <Saviq> mzanetti, they're not reviewed? ;)
[11:53] <mzanetti> Saviq: well, the first one is, by gerry
[11:54]  * greyback gonna have a review day, so can look at them
[11:54] <Saviq> mzanetti, not acked though https://code.launchpad.net/~mzanetti/unity8/desktop-stage/+merge/242140
[11:54] <greyback> mzanetti: ^^
[11:54] <mzanetti> greyback: cool
[11:55] <Saviq> mzanetti, one thing I'd add there - a minimum GU size for desktop stage
[11:55] <Saviq> mzanetti, not sure we want desktop stage on phone even if you enable it...
[11:56] <greyback> but but convergence!
[11:56] <Saviq> maybe we do, after all The Hypothesis Generator™ will take it into account
[11:56] <mzanetti> Saviq: yeah... but that's the kind of stuff that will change a lot...
[11:56] <mzanetti> exactly the HG will come into place
[11:56] <mzanetti> for now I'd say lets keep disruptive changes in Shell.qml as small as possible
[11:56] <Saviq> kk
[11:56] <mzanetti> (imho)
[11:57] <Saviq> mzanetti, you know, though, we'll need this all to become a single stage in the end? for nice transitions between modes? ;)
[11:57] <mzanetti> I was thinking about that yeah...
[11:58] <mzanetti> really not sure how to do that yet
[11:58] <Saviq> seb128, I just grepped through /usr for Ubuntu.Connectivity, looks like you guys are using it but not depending on it
[11:58] <Saviq> and we just dropped our dep
[12:06] <Saviq> mzanetti, unity8.application_lifecycle.tests.test_application_lifecycle.ApplicationLifecycleTests.test_app_moves_from_unfocused_to_focused fails with your spread changes (I expect the spread threshold change, as it's getting into spread when it shouldn't)
[12:06] <Saviq> silo 3 for reference
[12:07] <mzanetti> ack, will check
[12:09] <Saviq> tsdgeos, small one for you https://code.launchpad.net/~saviq/ubuntu-system-settings/add-connectivity-dep/+merge/243273
[12:10] <Saviq> tsdgeos, but also, unity8.shell.tests.test_emulators.GenericScopeViewEmulatorTestCase.test_open_preview fails
[12:10] <Saviq> tsdgeos, it seems with all your branches it takes a really long time for the dash to load the fake scopes
[12:10] <Saviq> mzanetti, tsdgeos, it's all in silo 3 for reference
[12:10]  * Saviq is running qml tests on it then
[12:11] <Saviq> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-003
[12:11] <mzanetti> tsdgeos: sorry, vesar just found an issue with this: https://code.launchpad.net/~mzanetti/unity8/spread-opacity-changes/+merge/242915
[12:11] <tsdgeos> Saviq: that's autopilot, right?
[12:11] <mzanetti> tsdgeos: I fixed it already, but requires another approval I guess
[12:11] <Saviq> tsdgeos, yes
[12:11] <tsdgeos> Saviq: doesn't make sense it takes more time, but i'll check
[12:12] <Saviq> tsdgeos, yeah, I know, but I can see it sit there for a really long time
[12:14] <tsdgeos> ok
[12:15] <tsdgeos> mzanetti: pushed?
[12:15] <mzanetti> tsdgeos: I'd say yes
[12:15] <tsdgeos> mzanetti: don't se it in the mr page
[12:15] <mzanetti> tsdgeos: rev 1452
[12:16] <mzanetti> tsdgeos: diff looks good too
[12:16] <mzanetti> not sure why it doesn't show up in the comments history
[12:16] <Saviq> tsdgeos, looks like the failure first showed up in https://code.launchpad.net/~aacid/unity8/photoscopeimprovements/+merge/239834
[12:16] <Saviq> tsdgeos, CI phones are dead until someone goes there and reflashes them, so for another few hours still
[12:16] <tsdgeos> ok
[12:17] <Saviq> tsdgeos, yeah, same failure I got https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/334/testReport/junit/unity8.shell.tests.test_emulators/GenericScopeViewEmulatorTestCase/test_open_preview_Nexus_4_/
[12:17] <tsdgeos> oki, will check
[12:21] <Saviq> we need more reliable AP tests, both of the tests I just saw fail failed in CI, too :?
[12:21] <Saviq> /food
[12:21] <tsdgeos> Saviq: approved https://code.launchpad.net/~saviq/ubuntu-system-settings/add-connectivity-dep/+merge/243273
[12:21] <Saviq> tsdgeos, tx
[12:35] <Saviq> Cimi, hey, could you help dandrader and greyback testing shell rotation today?
[12:35] <Saviq> dandrader, greyback, what device btw?
[12:35] <greyback> Saviq: phone for first pass
[12:36] <greyback> then tablet after, N7, then N10 is possible
[12:38] <Saviq> greyback, maybe we can parallelize then
[12:39] <greyback> sure, if anyone else available
[12:41] <Saviq> MacSlow|lunch, when you swallow, could you help the guys test shell rotation ↑
[12:41] <Saviq> https://wiki.ubuntu.com/Unity8/FullShellRotation
[12:42] <MacSlow|lunch> Saviq, noted
[12:44] <seb128> Saviq, hey, could be, can you open a bug about that?
[12:45] <Saviq> seb128, already building in my silo, want a bug nevertheless?
[12:45] <seb128> Saviq, no, it was for tracking, you have a mp coming that works too ;-)
[12:45] <Saviq> seb128, https://code.launchpad.net/~saviq/ubuntu-system-settings/add-connectivity-dep/+merge/243273
[12:46] <seb128> Saviq, why did you guys stop depending on it? Is it buggy/should we stop using it as well?
[12:47] <Saviq> tsdgeos, ↑
[12:47] <tsdgeos> we did and then we did not
[12:47] <Saviq> seb128, ah no, we just didn't need it
[12:47] <tsdgeos> lunch calling, i'll give a longer answer later :D
[12:47]  * Saviq conflates it with QNAM stil
[12:47] <Saviq> l
[12:51] <Saviq> mzanetti, testPhoneStage fails for me here, too
[12:52] <mzanetti> really
[12:52] <Saviq> in test_enterSpread
[12:52] <Saviq> and test_selectAppFromSpread
[12:52] <mzanetti> strange... I did test/fix that
[12:52] <mzanetti> will check again
[12:52] <Cimi> Saviq, sure
[12:53] <Saviq> mzanetti, it passed fine in jenkins, at least a while ago
[12:54] <Saviq> mzanetti, but it might be some interaction with the other MPs
[12:54] <Saviq> although nothing seems related
[12:55]  * Saviq tries trunk + reversible
[12:57] <Saviq> mzanetti, yeah in ↑I get 4 failures
[12:57] <Saviq> 5 from the silo
[12:58] <mzanetti> Saviq: ap test fixed. looking into qmltests now
[12:58] <Saviq> tx
[12:59] <mzanetti> Totals: 25 passed, 0 failed, 0 skipped
[13:00] <mzanetti> yeah, fails after merging
[13:01] <Saviq> mzanetti, aha, lp:~dandrader/unity8/fixTestCaseTouchFlick impacts that, too
[13:01] <Saviq> got 6 fails now
[13:01] <Saviq> with yours + ↑
[13:01] <Saviq> need food
[13:23] <mzanetti> Saviq: should all work again now
[13:43] <Saviq> mzanetti, okies
[13:51] <tsdgeos> seb128: Saviq: so we were using it for something, we don't need it anymore since we changed the feature, so it's gone, *but* it will be back once https://code.launchpad.net/~aacid/unity8/networkingstatus/+merge/239694 is merged
[13:51] <seb128> tsdgeos, ok, good to know, thanks
[13:51] <Saviq> well, back but in a different way
[13:51] <Saviq> not the qml module
[13:51] <Saviq> but the Qt lib
[13:52] <tsdgeos> seb128: so no, it's not "bad", it's just that we're not using it for what we used to be because we don't do that anymore
[13:52] <tsdgeos> Saviq: true
[13:52] <seb128> k
[14:07] <larsu> tsdgeos: is this the thing using the new nm property that desrt added?
[14:08] <tsdgeos> larsu: i don't know
[14:08] <larsu> tsdgeos: you proposed the branch, no?
[14:08] <tsdgeos> larsu: yes, i am not the coder of libconnectivity-qt1-dev, just the user
[14:09] <mterry> mzanetti, hey, remember when you were looking at that branch that loaded the greeter async, and I had some weird problems with the infographic that were solved by an empty Connections object?  Where did we leave that?  Did you end up having any thoughts of where I should look?
[14:09] <mzanetti> mterry: not really, sorry... I do agree something weird is going on, but couldn't figure what
[14:10] <larsu> tsdgeos: hm, seems to use com.ubuntu.connectivity1...
[14:10] <mterry> mzanetti, I guess I should play with timing (which was what originally exposed the problem) and see if I can make it go away
[14:10] <tsdgeos> Saviq: is there a branch with all those branches in silo3?
[14:11] <mzanetti> mterry: yeah... there are different ways of making it go away, still a bit unsatisfying that we've no idea what's going on
[14:11] <larsu> pete-woods: what supplied com.ubuntu.connectivity1?
[14:11] <larsu> sorry, *supplies
[14:11] <Saviq> tsdgeos, not a branch, but you can take the tarball from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-003/+sourcepub/4596048/+listing-archive-extra
[14:11] <Saviq> mterry, you got tags all over the place again
[14:12] <mterry> Saviq, ugh do you have a branch list?
[14:12] <Saviq> mterry, ./strip-tags.py `grep lp: | cut -d" " -f1`
[14:13] <Saviq> mterry, and paste the whole of https://code.launchpad.net/unity8/+activereviews
[14:13] <Saviq> mterry, and Ctrl+D
[14:13] <mterry> hah
[14:13] <mzanetti> still doesn't work for me :D
[14:13] <Saviq> mterry, but really, you must have them locally somewhere, just make sure you run the script on all your local checkouts too
[14:15] <mzanetti> look at that. it does work now
[14:15] <mterry> Saviq, yup.  Just sometimes it seems like the remotes ones hold on to tags even after I've cleaned things locally
[14:15] <mterry> So I need to make sure I do a clean sweep of both at the same time
[14:22] <Saviq> mterry, they *always* do hang to the tags
[14:22] <Saviq> mterry, you have to run the strip tags script on lp:~foo
[14:26] <pete-woods> larsu: I think that's the connectivity API
[14:26] <pete-woods> larsu: maintained by Wellark
[14:26] <larsu> pete-woods: no, that just uses it. Looks like indicator-network (of all places?) supplies it
[14:27] <larsu> pete-woods: I wonder why it's not using the property desrt added to network-manager
[14:27] <pete-woods> larsu: maybe it should? maybe Wellark doesn't know about this new property? maybe it's not what he needed? (I have no context here)
[14:28] <larsu> pete-woods: me neither. Trying to find out right now. Just pinged you because you wrote connectivity-api, but that seems to be the qt wrapper only
[14:29] <larsu> pete-woods: I thought we talked to the relevant people in DC, but apparently it didn't trickly through or something
[14:29] <pete-woods> larsu: I didn't write connectivity API. I generated some Qt bindings that the indictor secret-agent uses
[14:29] <pete-woods> perhaps they are also used for connectivity API now
[14:30] <larsu> pete-woods: ah, might be. Saw your name on launchpad on some page associated with it. Sorry :)
[14:30] <pete-woods> larsu: yeah, I created the project on LP for Antti, as he was v. busy at that point
[14:31] <larsu> :)
[14:31] <pete-woods> :)
[14:51] <mterry> Saviq, fyi, all my branches are clean of tags now
[14:55] <tedg> larsu, I think that long term we won't be able to use that as we want to move applications off of talking to the system bus.
[14:56] <tedg> larsu, When we loose fine grained control of dbus with kdbus we won't be able to do confinement of specific attributes.
[14:59] <larsu> tedg: it still talks to the bus via an API and we don't lose anything with kdbus, it's just that the service does the enforcing now instead of the daemon
[15:03] <tedg> larsu, No, the service does the enforcing not the security module… which is designed to enforce policy.
[15:04] <tedg> larsu, It does it via the daemon, but it can't in the future as there's not enough information available.
[15:04] <larsu> tedg: what information is missing? The kernel supplies all the necessary bits, no?
[15:05] <tedg> larsu, Nope, the headers were removed as "redundant"
[15:05] <larsu> tedg: I don't think that's true, but I also don't care enough to have this argument now
[15:26] <tsdgeos> Saviq: i can reproduce the problem, trying to find out if i can see why is it so much slower in autopilot or at least just make it pass
[15:46] <attente_> mzanetti: hi
[15:47] <attente_> mzanetti: how did you implement this (window positioning)? https://www.youtube.com/watch?v=MXHulRlq10s, is it using the mir client api?
[15:49] <mzanetti> attente_: it's using that api through qtmir
[15:49] <mzanetti> so in the end it's just moving QtQuick items around
[15:52] <attente_> mzanetti: how does qtmir tell mir where to place the surfaces? is there a way?
[15:52] <attente_> mzanetti: also, could you point me to the branch where your window management code is?
[15:53] <tsdgeos> Saviq: i pushed a change that makes the test pass
[15:53] <tsdgeos> i'll now revert to trunk and see if it's really slower or just more async (and that's why i need wait_select_single instead of select_single)
[15:57] <mzanetti> attente_: this is the branch in unity8: https://code.launchpad.net/~mzanetti/unity8/desktop-stage
[15:57] <mzanetti> attente_: and this is the qtmir code, the one that does the interaction with mir: https://code.launchpad.net/~mir-team/qtmir/trunk
[15:59] <attente_> mzanetti: thanks! i'll take a look
[16:02] <mzanetti> attente_: so what happens is that qtmir maps the client buffer to a QQuickItem
[16:02] <mzanetti> attente_: based on the position and size of that QQuickItem in the shell, qtmir tells Mir where to draw the buffer
[16:02] <mzanetti> maybe even draws it on its own, not exactly sure
[16:03] <attente_> mzanetti: but there isn't any client api for specifying the position of the surface is there?
[16:05] <mzanetti> attente_: ah, hmm... not sure if we support that yet. definitely not up to the unity8 level yet. it's on our todo
[16:05] <mzanetti> attente_: the plan is to use the toolkit's apis. so in Qt you would resize your QApplicationWindow (or what it's called)
[16:06] <attente_> mzanetti: oh. forgot to mention, we're need to implement this in the gdk-mir backend :)
[16:07] <mzanetti> attente_: right... so I don't know much about gdk, but I assume there is some sort of MainWindow class there too
[16:08] <mzanetti> greyback: do you know about the state of the client positioning/sizing api?
[16:08] <attente_> mzanetti: right, but we can't implement it at all if we don't have a way to position surfaces in the client api, no?
[16:09] <mzanetti> attente_: good question. I don't know about the state of that in Mir. I'm mostly looking at it from the shell perspective. You might want to ask in #ubuntu-mir about the client side apis
[16:09] <greyback> attente_: Mir will not allow clients to position themselves in general. But it will allow clients to request position & dimensions for a surface on creation, but that's not implemented yet unfortunately
[16:10] <greyback> it will be up to the shell to decide whether to do what the client asks or not.
[16:11] <attente_> greyback: so if a gtk app asks to set the position of the window, we have to request it from the shell?
[16:12] <greyback> attente_: you can ask for x:100, y:200. The shell might honor it, it might not, depending on its policy (e.g. on a phone, those coordinates would not be respected)
[16:12] <mzanetti> I guess you still request it from Mir, that one will forward it to the shell and the shell then does it (or not)
[16:12] <greyback> attente_: for menus, shell is very likely to respect the position
[16:12] <greyback> but that position will be relative to the parent surface
[17:21] <dandrader> mzanetti, I'm purging that ApplicationManager.ExecFlags in the shellRotation branches as it's no longer needed (as we now have separate Phone and Tablet stages)
[17:21] <mzanetti> dandrader: +1
[17:22] <mzanetti> dandrader: I think qtmir shouldn't on which stage some surface is
[17:22] <mzanetti> dandrader: I think qtmir shouldn't know on which stage some surface is
[17:22] <mzanetti> or at least it shouldn't care about it
[17:22] <mzanetti> maybe for convenience some flag is to be stored in there, but it shouldn't actually do anything with it
[17:23] <mzanetti> dandrader: greyback is purging focus handling from there currently, you might want to sync with him as he probably killed that flag too
[17:24] <dandrader> greyback, hmmm, do you plan to land that branch before shellRotation?
[17:24] <greyback> dandrader: after
[17:25] <greyback> dandrader: if you're making changes that aren't essential to shell rotation, please keep them in separate branches to minimize diffs
[17:28] <dandrader> greyback, there are quite a few cases like this in the shellRotation branches
[17:28] <greyback> dandrader: ok well use your judgement
[17:28] <dandrader> greyback, I would like to put them all in separate MPs
[17:28] <dandrader> greyback, but the work involved in creating and testing them all is just too much
[17:28] <dandrader> too time consuming
[17:31] <greyback> dandrader: sure I see that. But just consider the reviewers
[19:08] <cwayne> blargh, after installing fglrx my cursor is huge -- changing /org/gnome/desktop/interface/cursor-size doesnt seem to stick..
[19:45] <cwayne> anyone have any idea why setting a setting in dconf-editor wouldn't stick across reboots?
[19:58] <cwayne> Trevinho: ping
[20:03] <cwayne> bregma: also ping
[20:10] <davmor2> cwayne: it hates you?
[20:11] <davmor2> cwayne: check your resolution in the catalyst admin app
[20:11] <bregma> cwayne, no idea, dconf is dconf
[20:12] <cwayne> so there's something weird re: scaling and my cursor
[20:13] <cwayne> if im in chrome/pidgin its one size, then as soon as i go to the launcher, cursor gets huge
[20:13] <cwayne> driving me completely insane
[21:16] <Saviq> mterry, all your local checkouts, too? :)
[21:16] <mterry> Saviq, yes  :)
[21:18] <Saviq> mterry, coolz