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