=== jhodapp|brb is now known as jhodapp|afk === beidl_ is now known as beidl [08:19] didrocks, q: we need to move qml files into unity8-common, unity8 and unity-scope-tool would depend on it, but they'd have some other common dependencies, should those be moved under -common (even though that doesn't really depend on those), or should we just copy deps to unity-scope-tool? [08:19] pstolowski, I'm taking care of that ↑ [08:21] Saviq: I'm unsure to fully understand the "some other common dependencies […] which needs to be copied over? [08:23] Saviq, thanks! [08:23] didrocks, say, unity8 depends on unity8-common, so does unity-scopes-tool, both would also need to depend on uitk [08:23] ah [08:23] didrocks, so I can either put that dep on -common, or on unity8 and tool separately (which is more logical) [08:23] Saviq: but the dep really where the dep is created [08:24] so, if all qml files using the toolkit are in -common [08:24] -common needs to dep on uitk [08:24] if nothing else in the unity8 binary package deps on the toolkit [08:24] don't dep there on the toolkit, but only in -common [08:24] does it make sense? [08:24] didrocks, well, that just doesn't help, then, 'cause I'd just have to move all the deps from under unity8 to unity8-common, so... [08:25] which beats the purpose... [08:25] Saviq: how does this beats the purpose? [08:25] didrocks, because we want to install unity-scope-tool without everything that unity8 brings [08:25] but those -common files deps on the uitk and so on? [08:25] so maybe you need to split in 2 packages [08:25] didrocks, they files do, but no one will use them [08:26] didrocks, i.e. they're only used by either unity8 or unity-scope-tool [08:26] didrocks, we wouldn't support any other use [08:26] didrocks, so splitting the qml files into "real" common ones would be rather tricky and tedious [08:26] all the qml files are mixed? [08:26] to maintain [08:26] didrocks, more or less, yes [08:26] hum [08:27] didrocks, well, maybe not really mixed... [08:27] I could try and make an informed decision... like Components and Dash would end up in -common, others would only live in unity8... [08:27] ok let me try [08:27] I'd say the issue is how you separated those, and that will only reflect in wrong package dependency chain [08:27] that we can do [08:28] not really loving it, but if there is no other alternative [08:28] (the thing telling "we'll fix it later", you know how it goes…) [08:28] yeah I understand [08:28] didrocks, you're not loving what? [08:28] Saviq: having -common without any dep and reflecting those in unity8 and -scope-tools [08:29] didrocks, right, understood [08:29] didrocks, yeah, maybe I can do better [08:29] Saviq: keep me posted if you need any second eye [09:11] mhr3, think we should emit scope-ui-starting on scope tool startup? [09:12] Saviq, hm, not really necessary for sdk usage [09:12] and if you're running it manually you should know better :) [09:14] mhr3, ok [09:23] mzanetti: it's defenetely a bug in SmoothedAnimation [09:23] now i only need to understand the code ^_^ [09:23] and fix it [09:23] Saviq: or we move away from SmoothedAnimation (the unlocking gets locked bug) [09:24] tsdgeos, well, rather more maintainable if you fix it :) [09:24] agreed ;) [09:24] basically it is getting confused because we change the value of the smoothedanimation while the smoothedanimation is running [09:24] and at some point i understand something goes wrong [09:25] and does a last update oh wait i had to be stopped oh wait [09:25] and all goes bad [09:25] didrocks, https://code.launchpad.net/~saviq/unity8/split-common/+merge/214907 please [09:26] here some debug code you won't probably make much sense of http://paste.ubuntu.com/7225441/ [09:26] but basically the last UCT is the smoothtimer updating itself [09:26] when it should not anymore [09:28] mhr3, do we want scope tool to recommend scopes at all? [09:29] Saviq, no need imo [09:38] tsdgeos, well, isn't SmoothedAnimation meant to deal with exactly that? changing target value? [09:39] tsdgeos, so sounds like a bad bug for it [09:39] Saviq: it is :D [09:39] ;) [10:09] Saviq, can we keep going with yesterday debug of closing the app? [10:14] tsdgeos: thanks for digging into this [10:14] yeah, confirms my suspicions [10:16] Cimi, sure you can ;) [10:17] jibel, hey, can you please upload unity8.log from .cache/upstart/unity8.log? [10:17] to bug #1304959 [10:17] bug 1304959 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in QMessageLogger::fatal()" [Undecided,New] https://launchpad.net/bugs/1304959 [10:17] Saviq, yesterday evening I had same issues [10:17] QObject::connect(view->engine(), SIGNAL(quit()), application, SLOT(quit())) [10:17] this is my connection [10:18] I have this in the start_shell before int app->exec() [10:18] application seems to hang [10:18] Saviq, unity8-mir.log, right? [10:18] jibel, maybe, yes [10:18] * Saviq has nothing to do with the desktop session... [10:18] and this is my gdb that says nothing [10:19] http://paste.ubuntu.com/7222383/ [10:19] Saviq, is there any HW requirement apart running opensource drivers to run unity8 on a desktop? [10:19] jibel, there shouldn't be... [10:19] Cimi, thread apply all bt [10:19] Cimi, otherwise you only get a single thread [10:20] Saviq, log attached [10:22] jibel, thanks [10:32] what - apart from /var/cache/apt - tends to fill up the device eating up disk-space, which can easily be freed? [10:32] MacSlow, /var/log [10:33] MacSlow, why are you missing space on device? [10:34] Saviq, can't currently install the boost-dev packages to compile u-s-c on it [10:38] MacSlow, I was afraid you'll tell me that :P [10:38] MacSlow, https://wiki.ubuntu.com/SimpleSbuild and https://wiki.ubuntu.com/CrossBuilding [10:38] we really need to stop building stuff on device, it's just wasting time [10:39] hi pstolowski, was there a conclusion reached on how to remove the unity8 dependency from the SDK? [10:41] dpm, hi, yup, the unity8 will be split, Saviq is on it [10:42] Saviq: have a sec? [10:42] tsdgeos, hit me [10:43] cool, thanks pstolowski [10:45] Saviq: so i know how to fix that smoothedtimer bug, problem is, there's a commit for Qt 5.3 that i think also fixes it, and since it's virtually unreproduceable in the desktop (i guess sttuff is simply faster there) it's going to be hard to push for my fix upstream 5.3, so we basically have the option to go with my distro-patched patch for 5.2 until we hit 5.3 or try to backport the 5.3 patch. Problem is, my patch is 1 line and 5.3 patch is 460 (yes it [10:45] obviously does more things than mine) [10:45] dandrader, https://wiki.ubuntu.com/SimpleSbuild and https://wiki.ubuntu.com/CrossBuilding [10:45] Saviq: so i'm undecided on what we prefer, it's a bad-bad decision :D [10:45] i think i prefer going my 1-line patch route [10:46] but i can see its problems too [10:46] tsdgeos, +1 [10:46] tsdgeos, can we work around in unity8 code until 5.3, though? [10:46] (like add the debug :P)? [10:46] I understand we just need to spin the loop or so? [10:47] tsdgeos, basically, this late in the cycle I'd rather we do a workaround, and push for 5.3 [10:48] Saviq: just drop the smoothedanimation is the proper solution [10:49] or don't change the value of the property animated while it's animating [10:49] tsdgeos, proper as in that's what we should do? [10:49] tsdgeos, that will change the behaviour, though, won't it [10:49] proper as in "only way to workaround it" [10:49] tsdgeos, mhm [10:51] i know [10:51] it's bad-bad :/ [10:51] Saviq: my fix should be pretty safe [10:52] tsdgeos, ok, convince Mirv, then :) [10:52] he [10:52] tsdgeos, is your change "included" in the upstream patch? [10:52] Saviq: no [10:52] tsdgeos, or is it just refactored/approached differently [10:52] Saviq: basically the upstream patch is "Make SmoothedAnimation and SpringAnimation smoothly transition again" [10:53] tsdgeos, right... [10:53] since it seems they are not as smooth as they should [10:53] and while doing that i'm almost sure they've fixed our issue [10:53] yeah makes sense [10:53] but then that's a bigger change [10:53] so yeah let me talk with Mirv :D [10:53] Mirv: ping need you [10:56] tsdgeos: patches welcome! \o/ only problem that hard to get in since final freeze starts tomorrow and Qt is not touch specific [10:57] Mirv: how do you want the patch? bug in lp? [10:58] tsdgeos: bug in LP, attached patch. [10:58] tsdgeos: is it fixing a blocker listed on the blockers list? [10:58] Mirv: it is [10:58] (I'm thinking whether it can wait for u series to open next week or should go in before final freeze) [10:58] right, good to know === MacSlow is now known as MacSlow|lunch [11:17] didrocks, so ${source:Version} instead of ${binary:Version}? [11:18] didrocks, that doesn't put :arch in the dep does it? [11:18] Saviq: shouldn't, that should make the package binNMUable though [11:19] * Saviq has no idea what that means ;) [11:23] pete-woods, should we care about umoutput not building on powerpc / arm64? [11:23] https://launchpad.net/~ci-train-ppa-service/+archive/landing-010/+build/5892098 https://launchpad.net/~ci-train-ppa-service/+archive/landing-010/+build/5892099 [11:23] actually powerpc / ppc64 [11:24] pete-woods, hmm I wonder if it's the new style connections issue [11:30] no, those give you nice message [11:36] Mirv: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1305015 [11:36] Ubuntu bug 1305015 in qtdeclarative-opensource-src (Ubuntu) "Fix QSmoothedAnimation sometimes regressing in value" [Undecided,New] [11:45] tsdgeos: ok === MacSlow|lunch is now known as MacSlow [12:20] Saviq: googling for what umoutput is.. [12:20] ah [12:20] usermetrics outut [12:20] *output [12:20] weird [12:21] Saviq: I suppose it could be the new connection style.. but still very strange [12:23] I would find it hard to believe that Qt signals don't work on arm64 [12:23] but I can't offer any other explanation here, it's a definitely constructed object, and all we do is try and connect the signal === jhodapp|afk is now known as jhodapp [12:26] both are 64 bit arches.. [12:27] I could just try using the old style connections.. [12:45] pete-woods, yeah, please do [12:45] Mirv, do we have a plan for Qt 5.3 yet? [12:48] Saviq, do you happen to know how to fix/workaround this http://pastebin.ubuntu.com/7226043 [12:48] MacSlow, Cimi had that yesterday [12:48] Saviq, happened while trying to run "mk-sbuild --target=armhf trusty" [12:48] Cimi, ^ [12:48] MacSlow, it was a temporary archive issue for him [12:48] Cimi, did you find a solution /workaround for that? [12:49] MacSlow, try dropping the chroot from /var/lib/schroot/chroots and /etc/schroot/chroot.d and try again [12:49] MacSlow, do you have an apt cache or something? [12:49] Saviq, not that I know of [12:50] MacSlow, basically... try again, and if it happens again we'll escalate, this happens too often - or maybe is just bad timing / luck [12:51] Saviq, ok [12:53] didrocks, there are some more complaints on gencontrol output: http://pastebin.ubuntu.com/7226070/ should/how do I clean those up? [12:55] Saviq: remove ${shlibs:Depends} from -autopilot [12:55] there is no shlibs to link against [12:55] on the others, should be misc:depends, no pre-depends? [12:56] didrocks, it's Pre-Depends: ${misc:Pre-Depends} [12:56] didrocks, not sure where that came for === _salem is now known as salem_ [12:57] Saviq: ok, if may, I'll at that in a quieter time [12:58] didrocks, sure [13:00] Saviq, tried again with wiped /var/lib/schroot/chroots and /etc/schroot/chroot.d and still run into the same unmet-dependency error http://pastebin.ubuntu.com/7226043 [13:01] didrocks, FWIW, you added it :) http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/77#debian/control [13:01] Saviq: so, it should be perfectly right! :p [13:01] more seriously, I'll have a look later on [13:02] MacSlow, can you enter that chroot and apt-cache policy libc6 libc6-dev [13:02] MacSlow, you should be able to see it in `schroot -l` and then enter it with `schroot -c trusty-amd64-armhf` [13:02] -u root for good measure, but shouldn't be necessary [13:04] Saviq, here the output http://pastebin.ubuntu.com/7226113 [13:05] MacSlow, aaah [13:05] ? [13:05] MacSlow, skip proposed [13:06] Saviq, but outside that chroot on my regular system?! [13:06] SKIP_UPDATES="1" [13:06] SKIP_PROPOSED="1" [13:06] MacSlow, sbuild [13:06] ok [13:06] MacSlow, add that ↑ to mk-sbuild.rc [13:06] Saviq: no plan et [13:06] yet [13:07] Mirv, can we make one? :) [13:07] Saviq, which should be located where? [13:07] MacSlow, ~/.mk-sbuildrc [13:08] MacSlow, Cimi, you can also just pass --skip-updates --skip-proposed to mk-sbuild [13:11] * MacSlow crosses fingers for next attempt [13:13] Saviq: feel free to start planning! :) I'd need to have time dedicated for that from landing duties if it's wanted. [13:15] Mirv, ok, I'll start digging [13:17] Saviq: somewhere on my hdd I've a qtbase 5.3.0 beta initial packaging (patches removed until build starts), that's all [13:20] josharenson: http://notyetthere.org/data/sorting.tar.gz [13:27] Saviq, http://paste.ubuntu.com/7226208/ [13:34] Saviq: i'm confused at how reverting happens at the package level but not at the bzr level [13:34] tsdgeos, direct archive upload [13:34] i thoght this new airline mode made our bzrs and packages be synce [13:34] d [13:35] confusing :/ [13:35] tsdgeos, we need to sync to bzr manually [13:36] tsdgeos, but we don't, until the next landing, because we might actually get a fixed version straight away [13:36] ok [13:37] tsdgeos, we won't, in this case, but that's the general approach [13:38] mhall119, hey, we're sprinting here, so won't be able to attend the call today - but the time is much better for me and will be able to join from now on [13:38] ok [13:48] Saviq: https://bugs.launchpad.net/unity8/+bug/1296777 [13:48] Ubuntu bug 1296777 in Unity 8 "avatar displayed incorrectly in notification" [High,In progress] [13:50] Saviq, while I can trigger a build via sbuild now... I run into a several build issues -> http://pastebin.ubuntu.com/7226291 [13:53] MacSlow, what source is that? [13:53] Saviq, bzr branch lp:~unity-team/unity-system-compositor/new-gl-screen [13:53] MacSlow, ok, so u-s-c, let me try [13:53] Saviq, made a dpkg-buildpackages -S from that and ran the resulting .dsc through sbuild [13:55] MacSlow, confirmed, there must be some packaging / building issues [13:55] xnox, can you please have a look at http://paste.ubuntu.com/7226322/ [13:56] xnox, it's an armhf cross-build of lp:unity-system-compositor [13:56] it's definitely missing :any for the python dep [13:56] Saviq, so it's a chroot-issue?! [13:57] xnox, unping [13:57] MacSlow, add :any [13:57] MacSlow, in debian/control [13:57] MacSlow, in the python dependency [13:57] built fine for me now [13:57] * MacSlow tries... [13:57] MacSlow, bug in u-s-c packaging [13:58] Saviq: =) [13:58] Saviq: correct. [14:00] Saviq, add or replace "all" with "any" ? [14:07] MacSlow, there is no "all" [14:07] MacSlow, http://paste.ubuntu.com/7226374/ [14:08] xnox, yeah, the amount of errors was scarier, so thought would need you anyway :D [14:17] Saviq: i don't understand why we use a chroot for x-compiling [14:18] dednick, v [14:18] https://code.launchpad.net/~ogra/unity8/speed-up-indicator-startup/+merge/214944 [14:18] tsdgeos, because -dev packages conflict, for one [14:19] tsdgeos, i.e. a -dev:amd64 and -dev:armhf are not co-installable [14:19] hmmmmm [14:19] right, that's unforunate [14:19] tsdgeos, also clean chroot makes sure your build deps are correct [14:19] tsdgeos, and also it doesn't leave cruft on your host [14:19] tsdgeos, why not? [14:20] tsdgeos, I'm having lots of "fun" with it :) [14:20] because well, we have multiarch [14:20] we shouldn't need a chroot tbh [14:20] i don't even see why -dev would conflict if using multiarch [14:20] unless they both try to install the same includes [14:20] tsdgeos, they do [14:20] but then the packages should be smart enough [14:20] to knwo they are actually the same includes [14:21] Saviq: i'm not saying they do not, i am saying i don't see why they should not technically be able to be coinstalled [14:21] but i'm not fixing debian packaging, they decided they want a hard system a long time ago :D [14:21] tsdgeos, it's just cleaner really, and doesn't need to be slower [14:21] mterry, hey there... I'm currently trying to get my copy of u-s-c (with the latest tweaks) compiled and tested via cross-compiling [14:22] MacSlow, OK [14:22] tsdgeos, if you prep a pre-populated chroot for unity8, for example, you can skip apt update/distupgrade, and go straight into compiling [14:22] is what I do [14:22] Saviq: doesn't feel cleaner to me, but that's a matter for discussing with a beer, not now i guess [14:24] sure, that's not "clean", clean is when you start with a barely debootstrapped chroot, but that takes a long time, and you don't need to verify deps every time [14:25] tsdgeos, but also, if you're used to use chroots, you're suddenly able to build for different distro releases, control what's in them, build sets of packages without introducing them to your host directly [14:26] and then suddenly i need 500G of disk space more :D [14:26] because of so many unclean chroots around [14:26] but yeah i see the point [14:26] mterry, is unity-system-compositor from u-s-c really enought to test our new boot-screen binary? As I still don't have a ppa-silo to use on the device I wonder if I might be missing some packages. [14:26] i just don't like it :D [14:27] if mumble was a physical thing... [14:27] * MacSlow would throw it against the wall now!!! [14:28] Saviq: I have pushed an update to the branch that ditches the C++11 style connect calls [14:28] pete-woods, what's the problem with them? [14:29] dandrader: I don't know for sure, but it looks like they *might* not work on arm64 and ppc64 [14:29] dandrader: if the tests pass after this change, then we will know that for sure [14:30] pete-woods, did you read the ml? it's fixable with -fPIE [14:30] but i don't think that was your issue anyway [14:31] mhr3: clearly I didn't :p [14:32] looks like the same thing as I'm seeing [14:32] pete-woods, ok let's see, /me presses [14:33] thanks :) [14:35] MacSlow, it should be enough to see the boot up animation yeah [14:38] mterry, hm... installed the one I cross-compiled, but I don't see it being displayed during bootup [14:38] MacSlow, oh~! [14:38] MacSlow, right, it's disabled by default. You'll want to edit a file... let me see [14:38] mterry, I can't force it manually I assume [14:38] mterry, ah [14:39] MacSlow, edit /usr/share/ubuntu-touch-session/usc-wrapper [14:39] MacSlow, and add a --spinner=/usr/bin/unity-system-compositor-spinner argument [14:39] pete-woods, wow, i must be blind, i totally missed those connect messages when i looked at the log [14:39] so in that case, yea, it's that thing [14:39] mterry, ah... right the --spinner option [14:40] -fPIE would solve it :) [14:41] mhr3: glad we agree :) [14:43] elopio, hey, I left a comment or two on your MPs around AP tests [14:43] mterry, I'll test my local changes via the cross-compiled .deb before I commit them... some build-fixes I pushed already (so it'll work with cross-compiling) [14:44] mterry, did you ask for a silo back for split greeter yet? [14:46] Saviq, I asked kgunn earlier today but he never got back to me. If you can press some buttons that sounds good [14:46] Saviq, let me get you a list of branches... [14:46] Saviq, can a silo depend on another silo? [14:46] Saviq, fyi... so cross-compiling for u-s-c works now here too... and the resulting armhf-deb works on the devices too [14:46] mterry, no [14:46] MacSlow, see :) [14:47] it's awesome ;) [14:47] Saviq, do you know how close Mir 0.1.8 is to landing? [14:47] mterry, ah actually it seems to be there [14:47] mterry, in silo 2 [14:47] mterry, but a merge conflict [14:47] mterry, https://ci-train.ubuntu.com/job/landing-002-1-build/29/console [14:48] Saviq: thanks. I'll check. [14:48] mterry, that's the current list http://pastebin.ubuntu.com/7226534/ [14:48] mterry, ah, that conflict happened yesterday, let me know what to do [14:48] Saviq, ok, we can trim that a bunch. let me see... [14:49] Saviq, mixed bag... as quick iterations still are slow... because a cross-build via the chroot has to recreate the whole thing again [14:49] mterry, for mir landing, kgunn how close are we to land it? [14:49] MacSlow, not necessarily, there's a few tricks (I should probably put them in the wiki) [14:49] Saviq, is there a way to save all the grabbed dependencies somehow for the chroot [14:49] MacSlow, a) prepare a prepopulated chroot for a project with all the dependencies [14:49] mterry: crap...got distracted [14:50] mterry: Saviq ...unity-mir branch has a bug, gerry's gonna work on a fix [14:50] Saviq, so my plan to avoid further mir/devel drama is to base my branches off mir 0.1.8 (and just add one bugfix branch for mir that doesn't change api). So I'd like to drop the platform-api and unity-mir branches. Plus the indicator-sound branches can go [14:50] Saviq, yeah... that would be nice... atm I don't gain any speed-ups in my turn-around cycles using cross-compiling [14:50] for the mir silo [14:50] MacSlow, yeah, just create a separate chroot, chroot -u root source:foo-amd64-armhf into it, and apt-get build-dep -aarmhf foo [14:50] Saviq, got it [14:51] MacSlow, then, you can --no-apt-update --no-apt-distupgrade for sbuild to go straight into the build [14:51] MacSlow, but also, you can just open a chroot session yourself [14:51] MacSlow, and just dpkg-buildpackage -aarmhf -nc in there, it will still build packages, but won't dh_clean, so recompilation should be real fast [14:52] MacSlow, as I mentioned, I have plans to make a tool to automate / wrap all that into a relatively simple to use thing [14:53] but already there's things you can do [14:53] Saviq, but maybe we should just wait until 0.1.8 lands unless we want to replicate that silo inside this one [14:53] Saviq, I'll use the tips now and don't wait for that :) [14:53] mterry, your call, really :) [14:53] mterry, the amount of button presses doesn't change much for us - build time would, of course [14:54] Saviq, hmm, if it's easy. Then let me get a list of branches *on top of* the 0.1.8 silo I want [14:54] Saviq, that login into a custom chroot and prepopluating it would be basically to do a "sudo apt-get build-dep unity-system-compositor" there, right? [14:55] Saviq, so if you can configure a silo with Mir 0.1.8 contents + http://paste.ubuntu.com/7226569/ [14:55] that would be swell! :) [14:56] I'll see if there are any current merge conflicts [14:56] Saviq, to create a custom chroot I would have to use --name=?! [14:59] MacSlow, yeah, why the !? :D [14:59] MacSlow, yes, -aarmhf === jono is now known as Guest1478 [15:00] Saviq, I've not looked at the man-page yet... which I have now :) [15:09] MacSlow, https://wiki.ubuntu.com/SimpleSbuild#Pre-populated_chroots btw :) [15:09] Saviq, too late I already did it :) [15:09] MacSlow, I just added that section ;) [15:10] Saviq, have that page linked anyway for later reference [15:20] mterry, https://code.launchpad.net/~andreas-pokorny/mir/no-initial-display-configuration-sent-to-hosting-server/+merge/213126 targets mir devel... [15:20] mterry, if we want to skip devel, we need one to target mir trunk [15:21] Saviq: I've messed up the signal change, that branch is going to fail to build [15:22] pete-woods, k, let me know [15:24] Saviq, ok... I'll make a version that does [15:24] mterry, thing is, it probably does bring itself some devel already? [15:24] Saviq, no, it was made around the same time 0.1.8 was [15:25] Saviq, the line "mk-sbuild --arch armhf --name foo-amd64-armhf" was missing the distro to use... updated the wiki === olli__ is now known as olli [15:25] Saviq, I tested to make sure it doens't go further. But no matter, I'll make a new one targeting lp:mir [15:27] mterry, ok [15:27] MacSlow, right, thanks [15:27] MacSlow, thought it would use the default [15:27] Saviq, it does not for some reason [15:28] MacSlow, it's a required arg apparently [15:29] Saviq, yeah... the only one without a needed option :) [15:29] Saviq, try lp:~mterry/mir/no-nested-display-config [15:31] mzanetti, Saviq, so it seems that for the launcher items we're using negative numbers to hide the count, where as Unity7 allows negative numbers to be shown. Is that diff on purpose? [15:32] tedg: no, not really on purpose. I was talking to design and we didn't find a use case for negative numbers. are you aware of any? [15:32] tedg: I can change that if required === gatox is now known as gatox_lunch [15:33] Well, you may do inbox zero, but I do inbox negative one ;-) [15:33] Temperature? [15:33] on the launcher item.... hmm, ok... fair enough [15:34] Okay, I don't need it changed right now. I'll just have two dbus properties and if visible is turned off return -1 for now. [15:34] Then we can update the whole thing at once. [15:34] tedg: ok [15:35] oh I have to make that a merge [15:36] Saviq, ok, made that branch a real merge [15:36] mterry, an MP, yeah [15:37] mterry, hmm, where? [15:38] Saviq, https://code.launchpad.net/~mterry/mir/no-nested-display-config/+merge/214979 [15:44] xnox, platform-api fails to cross build due to gcc dep, is that something that could be fixed do you think http://paste.ubuntu.com/7226779/ ? [15:45] Saviq: no, that's not something that can be fixed. [15:46] xnox, ok thought so [15:46] Saviq: they must stop depending on a specific gcc, and we don't provide all versions of gcc's as cross-compilers. [15:47] xnox, well, there is a 4.7 cross gcc, could the dependency be improved so that it works? [15:47] Saviq: no, as there is no way to know the correct arch you want. [15:47] (target that is) [15:48] xnox, right, so manual it is then [15:48] xnox, got it [15:48] cause we cross-compile to armhf, arm64, ppc64el etc. and we want to have packages generic, when they cross-compile. [15:48] MacSlow, no need for sudo [15:49] MacSlow, as long as you're in the sbuild group [15:49] MacSlow, only mk-sbuild will ask you for sudo password [15:50] Saviq, I am (verified with id) but I still needed sudo [15:50] MacSlow, sounds like a bug, then, mzanetti had the same for the keygen... [15:50] MacSlow, should never happen [15:53]