[08:38] <didrocks> hey Saviq! I think you saw thomi's answer, but I think he's mixing 2 issues
[08:38] <Saviq> didrocks, yeah
[08:38] <didrocks> there is actually an AP test reliably failing now
[08:38] <didrocks> I think we should first focus on that one to avoid misunderstanding :)
[08:38] <Saviq> didrocks, I just replied to the post - should be fixed now
[08:38] <didrocks> oh
[08:39] <Saviq> didrocks, it was failing on uitk
[08:39] <Saviq> didrocks, not having transitioned to py3
[08:39] <Saviq> which happened yesterday AFAICT
[08:39] <didrocks> hum
[08:39] <didrocks> let me look
[08:39] <didrocks> ok, it's in #221
[08:39] <didrocks> let me look at the test result :)
[08:39] <didrocks> once ci.ubuntu.com loaded
[08:40] <didrocks> ah indeed :)
[08:40] <didrocks> thanks Saviq!
[08:40] <didrocks> Saviq: btw, not sure you have time, but did you gave a look at the theme?
[08:41] <Saviq> didrocks, I did, and we tweaked some things with Mathieu, but we had to file bug #1284235
[08:42] <Saviq> didrocks, I actually pushed the fixes to your branch already
[08:43] <Saviq> didrocks, but also Mathieu had to add some symlinks and such, we were missing battery charging icons - maybe you can check with him if the package should get updated?
[08:43] <didrocks> Saviq: yeah, I told him about the battery, I didn't update the package
[08:43] <didrocks> Saviq: ok, so basically, we can have a silo with the theme change today
[08:43] <didrocks> (even without the sdk fix?)
[08:43] <Saviq> didrocks, yeah, he agreed to squish them
[08:44] <Saviq> didrocks, that I didn't know before http://ci.ubuntu.com/smokeng/trusty/touch/mako/221:20140305:20140304/6988/unity8/853561/
[08:44] <didrocks> Saviq: if only the .crash file was per test and not per testsuite …
[08:44] <Saviq> didrocks, that's not the crash, for sure
[08:45] <Saviq> didrocks, I'll look into it
[08:45] <didrocks> because he was able to kill the apps?
[08:45] <didrocks> or you think autopilot doesn't return "" if the app didn't answer?
[08:45] <Saviq> didrocks, it should raise I think, if the test app failed
[08:46] <Saviq> didrocks, anyway, I'll see if I can repro - I got 100% on Qt 5.2 though, will run it a few times to see if it's reliable
[08:46] <didrocks> Saviq: ok :)
[08:46] <tsdgeos> Saviq: the bluetooth crash is gone, now there should be a x misplacement of the highlight when disabling it
[08:47] <didrocks> Saviq: keep me posted, once you know about that one, we'll see if we can set a silo for the theme + unity8 + system settings
[08:47] <Saviq> tsdgeos, you can't even see it on the phone - the page is gone as soon as you touch it
[08:47] <Saviq> tsdgeos, at least I couldn't
[08:47] <tsdgeos> Saviq: but open the indicators again
[08:47] <Saviq> tsdgeos, ah you mean that the tab bar is misplaced? yes
[08:47] <tsdgeos> no
[08:47] <tsdgeos> the orange bar highlight under the icon
[08:47] <tsdgeos> it'll be misplaced
[08:47] <Saviq> ah that
[08:48] <tsdgeos> https://code.launchpad.net/~aacid/unity8/indicator_highlight_x_position/+merge/209400 fixes it
[08:48] <Saviq> will try and see, autopiloting now
[08:57] <Cimi> Saviq, ciao :) we forgot this https://code.launchpad.net/~unity-team/unity8/new-scopes.carousel-dinamic-fallback/+merge/207451
[08:57] <Saviq> Cimi, we didn't forget ;)
[08:58] <Cimi> hah
[08:58] <Saviq> Cimi, I'm cleaning up new-scopes and looking into how we're going to merge it all into trunk, so I have my eyes on your branch
[08:59] <tsdgeos> Saviq: are you aware of my cleanup branch?
[08:59] <Saviq> tsdgeos, btw, checklist for your MP please
[08:59] <tsdgeos> Saviq: it's there
[08:59]  * Saviq refreshes
[09:00] <Cimi> Saviq, I'm trying to catch up after mwc/holidays
[09:00] <Saviq> tsdgeos, it's marked WiP https://code.launchpad.net/~aacid/unity8/new-scopes-cleanup/+merge/207921 :)
[09:00] <Cimi> Saviq, what's current priority for us?
[09:00] <Saviq> Cimi, getting Qt 5.2 in, then new scopes and right edge
[09:00] <Saviq> tsdgeos, also, I didn't see the gradient changes in there?
[09:01] <tsdgeos> Saviq: because it is WiP (i.e. the plan was to get all the tests working and they don't yet), just making sure you're not doing the same work again
[09:01] <Saviq> tsdgeos, ah no no
[09:01] <tsdgeos> let me re-merge it
[09:01] <Saviq> tsdgeos, I'm just looking into what's in new-scopes and what of that should go away (native orientation stuff) or get into separate MPs into trunk
[09:02] <tsdgeos> ah
[09:02] <tsdgeos> ok
[09:02] <Saviq> tsdgeos, one such would I think be sidestage-over-dash, which could go into trunk I think (after having added some tests)
[09:03] <tsdgeos> probably could yes
[09:03] <tsdgeos> have to check if i'm using something from new-scopes specific
[09:05] <Saviq> tsdgeos, think we could add a test for lp:~aacid/unity8/indicator_highlight_x_position ?
[09:07] <tsdgeos> Saviq: we could, have to code a fake indicator that hides itself when clicking on it, not sure if it's worth the hassle tbh
[09:07] <Saviq> tsdgeos, does it need to be "when clicking on it"? I mean just for the highlight
[09:07] <Saviq> tsdgeos, shouldn't it be "focus an indicator, remove it, check highlight"?
[09:08] <tsdgeos> Saviq: sure, but the highlight only gets of sync when you're doing something like the bluetooth indicator (and you're using Qt 5.2.1)
[09:08] <Saviq> tsdgeos, k
[09:08] <tsdgeos> otherwise it would be a test that doesn't test what the code fixes
[09:16] <tsdgeos> Saviq: so what do we do with https://code.launchpad.net/~aacid/unity8/bring_hud_quit_back/+merge/203020 ? do i get it out of WIP or just discard it?
[09:21] <Cimi> Saviq, hud going away from the bottom?
[09:25] <tsdgeos> Cimi: yep, see https://code.launchpad.net/~mzanetti/unity8/disable-hud/+merge/209226
[09:26] <tsdgeos> mzanetti: i'm surprised the hud autopilot tests didn't fail in https://code.launchpad.net/~mzanetti/unity8/disable-hud/+merge/209226
[09:26] <Cimi> tsdgeos, ok that I noticed hud being confusugint at mwc
[09:26] <Cimi> tsdgeos, do we have another design?
[09:26] <mzanetti> tsdgeos: I disabled them
[09:26] <tsdgeos> mzanetti: ah right, can't read
[09:26] <mzanetti> tsdgeos: I renamed them from test_hud.py to disabled_test_hud.py
[09:27] <tsdgeos> Cimi: don't know tbh
[09:27] <mzanetti> its a bit small in the diff
[09:28] <mzanetti> did our autopilot tests get more unstable lately?
[09:29] <tsdgeos> mzanetti: on plain unity8 or in the new-scopes one?
[09:29] <tsdgeos> mzanetti: added a needs fixing to that disable hud thing
[09:29] <tsdgeos> mzanetti: though maybe you can just let it live
[09:29] <seb128> pete-woods, hey, could you have a look to https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1288025? That seems a regression in the "new" hud (new as the new codebase, not in a recent update)
[09:30] <mzanetti> tsdgeos: thanks. good catch. will fix
[09:30] <tsdgeos> mzanetti: do you think you should make the hud plugin not compile too?
[09:30] <tsdgeos> mzanetti: i.e. plugins/HudClient/
[09:30] <mzanetti> tsdgeos: hmm... I really don't know... will ask Saviq on this
[09:31] <mzanetti> I mean, it will come back at some point
[09:31] <mzanetti> so the plugin will probably still be needed
[09:31] <tsdgeos> sure
[09:40] <pete-woods> seb128: sure, will look into it
[09:40] <seb128> pete-woods, thanks
[09:41] <pete-woods> seb128: can confirm that I can reproduce it with evince
[09:41] <seb128> good
[09:46] <Saviq> tsdgeos, re: hud quit, we can merge it, it's not gonna be in use, but at least it'd be in sync with the backend if/when we want to bring it back
[09:47] <tsdgeos> Saviq: ok, i'll put it to needs review then
[09:50] <Saviq> mzanetti, leave the plugin be, it's not being loaded so it's fine, we'd only save minimal build time
[09:50] <Saviq> Cimi, no new design yet, no
[09:58] <mzanetti> Saviq: ack
[10:00] <maxb> Hello, is unity the correct package to report a bug against if it goes away way setting UBUNTU_MENUPROXY=0 ?
[10:01] <maxb> Ugh, I should have proofread that sentence
[10:01] <maxb> Hello, is unity the correct package to report a bug against if it goes away when UBUNTU_MENUPROXY=0 is set?
[10:03] <Saviq> maxb, "it goes away" meaning unity crashes? if so, you should have a related .crash file (compiz probably) in /var/crash
[10:03] <maxb> Sorry, I mean "the bug no longer manifests"
[10:03] <Saviq> maxb, what bug is that?
[10:03] <maxb> gnome-terminal has a setting to disable menu access keys. It is no longer honoured in trusty
[10:04] <RAOF> Yeah, that's kinda annoying.
[10:04] <Saviq> maxb, yeah, that sounds like a unity bug indeed
[10:05]  * maxb does the 'also affects' thing
[10:08]  * apw has some HUD keybinding issues, which is suspect are actually upgrade of settings not working issues:
[10:08] <apw> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1288154
[10:10] <seb128> Trevinho, bregma, ChrisTownsend: ^
[10:11] <larsu> maxb: what's the bug # for that? I remember somebody discussing this recently
[10:11] <larsu> maxb: the problem is that unity grabs those keys before gnome-terminal sees them
[10:11] <maxb> bug 1282203
[10:11] <larsu> and of course unity doesn't know about the setting...
[10:11] <larsu> maxb: thanks
[10:14] <larsu> maxb: are you sure about that? I still get the keys when setting UBUNTU_MENUPROXY
[10:14] <maxb> get the keys?
[10:14] <larsu> menu access keys are still enabled
[10:15] <larsu> which makes sense, I don't think anything looks at that env variable in the gmenumodel case
[10:16] <larsu> ah wait, it is still using unity-gtk-module
[10:16] <seb128> larsu, maxb: is the bug you discuss the one fixed by https://code.launchpad.net/~attente/unity-gtk-module/gtk-enable-mnemonics/+merge/207752 ?
[10:16] <maxb> UBUNTU_MENUPROXY=1 (default) - the setting to disable the keys doesn't work, things like Alt+E are intercepted and not passed to my irssi;  UBUNTU_MENUPROXY=0 - the Alt+E keypress and similar do make it through to my irssi
[10:17] <larsu> seb128: thanks :)
[10:17] <seb128> yw!
[10:17] <seb128> we should land that soon, it's just waiting for desrt to do another review round
[10:17] <seb128> but he said he wouldn't block it further in the previous review so it should be ready
[10:19] <maxb> That looks nice.
[10:19]  * maxb dupes the other bug
[10:19] <mhr3_> seb128, ping? oh dpkg master, would you know how can i get demangled c++ names in .symbols file?
[10:19] <maxb> oh, someone got there first :-)
[10:20] <seb128> mhr3_, not sure there is a good solution for c++ symbols, I just know "they are so annoying to deal with that we often end of not having a .symbols"
[10:20] <seb128> mhr3_, better to ask didrocks, he's probably more aware of the current status there
[10:21] <mhr3_> didrocks, oh dpkg master, share your endless wisdom please
[10:21] <didrocks> mhr3_: seb128: https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_exposing_a_new_C.2BAC8-C.2B-.2B-_symbols_in_my_library.2C_it_seems_that_some_packaging_changes_are_needed.2BICY-
[10:21] <didrocks> see "NB! For C++ the diff will be using mangled symbol names, but if you pipe the diff through C++filt, you can get the demangled name. For example if the diff has a clearly C++ symbol like this one:
[10:22] <didrocks> "
[10:22] <RAOF> didrocks is too fast!
[10:22] <didrocks> ;)
[10:22] <RAOF> mhr3_: Also, “man dpkg-gensymbols” /c++
[10:22] <seb128> didrocks, thanks
[10:22] <didrocks> yw
[10:24] <mhr3_> merci
[10:26] <mhr3_> the sed there is just magical
[11:06] <tsdgeos> pete-woods: hud-service at 100% again :-/
[11:08] <tsdgeos> and back to 0%
[11:08] <tsdgeos> weird
[11:10] <pete-woods> tsdgeos: strange indeed
[11:11] <pete-woods> it's definitely something to do with dbusmenu-qt's dbusmenuimporter, I'm starting to develop the motivation to give it some serious attention
[11:23] <tsdgeos> pete-woods: actually my computer went trough a massive swap to disk spell
[11:23] <tsdgeos> so may have been that
[11:23] <tsdgeos> ended with 2G of swap disk used
[11:23] <pete-woods> tsdgeos: fingers crossed!
[11:23] <pete-woods> wow
[11:23] <tsdgeos> meaning my computer was kind of unresponsive for a good 5 mins :D
[11:23] <tsdgeos> yeah compiling qtwebkit is something i have to learn not to do so often :D
[11:24] <pete-woods> since I stuck 16GB of RAM in my computer (for a grand total of £50 IIRC) I don't seem to use swap any more
[11:24] <pete-woods> ha!
[11:24] <pete-woods> yeah, that's like compiling openoffice!
[11:44] <dandrader> mzanetti, ping
[11:45] <mzanetti> dandrader: hi
[11:45] <dandrader> mzanetti, hi. about your unity8/right-edge-2 branch. It works fine on tablet?
[11:45] <mzanetti> dandrader: it should, yes. The sidestage is not perfect, but I think its not much worse that the trunk version
[11:46] <mzanetti> s/that/than/
[11:46] <anpok> I currently try to resolve some issues we have with the input_region functionality of mir surfaces..
[11:47] <anpok> I just saw that unity mir also exposes that functionality in MirSurface.
[11:47] <dandrader> mzanetti, ok. I'm using it as the starting point for a unity8 version that works as a mir compositor.
[11:47] <mzanetti> dandrader: \o/
[11:47] <dandrader> fyi, as you were away late last week
[11:48] <mzanetti> dandrader: please let me know how it works, and feel free to ping me about issues or other questions you have with it
[11:48] <anpok> So I wonder what is the expectation here. When the Surface moves around.. should those regions move together with the surface?
[11:48] <dandrader> mzanetti, I spent  a lot of time just adapting to the unity-api changes it needs
[11:48] <mzanetti> dandrader: right... I did some changes there too
[11:49] <mzanetti> dandrader: mostly about the screenshotting stuff. but afaiu that would go away again, right?
[11:49] <anpok> hence those coordinates in the input regions are trated as being inside the local co-ordinate system of the surface
[11:49] <dandrader> mzanetti, well, I think there would still be screenshotting for the dash thumbnails
[11:50] <mzanetti> dandrader: hmm... really? I would probably just drop that altoghether and put the real surfaces in there too (if thats ok from a resource consumption pov)
[11:51] <mzanetti> anpok: I'd say yes, that's how qml works at least
[11:51] <anpok> good - makes my live simpler too
[11:51] <mzanetti> anpok: I think dandrader can help with details on this
[11:52] <anpok> dandrader: if thats not the expected behavior unity-mir would have to change when we also support free floating windows..
[11:53] <Saviq> tsdgeos, re: see-through main stage... maybe base your work on mzanetti's branch?
[11:53] <anpok> dandrader: up to now input_region was in global co-ordinate system.. and nobody updates it when surfaces move around - so I think it is a simpler behavior to have them specified as local co-ordinates
[11:53] <dandrader> anpok, as a side note: "Input regions" won't be used anymore once we move to have unity8 as the mir compositor.
[11:53] <mzanetti> Saviq: tsdgeos: my branch does that already. If there's only a side stage app running, you can see the dash background and interacti with that
[11:54] <Saviq> mzanetti, so that needs fixing, you shouldn't be able to interact with it, at least that's what we did for MWC
[11:54] <anpok> dandrader: ok - means you are fine with local..?
[11:54]  * dandrader looks at the MirSurface vs input_region code
[11:54] <mzanetti> Saviq: huh?
[11:54] <mzanetti> Saviq: why wouldn't you be able to interact with it?
[11:54] <dandrader> anpok, give me a minute to look at the code
[11:54] <tsdgeos> mzanetti: darken the dash and clicking on it hides the sidestage
[11:55] <tsdgeos> that's what the new-scopes branch did
[11:55] <Saviq> mzanetti, https://bugs.launchpad.net/unity8/+bug/1127665
[11:55] <tsdgeos> Saviq: mzanetti: so what do i do? stop the separate merge altogether since mzanetti's branch already kind of does it? or?
[11:55] <Saviq> mzanetti, that's obviously kind of tangential, with the rehaul of tablet right edge and side stage...
[11:55] <Saviq> tsdgeos, sounds like it
[11:56] <mzanetti> really... ok... well, will change it then... but I really liked that I can launch another app from the dash even though the SS is open
[11:56] <mzanetti> you still could drag the sidestage away with the draghandle
[11:56] <Saviq> mzanetti, do you know if it's like that in the new sidestage/right-edge design?
[11:57] <dandrader> anpok, right, input areas are in the local coordinate system of the surface they belong to
[11:57] <mzanetti> Saviq: I don't think the spec specifies that at all. It felt like the proper thing to me to do it that way.
[11:57] <mzanetti> will check back with design
[11:57] <Saviq> mzanetti, please do, mention that bug - maybe it needs overturning
[11:57] <mzanetti> ack
[11:58] <anpok> dandrader: good. thanks for looking.
[11:58] <Saviq> mzanetti, and mark your branch for that bug, please, too
[11:58] <dandrader> anpok, or at least that's how unity-mir and unity8 expects them to be
[11:58] <tsdgeos> ok, then this one was fast :D
[11:58] <mzanetti> tsdgeos: so yeah. please don't do anything related to this anywhere else than on top of my branches
[11:58] <tsdgeos> mzanetti: i'll leave it to you i guess :)
[11:58] <mzanetti> ok
[11:58] <tsdgeos> since you kind of have it done anyway
[11:59] <anpok> will try to fulfill that expectation
[12:10] <mzanetti> Saviq: re your comment on the hud branch: do I read it correctly that you've added the first comment by mistake and revoked the Needs Fixing with the abstain comment?
[12:10] <Saviq> mzanetti, yes
[12:10] <mzanetti> ok
[12:10] <Saviq> mzanetti, the "abstain" I believe means that I abstain from the vote, not to abstain with the branch ;)
[12:11] <mzanetti> yeah, didn't want to add 5 function decorators when there's only hud tests in the whole file anyways
[12:11] <Saviq> yup
[12:14] <mzanetti> Cimi: what exactly does the BottomBarVisiblityCommunicatorShell do? iirc you created that one
[12:15] <tsdgeos> mzanetti: it talks to the sdk toolbar
[12:16] <tsdgeos> and tells it to show/go away/stuff
[12:16] <Saviq> tsdgeos, re: fixing screenshot.visible - I just removed it 'cause it's wrong
[12:16] <tsdgeos> Saviq: want me to have a look at LVWPH tests with 5.2?
[12:16] <mzanetti> tsdgeos: so the question is: If I remove that , will that break something the SDK expects?
[12:16] <Saviq> tsdgeos, it's always meant to be visible, AFAICT
[12:16] <Saviq> tsdgeos, will have a look again
[12:16] <Saviq> tsdgeos, but yes, please have a look at those
[12:16] <tsdgeos> mzanetti: no, it will just not talk to their end
[12:17] <tsdgeos> mzanetti: though maybe something will be waiting to the dbus name to appear
[12:17] <tsdgeos> maybe just leave it in
[12:17] <Saviq> tsdgeos, for an even easier way to reproduce some issues with the tests (that I would like to get rid of (the issues)):
[12:17] <tsdgeos> or remove it from both places
[12:17] <Saviq> xvfb-run -s "-screen 0 1024x768x24" make -C builddir qmltests
[12:18] <mzanetti> mhm... Saviq, are we sure we don't need the bottombar stuff any more? I could also drop it from the SDK in that case
[12:18] <Saviq> mzanetti, there's no new design yet
[12:18] <mzanetti> so better leave it for now?
[12:18] <Saviq> mzanetti, but I doubt it's going to come back into the bottom edge
[12:18] <Saviq> mzanetti, so sounds like it can be safely removed from there, too
[12:19] <mzanetti> ok then. I'll drop stuff
[12:19] <tsdgeos> Saviq: ok
[12:19] <Saviq> tsdgeos, LD_PRELOAD=/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 might be you're on nvidia or fglrx or some such
[12:19] <Saviq> tsdgeos, any fixes - just push to the same branch
[12:20] <Saviq> s/be/be needed/
[12:20] <Saviq> +if
[12:20] <Saviq> ugh
[12:44] <mhr3_> Saviq, got my msg yesterday about gotoScope?
[12:44] <Saviq> dandrader, hey, could you please extract the rotated DDA changes and MP them into trunk?
[12:44] <Saviq> mhr3_, don't think I did
[12:44] <mhr3_> Saviq, http://paste.ubuntu.com/7038320/
[12:44] <didrocks> Saviq: are you sure it's supposed to be fixed by the sdk? #221 has latest sdk and it's still failing: http://ci.ubuntu.com/smokeng/trusty/touch/mako/221:20140305:20140304/6988/unity8/853561/
[12:45] <Saviq> didrocks, I told you that failure is not something I understand
[12:45] <Saviq> didrocks, and couldn't reproduce locally
[12:45] <Saviq> didrocks, it *could* be that the app crashed, and so it didn't focus
[12:45] <didrocks> Saviq: ok
[12:45] <dandrader> Saviq, aren't hey all in tunk already?
[12:47] <dandrader> Saviq, revision 721
[12:47] <Saviq> dandrader, right, that explains things!
[12:47] <Saviq> dandrader, as you were ;)
[12:55] <dandrader> mzanetti, trying to build your unity-scopes-shell/activate-appid-2 branch on the device: http://paste.ubuntu.com/7038367/
[12:55] <dandrader> mzanetti, what am I missing?
[12:57] <Saviq> mhr3_, no, I won't invalidate it
[12:57] <Saviq> mhr3_, at least I don't think I will, but to get it displayed in the UI we might need some code
[12:57] <Saviq> minimal
[12:57] <Saviq> mhr3_, so... I think it'd be fine if you dealt with it internally
[12:58] <Saviq> mhr3_, that would work later for annotations, too
[12:58] <mhr3_> Saviq, ok, that feature should be deployed on the server soon, so we'll see how much it (doesn't) works :)
[12:58] <Saviq> mhr3_, indeed
[13:02] <Saviq> tsdgeos, did you put the gradient changes somewhere in the end?
[13:02] <Saviq> tsdgeos, I'm feeling like we should just commit it to new-scopes separately from the cleanup
[13:08] <dandrader> mzanetti, so in src/Unity/scopes-ng/scope.cpp:166  -> s/Handled/HideDash ?
[13:08] <mzanetti> dandrader: not sure what you're talking about. let me check the code
[13:09] <dandrader> mzanetti, just try compiling that branch on the latest device image
[13:10] <mzanetti> hmm... don't really see yet how that would be related to scopes-ng, but /me tries
[13:15] <dandrader> mzanetti, ahh, I think that's because I'm trying to use your branch directly instead of merging it with trunk
[13:16] <mzanetti> dandrader: which indicates that I need to merge my branches and update them. will do so. thanks
[13:16] <Saviq> mhr3_, btw, can we s/template/renderer/ in -scopes? or are you really friendly with the "renderer" name?
[13:16] <Saviq> erm
[13:17] <Saviq> make that s/renderer/template/
[13:17] <mhr3_> Saviq,  idont like template cause it's c++ keyword :P
[13:18] <Saviq> mhr3_, ugh, categoryTemplate then?
[13:18] <Saviq> mhr3_, we're naming it template everywhere else...
[13:20] <mhr3_> i don't really care that much, if you want it renamed, so be it
[13:21] <Saviq> mhr3_, I just wanted it to be consistent
[13:24] <pstolowski> sil2100, ping
[13:25] <sil2100> pstolowski: pong
[13:25] <sil2100> What's up?
[13:26] <pstolowski> sil2100, hey, is lp:~sil2100/unity-scopes-api/dependencies still needed?
[13:26] <Saviq> tsdgeos, how about https://code.launchpad.net/~aacid/unity8/fix-new-scopes-tab-name-missing/+merge/206162 - do we want that separate into trunk, or maybe an actual bug against uitk?
[13:26] <Saviq> and/or
[13:26] <sil2100> pstolowski: uuuh, what the heck is that?
[13:26] <sil2100> I would say no, but let me check
[13:26] <pstolowski> sil2100, you tell me :) https://code.launchpad.net/unity-scopes-api
[13:34] <mzanetti> dandrader|afk: I've merged trunk
[13:54] <jdrab> hi guys does unity(7) in 14.04 need "indirect context rendering support" ? i don't understand what it exactly is or how it works but for me unity on 14.04 does not work :/
[13:56] <jdrab> unity_support_test http://paste.ubuntu.com/7038608/
[13:59] <jdrab> oh and btw "does not work" means there is no window decoration,panel,launcher absolutelly nothing :/
[14:01] <tsdgeos> Saviq: i was told that tabs are going away
[14:02] <tsdgeos> like in the whole uitk
[14:02] <tsdgeos> and thus made no sense to open bugs against it
[14:02] <tsdgeos> or that's what i understood
[14:02] <Saviq> tsdgeos, ok, think it makes sense to merge it separately from new-scopes?
[14:03] <tsdgeos> Saviq: the bugfix? don't know, i think the fact that we use new-scopes made the bug much more promiment
[14:03] <tsdgeos> i can almost never see it in trunk
[14:03] <tsdgeos> but quite often in new-scopes
[14:04] <tsdgeos> Saviq: not sure what you mean with the gradient changes
[14:04] <Saviq> tsdgeos, I sent you a diff last week or something
[14:04] <tsdgeos> ah yes
[14:04] <Saviq> tsdgeos, that was moving the gradients back from DashRenderer (and ...Apps.qml) to GenericScopeView
[14:04] <tsdgeos> it's on the cleanup branch
[14:04] <tsdgeos> i think
[14:04] <Saviq> tsdgeos, didn't see it there
[14:04] <tsdgeos> or maybe it's in the seemore branch
[14:05] <tsdgeos> yes
[14:05] <tsdgeos> it's in the seemore
[14:05] <tsdgeos> http://bazaar.launchpad.net/~aacid/unity8/grid-see-more/revision/697
[14:05] <Saviq> tsdgeos, I'll just pull that one commit into new-scopes
[14:05] <tsdgeos> Saviq: sure
[14:06] <Saviq> tsdgeos, as it annoys me ;)
[14:07] <tsdgeos> lol, i just found a nice bug in QGLXPbuffer that basically makes the xcb plugin make uninitialized memory accesses on every single app start :D
[14:08] <tsdgeos> wonder how we don't get much more crashes
[14:12] <seb128> bregma, andyrock: what's the status of the lock screen? still trying to land it for the lts?
[14:13] <bregma> seb128, there's a weird problem in the jenkins builds, but at this point I'm starting it through the prep for the next ci-train landing
[14:13] <bregma> which means I buildm install, and test locally
[14:14] <bregma> and we need to coordinate changes to the other packages with you
[14:15] <bregma> shall we try to land all changes in the same silo?
[14:16] <dandrader> mzanetti, about your right-edge-2 branch (on a tablet): I launch two main stage apps. One of them is being displayed. what should happen on a right-edge drag?
[14:16] <Saviq> tsdgeos, Cimi, btw, I've cleaned up new-scopes for merging (still a few minor things to do), please (re)base your new-scopes-related branches on that, MP into trunk with that one as prerequisite
[14:16] <tsdgeos> Saviq: okidoki
[14:16] <Saviq> a simple merge from it should work
[14:17] <tsdgeos> Saviq: you think we should backport https://codereview.qt-project.org/#change,80007 ? see comment from Laszlo Agocs
[14:17] <seb128> bregma, yes, having somebody from your team commenting on the ffe to reply to Laney's comments would be nice (I would like to know as well what components need to be patch and in which way, and what happens if somebody want to go back to use g-s for some reason)
[14:17] <mzanetti> dandrader: hmm... well, what should happen is that the app spread comes in... but that's not there yet
[14:18] <Saviq> tsdgeos, sounds like yeah, let's
[14:18] <Saviq> tsdgeos, for your cleanup branch... think we should merge it into the above or separate MP for just the cleanup?
[14:18] <mzanetti> dandrader: want me to implement a temporary right edge behavior for now?
[14:18] <tsdgeos> Saviq: "merge it into the above" ? what is "the above"?
[14:18] <mzanetti> otherwise I would build the proper animation on top of that as soon as we got it merged
[14:18] <mzanetti> dandrader: ^
[14:18] <Saviq> tsdgeos, new-scopes-clean-to-trunk
[14:18] <Saviq> tsdgeos, or maybe we could go for a split: test fixes and such in one branch, all red (removing unused files) separate?
[14:19] <dandrader> mzanetti, no, it's fine. I just want to make sure that I'm getting what I'm supposed to get
[14:19] <tsdgeos> Saviq: that's what i had originally, and then you told me to batch it all :D
[14:19] <Saviq> tsdgeos, I know ;)
[14:19] <tsdgeos> Saviq: i don't mind either way
[14:19] <Saviq> tsdgeos, yeah, let's merge it into one branch
[14:20] <Saviq> tsdgeos, btw, did you do something with DashFilterGrid? it looked to me like we could get rid of it, there's only CardFilterGrid using it now, so the wrapping can be gone probably
[14:20] <mzanetti> dandrader: so basically the StageWithSideStage.qml is quick and dirty "make-it-look-similar-as-in-trunk" and really not polished. The rest should be production code tho.
[14:21] <dandrader> mzanetti, ok.
[14:21] <tsdgeos> Saviq: i killed it in the SeeMore branch
[14:21] <Saviq> tsdgeos, ok
[14:21] <Saviq> tsdgeos, good enough
[14:21] <tsdgeos> Mirv: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1288278
[14:23] <Cimi> Saviq, ok
[14:25] <Cimi> Saviq, tsdgeos we review against 5.2 now?
[14:25] <Saviq> Cimi, not yet
[14:25] <Saviq> Cimi, or, well, against both, ideally
[14:25] <Cimi> I am doing a review but I realised it doesn't work
[14:26] <andyrock> seb128, i fixed the failing tests
[14:26] <andyrock> but jenkins fails for some reason
[14:27] <andyrock> seb128, can you trigger a re-build?
[14:27] <seb128> andyrock, good, what about the questions on the ffe/the impact on things that "call lockscreen"? do we need to patch them to use a new interface? does that let a fallback for people not using unity?
[14:28] <tsdgeos> Cimi: what doesn't work?
[14:28] <Cimi> tsdgeos, tests
[14:28] <andyrock> in teory we should patch gnome-session to provide a interface to lock the screen
[14:28] <tsdgeos> Cimi: with 5.2.1? we're fixing some at https://code.launchpad.net/~unity-team/unity8/fix-5.2-tests/+merge/209058
[14:28] <andyrock> gnome-session should emit the logind signal
[14:29] <andyrock> and all the things that "call lockscreen" should use the gnome-session interface
[14:29] <seb128> andyrock, when I tried I ended up in cases where g-s was running as the lockscreen...
[14:29] <seb128> hum, k
[14:29] <andyrock> yeah but because you enabled it
[14:29] <andyrock> it's disabled by default
[14:30] <Saviq> Cimi, standup,
[14:31] <seb128> andyrock, oh ok, well, I enabled it because after session restart ctrl-alt-L was giving me a gnome-screensaver lock
[14:32] <andyrock> yeah we should disable that shortcut
[14:32] <andyrock> super+l is the correct one
[14:33] <seb128> can we have both?
[14:33] <seb128> lot of people (me included) are used to ctrl-alt-L and would get confused if it stops working
[14:38] <Cimi> dednick, didn't hear you well, can you paste me notes in pct?
[14:38] <Cimi> pvt
[14:48] <Saviq> tsdgeos, how does testLauncher fail for you?
[14:48] <tsdgeos> Saviq: test_quicklist_positioning
[14:49] <tsdgeos> seems the flicking doesn't actully work
[14:49] <tsdgeos> using 5.2.1
[14:49] <Saviq> tsdgeos, passed fine here :/
[14:49] <Saviq> tsdgeos, I think I saw that failure under a different GRID_UNIT_PX though
[14:49] <Saviq> tsdgeos, ah now it failed
[14:50] <Saviq> ok, so somewhat unreliable
[14:50] <Saviq> we'll need to look at it
[14:51] <Saviq> dednick, the guy fixed his phone... but created a new thread every time he posted a message on the ML...
[14:52] <Saviq> dednick, https://lists.launchpad.net/ubuntu-phone/msg06744.html
[14:55] <dednick> Saviq: yeah, i saw that after I replied
[14:58] <tsdgeos> Saviq: yeah :-/
[15:05] <apw> does anyone know if it is possible to add a mouse binding to the title bar of a window in unity?
[15:06] <apw> (i am pretty sure i used to be able to bind mouse-2 on the title bar to "lower", but it is gone and i cannot remember how i might have done it)
[15:07] <tsdgeos> Saviq: lazyimage failed too
[15:08] <Saviq> tsdgeos, hmm fine here, too
[15:08]  * Saviq tries under xvfb
[15:09] <Saviq> hmm works
[15:09] <tsdgeos> this one http://paste.ubuntu.com/7038936/
[15:09] <Saviq> ah got one to fail
[15:10] <Saviq> tsdgeos, try http://paste.ubuntu.com/7038941/
[15:10] <Saviq> tsdgeos, I had that for xvfb, but seems it might be needed for you as well
[15:10] <tsdgeos> let's see
[15:16] <tsdgeos> Saviq: i can't make it to fail again so not sure if it fixes it :D
[15:17] <Saviq> tsdgeos, ;)
[15:17] <Saviq> tsdgeos, try under xvfb
[15:17] <Saviq> tsdgeos, but a waitForRendering() would be a better fix anyway
[15:17] <tsdgeos> hmmm actually i fails quite a bit on xvfb
[15:18] <tsdgeos> the 10 seconds don't help either
[15:18] <Saviq> tsdgeos, just testLazyImage?
[15:18] <tsdgeos> sure
[15:18] <tsdgeos> actually i think it's the other way around
[15:18] <Saviq> hmm is fine here :/
[15:18] <tsdgeos> and the transition is already finished when it gets there
[15:18] <tsdgeos> i mean i upped the tryCompare to 20 secs
[15:19] <tsdgeos> and it's still failing
[15:19] <Saviq> tsdgeos, ok, will look into it
[15:20] <tsdgeos> ok
[15:20] <tsdgeos> tell me if you need testing
[15:20] <tsdgeos> since it is quite stable here in failing
[15:37] <karni> hey guys, can we have someone kick the phone-right-edge build? archive unity8 is again newer than the ppa
[15:41] <Saviq> karni, that's expected, we didn't want anything to replace the MWC builds (hence the devices were rid of the usual archive)
[15:41] <Saviq> karni, we'll be merging right edge and new-scopes into trunk soon enough, is there anything in particular you're looking for?
[15:50] <karni> Saviq: I see. nah, it's nothing critical.
[15:50] <karni> Thanks :)
[15:57] <mhr3> didrocks, the instructions for the c++ symbols are awesome, unfortunately the diff generated by dh_makeshlibs is broken, it can't be just applied to the symbols file
[15:58] <mhr3> didrocks, i mean not even after passing it through c++filt
[15:58] <didrocks> mhr3: oh? weird, I've been using my own instructions for quite a while though
[15:59] <mhr3> didrocks, i just get hunk failed for everything it generates
[15:59] <didrocks> mhr3: hum, maybe for the first time, you should just copy and paste the whole generated file
[16:00] <mhr3> didrocks, yea sure, this is when the symbols change
[16:05] <Saviq> Cimi, https://code.launchpad.net/~unity-team/unity8/new-scopes.carousel-dinamic-fallback/+merge/207451/comments/492804
[16:06] <Cimi> Saviq, ok
[16:54] <Cimi> Saviq, that you're awayre
[16:55] <Cimi> *aware
[16:55] <Cimi> Saviq, this logic comes from somewhere? https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941
[16:55] <Cimi> for pinch
[17:31] <Saviq> Cimi, not sure what you mean?
[17:31]  * Saviq doesn't know AnimatedImage, though...
[17:32] <Saviq> I don't think that should be used
[17:40] <Cimi> Saviq, I mean the js code I see here
[17:40] <Cimi> Saviq, it has some magic numbers like 0.98 or 0.1 or such
[17:40] <Cimi> wondering who wrote the original code
[17:41] <Saviq> Cimi, yeah, dunno, didn't look at it yet
[17:41] <Cimi> Saviq, I can review the code
[17:42] <Cimi> Saviq, just wondering if someone else already reviewed that
[17:42] <Saviq> Cimi, would probably leave a comment if they did :)
[17:42] <Cimi> Saviq, although it sounds reasonable to me having a pinch to zoom image component in the sdk
[17:42] <Saviq> Cimi, indeed
[17:43] <dandrader> anyone knows what should I do when I start getting this on the device when runnint unity8?
[17:43] <dandrader>  "** (process:2815): WARNING **: Unable to connect to Upstart bus: Could not connect: Connection refused"
[18:20] <Saviq> dandrader, restart lightdm
[18:20] <Saviq> dandrader, means your user session died
[18:20] <Saviq> dandrader, if you get a init .crash file, report it, too
[18:20] <dandrader> Saviq, hmmm, I was trying out running "init --user" from a phablet ssh shell
[18:21] <dandrader> Saviq, seems to do the trick...
[18:21] <dandrader> Saviq, so we already have lightdm (system compositor) on the device?
[18:21] <Saviq> dandrader, yeah, that probably helps, too, although might be lost when you connect again
[18:22] <Saviq> dandrader, well, lightdm was there all the time, launching the user session without system compositor
[18:22] <Saviq> dandrader, but now we have unity-system-compositor enabled, too
[18:22] <Saviq> greeter not split yet
[18:22] <dandrader> hmm
[18:23] <dandrader> Saviq, and lightdm lives on the upstart system session so I should start it from a roo@device?
[18:23] <Saviq> dandrader, yes