[03:22] 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] Launchpad bug 1400580 in unity8 (Ubuntu) " Color Inverse on display. Toggle Negative Image" [Wishlist,Triaged] [03:22] 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] 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] duflu, Yes I saw you in the channel and was thinking of you [03:27] 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] 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] Well, who should I talk too :) [03:28] mikodo: Best to comment on the bug: "Hey where's the feature?" [03:29] And the Unity8 team (at least some of them) will see it [03:29] Cool. I was thinking of that, but didn't want to sound to forward respective of your work [03:29] We can do high contrast and red-shift at the same time [03:30] 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] Thanks! [03:31] Sometimes change only happens when we get bad publicity. It's better if we change before then [03:32] Somewhere, somehow I have an advocate. Let me think on what you have said. [04:15] 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] mikodo: Again, please keep it formal by commenting in the bug [05:24] duflu, Okay. No worries. [05:42] 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] omfortable with my words. I need to think on this a while. [09:48] greyback: yep you need a new laptop/wifi driver :D [09:49] yeah :( [09:50] * Saviq doesn't trust wifi, still on ethernet wherever possible [11:35] 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] Saviq, or is it Y-specific now? [11:36] Saviq, in any case, i think silo 47 is good to go === JanC is now known as Guest85398 === JanC_ is now known as JanC [12:21] Saviq, thanks for managing silo 59 [12:22] I'll help test today, hopefully we can pass to qa [12:51] tsdgeos, in https://code.launchpad.net/~aacid/qtmir/compile_with_ubsan/+merge/295677 [12:51] tsdgeos, what's "ubsan'? [12:52] tsdgeos, in the diff I only see you adding a header file [12:52] dandrader: sorry [12:52] dandrader: undefined behaviour sanitizer [12:52] -fsanitize=undefined [12:52] dandrader: http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html [12:52] tsdgeos, ok, thanks [12:53] 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] dandrader: i'll add it to the description [12:55] mterry, nw, we should ask if there's any more code we wanna add since [12:55] and make sure things are reviewed (https://code.launchpad.net/~saviq/unity8/build-arm64/+merge/295573 hint hint) [12:56] 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] Saviq, should use qml-module-ubuntu-web instead of qtdec* :) [12:57] otherwise fine [12:57] mterry, I think there's a branch from tsdgeos for that [12:57] Though I see you snuck a fullscreen fix in [12:57] did I? [12:58] Saviq, hah, then ltinkl did... [12:58] ah for fullscreen notifs, yeah we did [12:58] 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] Saviq, yeah but you moved the declaration to a different file, could have fixed. But fine, we'll let tsdgeos do it :) [12:58] mterry, ok, cut off is fine with me [12:58] Saviq: mterry: yeah but conflcits as hell, so we shelved it for next time [12:58] mterry, I'm innocent :) [12:59] mterry, it needed a rebuild anyway, so that's when I snuck in [12:59] Silos need bzr blame [12:59] he je [12:59] tsdgeos, when you rebase your branch, make sure to look at build.sh too, it has build-deps there [13:00] mterry: can you mark that as needs fixing on the branch? [13:00] otherwise i'll forget :D [13:00] tsdgeos, oh actually use the process?! ok :) [13:01] mterry, "show audit logs" [13:01] Saviq, whoa [13:08] mterry, kicked https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/171/ off [13:08] Saviq, oh thanks -- is the entry point for doing so at unity8-jenkins.ubuntu.com? [13:09] Never manually started that job [13:09] mterry, yeah https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/build?delay=0sec simply [13:10] 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] ltinkl, I can't get dragPanelDownToRestoreWindow to work for me -- is there a trick? [13:14] ltinkl, oh haha! [13:14] ltinkl, user error, nm [13:22] ltinkl, hrm. no actually, my question stands... [13:34] 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] mterry: it did work back when i tried it [13:35] mterry: you can't drag from the indicators i think [13:35] tsdgeos, just drag with a mouse on the non-notification area panel? [13:35] yeah drag down with the maximized window [13:35] doesn't work? [13:35] didn't for me [13:35] might be being dumb though [13:36] which silo, want me to try? [13:36] just in case you're really doing it wrong? [13:36] tsdgeos, silo 59 === dandrader is now known as dandrader|bbl [13:55] mterry: it seems it has indeed broken [13:55] tsdgeos, oh good (sorta) [13:55] paging ltinkl! [13:55] let me try the branch standaalone again [14:08] mterry: something has defenitely "conflicted" [14:08] if i go back to current unity8+ltinkl's branch it works again [14:08] btu with silo59 it does not [14:08] so even if it doesn't code conflict [14:09] there's a "this doesn't work anymore" conflict [14:09] tsdgeos, hmph. Easy enough to drop from silo, but I'd prefer ltinkl's guess on whether it can be quickly fixed [14:09] +1 [14:09] tsdgeos, thanks for testing [14:10] mterry, let me test it in the silo (and without) [14:11] mterry, how quickly you want to hand it over to QA? [14:11] ltinkl, I'm still testing it manually, but I hoped to do so today [14:12] mterry, I wonder what could be the cause... some botched merge probably [14:12] * ltinkl installs the silo [14:12] ltinkl, merges are the worst :) [14:12] ltinkl, well not quite a botched merge -- the branch alone works [14:12] ltinkl, just some interaction with something else in the silo [14:13] mterry, yeah, let me diff my branch and the silo [14:15] mterry, looks like some other MouseArea in Panel.qml [14:20] 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] mterry, yeah, that'đ a feature [14:20] mterry, odd I know [14:20] huh [14:21] ltinkl, why? the vol dialog is obscuring the panel in that case. And you can't drag it down... [14:21] mterry, the "confirmation notification" (like volume) get by design inserted unconditionally to the top of the displayed queue [14:21] ltinkl, that's fine... I don't mind displaying it on top of the PUK [14:22] ltinkl, but the PUK gets moved, which seems wrong. And the vol dialog is placed oddly (overlapping panel) [14:23] 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] one notification * [14:23] ltinkl, humph. ok. I guess it's not worse than before [14:23] thanks [14:32] mterry, branch unbroken :) can you pls rebuild? [14:32] ltinkl, awesome. I also noticed a test failure that looks related -- test_dragPanelToRestoreMaximizedWindow -- would this fix that then? [14:33] mterry, yeah, this was a proof it was not working :) [14:33] presumably the test failure was capturing the incompatibility and will now pass [14:33] cool [14:33] mterry, exactly [14:41] 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] ltinkl, tsdgeos: that failure only showed up in xenial, so might be flaky. Which isn't a good thing either, but still [14:43] let me see [14:43] do we have two lvpwh branches? [14:43] if so it may be a problem [14:43] since i'm renaming some names in that branch [14:43] so the other branch may cleanly merge but still fail [14:43] but otoh didn't fail in vivid [14:44] i'll download the code and run the tests here to see if i can repro [14:44] is there a way to know if an app was killer by the oom ? [14:46] tsdgeos, syslog [14:55] yep, i'm getting oom killed :/ [14:56] will talk to sergio tomorrow see if i can split this in smaller runs instead of one big one === charles_ is now known as charles [15:21] mterry: fwiw i've been running the 4 tests that failed on xenial in a loop for 20 minutes [15:21] no failure yet [15:21] tsdgeos, oh good thanks. That's odd that all 4 failed though [15:21] but good to know they aren't completely bogus [15:22] 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] tsdgeos, tried adding some "stress"? [15:22] yeah [15:23] 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] 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] tsdgeos, "stress --cpu 8 --io 2" [15:24] ltinkl: i'm just saying "the tests are not wrong per se" [15:24] i'm not saying they are good :D [15:42] * mterry starts silo 59 official autopkg run, goes to gym [15:51] hrm why does this jenkins job take an hour... when a normal CI run takes 20mins === dandrader|bbl is now known as dandrader [21:37] josharenson, hi, regarding bug 1583624, have you dug into Mir as to why it's trying to get the VT? [21:37] bug 1583624 in Light Display Manager "Mir cannot open a tty when started by lightdm" [Undecided,Incomplete] https://launchpad.net/bugs/1583624 [22:06] robert_ancell: no further than knowing a mir server needs a VT to run in... [22:06] 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] josharenson, when it's running as non-root? Why does it need a VT? [22:07] robert_ancell: I'd have to ask a mir person :-/ [22:07] I'll ask RAOF when he's on later [22:08] josharenson, Can I reproduce the issue here? Is this on Yakkety? [22:09] 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] josharenson, a branch is good [22:10] robert_ancell: ok, 1 min. I need to push 1 small change then [22:10] no rush [22:11] * josharenson is also resyncing w/ trunk as its been a while [22:14] 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:14] Launchpad bug 1536662 in Mir 0.21 "[regression] Black screen: Mir hangs and then crashes on startup/login due to reading from /dev/random" [Critical,Triaged] [22:18] * josharenson goes afk for 10 min to walk his dog [23:11] 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] josharenson, thanks