[05:34] <Mirv> Saviq: no, no aware, let's try to find what it is about
[08:28] <tsdgeos> Saviq: you've made test failures be failures instaead of unstable? https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/15/
[08:53] <Saviq> tsdgeos, otherwise we'd end up in the make exit code situation potentially
[08:53] <tsdgeos> ok, that's a bit of a step back but not terrible i guess
[08:54] <Saviq> tsdgeos, you mean to not see the difference between unstable and failed?
[08:54] <tsdgeos> yep
[08:56] <Saviq> tsdgeos, I could interpret adt-run exit status http://manpages.ubuntu.com/manpages/precise/man1/adt-run.1.html
[08:56] <tsdgeos> i guess it's fine, i mean it's just a few extra clicks
[08:56] <Saviq> so if 2,4,6,8, exit 0
[08:57] <Saviq> tsdgeos, no I get what you mean, when we get reports on MPs it's important to know the difference
[08:57] <Saviq> hopefully I can still mark it unstable if 2,4,6,8
[08:57] <Saviq> so we don't miss make exit
[09:00] <Saviq> yeah easy enough to do
[09:01] <tsdgeos> ok :)
[09:30] <Saviq> d'oh, looks like we'll build up a dummy .xml file after all :P
[09:57] <tsdgeos> mzanetti: Saviq: we're going to need a decision on whether we want https://code.launchpad.net/~aacid/unity8/fallback_for_empty/+merge/282002 or not
[10:00] <Saviq> tsdgeos, mzanetti, you were arguing that it might be desirable to pass empty, I somewhat agree that fallback was meant for the case where the scope can't do anything about it, because they don't know if we successfully retrieve the image
[10:00] <Saviq> when sending empty, they might as well send the fallback url again
[10:00] <Saviq> s/again/instead/
[10:00] <mzanetti> that's our thinking yes
[10:01] <mzanetti> but dobey strongly disagrees
[10:01] <tsdgeos> my guess  is mostly by the "fallback" name than by real disagreeing
[10:02] <Saviq> ultimately it's the API guys' decision
[10:03] <Saviq> because they're signing the contract with the scope developer
[10:03] <Saviq> s
[10:04] <mzanetti> fair enough.
[10:09] <Saviq> tsdgeos, https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/16/ should come up unstable now instead of failed (/me should have ran the parallel qmluitests instead, cuts the time by half)
[10:17]  * Saviq starts thinking Jenkaas might be a good thing for us in the end
[10:18] <Saviq> looks like I'll be able to cut the CI turnaround by a significant margin
[10:20] <Saviq> but we seem to have "lost" almost twenty tests somehow
[10:21] <tsdgeos> :?
[10:23] <Saviq> tsdgeos, and btw, it was enough to make them run in parallel https://code.launchpad.net/~saviq/unity8/parallel-qmluitests/+merge/282603 ;)
[10:23] <Saviq> tsdgeos, I mean https://code.launchpad.net/~saviq/unity8/parallel-qmluitests/+merge/282603/comments/717308
[10:24] <Saviq> tsdgeos, well, ok, not 20, but 7 https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/13/testReport/ vs. https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/13/testReport/
[10:24] <tsdgeos> Saviq: that's the same link twice
[10:24] <Saviq> grr
[10:25] <Saviq> tsdgeos, https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/1774/testReport/%28root%29/ vs. https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/13/label=amd64,release=vivid+overlay/testReport/%28root%29/
[10:26] <Saviq> meld to the rescue
[10:26] <tsdgeos> weird
[10:27] <Saviq> tsdgeos, that's the diff http://pastebin.ubuntu.com/14503845/
[10:29] <Saviq> ah I wonder if it put the .xml file somewhere
[10:30] <Saviq> or or
[10:30] <Saviq> same name
[10:31] <Saviq> or not part of xvfballtests
[10:31] <Saviq> 'cause I can't see them at all in the adt-run log
[10:31] <Saviq> tsdgeos, oh oh, and... good news and bad news https://requests.ci-train.ubuntu.com/#/ticket/877 (check out "Automated test results")
[10:32] <tsdgeos> aren't they part of make test?
[10:32] <Saviq> tsdgeos, I'll find them, nw
[10:33] <tsdgeos> hey, got a pass for amd64
[10:33] <tsdgeos> still some failures though :/
[10:34] <Saviq> tsdgeos, the i386 fail on vivid is a time out, something got stuck (3h between start and timeout)
[10:34] <Saviq> armhf is like a swiss cheese :/
[10:35] <tsdgeos> yeah :D
[10:35] <tsdgeos> i'll have a look
[10:35] <tsdgeos> i think most are timing related
[10:35] <tsdgeos> but still it'd be great if we could get them to pass
[10:35] <Saviq> 123 failures
[10:36] <Saviq> we could use the .xml out of that
[10:37] <Saviq> xenial i386 is just two fails in launcher that didn't get pulled out, so some improvement needed there, too
[10:37]  * Saviq worried to make them pass, they will shout Regression! at us all the time after that
[10:38] <Saviq> ah, wonder if it's the parallel that made them stuck
[10:38] <Saviq> hmm no, xvfballtests still went -j1
[10:39] <Saviq> only 52 failures on xenial armhf :)
[10:42] <tsdgeos> he he
[11:23] <Saviq> Mirv, hey, so yeah lp:ubuntu-settings-components cross-builds on vivid+overlay but not on xenial: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=cross-armhf,release=xenial/163/console
[11:28] <Saviq> Mirv, same for lp:unity-api https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/164/
[11:28] <Saviq> owait that's actually a different - g++ - issue
[11:31] <mzanetti> Saviq, hey, I'm sure I saw a bug report coming by lately for apps crashing if you launch them immediately after closing them
[11:32] <mzanetti> can't find it any more, neither in my inbox nor on LP
[11:32] <mzanetti> you happen to know about it?
[11:32] <Saviq> mzanetti, bug #1527737
[11:32] <mzanetti> faenil, ^
[11:32] <mzanetti> thanks Saviq
[11:32] <faenil> ah finally :) thanks
[11:33] <Saviq> we almost landed a fix, but found a bad regression that sometimes stopped you from launching apps altogether...
[11:35] <faenil> I see
[11:35] <faenil> left a comment there with my current experience
[11:43] <Saviq> Mirv, *or* my chroots are borked, can't seem to reproduce locally
[11:43] <Saviq> ah
[11:43] <Saviq> proposed??
[11:46] <Mirv> Saviq: hmm
[11:46] <Mirv> Saviq: maybe some gcc proposed update indeed
[11:46] <Saviq> Mirv, that would actually explain the boost issue as well
[11:46] <Mirv> Saviq: there was a new gcc-5 upload 14 hours ago
[11:46] <Mirv> at least
[11:46] <Saviq> hmm I first saw the issues earlier than that
[11:48] <Mirv> boost stuff from a week ago is in release pocket
[11:58]  * Saviq recreates the chroots
[11:59] <Saviq> Mirv, meh, can't reproduce locally, will let you know what I find out
[12:01] <Mirv> Saviq: ok, let's see later
[12:27] <Saviq> tsdgeos, yay, unstable https://unity8-jenkins.ubuntu.com/view/unity8/ (second from the top)
[12:28] <tsdgeos> Saviq: third?
[12:28] <Saviq> maybe third by now
[12:28] <tsdgeos> parallel one, no?
[12:28] <Saviq> yes
[12:28] <Saviq> yellow-ish
[12:29] <Saviq> instead of red
[12:29] <Saviq> need to fix the upstream job, too (thought I did already)
[12:29] <Saviq> ah
[12:29] <Saviq> now I did
[12:30] <tsdgeos> food!
[13:48] <mterry> Saviq, how trustworthy are the unity8 CI bot results so far?
[13:50] <tsdgeos> dandrader: have a sec?
[13:52] <dandrader> tsdgeos, yeah
[13:53] <tsdgeos> dandrader: i can't figure out why mouseMove on the tests is failing to turn containsMouse of a MouseArea to true
[13:53] <tsdgeos> i thought it was the MouseTouchAdaptor
[13:53] <tsdgeos> but i've set it to false and still fails
[13:55] <tsdgeos> dandrader: i can push the branch somewhere if you want
[13:55] <dandrader> tsdgeos, MouseTouchAdaptor should be completely transparent to tests
[13:55] <dandrader> tsdgeos, your second is up
[13:55] <dandrader> :)
[13:55] <tsdgeos> ok
[13:56] <dandrader> tsdgeos, does it happens only in tests?
[13:56] <dandrader> tsdgeos, or in "make tryFoo" as well?
[13:57] <tsdgeos> make tryFoo works if i uncheck the "mouse emulates touch"
[13:57] <tsdgeos> checkbox
[14:01] <dandrader> tsdgeos, add some wait(xxx) between commands. helps to see if there's some race/timing issue
[14:01] <tsdgeos> yeah i did, didn't seem to help
[14:01] <tsdgeos> will keep trying, don't worry
[14:02] <tsdgeos> it was just if you had something quick in mind
[14:12] <Saviq> mterry, by now should be really trustworthy, modulo autopilot, which don't run yet
[14:12] <Saviq> and armhf, which we can't build
[14:12] <Saviq> and I need to find 7 tests that disappeared :P
[14:12] <mterry> Saviq, hah we can't build armhf?  Because of ci restrictions?  that seems like a big gap  :)
[14:12] <Saviq> mterry, no
[14:13] <Saviq> because of bug #1472186 (I wanted to cross-build)
[14:13] <Saviq> where possible
[14:13] <mterry> Saviq, ah
[14:13] <Saviq> will likely need an armhf node for non-cross-buildable stuff
[14:13] <Saviq> and then we have a phone, but don't want to use that for building, only for ap
[14:43] <Saviq> on that note
[14:54] <oSoMoN> is there a way to change the keyboard layout of a bluetooth keyboard connected to a phone?
[14:57] <oSoMoN> nm, found https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1412492
[14:58] <Saviq> mzanetti, not sure what failed in launcher-sizing autopkgtest, added some debugging and restarted
[14:58] <ltinkl> oSoMoN, nope, not supported yet
[14:58] <mzanetti> hmm
[14:59] <oSoMoN> that’s unfortunate, there’s a lot of people out there who don’t use qwerty and want to type non latin1 characters
[15:01] <Saviq> oSoMoN, we're thinking hard about it ;)
[15:01] <Saviq> but
[15:02] <Saviq> people not using qwerty are... well, you know what I mean :P
[15:02] <oSoMoN> Saviq, no I don’t, what do you mean?
[15:03] <Saviq> I mean it's their own fault :P
[15:03] <Saviq> should be forced to use qwerty for the sake of humanity
[15:03] <ltinkl> Saviq, right but it's mainly about being able to input non latin1 stuff :)
[15:04] <Saviq> I'm using qwerty and input non-latin1 stuff all the time
[15:04] <Saviq> not to mention compose key
[15:04] <Saviq> we've done away with the "polish" layout some time ago and everyone uses "polish (programmer's)" now ;)
[15:04] <Saviq> with AltGr to add diacriticts
[15:05] <Saviq> but yeah, /me has caps mapped to compose, much more useful
[15:05] <oSoMoN> does Mir allow remapping keys?
[15:07] <Saviq> not yet I don't think
[15:10] <ltinkl> Saviq, yeah but not in u8, Mir forces a "en_US" layout
[15:10] <Saviq> ltinkl, I know, I know :P
[15:12] <ltinkl> Saviq, otherwise I'm using a cz+qwerty+AltGr as well
[15:21] <Saviq> grr /me broke autopkgtest job, fixing
[15:27] <Saviq> fixeded
[17:12] <faenil> Saviq: is it possible to install&run click apps on desktop unity8 yet?
[17:12] <faenil> I played a bit with click install + register
[17:13] <faenil> but didn't get anywhere
[17:13] <faenil> (note: it could have been that the click was corrupt as well)
[17:13] <Saviq> mzanetti, you have a recipe for that ↑ ;)
[17:14] <mzanetti> faenil, should work, yes
[17:15] <mzanetti> faenil, need click install, yes. but then it should just work
[17:15] <mzanetti> faenil, store is broken. you can still click on them to download them. they'll end up in ~/.cache
[17:16] <mzanetti> faenil, installation with pkcon will fail, but click install should work
[17:16] <mzanetti> you need multiarch or x86 packages obviously
[17:17] <faenil> mzanetti: yeah, does store hand out x86 or arm packages?
[17:17] <faenil> and I used click install + register but it didn't work...must have been the click then
[17:17] <faenil> mzanetti: pkcon is because it has apt configured as backend right?
[17:18] <faenil> I had a quick look at how to swap pkcon's backend but didn't find any simple way
[17:24] <oSoMoN> Saviq, ltinkl: I could use a review for https://code.launchpad.net/~osomon/qtubuntu/qkeyevent-native-virtual-key/+merge/282515
[17:45] <davidcalle> Here we go! https://developer.ubuntu.com/en/blog/2016/01/15/announcing-ubuntu-scopes-showdown-2016/
[17:49] <mzanetti> faenil, yes, and yes
[17:49] <mzanetti> faenil, core apps are packaged multiarch nowadays
[17:49] <mzanetti> faenil, simple webapps or qml only would work too
[17:49] <faenil> mzanetti: okay, cool
[17:49] <faenil> mzanetti: nah, clicks