[06:52] <tigrang> Anyone know John Lea's nick in here (if he does come in here), or anther way to ping him? Thanks.
[06:53] <tigrang> heh nvm, just saw the contact link in LP
[07:22] <didrocks> Trevinho__: hey, around?
[08:12] <tsdgeos> Saviq: Morning! how are we regarding the unity-core stuff?
[08:13] <Saviq> tsdgeos, it didn't build on raring, so yeah, let's extract it into a separate tree
[08:15] <tsdgeos> oka
[08:16] <Saviq> tsdgeos, can you take care of it?
[08:16] <tsdgeos> Saviq: sure, so what we want is a new branch inside the unity repo where we just build unity-core? And have that into the phablet-ppa, right?
[08:17] <Saviq> tsdgeos, yeah, preferably keeping the tests for UnityCore
[08:17] <tsdgeos> ok
[08:17] <tsdgeos> Saviq: do you want me to just adapt the cmakelists and keep the uncompiled code around or kill the code?
[08:18] <Saviq> tsdgeos, whatever's easier
[08:19] <didrocks> Saviq: didn't build on raring? it surely does build :)
[08:19] <Saviq> didrocks, long story ;)
[08:19] <didrocks> ok ;)
[08:19] <Saviq> didrocks, it's behind trunk a lot (and conflicting a lot, too)
[08:19] <didrocks> ok, so not unity-core unity, but old unity-core forked :)
[08:21] <Saviq> didrocks, yes
[08:23] <Saviq> tsdgeos, or...
[08:23] <tsdgeos> yes?
[08:24] <Saviq> tsdgeos, we only use r2909..r2910
[08:24] <Saviq> from lp:unity/phablet-mods
[08:25] <Saviq> tsdgeos, so maybe we should first try just merging that on top of lp:unity
[08:25] <Saviq> and be done with it
[08:25] <tsdgeos> that seems sensible
[08:26] <tsdgeos> will do as soon as i stop deleting^Wreading emails
[08:26] <Saviq> tsdgeos, ok, try going that route, make sure it builds on armhf, though
[08:26] <Saviq> in case that wasn't merged back
[08:27] <tsdgeos> armhf is the phone/tablet?
[08:27] <Saviq> yes
[08:27] <tsdgeos> ok
[08:27] <Saviq> tsdgeos, and on quantal, too...
[08:29] <tsdgeos> yes
[08:29] <tsdgeos> let's see how it goes :D
[08:52] <suga> I would like to get know about autopilot testing. I'm installed python-autopilot and download the autopilot test suite from bzr
[08:52] <suga> I'm facing the issue when executing the simple autopilot test, it couldn't be succcessful
[08:54] <sil2100> suga: hi!
[08:54] <sil2100> suga: what are the problems you are experiencing? What test suite are you trying to run? What bzr branch did you download?
[08:55] <sil2100> suga: and first of all, what Ubuntu version are you using?
[08:55] <suga> Ubuntu 12.04
[08:55] <sil2100> Ah, 12.04, then it's a bit less straightforward on this version
[08:55] <suga> When i execute with the simple command the below error proept
[08:56] <sil2100> suga: what python-autopilot version are you using then? Since the main archives don't have autopilot for precise
[08:58] <suga> So, Ur suggestion is that not better to use Python-autopilot on ubuntu12.04?
[08:58] <sil2100> suga: not exactly, it's just a bit different to use it on 12.04
[08:59] <sil2100> suga: I got disconnected and didn't get an answer - what version of python-autopilot are you using and where did you fetch it from?
[08:59] <didrocks> hey sil2100!
[08:59] <suga> is there any reference for using python-autopilot on Ubuntu 12.04?
[08:59] <didrocks> sil2100: btw, you have results from the last week-end autopilot runs ;)
[08:59] <didrocks> sil2100: getting a little bit lower, but still work needed to be done! :)
[09:00]  * didrocks is trying to fix some unit tests failing due to glib behavior change
[09:00] <sil2100> didrocks: is build 16 'correct'?
[09:00]  * didrocks looks, one sec
[09:00] <sil2100> Since I see some new tests failing that didn't fail before, hm hm
[09:00] <suga> Noo... previous build
[09:01] <didrocks> sil2100: yep, that's from saturday morning
[09:01] <sil2100> suga: hm, not sure if there is one, but it's easy to do:
[09:01] <didrocks> sil2100: flacky tests? :/
[09:01] <suga> I can download from bzr repo?
[09:01] <sil2100> didrocks: it seems nvidia did something strange and suddenly all tests got broken, will check what it was
[09:02] <sil2100> suga: anyway, first of all, could you do apt-cache policy python-autopilot and tell me the version number installed?
[09:02] <didrocks> sil2100: yeah, it's not the first time it happens
[09:02] <didrocks> sil2100: it seems that if a service is failing, nothing tries to respawn it
[09:02] <didrocks> sil2100: like the hud in the past
[09:02] <didrocks> and so all tests are timing out
[09:03] <didrocks> sil2100: the "no respawn" is a bug in itself
[09:03] <sil2100> But still, it's very annoying and introduces a lot of false-positives
[09:03] <sil2100> :<
[09:04] <suga> ok thx.. I try with the command and tell the installed version
[09:04] <suga> So.. can u tell that is there any flexible tool for test automation on Ubuntu 12.04 unity?
[09:05] <suga> except from Autopilot
[09:07] <suga> installed version seems as Installed: 0.1~ppa1-0~12+2~precise1
[09:07] <didrocks> suga: ah, you are telling "false-positives" as well? :)
[09:07] <didrocks> oupss
[09:07] <didrocks> sil2100: ^
[09:07] <sil2100> didrocks: I actually picked that up hearing that from you ;) I like the sound of it very much
[09:07] <didrocks> ah :-)
[09:08] <sil2100> suga: ok, so, hmmm, give me a moment, need to check what version is this
[09:08] <didrocks> false joy: olli was pulling on my legs, telling that's a "French thing". I believed for one sec it wasn't one :)
[09:08] <sil2100> suga: but it should work like with the 1.1 version, so before you run some tests from any directory, you need to set PYTHONPATH to that directory, example:
[09:09] <sil2100> You have the tests in /tmp/unity/tests/autopilot
[09:09] <sil2100> So, you do:
[09:10] <sil2100> PYTHONPATH=/tmp/unity/tests/autopilot unity list
[09:10] <sil2100> To list the available tests from the given test branch
[09:10] <sil2100> The same when using run
[09:10] <suga> ahh ... thanks... I put the test on the location and set the python path
[09:11] <sil2100> PYTHONPATH=/tmp/unity/tests/autopilot unity run name.of.the.tests.to.run
[09:11] <suga> and let pick with the feedback from that
[09:11] <sil2100> And it *should* work, but sadly right now I have nowhere I could check that, since I'm on 13.04
[09:12] <suga> it's ok.. I try with my machine.. let u know if i face any issue
[09:12] <sil2100> Good luck
[09:13] <sil2100> didrocks: nvidia seems to have broken down on unity.tests.test_hud.HudBehaviorTests.test_dash_to_hud_has_key_focus
[09:13] <didrocks> sil2100: yeah, that's when the hud process is taken down, right?
[09:13] <didrocks> sil2100: and nothing restarts it?
[09:13] <sil2100> didrocks: it looks like it ;/
[09:14] <sil2100> */job/ps-unity-100scopes-experimental-autopilot-release-testing/label=autopilot-nvidia/16/artifact/results/artifacts/unity.tests.test_hud.HudBehaviorTests.test_dash_to_hud_has_key_focus.ogv
[09:14] <didrocks> sil2100: can you please open a bug on hud and ping ted for it?
[09:14] <didrocks> sil2100: would be nice to have get it fixed
[09:14] <sil2100> didrocks: will do!
[09:14] <didrocks> sil2100: other than that, I would say: look at the other configs
[09:45] <seb128> didrocks, sil2100: btw, jono opened https://bugs.launchpad.net/unity/+bug/1159200 about the segfaults he sees with the ppa
[09:45] <seb128> dednick, mhr3: ^
[09:47] <nic-doffay> Saviq, I'm back on the PageHeader tests now. What was that fix you recommended for the label hiding behind the search field? I can't seem to find it in the logs.
[09:48] <Saviq> nic-doffay, you need to check whether the label contentWidth + units.gu(40) < pageHeader's width
[09:48] <Saviq> nic-doffay, units.gu(40) being searchField's expanded width
[09:53] <didrocks> dednick: https://code.launchpad.net/~didrocks/unity/fix-tests-with-latest-glib-unity7/+merge/155189
[09:54] <nic-doffay> What does .gu do Saviq ?
[09:54] <Saviq> nic-doffay, it's grid unit - units.gu() returns the device-specific amount of pixels per grid unit
[09:55] <didrocks> dednick: and https://code.launchpad.net/~didrocks/unity/fix-tests-with-latest-glib/+merge/155190 for trunk
[09:56] <didrocks> mhr3: oh, almost forgot about it: https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation/+build/4397994/+files/buildlog_ubuntu-raring-i386.libunity_6.91.7%7Edaily13.03.25ubuntu.unity.experimental.certified-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:56] <dednick> didrocks: which tests were failing? unit or AP?
[09:56] <didrocks> dednick: unit
[10:00] <nic-doffay> That didn't seem to do the trick for me Saviq
[10:00] <didrocks> mhr3: pstolowski: mind having a look at the libunity FTBFS? ^
[10:01] <Saviq> nic-doffay, there's a "narrowMode" prop on searchContainer
[10:01] <Saviq> nic-doffay, that's what decides if the search entry goes next to the label or above it
[10:02] <Saviq> nic-doffay, that's where the condition needs to take the label's contentWidth into account
[10:02] <didrocks> mhall119: pstolowski: looking at it, I can bet this is the same cause, one sec
[10:08] <mhr3> didrocks, seems that way
[10:08] <mhr3> didrocks, so what exactly did they do to glib? if the binary is not present they ignore the desktop file?
[10:09] <didrocks> mhr3: exactly, see https://git.gnome.org/browse/glib/commit/?id=f641699299ed2713cf247e3465bb1a21612b36f7
[10:09] <didrocks> mhr3: I'll fix it in few minutes, debugging something else meanwhile
[10:13] <nic-doffay> Saviq, property bool narrowMode: label.contentWidth + units.gu(40) < pageHeader.width
[10:13] <mhr3> i'm a bit worried what other things will break
[10:14] <Saviq> nic-doffay, yeah, looks roughly OK, does it work?
[10:14] <nic-doffay> No, that was what I had done prior Saviq
[10:15] <Saviq> nic-doffay, pastebin your diff (with the tests) please?
[10:22] <mhr3> didrocks, it looks like the pygi overrides files in libunity are not installed for python3, could you add the necessary deb voodoo to make it happen pls?
[10:22] <mhr3> cc: davidcalle ^
[10:23] <didrocks> mhr3: will do, is the override the same than for python2?
[10:23] <mhr3> didrocks, yep
[10:23] <sil2100> brb!
[10:23] <didrocks> ok
[10:23] <mhr3> didrocks, merci
[10:23] <davidcalle> mhr3, didrocks, thanks :)
[10:24] <didrocks> davidcalle: mhr3: de rien :)
[10:25] <didrocks> dednick: tell me once you are happy with those branches, that will enable to start another daily
[10:26] <dednick> didrocks: sure. give me a sec.
[10:27] <dednick> didrocks: you want me to global approve?
[10:28] <nic-doffay> Saviq, test: https://pastebin.canonical.com/87598/
[10:28] <didrocks> dednick: yes please :)
[10:28] <dednick> didrocks: done
[10:29] <nic-doffay> Saviq, https://pastebin.canonical.com/87599/ Diff there
[10:29] <didrocks> dednick: thanks!
[10:31] <Saviq> nic-doffay, https://pastebin.canonical.com/87601/ seems to work for me
[10:37] <Saviq> brb
[10:44] <nic-doffay> Saviq, I'm doing a ./build then running qmlscene tst_PageHeader.qml, not seeing a fix though.
[10:52] <Saviq> nic-doffay, just resize the window, you'll see that it goes away when there's not enough space
[10:54] <Saviq> nic-doffay, that calls for a test, btw
[10:57] <nic-doffay> Agreed
[11:06] <nic-doffay> Saviq, the label still appears over the search box though.
[11:06] <nic-doffay> If the label is too long.
[11:08] <Saviq> nic-doffay, you mean when you expand it? then yeah, use units.gu(50) or so, I didn't take margins into account
[11:10] <nic-doffay> Yeah when it's expanded Saviq
[11:11] <Saviq> nic-doffay, yeah, I didn't take margins into account - units.gu(40) is the width of the expanded search entry
[11:11] <Saviq> nic-doffay, but the label has a margin etc.
[11:11] <Saviq> nic-doffay, so units.gu(50) looks fine, leaving some space between the label and expanded search entry, too
[11:36] <didrocks> mhr3: davidcalle: https://code.launchpad.net/~didrocks/libunity/install-python3-override/+merge/155206 FYI
[11:36] <didrocks> mhr3: davidcalle: we need to have libunity7 rebuilding first though before approving that one
[11:38] <davidcalle> didrocks, thanks, this was blocking some previews :) By the way, I've found a way to have geolocalized weather photos
[11:39] <didrocks> davidcalle: yeah, I saw your post on g+, this is awesome!
[11:39] <didrocks> davidcalle: not sure how many photos you find though ;)
[11:40] <davidcalle> didrocks, quite a lot actually, and it's flexible enough to give small cities a photo from the largest city near them.
[11:40] <didrocks> davidcalle: I think for my week-end html5-app, I will steal some of your logic here :)
[11:43] <davidcalle> didrocks, sure :) btw, you can even submit some pictures of Lyon's weather http://www.flickr.com/groups/projectweather/ to have them in the scope, because there is nothing yet for it.
[11:43] <didrocks> davidcalle: interesting, will do! :)
[11:43] <didrocks> davidcalle: there is no limitation in term of calls?
[11:45] <davidcalle> didrocks, I'm using the API key we have in distro since 12.10, I'm not sure of the limit, but since it's fine with our current load...
[11:45] <didrocks> davidcalle: excellent, will definitively have a look :)
[11:48] <nic-doffay> Could anyone have a look at this and recommend more tests which could be done?
[11:48] <nic-doffay> https://code.launchpad.net/~nicolas-doffay/unity/page-header-test
[11:56] <tsdgeos> Saviq: i've done the merge, but there's a billion things that don't build in quantal now, i'm going to make it build unitycore only, ok?
[11:56] <Saviq> tsdgeos, yeah I suspected as much
[11:57] <Saviq> tsdgeos, but at least we'll be able to keep on top of lp:unity
[11:57] <tsdgeos> yep
[13:11] <didrocks> mhr3: pstolowski: https://code.launchpad.net/~stolowski/libunity/insert-scope-id/+merge/155197/comments/338887
[13:12] <pstolowski> didrocks: ah, thanks
[13:12] <cyphermox_> good morning!
[13:12] <didrocks> pstolowski: yw ;)
[13:12] <didrocks> hey cyphermox
[13:12] <cyphermox> hey didrocks
[13:12] <cyphermox> how are you?
[13:12] <didrocks> good good, had fun due to glib this morning…
[13:13] <didrocks> and you?
[13:13] <cyphermox> yuck
[13:13] <cyphermox> good good, things are green, makes me happy
[13:13] <didrocks> :)
[13:13] <didrocks> cyphermox: watch out next time you have something new
[13:13] <didrocks> cyphermox: glib changed its way of dealing with .desktop file
[13:13] <cyphermox> oh fun
[13:13] <cyphermox> I'll keep that in mind
[13:13] <cyphermox> changed how?
[13:13] <didrocks> if the Exec= refers to a binary which isn't in the PATH
[13:14] <didrocks> it will ignore it
[13:14] <cyphermox> oh. cute.
[13:14] <didrocks> makes sense in most of case
[13:14] <cyphermox> yeah
[13:14] <didrocks> not for testing…
[13:14] <cyphermox> didrocks: you can fix PATH for testing ;)
[13:14] <didrocks> as you ship .desktop just to test something
[13:14] <didrocks> cyphermox: well, you need to ship those binaries…
[13:14] <didrocks> which maybe you don't want
[13:14] <didrocks> so I set to /bin/true :)
[13:15] <mhr3> didrocks, pstolowski, it wasn't really necessary to bump it in the first place
[13:15] <didrocks> mhr3: just be coherent if you bump it please :)
[13:17] <pstolowski> mhr3: I know it wasn't a hard requirement, but it's required for the functionality to work as expected
[13:18] <mhr3> pstolowski, oh but you bumped the requirement on the home scope branch
[13:19] <pstolowski> didrocks: I guess it's enough to bump the version in the existing changelog entry (that says UNRELEASED)?
[13:19] <didrocks> pstolowski: yeah, just modify this one
[13:19] <didrocks> pstolowski: we should remove the ~ btw
[13:21] <pstolowski> didrocks: "6.91.8-0ubuntu1" ?
[13:21] <didrocks> pstolowski: got it! :)
[13:22] <pstolowski> \m/
[13:24] <pstolowski> didrocks: https://code.launchpad.net/~stolowski/libunity/insert-scope-id/+merge/155221 pls
[13:25] <didrocks> pstolowski: speaking of which: http://bazaar.launchpad.net/~unity-team/libunity/libunity-7.0/view/head:/data/client-scopes.json
[13:25] <didrocks> pstolowski: there is no scope ids for gwibber/photos
[13:25] <didrocks> (and gwibber should be friends)
[13:26] <didrocks> pstolowski: maybe we should fix that at the same time?
[13:26] <pstolowski> didrocks: right
[13:27] <didrocks> pstolowski: tell me once done :)
[13:27] <pstolowski> k
[13:40] <pstolowski> didrocks: afaict, looking at http://bazaar.launchpad.net/~unity-team/unity-lens-friends/libunity7-compatible/files/head:/data/ , it's not 'friends', but 'social'?
[13:42] <didrocks> pstolowski: package is friends, social is the master scope name AFAIK
[14:10] <pstolowski> didrocks: hey, you've approved already? I'm updating client-scopes.json
[14:10] <didrocks> pstolowski: well, I wasn't sure if you wanted to finally push to the same branch as it was 45 minutes ago :)
[14:10] <didrocks> pstolowski: ok, will remove the approval
[14:10] <didrocks> pstolowski: done :)
[14:11] <pstolowski> didrocks: I had a lot of fun and confusion trying to find actual gwibber scope, and then also understanding what we want. and we're also missing .scope files for photos, adding them as well
[14:12] <didrocks> pstolowski: thanks!
[14:15] <mzanetti_> tsdgeos: lol: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner/280/artifact/qml_phone_shell.tests.testconfigurations.TestNexus4.test_hide_hud_click_outside_handle.ogv
[14:15] <mzanetti_> what the heck is happening here
[14:16] <tsdgeos> ouch
[14:16] <tsdgeos> poor guy :D
[14:31] <Saviq> dednick, you coming to standup?
[14:31] <dednick> Saviq: be there in a sec
[14:38] <mhall119> didrocks: hey, what's delaying the smart scopes?
[14:39] <didrocks> mhall119: the fact to run 40 python process I would say
[14:39] <didrocks> davidcalle: ^
[14:39] <didrocks> and maybe the REST results
[14:39] <didrocks> some part are also ran by the server
[14:39] <didrocks> which can be slow
[14:39] <nic-doffay> Here's the MP everyone: https://code.launchpad.net/~nicolas-doffay/unity/page-header-test/+merge/155242
[14:40] <mhall119> IIRC, there were only about a dozen local scopes, the rest were server-side
[14:40] <mhall119> and I'm *assuming* that the server-side is cloud-scalable
[14:40] <davidcalle> mhall119, didrocks: the fact that searches are not properly canceled yet. If you move a master scope out of the home dash (with a dconf key), you can see it running as fast as any lens.
[14:41] <didrocks> mhall119: we have 40 installed
[14:41] <davidcalle> 29 new local scopes, IIRC
[14:41] <mhall119> davidcalle: I did notice that it wasn't cancelling searches when the search term changed
[14:42] <mhall119> didrocks: and isn't the point of the new service the fact that we won't have to run them all?
[14:42] <MacSlow> Saviq, something (like ListView) that's set to interactive: false does not allow any interactive child-items anymore?
[14:43] <mhall119> "having 40 python processes" was baked into the design
[14:43] <pstolowski> didrocks: updated https://code.launchpad.net/~stolowski/libunity/insert-scope-id/+merge/155221
[14:43] <Saviq> MacSlow, no, that just means the listview itself won't be interactive
[14:44] <Saviq> MacSlow, i.e. you won't be able to drag it, essentially
[14:44] <didrocks> mhall119: right, but the recommendations by the server is not optimal
[14:44] <MacSlow> Saviq, ok tkx
[14:44] <MacSlow> thx
[14:44] <didrocks> mhall119: so right now, we are running them all to get results
[14:44] <didrocks> pstolowski: thanks!
[14:44] <Saviq> MacSlow, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-flickable.html#interactive-prop
[14:44] <mhall119> didrocks: also something that was expected, and will start to resolve itself as the server learns, right?
[14:45] <didrocks> mhall119: right
[14:46] <didrocks> mhall119: but there are still room for improvment on our side first :)
[15:29] <didrocks> sil2100: FYI, latest of the latest results available :)
[15:29] <didrocks> dednick: sil2100: did you get any progress today on it? ^
[15:30] <dednick> didrocks: working on it now. i think the basic problem is that the scopes are slower at displaying results, and there are points in the AP tests where it doesnt actually wait.
[15:30] <dednick> which is where the flakyness comes in
[15:30] <didrocks> dednick: yeah, that was part of my guess once I saw that you didn't as much fixed ones as planned
[15:30] <dednick> sometimes the results are available, sometimes not
[15:30] <didrocks> get*
[15:30] <didrocks> yeah :/
[15:31] <didrocks> dednick: we should maybe wait for the full timeout?
[15:31] <mterry> didrocks, heyo.  re: daily release of the touch stack.  Let's say I wanted to enable daily releases of qtubuntu into our touch PPA.  How would I do that?
[15:33] <didrocks> mterry: with the 100scopes project, all my planning around the touch stack is screwed. I would have hope we got some discussion and all the platform ready by now, but I'm postponing it for now
[15:33] <dednick> didrocks: there are many places where it just does something like "get_results()[0]" without verifying that there are results yet. so it's just about adding the wait functions between.
[15:33] <mterry> didrocks, k
[15:33] <didrocks> mterry: is everything that qtubuntu build-dep on already in the distro or daily-releasing?
[15:33] <didrocks> dednick: ah nice!
[15:34] <mterry> didrocks, libhybris and ubuntu-platform I think are not yet daily-release
[15:35] <mterry> didrocks, I'm not sure anything is daily-releasing yet?
[15:35] <didrocks> mterry: libhybris is the android side
[15:35] <didrocks> mterry: I asked a lot of people to decipher the story to be able to build what we need to build on x86
[15:35] <mterry> didrocks, yar, qtubuntu is armhf only right now
[15:35] <didrocks> mterry: didn't get anyone communicating though :)
[15:35] <didrocks> mterry: so yeah, if you can look at it and know what's needed to be done to build on x86
[15:36] <mterry> which is a problem, but a separate one from daily-release
[15:36] <didrocks> I think is was mzanetti_ telling me that everything can build on x86
[15:36] <didrocks> mterry: well, I'm taking that as part of "let's bootstrap"
[15:36] <mterry> didrocks, I remember asking around and everyone told me to ask someone else
[15:36] <mzanetti_> yes, it was mzanetti_
[15:36] <didrocks> :)
[15:37] <didrocks> mzanetti_: so, do you know what's the issue when an app is depending on qtubuntu?
[15:37] <didrocks> which is armhf* only
[15:37] <mzanetti_> didrocks: then it should only depend on qtubuntu for armhf
[15:37] <didrocks> mzanetti_: but the app can work without it?
[15:37] <mzanetti_> didrocks: yes
[15:37] <didrocks> on x86
[15:37] <didrocks> interesting
[15:38] <didrocks> qtubuntu is and will really stay amrhf-only?
[15:38] <mzanetti_> didrocks: here's the explanation:
[15:38] <didrocks> mterry: did you see that in the packaging?  ^
[15:38]  * didrocks listens!
[15:38] <mzanetti_> didrocks: we have Qt as a middleware
[15:38] <mzanetti_> didrocks: qtubuntu sits below qt, as a Qt plugin
[15:38] <mzanetti_> didrocks: the app sits above Qt
[15:38] <didrocks> ok, so the app always dep on Qt, not qtubuntu
[15:39] <mzanetti_> didrocks: I think our apps would also work on the phone without qtubuntu
[15:39] <didrocks> and qtubuntu is installed by seeding it on amrhf
[15:39] <mzanetti_> didrocks: just lack hardware acceleration support etc
[15:39] <mzanetti_> didrocks: yeah, exactly
[15:39] <didrocks> ah, finally, someone explaining it \o/
[15:39] <mzanetti_> didrocks: if an application has a direct dep on qtubuntu Imho its wrong
[15:40] <mzanetti_> didrocks: well... Qt would bail out on the device saying: No hardware backend found
[15:40] <mzanetti_> didrocks: but we could install some mimimalistic, no-accelerated backend instead of qtubuntu and itll work too
[15:40] <didrocks> mzanetti_: making sense
[15:41] <dandrader> any wiki or webpage explaining the setup for an armhf chroot for building packages for the device? I have one it's been a while since I last used it. I fear it might be outdated (e.g. using wrong apt sources)
[15:41] <mzanetti_> didrocks: the equivalent of qtubuntu on the desktop is libxcb (and probably some qtxcb package  - dunno the exact names)
[15:42] <didrocks> mzanetti_: ah, this is the part binding to surfaceflingers?
[15:42] <didrocks> (qtubuntu)
[15:43] <mzanetti_> didrocks: yeah! I think qtubuntu was split up in 3 packages lately, so I don't know exactly which part sits in which package... ricmm could help you there
[15:43] <mzanetti_> didrocks: but yes, in general, thats the idea
[15:44] <didrocks> mzanetti_: and what about the ubuntu-platform-api?
[15:44] <mzanetti_> didrocks: thats one of those 3 packages I meant
[15:44] <didrocks> ah :)
[15:44] <mzanetti_> didrocks: but now we are getting into the area where a rocket scientist has better information than I do
[15:44] <mzanetti_> e.g. ricmm or jhodapp
[15:44] <didrocks> ok ;)
[15:45] <didrocks> thanks a lot mzanetti_
[15:45] <mzanetti_> np
[15:46] <mterry> mzanetti_, qtubuntu-media is another of the 3 packages?
[15:46] <mzanetti_> mterry: I think so, yes.
[15:46] <mzanetti_> but as I said, the exact details of those packages are a bit out of my scope... I work mostly from Qt upwards
[15:47] <mzanetti_> so don't rely on everything below with 100% on me
[15:49] <didrocks> mzanetti_: it's already a lot in the stack :)
[16:00] <luv> mardy: yo, thanks for having a look at https://bugs.launchpad.net/signon/+bug/1156776 .. but signon-plugin-oauth2-0.15  still does not build :-/ ... another issue now
[16:01] <luv> I updated qmake .pro files in signond to build "signon-plugins" as .so as well and then I got signon-plugins-oauth2 to build
[16:01] <luv> but maybe there is a reason why it's not built as a shared object ... :-s
[16:05] <kgunn> tsdgeos: just curious...what's left on hud unit/autopilot tests?
[16:05] <tsdgeos> kgunn: i'd say i'm mostly done
[16:05] <tsdgeos> my plan was having a review today on what was missing
[16:06] <tsdgeos> but i got hooked on fixing the unity-core build in raring by Saviq
[16:06] <tsdgeos> so haven't done it
[16:06] <kgunn> tsdgeos: cool :) i was bp digging....np
[16:06] <tsdgeos> still paying our fork everything in incompabile ways punishment
[16:07] <kgunn> tsdgeos: no doubt....remerge hell
[16:07] <kgunn> always is a pain
[16:31] <tvoss> Saviq, ping
[16:31] <Saviq> tvoss, pong
[16:32] <tvoss> Saviq, are we aware of https://bugs.launchpad.net/touch-preview-images/+bug/1159011
[16:32] <tvoss> ?
[16:32] <Saviq> tvoss, no
[16:33] <Saviq> tvoss, I don't have a 7, though :/
[16:36] <tvoss> Saviq, is that bug logged against the right project?
[16:37] <kgunn> tvoss: let me chase
[16:41] <kgunn> tvoss: i have a 7, just tested against the description - i kind of think its right
[16:41] <kgunn> tvoss: meaning current behavior
[16:41] <kgunn> tvoss: if you're on the greeter (aka lock screen)
[16:42] <kgunn> tvoss: you shouldn't be able to fiddle with indicators
[16:42] <kgunn> tvoss: a question for design to settle i suppose
[16:43] <tvoss> kgunn, can you assign it to someone to take care of it?
[16:43] <kgunn> tvoss: yep...going to point it to a design folk
[16:46] <tvoss> kgunn, thanks
[16:48] <kgunn> mpt: ping
[16:49] <didrocks> mterry: thanks for backporting this commit!
[17:00] <Saviq> kgunn, http://unity.ubuntu.com/getinvolved/development/unitynext/
[17:04] <tsdgeos> Saviq: ok, did the merge, this is the monsted https://code.launchpad.net/~aacid/unity/phablet-mods-merged/+merge/155243
[17:04] <tsdgeos> after that we need this change in the shell https://code.launchpad.net/~aacid/unity/new_unitycore_api/+merge/155286
[17:04] <Saviq> tsdgeos, you rebased?
[17:05] <tsdgeos> Saviq: for some reason the CI is failing, mzanetti_ says mmrazik knows why
[17:05] <tsdgeos> Saviq: merged lp:unity into the phablet-mods thing
[17:05] <Saviq> tsdgeos, I thought you'd just get lp:unity and cherry-pick from lp:unity/phablet-mods
[17:05] <tsdgeos> Saviq: yeah but in the end i thought it'd be safer to make sure i did not leave anything out to merge
[17:06] <tsdgeos> Saviq: i can do the cherry-picking if you prefer, now that i know what files don't build anyway :D
[17:06] <Saviq> tsdgeos, yeah that's right, I just wanted to save you the merge
[17:06] <Saviq> or the conflict resolution, more
[17:06] <tsdgeos> merge was "easy-ish"
[17:07] <tsdgeos> problem was going into device+quantal and skipping stuff that don't build
[17:07] <tsdgeos> in the more "fine grained" possible way
[17:07] <tsdgeos> so we still run as much tests as we can
[17:07] <tsdgeos> at this stage i've dpkg-buildpackage'd in device+quantal and VM+raring and built unity/phablet on top of it
[17:08] <tsdgeos> "should" work (TM)
[17:16] <Saviq> tsdgeos, great
[17:18] <Saviq> will get on it first thing tomorrow
[17:22] <tsdgeos> Saviq: i'm eoding too, let's see if mmrazik can have a look at the CI job in the meanwhile
[17:22]  * tsdgeos waves
[17:41] <mardy> luv: hi! can you find a libsignon-plugins.* somewhere in your system?
[17:43] <luv> will do when i get back home - am i looking for a package or a file?
[17:43] <mardy> luv: a file; IIRC the package has a similar name, though
[17:52] <mhr3> larsu_, ping?
[17:55] <larsu_> mhr3: on my way to lunch. Talk later?
[17:55] <mhr3> larsu_, just a quickie
[17:55] <mhr3> larsu_, do you know who would know about gvfs-httpd?
[17:56] <larsu_> mhr3: nope :)
[17:56] <mhr3> see... quickie :)
[17:56] <larsu_> haha nice
[18:12] <kgunn> Saviq: looks good...good to get that one out there
[19:32] <luv> mardy: http://pastebin.blesmrt.net/3103/
[19:34] <luv> mardy: only relavant libs i have installed in the system are libsignon-plugins-common.so.* (don't mind libsignon-plugins.* in my home - it's a custom build after modifying .pro file, upstream doesnt build shared objects there by default)
[19:45] <kgunn> greyback: ping
[19:45] <greyback> kgunn: pong
[21:28] <matzipan> hey guys, I applied for them ailing list a  while ago
[21:28] <matzipan> didn't have any success