[01:48] <meercat> there is a bug in the ubuntu 15.10 installation process that prevents uefi boots on some systems and in virtualbox, the fix applied does not work on all systems.  for now, the workaround is to install xubuntu and then install unity.  https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1363719
[01:48] <meercat> the bug is specific to ubuntu
[07:38] <lpotter> hmm.. I take it grayback is on holiday
[07:39] <lpotter> ot just not here at the moment...
[09:19] <Saviq> lpotter, yeah, he's out until next week, can I help?
[09:19] <Saviq> mzanetti, bug #1532974, rings a bell?
[09:20] <lpotter> just wanted to chat about his change to qtubuntu-sensors. :) no biggy
[09:21] <mzanetti> lpotter, grayback will show up in approx an hour...
[09:21] <mzanetti> Saviq, hmm, not really
[09:21] <mzanetti> lpotter, oh sorry. I saw saviq told he's on hols for real
[09:22] <mzanetti> didn't know :D
[09:22] <lpotter> I have a couple patches for that package, but I need to talk to someone about that. maybe tvoss might be better
[09:22] <lpotter> because it has "issues" :)
[09:23] <lpotter> (not his patch but sensors handling)
[09:23] <mzanetti> heh, well, I guess you can just propose an MP with the fixes
[09:24] <lpotter> sure. but one issue I haven't looked at, as it would be a bigger thing to deal with
[09:28]  * Saviq flashes flo
[09:28] <lpotter> thought I had a bug that it...
[09:32] <Saviq> mzanetti, some success: https://unity8-jenkins.ubuntu.com/view/Build/job/build-2-binpkg/
[09:33] <mzanetti> saviq nice!
[09:34] <Saviq> I just realized, though, that cross-building will give us trouble for qmake projects and such, so might need a armhf node after all
[09:34] <mzanetti> hmm... qmake cross compiling should work fine nowadays
[09:34] <Saviq> oh well, yeah, but there's no project that actually implements it in their packaging
[09:35] <Saviq> because it's some manual labour
[09:35] <Saviq> like generating debian/control to include the cross qmake
[09:35] <mzanetti> well, I anyways think proper armhf nodes would be beneficial
[09:36] <lpotter> I tried xcompiling qt with sbuild last week, and it failed.
[09:38] <lpotter> and I cried
[09:38] <Saviq> yeah, it should be doable these days, but it's not convenient yet
[09:41] <lpotter> well. qt itself is a special case and no doubt trickier than your average qt app
[09:53] <Saviq> trueth
[11:24] <dandrader> Saviq, did you also have https://code.launchpad.net/~dandrader/qtubuntu/offscreenSurface-lp1527737/+merge/281638 installed?
[11:24] <dandrader> Saviq, (talking about https://code.launchpad.net/~dandrader/qtmir/appRestart-lp1527737/+merge/281701/comments/716413  )
[11:25] <Saviq> dandrader, no
[11:26] <Saviq> did I miss a prereq?
[11:26] <dandrader> Saviq, it's stated in the MP checklist
[11:27] <dandrader> Saviq, offscreenSurface-lp1527737 removes noise from a closing application
[11:27] <dandrader> Saviq, without it an application will create a new mir surface when shutting down
[11:27] <dandrader> Saviq, just so that Qt does some internal GL context clean up it seems
[11:29] <dandrader> Saviq, will try that use case some more to try to get that crash, then remove the offscreenSurface-lp152773 patch and try it again. who knows, maybe I'm lucky :)
[11:30] <Saviq> dandrader, if crash is indeed the problem, you can just kill -SIGABRT something
[11:30] <Saviq> dandrader, the prereq says "not strictly required", so maybe it is, after all
[11:31] <Saviq> dandrader, in any case, the closing surface should not cause me being unable to start an app, shouldn't it?
[11:31] <Saviq> dandrader, the log said "rejecting because there is one queued to start already"
[11:31] <Saviq> or some such
[11:31] <dandrader> Saviq, let me reproduce that situation before saying anything else.....
[11:32] <Saviq> dandrader, yeah, sorry we have no better steps, but it happened to me straight away when I tried those steps from trello
[11:32] <Saviq> and he had it with both camera and settings, so unlikely to be content-hub-related
[11:34] <dandrader> Saviq, when launching settings straight from the dash!?
[11:35] <Saviq> dandrader, I'd assume so, rvr ↑?
[11:37] <rvr> Saviq: ?
[11:37] <Saviq> rvr, when you had settings in a "can't launch" state yesterday with broken silo 30
[11:38] <Saviq> rvr, do you remember how did you start them before?
[11:38] <rvr> Saviq: Ah, yes, directly from the Dash
[11:38] <Saviq> dandrader, ↑
[11:38] <rvr> But I also opened it from the indicators
[11:46] <tsdgeos> Saviq: went the poor man's way to fix the i386 precision test failure https://code.launchpad.net/~aacid/unity8/card_test_precision/+merge/282425
[11:55] <Saviq> tsdgeos, ack
[14:03] <tsdgeos> i hate how the train makes the pacakges available but takes more time to merge the code in bzr
[14:13] <Saviq> tsdgeos, that's only because of overlay
[14:14] <Saviq> they're not published in xenial until they migrate
[14:16] <tsdgeos> right
[14:16] <tsdgeos> i mean
[14:17] <tsdgeos> no
[14:17] <tsdgeos> 8.11+16.04.20160111.1-0ubuntu1
[14:17] <tsdgeos> says apt-cache policy in xenial
[14:17] <Saviq> sure you don't have proposed enabled?
[14:18] <Saviq> https://launchpad.net/ubuntu/+source/unity8
[14:18] <Saviq> ah because it got published already
[14:18] <Saviq> code should be there then, too
[14:18] <Saviq> ah it's waiting for gsettings-qt
[14:18] <Saviq> which is blocked by unity-scope-click's flaky tests :*
[14:19] <mterry> tsdgeos, ah that must have been it -- I didn't run make so CardCreator.js never got copied.  Didn't know about that
[14:20] <tsdgeos> mterry: yeah it's a bit weird
[14:21] <mterry> tsdgeos, presumably our cmake code is missing a target depends there for the test
[14:43] <tsdgeos> Saviq: is there anything we can do to convince it into publishing the changes to bzr?
[14:44] <Saviq> tsdgeos, yes
[14:48] <Saviq> will ask for a forced merge&clean
[15:21] <mterry> Saviq, ooh, a "Unity8 bot" instead of jenkins CI  :)
[15:32] <Saviq> busy busy https://unity8-jenkins.ubuntu.com/view/qtmir/
[15:56] <tsdgeos> cimi: https://code.launchpad.net/~aacid/unity8/avila_apps_scope/+merge/282454
[15:57] <tsdgeos> Saviq: it has colors \o/
[15:57] <tsdgeos> and boxes \o/
[15:57] <tsdgeos> whatever they mean :D
[15:58] <cimi> tsdgeos, ok !
[15:58] <tsdgeos> mzanetti: that branch for you too ↑↑↑
[16:07] <Saviq> tsdgeos, as long as it's green ;)
[16:07] <tsdgeos> I wonder if the newly released Qt virtual keyboard is of any interest to us
[16:08] <tsdgeos> Saviq: will you give us a quick lesson on how to read those boxes in Austin?
[16:08] <Saviq> tsdgeos, sure
[16:08] <Saviq> tsdgeos, IIUC not really, it's more geared towards embedded
[16:10] <tsdgeos> code landed!
[16:10]  * tsdgeos runs the conflcits script
[16:13]  * Saviq will put that script in our CI at some point :p
[16:36] <Saviq> @unity FYI: if qtmir tests failed for you it's because of https://code.launchpad.net/~saviq/qtmir/use-qstandardpaths-cache/+merge/282394
[16:40] <tsdgeos> Saviq: on next qtmir landing can you include https://code.launchpad.net/~aacid/qtmir/timestampsInPast/+merge/280567 (and optionally https://code.launchpad.net/~aacid/qtmir/unlikelyResetStartTime/+merge/281843 )?
[16:40] <Saviq> tsdgeos, ack