[08:46] <tsdgeos> greyback_: https://code.launchpad.net/~aacid/qtmir/no_double_search/+merge/272707 ?
[08:48] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/stabilize-launcher-test-more/+merge/272708
[08:48] <mzanetti> tsdgeos, thanks
[08:48] <mzanetti> would've never found this without being able to repro :/
[08:51] <tsdgeos> yeah, repro is nice in these cases
[08:52] <tsdgeos> well mostly always :D
[08:53] <greyback_> tsdgeos: nice find, thanks
[08:56] <mzanetti> tsdgeos, did you intentionally set my branch as target?
[08:58] <tsdgeos> mzanetti: i did intentionally set your branch as prerequisite, and failed :D
[08:58] <tsdgeos> fixing
[08:58] <mzanetti> ok :)
[09:01] <tsdgeos> mzanetti: now https://code.launchpad.net/~aacid/unity8/stabilize-launcher-test-more/+merge/272709
[09:39] <Saviq> tsdgeos, looks like your clazy run MP reduced our memory usage significantly enough that Victor could not get webbrowser to get OOM-killed on arale ;)
[09:40] <tsdgeos> lol
[09:40] <tsdgeos> really?
[09:40] <mzanetti> wat
[09:40] <Saviq> he struggled to get it killed indeed
[09:40] <Saviq> and nothing else in the list looks to me like could have any impact https://requests.ci-train.ubuntu.com/#/ticket/410
[09:41] <Saviq> maybe all the QStringLiterals?
[09:41] <mzanetti> well, arale is also not the best example to try to repro that
[09:41] <Saviq> that'd be dumb seeing what QSL is
[09:42] <tsdgeos> well
[09:42] <Saviq> mzanetti, yeah, but he went: silo → can't get it killed; no silo → killed; silo → can't get it killed
[09:42] <tsdgeos> the nice thing about it
[09:42] <tsdgeos> is not that it saves memory
[09:42] <tsdgeos> it's that it doesn't fragment it
[09:42] <tsdgeos> so it saves much more memory than what it really saves
[09:42] <tsdgeos> since doesn't need to allocate/deallocate it
[09:42] <tsdgeos> all the time
[09:43] <Saviq> right
[09:43] <mzanetti> yeah, I would have expected it to have a bigger impact on perf than on actual usage
[09:43] <mzanetti> but glad to hear it also gets us better there
[09:54] <pstolowski> Saviq, hey, I got a svg icon for the dash from design (to be used in unity8-dash.desktop), do you have any recommendations where to put it? qml/graphics/applicationIcons?
[10:14] <Saviq> pstolowski, data/
[10:19] <Saviq> hmm can't access launchpad and other Ubuntu servers...
[10:20] <Saviq> anyone else have problems?
[10:21] <pstolowski> Saviq, work here
[10:21] <tsdgeos> works here too
[10:21] <Saviq> tx
[10:21] <tsdgeos> i have problems accessing the yahoo servers though :D
[10:22] <tsdgeos> so maybe the internet is breaking little by little
[10:22] <Saviq> might be
[10:22] <Saviq> yeah it's back again for me
[10:22] <tsdgeos> and yahoo is back here too :D
[10:22] <tsdgeos> weird
[10:22] <mzanetti> I am struggling too
[10:23] <greyback> me too
[10:23] <mzanetti> launchpad, IRC...
[10:23] <mzanetti> google stuff seems ok
[10:38] <Saviq> ltinkl, hey, greyback pointed me at https://launchpad.net/libqtdbustest that could be useful for the dbus mocking (although in the case of logind it's probably easier to just use the template provided by dbusmock)
[10:43] <ltinkl> Saviq, hi, thanks for the ref, I can have a look if it provides something better
[10:51] <popey> kgunn: dpm tells me you had fun with xorg recently - a bad update? (I'm getting xorg exploding randomly on my intel laptop) wondered if there was a bug to follow or some other detail?
[10:52]  * tsdgeos got a xorg update in vivid overlay
[10:52] <tsdgeos> now i'm scared to reboot :D
[11:12] <popey> tsdgeos: I'm on wily :)
[11:12] <tsdgeos> ok
[11:25] <Mirv> unity8 requires webbrowser nowadays?
[11:44] <Saviq> Mirv, we need the web view
[11:45] <Saviq> Mirv, to display the HERE terms
[12:11] <Mirv> Saviq: ok. I just noticed it since a) Oxide just (re)gained dependency on private Qt ABI, needing a rebuild, b) Oxide fails to rebuild against Qt 5.5, c) webbrowser needs oxide d) unity8 needs webbrowser
[12:11] <Saviq> sorries :)
[12:11] <Mirv> this after I was finally able to hack UITK far enough to get packages out and I was rejoicing at the possibility of rebuilding webbrowser + unity8 to be able to run Qt 5.5 on the phone for the first time since July :)
[12:12] <Mirv> or was it June
[12:12] <Mirv> Saviq: no problem, life is just complicated
[12:12] <Saviq> Mirv, did you see mterry's questions yesterday about an upstream LP project for Qt?
[12:12] <Saviq> to be able to assign upstream bugs to it
[12:13] <Mirv> Saviq: yes, I replied to his e-mail about this another patch and said to do whatever he thinks would help. I wasn't aware of anything that could be done aside from coding Qt bug report support into LP
[12:13] <Saviq> ack
[12:14] <Saviq> @unity please merge trunk in your branches, most of the MPs had conflicts with new trunk
[12:14] <mzanetti> ack
[12:15] <seb128> Saviq, I didn't see that, but it's basically bug #157488?
[12:15] <ubot5`> bug 157488 in Launchpad itself "Add bugwatch support for the JIRA bugtracker" [High,Triaged] https://launchpad.net/bugs/157488
[12:15] <seb128> now that launchpad has some more hackers maybe they can do that? ;-)
[12:32] <seb128> Saviq, which is indicator-bluetooth not working on wily? (just saw that in the unity8 changes)
[12:35] <Saviq> seb128, you can't enable it
[12:35] <Saviq> seb128, I thought it was a known issue that we've not ported to BlueZ 5 yet...
[12:35] <seb128> Saviq, it should work, it got ported to bluez5 and works on unity7, do we have a bug?
[12:36] <seb128> Saviq, you though we would release ubuntu desktop without working bluetooth? ;-)
[12:36] <Saviq> seb128, not desktop, but wily phone is quite ignored
[12:36] <seb128> oh, that commit doesn't state phone
[12:36] <seb128> what about unity8 desktop session?
[12:37] <seb128> though in theory it should work on the phone, I'm unsure it got tested and about the kernel side though...
[12:39] <Saviq> seb128, indeed we didn't pay enough attention to desktop, sorry about that, I just thought this is an expected state at this point in time, let me verify and file a bug
[12:39] <seb128> Saviq, thanks
[12:39] <seb128> I'm going to update my test machine and try there as well
[12:39] <seb128> it should work, but if it doesn't it's good to know and we should fix it ;-)
[12:50] <tsdgeos> Saviq: so this landing means the tests passed in that new test-y thing we added right?
[12:50] <tsdgeos> autopkg tests i mean
[12:51] <Saviq> tsdgeos, at the moment they're "always failed" because of the missing logind mock
[12:51] <tsdgeos> oh right
[12:51] <Saviq> and armhf looks broken in terms of dependencies, so need to look into that too
[12:53] <Saviq> seb128, can't get a unity8 desktop session, just get a black screen and broken vtswitching :/
[12:55] <tsdgeos> Saviq: arhmf on CI or when building?
[12:55] <Saviq> tsdgeos, autopkgtest
[12:55] <tsdgeos> ah
[12:55] <Saviq> which is != than CI, because it installs packages from -proposed, doesn't build the whole thing
[12:56] <tsdgeos> right
[12:57] <Saviq> seb128, bug #1500855
[12:57] <ubot5`> bug 1500855 in indicator-bluetooth (Ubuntu) "Bluetooth can't be enabled on devel-proposed phone" [Undecided,New] https://launchpad.net/bugs/1500855
[12:57] <Saviq> tsdgeos, but we should be getting green CI now
[12:58] <tsdgeos> let's see
[12:58] <tsdgeos> i proposed another clazy run with 3 small fixes
[12:58] <tsdgeos> should be green
[12:58] <seb128> Saviq, thanks
[12:59] <seb128> Saviq, is the desktop session not working an unity8 regression?
[13:00] <Saviq> seb128, doubt it (the cursor disappears, too, which suggests unity-system-compositor), will need investigation
[13:00] <Saviq> OTOH I can see an ibus and unity8 crash
[13:00] <seb128> let me see if it does that here
[13:01] <seb128> unity8 segfault doesn't sound too good
[13:01]  * Saviq tries again with a clean /var/crash
[13:08] <Saviq> seb128, no unity8 crash this time, but ibus yes, stacktracetop mentions mirclient
[13:11] <Saviq> seb128, here's the ibus oops https://errors.ubuntu.com/oops/79161cec-66ab-11e5-8bc8-fa163e22e467
[13:12] <seb128> Saviq, thanks
[13:24] <Saviq> seb128, quick glance suggests it's similar to bug #1439202
[13:24] <ubot5`> bug 1439202 in ibus (Ubuntu) "/usr/lib/ibus/ibus-ui-gtk3:11:XKeysymToKeycode:keybinding_manager_bind:panel_keybinding_manager_bind:panel_bind_switch_shortcut:panel_construct" [High,Confirmed] https://launchpad.net/bugs/1439202
[13:25] <seb128> Saviq, yeah, not likely the unity8 session issue
[13:25] <Saviq> seb128, indeed
[13:37] <tsdgeos> dandrader: greyback_: since the clazy fixes for unity8 seem to have been so good i've done one for qtubuntu too https://code.launchpad.net/~aacid/qtubuntu/clazy_fixes/+merge/272747
[13:38] <dandrader> ok
[13:59] <Saviq> ltinkl, dandrader's mousePointer branch already bumps application api to 9, you might wanna rebase on that
[14:00] <ltinkl> Saviq, yikes, noted; I feared that :)
[14:03]  * ltinkl on it
[14:04] <seb128> Saviq, on my wily test laptop unity8 desktop session works and indicator-bluetooth loads and shows devices and has working items
[14:08] <Saviq> seb128, glad to hear
[14:13] <greyback_> tsdgeos: thank you
[14:19] <biot> hey, seb128 sounds familiar
[14:20] <biot> seb128: I think you reclassified some bug I looked at, gvfs breaking magnet links
[14:21] <Saviq> dandrader, did you merge qtmir as well?
[14:21] <dandrader> Saviq, qtmir/mousePointer?
[14:21] <Saviq> dandrader, yeah
[14:21] <Saviq> debian/control has a conflict there too
[14:21] <dandrader> Saviq, not today
[14:21] <Saviq> please do
[14:23] <dandrader> Saviq, done
[14:23] <Saviq> tx
[14:38]  * guest42315 ubuntuonair in 20 min http://ubuntuonair.com/
[14:38] <seb128> biot, yes, I did
[15:15] <tsdgeos> ouch
[15:15] <tsdgeos> we had a function in qmenumodel not returning anything
[15:15] <tsdgeos> when it should be returning a bool
[15:20] <tsdgeos> dednick: https://code.launchpad.net/~aacid/qmenumodel/clazy_run/+merge/272788
[15:25] <mterry> greyback, heyo -- we talked about X-Ubuntu-Touch the other day -- assuming that's the road we go down, is this MP roughly acceptable?  https://code.launchpad.net/~mterry/qtmir/no-touch-no-lifecycle/+merge/272791
[15:26] <mterry> tsdgeos, how is that not a compile error?  :)  stupid lenient compile modes
[15:26] <greyback> mterry: kinda. First thing I see if you're implementing policy in qtmir - I'd rather you export the "isTouchApp" as a bool to the shell, so it can decide what to do
[15:26] <tsdgeos> mterry: yaeh :/
[15:27] <greyback> mterry: there is no second thing :)
[15:27] <mterry> greyback, it looked like that policy decision was already in qtmir?
[15:27] <dednick> tsdgeos: looks fine. suppose i should test it... :)
[15:27] <mterry> greyback, but I can do the round trip way -- that's something that mzanetti needs eventually anyway to show a different close button
[15:28] <dednick> tsdgeos: what's with the reserve?
[15:28] <mterry> greyback, if I'm doing that though, I feel like we ought to pull the whitelist out of qtmir
[15:28] <greyback> mterry: well it is the shell which decides if an app should be suspended or not.
[15:28] <dednick> tsdgeos: just dynamic alloc?
[15:28] <greyback> mterry: yep, that I agree with
[15:29] <tsdgeos> dednick: so makes sure the list is the szie we need from start instead of growing as it "fills" and needing to realloc and stuff
[15:29] <tsdgeos> dednick: it's minor optimization
[15:29] <mterry> greyback, right -- that's why I stuck it in qtmir.  Because it was doing the policy via whitelist already.  But sure, I'll move all out
[15:29] <tsdgeos> since we know the size it doesn't harm to reserve
[15:29] <greyback> mterry: cool, thanks
[15:29] <dednick> tsdgeos: mkay
[15:30] <dednick> figured
[15:31] <greyback> dednick: "replaceme" in a debian .symbols file does what I think it does?
[15:32] <dednick> greyback: i think the ci bot comes along and changes it when released
[15:32] <greyback> cool
[15:32] <dednick> greyback: looked at history and seems to be what happens :|
[15:32] <greyback> I didn't know that
[15:33] <dednick> greyback: i've requested a review from ricmm, who should know the details
[15:34] <greyback> ack. he's a busy bunny tho
[15:34] <greyback> dednick: this Holder thingy is weird
[15:34] <dednick> greyback: yeah. doesn't do anything that i can see
[15:35] <greyback> was it supposed to be a QScopedPointer/unique_ptr
[15:35] <greyback> but it's got no deleter afaics
[15:36] <dednick> greyback: the other sensors are all handled by android registration keeping shared pointers. so they aren't destroyed till the sensor controller is. the haptic is a special case.
[15:36] <tsdgeos> larsu: yeah it's ugly, but saves lots of allocs
[15:36] <tsdgeos> that's why it's cool having a tool that does the replacement for you
[15:36] <tsdgeos> we can code and then just run the tool :D
[15:36] <greyback> dednick: I see
[15:36] <dednick> greyback: i'm thinking it probably should be shared, but it isn't here.
[15:36] <larsu> tsdgeos: ya I just read about it, pretty neat
[15:37] <dednick> dont see a point of 2 things asking for it creating 2 dbus connections.
[15:37] <greyback> dednick: to be absolutely correct, maybe yeah. Let's see what a papi maintainer says
[15:38] <dednick> I'm hoping every button doesnt do that :)
[15:38] <dednick> i think the Qt sensor may be shared
[15:38] <greyback> yeah, but qtsensors does that itself
[15:39] <greyback> IMO papi should be the one dedupicating such resources
[15:39] <greyback> +l
[15:56] <dandrader> dednick, about your polit-close branch: ApplicationManager test is still failing
[15:56] <dednick> dandrader: hm weird. give me a minute
[15:57] <dednick> dandrader: passes for me :/
[15:58] <dandrader> dednick, and item 2 here still applies https://code.launchpad.net/~nick-dedekind/qtmir/polite-close/+merge/262188/comments/683011
[16:01] <dednick> dandrader: ok. fixing in a minute
[16:01] <dandrader> greyback,  could you check if you get the test failure I describe here? https://code.launchpad.net/~nick-dedekind/qtmir/polite-close/+merge/262188/comments/683011
[16:03] <dednick> dandrader: you on mir 0.16
[16:03] <dednick> ?
[16:04] <dandrader> dednick, yes
[16:05] <dandrader> dednick, but it's a test, shoulnd't make a difference
[16:05] <dednick> well i just upgraded things have just gone shitty
[16:06] <dednick> Application test wont run either.
[16:06] <dednick> dandrader: ^
[16:07] <dandrader> dednick, great. so you're getting the same test failure now
[16:07] <dednick> dandrader: no. Application, not ApplicationManager
[16:08] <dednick> dandrader: ApplicationTests.checkResumeAcquiresWakeLock
[16:08] <dandrader> dednick, that one passes here :)
[16:09] <dednick> those wake lock tests have always been flaky for me
[16:12] <dednick> dandrader: tests passed on jenkins wily a couple of days ago.
[16:12] <dednick> dandrader: i'll kick off another run
[16:15] <dednick> dandrader: deleted all my build files and rebuilt. all tests pass again
[16:35] <dandrader> Saviq, could you check if you get the same test failure I describe here? https://code.launchpad.net/~nick-dedekind/qtmir/polite-close/+merge/262188/comments/683011
[16:36] <dandrader> Saviq, I'm getting it but dednick is not
[16:58] <Saviq> dandrader, wouldn't ci show a test failure?
[17:02] <dandrader> Saviq, right, and it's passing there. damn it
[17:02] <Saviq> dandrader, in any case, all passed here as well
[17:03] <Saviq> I'm on wily, mind you
[17:07] <dandrader> me too
[17:07] <dandrader> I do out of source builds. But I would be really surpised if that's the cause
[18:29] <mterry> mzanetti, I assume you're not around, but if you are, I updated my no-touch-no-lifecycle branch to have an isTouchApp bool you can consume in unity8
[18:29] <mterry> https://code.launchpad.net/~mterry/unity-api/no-touch-no-lifecycle/+merge/272829
[18:29] <mterry> https://code.launchpad.net/~mterry/qtmir/no-touch-no-lifecycle/+merge/272791
[18:29] <mterry> mzanetti, I'm working on the unity8 side, but it may already be useful to you
[18:30] <mzanetti> mterry, cool! thanks. not working on it any more today, but will check it out tomorrow morning
[18:30] <mterry> mzanetti, good answer  :)
[20:01] <dandrader> greyback, still around?
[20:02] <greyback> dandrader: for brief questions, yes
[20:02] <dandrader> greyback, why not having polite-close as a pre-requisite of https://code.launchpad.net/~gerboland/qtmir/dont-delete-qml-cache-on-good-stop/+merge/272761 ?
[20:02] <dandrader> greyback, as you said you took a bunch of code from it
[20:02] <greyback> dandrader: I will tomorrow. I didn't realise polite-close was going to be approved so fast
[20:03] <greyback> rebase should be easy
[20:50] <mzanetti> josharenson, https://plus.google.com/105839534016416729197/posts/BSnrzs65r7i
[20:50] <mzanetti> there's some feedback in the comments
[20:51] <josharenson> mzanetti: ah good to know... I'll merge trunk into the ppa branch and try it on wily (just finished upgrading to wily about 10 min ago)