[03:22] <mikodo> I am hearing of much activity happening with development of unity8. Rightly or wrongly, that is what I heard. How can I restate my desire to see this become a priority in unity8  https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400580
[03:22] <mikodo> Even hearing that it looks like unity8 session has gone from being a pre-view to being the intended Xserver Ubuntu replacement. Is is time to build in replacement shading for Unity8 to replace X like my bug reads?
[03:25] <duflu> mikodo: Yeah I implemented that in Mir over a year ago. I would like Unity8 to get access to that implementation too (via unity-system-compositor), rather than waiting indefinitely for Unity8 to reimplement the same feature
[03:26] <mikodo> duflu, Yes I saw you in the channel and was thinking of you
[03:27] <duflu> Essentially we don't even need agreement from Unity8. Just Mir team to agree on some key combo to access system-compositor features (like Ctrl+Alt+Shift+...)
[03:28] <duflu> Same goes for video mode switching etc. But it would be better if Unity8 was involved so we could have a GUI to control it
[03:28] <mikodo> Well, who should I talk too :)
[03:28] <duflu> mikodo: Best to comment on the bug: "Hey where's the feature?"
[03:29] <duflu> And the Unity8 team (at least some of them) will see it
[03:29] <mikodo> Cool. I was thinking of that, but didn't  want to sound to forward respective of your work
[03:29] <duflu> We can do high contrast and red-shift at the same time
[03:30] <duflu> mikodo: Speaking as a Canonical employee, I recommend you do beat us up. Ubuntu is yours and you should be hitting us over the head with it to make it better
[03:31] <mikodo> Thanks!
[03:31] <duflu> Sometimes change only happens when we get bad publicity. It's better if we change before then
[03:32] <mikodo> Somewhere, somehow I have an advocate. Let me think on what you have said.
[04:15] <mikodo> Okay. Thanks. camako (Cemil) , Greyback (Gerry), SABDFL (Mark) are going to here about this. I think it is too important for them to not see the stonewalling on this important user accommodation.
[05:20] <duflu> mikodo: Again, please keep it formal by commenting in the bug
[05:24] <mikodo> duflu, Okay. No worries.
[05:42] <mikodo> Thank you. Though not legally blind, I do have vision problems. More importantly I do have a a brother who is,  and has much less vision. I want to think on what I am going to include in the bug as, it is not just we brothers who I am asking this for. That leaves me with some trepidation,  as I will speaking for others needing these features from around the globe. So, I will comment on this in the bug, and take it further then (as needed)  when I am c
[05:42] <mikodo> omfortable with my words. I need to think on this a while.
[09:48] <tsdgeos> greyback: yep you need a new laptop/wifi driver :D
[09:49] <greyback> yeah :(
[09:50]  * Saviq doesn't trust wifi, still on ethernet wherever possible
[11:35] <pstolowski> Saviq, i thought that was fixed, no? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-047/yakkety/i386/u/unity8/20160524_215652@/log.gz
[11:35] <pstolowski> Saviq, or is it Y-specific now?
[11:36] <pstolowski> Saviq, in any case, i think silo 47 is good to go
[12:21] <mterry> Saviq, thanks for managing silo 59
[12:22] <mterry> I'll help test today, hopefully we can pass to qa
[12:51] <dandrader> tsdgeos, in https://code.launchpad.net/~aacid/qtmir/compile_with_ubsan/+merge/295677
[12:51] <dandrader> tsdgeos, what's "ubsan'?
[12:52] <dandrader> tsdgeos, in the diff I only see you adding a header file
[12:52] <tsdgeos> dandrader: sorry
[12:52] <tsdgeos> dandrader: undefined behaviour sanitizer
[12:52] <tsdgeos> -fsanitize=undefined
[12:52] <tsdgeos> dandrader: http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
[12:52] <dandrader> tsdgeos, ok, thanks
[12:53] <tsdgeos> dandrader: if you also use https://code.launchpad.net/~aacid/qtmir/ecm_optional_santizers/+merge/295673 you can enable it by using -DECM_ENABLE_SANITIZERS='undefined' if you have ecm installed
[12:54] <tsdgeos> dandrader: i'll add it to the description
[12:55] <Saviq> mterry, nw, we should ask if there's any more code we wanna add since
[12:55] <Saviq> and make sure things are reviewed (https://code.launchpad.net/~saviq/unity8/build-arm64/+merge/295573 hint hint)
[12:56] <mterry> Saviq, I was hoping to cut things off and do another silo after with everything new -- neverending cycle of silos.  I figured the silo was already quite large
[12:57] <mterry> Saviq, should use qml-module-ubuntu-web instead of qtdec*  :)
[12:57] <mterry> otherwise fine
[12:57] <Saviq> mterry, I think there's a branch from tsdgeos for that
[12:57] <mterry> Though I see you snuck a fullscreen fix in
[12:57] <Saviq> did I?
[12:58] <mterry> Saviq, hah, then ltinkl did...
[12:58] <Saviq> ah for fullscreen notifs, yeah we did
[12:58] <tsdgeos> Saviq: mterry: i'd also appreciate if we can land this one asap instead of keeping adding things, the handle_termination_signals branch is needed for the dash performance metrings since otherwise we use random debs that will break at some point
[12:58] <mterry> Saviq, yeah but you moved the declaration to a different file, could have fixed.  But fine, we'll let tsdgeos do it  :)
[12:58] <Saviq> mterry, ok, cut off is fine with me
[12:58] <tsdgeos> Saviq: mterry: yeah but conflcits as hell, so we shelved it for next time
[12:58] <ltinkl> mterry, I'm innocent :)
[12:59] <Saviq> mterry, it needed a rebuild anyway, so that's when I snuck in
[12:59] <mterry> Silos need bzr blame
[12:59] <tsdgeos> he je
[12:59] <mterry> tsdgeos, when you rebase your branch, make sure to look at build.sh too, it has build-deps there
[13:00] <tsdgeos> mterry: can you mark that as needs fixing on the branch?
[13:00] <tsdgeos> otherwise i'll forget :D
[13:00] <mterry> tsdgeos, oh actually use the process?!  ok  :)
[13:01] <Saviq> mterry, "show audit logs"
[13:01] <mterry> Saviq, whoa
[13:08] <Saviq> mterry, kicked https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/171/ off
[13:08] <mterry> Saviq, oh thanks -- is the entry point for doing so at unity8-jenkins.ubuntu.com?
[13:09] <mterry> Never manually started that job
[13:09] <Saviq> mterry, yeah https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/build?delay=0sec simply
[13:10] <Saviq> mterry, it's a slightly different job to the test-0-autopkgtest one - not "public" yet, need to clear a thing or two up in there
[13:13] <mterry> ltinkl, I can't get dragPanelDownToRestoreWindow to work for me -- is there a trick?
[13:14] <mterry> ltinkl, oh haha!
[13:14] <mterry> ltinkl, user error, nm
[13:22] <mterry> ltinkl, hrm.  no actually, my question stands...
[13:34] <mterry> tsdgeos, you approved that branch ^ (https://code.launchpad.net/~lukas-kde/unity8/dragPanelDownToRestoreWindow/+merge/290327)  -- is there a trick to get it to work?
[13:35] <tsdgeos> mterry: it did work back when i tried it
[13:35] <tsdgeos> mterry: you can't drag from the indicators i think
[13:35] <mterry> tsdgeos, just drag with a mouse on the non-notification area panel?
[13:35] <tsdgeos> yeah drag down with the maximized window
[13:35] <tsdgeos> doesn't work?
[13:35] <mterry> didn't for me
[13:35] <mterry> might be being dumb though
[13:36] <tsdgeos> which silo, want me to try?
[13:36] <tsdgeos> just in case you're really doing it wrong?
[13:36] <mterry> tsdgeos, silo 59
[13:55] <tsdgeos> mterry: it seems it has indeed broken
[13:55] <mterry> tsdgeos, oh good (sorta)
[13:55] <mterry> paging ltinkl!
[13:55] <tsdgeos> let me try the branch standaalone again
[14:08] <tsdgeos> mterry: something has defenitely "conflicted"
[14:08] <tsdgeos> if i go back to current unity8+ltinkl's branch it works again
[14:08] <tsdgeos> btu with silo59 it does not
[14:08] <tsdgeos> so even if it doesn't code conflict
[14:09] <tsdgeos> there's a "this doesn't work anymore" conflict
[14:09] <mterry> tsdgeos, hmph.  Easy enough to drop from silo, but I'd prefer ltinkl's guess on whether it can be quickly fixed
[14:09] <tsdgeos> +1
[14:09] <mterry> tsdgeos, thanks for testing
[14:10] <ltinkl> mterry, let me test it in the silo (and without)
[14:11] <ltinkl> mterry, how quickly you want to hand it over to QA?
[14:11] <mterry> ltinkl, I'm still testing it manually, but I hoped to do so today
[14:12] <ltinkl> mterry, I wonder what could be the cause... some botched merge probably
[14:12]  * ltinkl installs the silo
[14:12] <mterry> ltinkl, merges are the worst  :)
[14:12] <mterry> ltinkl, well not quite a botched merge -- the branch alone works
[14:12] <mterry> ltinkl, just some interaction with something else in the silo
[14:13] <ltinkl> mterry, yeah, let me diff my branch and the silo
[14:15] <ltinkl> mterry, looks like some other MouseArea in Panel.qml
[14:20] <mterry> ltinkl, hrm.  Also with the fullscreen notificatino branch, the PUK dialog drops down to reveal the panel when I do vol up/ vol down
[14:20] <ltinkl> mterry, yeah, that'đ a feature
[14:20] <ltinkl> mterry, odd I know
[14:20] <mterry> huh
[14:21] <mterry> ltinkl, why?  the vol dialog is obscuring the panel in that case.  And you can't drag it down...
[14:21] <ltinkl> mterry, the "confirmation notification" (like volume) get by design inserted unconditionally to the top of the displayed queue
[14:21] <mterry> ltinkl, that's fine...  I don't mind displaying it on top of the PUK
[14:22] <mterry> ltinkl, but the PUK gets moved, which seems wrong.  And the vol dialog is placed oddly (overlapping panel)
[14:23] <ltinkl> mterry, yeah, again - hope this gets solved by having dialogs for those things... we can't display on notification over another, the container is a listview
[14:23] <ltinkl> one notification *
[14:23] <mterry> ltinkl, humph.  ok.  I guess it's not worse than before
[14:23] <mterry> thanks
[14:32] <ltinkl> mterry, branch unbroken :) can you pls rebuild?
[14:32] <mterry> ltinkl, awesome.  I also noticed a test failure that looks related -- test_dragPanelToRestoreMaximizedWindow -- would this fix that then?
[14:33] <ltinkl> mterry, yeah, this was a proof it was not working :)
[14:33] <mterry> presumably the test failure was capturing the incompatibility and will now pass
[14:33] <mterry> cool
[14:33] <ltinkl> mterry, exactly
[14:41] <ltinkl> mterry, hmm, this failure https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/171/label=amd64,package=unity8,release=xenial+overlay,testname=qmluitests.sh/testReport/(root)/ListViewWithPageHeaderTest/testMaximizeVisibleAreaAndShowHeader/ could be caused by this branch https://code.launchpad.net/~aacid/unity8/optimize_LVWPH_layout/+merge/290021 in the new silo
[14:42] <mterry> ltinkl, tsdgeos: that failure only showed up in xenial, so might be flaky.  Which isn't a good thing either, but still
[14:43] <tsdgeos> let me see
[14:43] <tsdgeos> do we have two lvpwh branches?
[14:43] <tsdgeos> if so it may be a problem
[14:43] <tsdgeos> since i'm renaming some names in that branch
[14:43] <tsdgeos> so the other branch may cleanly merge but still fail
[14:43] <tsdgeos> but otoh didn't fail in vivid
[14:44] <tsdgeos> i'll download the code and run the tests here to see if i can repro
[14:44] <tsdgeos> is there a way to know if an app was killer by the oom ?
[14:46] <Saviq> tsdgeos, syslog
[14:55] <tsdgeos> yep, i'm getting oom killed :/
[14:56] <tsdgeos> will talk to sergio tomorrow see if i can split this in smaller runs instead of one big one
[15:21] <tsdgeos> mterry: fwiw i've been running the 4 tests that failed on xenial in a loop for 20 minutes
[15:21] <tsdgeos> no failure yet
[15:21] <mterry> tsdgeos, oh good thanks.  That's odd that all 4 failed though
[15:21] <mterry> but good to know they aren't completely bogus
[15:22] <mterry> tsdgeos, since only one test failed in all 3 releases, I think the others must be flaky.  Maybe more flaky in jenkins than on our machines though...
[15:22] <ltinkl> tsdgeos, tried adding some "stress"?
[15:22] <tsdgeos> yeah
[15:23] <tsdgeos> ltinkl: well running the 4 of them at the same time already uses like 70% of the cpu
[15:24]  * tsdgeos updates the huge kde l10n svn tree to create some hd noise
[15:24] <ltinkl> tsdgeos, that's not enough I'm afraid... the flaky wizard test I fixed earlier wasn't failing either untill I added "stress" to the mix
[15:24] <ltinkl> tsdgeos, "stress --cpu 8 --io 2"
[15:24] <tsdgeos> ltinkl: i'm just saying "the tests are not wrong per se"
[15:24] <tsdgeos> i'm not saying they are good :D
[15:42]  * mterry starts silo 59 official autopkg run, goes to gym
[15:51] <Saviq> hrm why does this jenkins job take an hour... when a normal CI run takes 20mins
[21:37] <robert_ancell> josharenson, hi, regarding bug 1583624, have you dug into Mir as to why it's trying to get the VT?
[22:06] <josharenson> robert_ancell: no further than knowing a mir server needs a VT to run in...
[22:06] <salty-horse> noticed something strange. if my executable is named a.out, the icon it sets on startup isn't respected. if I rename it, I see the icon. any idea why that happens?
[22:07] <robert_ancell> josharenson, when it's running as non-root? Why does it need a VT?
[22:07] <josharenson> robert_ancell: I'd have to ask a mir person :-/
[22:07] <robert_ancell> I'll ask RAOF when he's on later
[22:08] <robert_ancell> josharenson, Can I reproduce the issue here? Is this on Yakkety?
[22:09] <josharenson> robert_ancell: I haven't tried it on yakkety yet (just upgrade this morning) but it should be pretty easy to reproduce locally. I can point you to a branch or build you debs..
[22:09] <robert_ancell> josharenson, a branch is good
[22:10] <josharenson> robert_ancell: ok, 1 min. I need to push 1 small change then
[22:10] <robert_ancell> no rush
[22:11]  * josharenson is also resyncing w/ trunk as its been a while
[22:14] <josharenson> robert_ancell: https://code.launchpad.net/~josharenson/unity8/session-chooser-gui should do it. Just be mindful of https://bugs.launchpad.net/unity-system-compositor/+bug/1536662 (which looks fixed now)
[22:18]  * josharenson goes afk for 10 min to walk his dog
[23:11] <josharenson> robert_ancell: I'm going eod, but if you have any questions, ill be back on for a bit in a few hours
[23:17] <robert_ancell> josharenson, thanks