[00:02] <bschaefer> digital, im not actually that sure, as you are no longer using unity :)
[07:34] <davidcalle> didrocks, ping
[07:35] <didrocks> davidcalle: pong
[07:35] <davidcalle> didrocks, ça va bien ?
[07:35] <didrocks> davidcalle: ça va, et toi, les vacances bientôt? :)
[07:35] <davidcalle> didrocks, ça va :) Oui, dans quelques semaines... Et toi ?
[07:36] <didrocks> fin août, donc il y a le temps!
[07:37] <davidcalle> didrocks, hehe, en effet ;) Au fait, j'ai oublié ça hier https://code.launchpad.net/~davidc3/cupstream2distro-config/online-raring-to-saucy/+merge/172476
[07:38] <didrocks> davidcalle: il n'y a pas d'importance en fait de ça, puisque cette stack n'est pas sous daily releases
[07:38] <didrocks> (tout ce qui est dans online)
[07:38] <didrocks> davidcalle: tu peux même le supprimer en fait :)
[07:39] <davidcalle> didrocks, hum... J'ai l'impression que Jenkins ne peut pas trouver les build deps, ça ne dépend pas de ça, donc...
[07:39] <didrocks> intéressant
[07:40] <didrocks> dac
[07:40] <didrocks> done!
[07:41] <davidcalle> didrocks, par hasard, est-ce que Jenkins utilise la distro du dernier changelog ?
[07:41] <didrocks> davidcalle: possible, aucune idée pour la partie non daily release, ça a pas mal changé depuis mon premier prototype :)
[07:42] <didrocks> mais à l'époque, ça utilisait la distro du changelog
[07:42] <davidcalle> didrocks, ok, je vais regarder de ce côté là aussi. Merci ! ;)
[07:44] <didrocks> de rien!
[07:55] <didrocks> pstolowski: thostr_: hey!
[07:56] <pstolowski> didrocks: hi!
[07:56] <didrocks> FYI https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1189088/comments/20
[07:56] <didrocks> so I think we need to revert the behavior for the application lens
[07:56] <didrocks> as well as adapating surely some integration tests, right?
[07:58] <thostr_> didrocks: yes. and most probably extending the scope interface with a kind of activationBehaviour flag
[07:59] <didrocks> thostr_: right, would make sense
[07:59] <didrocks> do you know how long we can expect this to take before landing?
[07:59] <didrocks> would be good to have the definitive action soon enough
[07:59] <pstolowski> didrocks: that's good news... the bad thing is it has been implemented in the dash globally
[08:00] <didrocks> argh
[08:01] <pstolowski> didrocks: so we need to make an 'exception' for apps in the dash... or implement something along the thostr_'s idea
[08:01] <didrocks> just give me a rough approximation for landing those :)
[08:07] <thostr_> the fix shouldn't take that much time (hours)
[08:07] <thostr_> the challenge is predicting the integration and fixing the tests
[08:13] <didrocks> thostr_: right, we need a plan for that. Can you preparing one and get back to me once you get the estimate?
[08:13] <Saviq> pstolowski, thostr_ couldn't this work roughly how action activation works in previews? i.e. on activation you either come back with a preview (or a hint that a preview should be requested?), notice of scope-side activation or no-op (as it is now, right?)
[08:14] <pstolowski> didrocks: I'll implement the change across the stack today (libunity, unitycore, dash). not sure about AP test atm, I've a feeling it's simple change
[08:14] <didrocks> pstolowski: ok, let's cross fingers! Thanks :)
[08:15] <pstolowski> Saviq: it could... but then you need to change every single scope. so we can think of it as a 'hint' about how to handle activation click
[08:15] <seb128> pstolowski, you guys managed to make alt-f2 skip previews, isn't the "framework" already there?
[08:16] <seb128> or how is that different?
[08:16] <Saviq> pstolowski, right...
[08:17] <pstolowski> seb128: for alt+f2 we added a special pseudo-schema "x-unity-no-preview:". no use for this case.
[08:18] <seb128> ok, I was mentioning it in case... ;-)
[08:18] <seb128> you probably know what you are doing, /me goes back to stuff he's doing :p
[08:18] <pstolowski> seb128: that was a good question, it got me puzzled for a second and I had actually to lookup the sources ;)
[08:18] <seb128> ;-)
[08:18] <didrocks> seb128: see, they don't know what they are doing OMG /o\ ^
[08:19] <seb128> haha
[08:29] <pstolowski> Saviq, tsdgeos: are you ok with https://code.launchpad.net/~stolowski/unity8/activation-and-previews/+merge/172102 for the time being (I've just merged trunk as there was a text conflict)?
[08:30] <Saviq> pstolowski, I didn't look at the code much, tsdgeos your call - I'm ok with leaving LocalResult for now
[08:30] <Saviq> pstolowski, btw, can you add a TODO/FIXME around there?
[08:31] <tsdgeos> pstolowski: i'll have another look onow
[08:31] <pstolowski> Saviq: sure. I plan to do the change today/tomorrow
[08:31] <Saviq> pstolowski, the index approach looks sane, either with a "master" index role passed down from DeeListModel
[08:32] <Saviq> pstolowski, or maybe even saner with mapToSource()
[08:32] <pstolowski> Saviq: do you think we are safe wrt to potential races? should be ok as long as we're single-threaded?
[08:33] <Saviq> pstolowski, think so, but just to be safe maybe the index role approach makes more sense
[08:33] <Saviq> we did that somewhere already, yoo
[08:33] <Saviq> too
[08:34] <Saviq> pstolowski, I think in the Categories object
[08:34] <pstolowski> Saviq: ok
[08:34] <Saviq> pstolowski, yeah, case RoleId: return QVariant::fromValue(index.row());
[08:35] <pstolowski> Saviq: ok, nice, I didn't see that
[08:52] <tsdgeos> is testDragHandle failing for you too?
[08:52] <tsdgeos> Saviq: greyback: mzanetti: ↑↑↑
[08:53]  * mzanetti tries
[08:53] <tsdgeos>    Actual   (actualFunc()): 100
[08:53] <tsdgeos>    Expected (expectedValue): 0
[08:53] <tsdgeos>    Loc: [/home/tsdgeos_work/phablet/lolo/tests/qmltests/Components/tst_DragHandle.cpp(139)]
[08:54] <mzanetti> tsdgeos: yep. failing here too
[08:54]  * mzanetti wonders how that passed CI
[08:54] <tsdgeos> yeah :D
[08:54] <tsdgeos> we were unlucky in that it passed CI
[08:54] <tsdgeos> and now it's blocking the rest of the stuff :D
[08:54] <dednick> hm. that passed when i tested before approve
[08:55] <Saviq> didn't dandrader file an MP to fix?
[08:55] <Saviq> https://code.launchpad.net/~dandrader/unity8/fixDraHandleHint/+merge/172426
[08:55] <Saviq> it was probably my fault
[08:55] <Saviq> 'cause I merged lp:unity8 and lp:unity/8.0
[08:56] <Saviq> happroved
[08:56] <tsdgeos> ahhh
[08:56] <tsdgeos> makes sense
[08:56] <Saviq> tsdgeos, dednick, mzanetti ↑
[08:56] <mzanetti> ah ok
[08:56] <dednick> Saviq: ah ok. yeah, i remember that line there
[08:56] <Saviq> bzr f***ed up
[08:57] <mzanetti> Saviq: tsdgeos: still, the commit that introduces the failure was approved by PS Jenkins Bot
[08:57] <Saviq> mzanetti, nope
[08:57] <mzanetti> and also dednick and tsdgeos...
[08:57] <Saviq> mzanetti, there were two commits in parallel to lp:unity8
[08:57] <Saviq> mzanetti, and lp:unity/8.0
[08:57] <Saviq> mzanetti, to sync them, I merged one into the other
[08:57] <mzanetti> hmm... so much for the history in bzr
[08:57] <Saviq> mzanetti, and pushed
[08:57] <Saviq> mzanetti, it's fine
[08:58] <Saviq> mzanetti, only I didn't test
[08:58] <Saviq> /mea culpa
[08:58] <Saviq> but bzr didn't complain... :/
[08:58] <tsdgeos> question
[08:58] <tsdgeos> why https://code.launchpad.net/~stolowski/unity8/activation-and-previews/+merge/172102 CI passed ?
[08:58] <dednick> Saviq: would you be apposed to me creating cmake procedure for qmltypes files for the plugins? so we can get type info in qtcreator?
[08:59] <Saviq> dednick, no, I wouldn't be apposed :)
[08:59] <Saviq> dednick, assuming it doesn't take your whole day
[08:59] <dednick> Saviq: nope. should be quick
[08:59] <Saviq> dednick, yup
[08:59] <mzanetti> dednick: yay. nice
[09:00] <mzanetti> tsdgeos: oooops
[09:00] <mzanetti> tsdgeos: you found a bad bug
[09:01] <tsdgeos> where? when? how?
[09:01] <mzanetti> tsdgeos: the jenkins job still merges to lp:unity/8.0 before testing
[09:01] <tsdgeos> wops :_D
[09:02] <mzanetti> fixed. tests may start failing now :D
[09:04] <tsdgeos> yay!
[09:04] <tsdgeos> not!
[09:06] <mzanetti> huh?
[09:08] <mzanetti> Saviq: any news on the unity-api releasing?
[09:08] <Saviq> didrocks, ↑?
[09:08] <didrocks> mhr3: hey, around?
[09:09] <Saviq> mzanetti, that's no bug, lp:unity8 == lp:unity/8.0
[09:09] <Saviq> mzanetti, well, bug, maybe - but nothing tragic yet
[09:09] <didrocks> mzanetti: what about it? it's released and in the next ppa
[09:09] <mzanetti> Saviq: well, tests fail with unity8 but pass with unity/8.0
[09:09] <didrocks> as the whole unity8 stack
[09:10] <mzanetti> didrocks: ah ok... I thought we shouldn't use any ppas any more
[09:10] <didrocks> mzanetti: well, apparently, we can't push unity8 to distro right now
[09:10] <didrocks> to we have to use a ppa for releasing
[09:10] <Saviq> mzanetti, unity8 will remain in a PPA until mir integration is complete
[09:10] <mzanetti> didrocks: ok. thanks
[09:12] <mhr3> didrocks, in hangout
[09:12] <didrocks> mhr3: there is just the start of a hang
[09:12] <didrocks> mhr3: on the ati machine
[09:12] <didrocks> mhr3: so run if you want to look at it :)
[09:15] <Saviq> didrocks, are we merging all the qtubuntu and unity8 packaging changes today
[09:15] <Saviq> ?
[09:16] <didrocks> Saviq: waiting for Mirv to deal with the unity stack to get libunity in distro and then, yeah :)
[09:16] <Saviq> didrocks, cool
[09:16] <didrocks> mhr3: letting the -check running for you
[09:24] <nic-doffay> mzanetti, you have a moment?
[09:26] <mzanetti> nic-doffay: meeting starting in 4 minutes
[09:26] <mzanetti> nic-doffay: what up?
[09:26] <ethana3> Does anyone here have an always-displayed global menu bar working? I've installed various PPAs and they never seem to work.. I used to have this with ASD's global menu hack and gnome panel widget...
[09:26] <ethana3> oh, interesting.
[09:27] <nic-doffay> mzanetti, unknown issue I'm facing.
[09:27] <nic-doffay> QML related.
[09:28] <mzanetti> nic-doffay: that's not exactly the most precise description of a problem...
[09:28] <mzanetti> nic-doffay: have some code and a error message?
[09:29] <nic-doffay> mzanetti, it's in the gallery of the SDK.
[09:29] <nic-doffay> ./gallery.sh
[09:30] <nic-doffay> The templates are displayed using a delegate.
[09:30] <nic-doffay> Everything on the component is repeated, even though it follows the same trend as all other gallery components. So I must be missing something.
[09:31] <nic-doffay> It's fine in a normal qmlscene.
[09:32] <mzanetti> nic-doffay: not following
[09:32] <mzanetti> nic-doffay: I've opened the gallery
[09:32] <mzanetti> now what?
[09:32] <nic-doffay> mzanetti, you'll need my branch.
[09:32] <nic-doffay> mzanetti, lp:~nicolas-doffay/+junk/option-selector
[09:33] <nic-doffay> mzanetti, to see the issue go to list items, then scroll down to option selector.
[09:33] <nic-doffay> That's handled is ListItems.qml
[09:34] <nic-doffay> *in
[09:34] <mhr3> didrocks, eh, lost me scrollback, which one was it?
[09:34] <mhr3> my*
[09:34] <didrocks> mhr3: ati machine
[09:34] <mhr3> thx
[09:34] <didrocks> yw :)
[09:36] <mhr3> didrocks, can't attach to it again, so no good :/
[09:36] <mhr3> jibel, ^ ati dead
[09:37] <jibel> mhr3, ack, oom
[09:37] <jibel> can I have that machine for 15min, I'll collect information to report a bug
[09:37] <mhr3> jibel, sure
[09:38] <mhr3> ehm, i mean, not my call :)
[09:38] <mhr3> but surely 15minutes won't kill anyone
[09:38] <didrocks> even more if needed :)
[09:38] <didrocks> nothing else to run
[09:39] <m4n1sh> mhr3: when you are free can you have a look at #1196878 #1196800 and  #1196822
[09:39] <m4n1sh> you know both the components well :)
[09:42] <jibel> [76766.931095] lxc-list[26171]: segfault at 0 ip b762c1a6 sp bfd80674 error 4 in libc-2.17.so[b75a7000+1ad000]
[09:42] <jibel> not good
[09:43] <mhr3> m4n1sh, what's the benefit of moving those to libzg2?
[09:44] <mhr3> jibel, so, did i make it crash with the list call?
[09:44] <mzanetti> nic-doffay: so. meeting has ended. checking out your branch now
[09:45] <jibel> mhr3, no compiz and recordmydesktop crashed before that
[09:45] <jibel> I'm disabling the node in jenkins, so it doesn't reboot under my feet
[09:50] <tsdgeos> pstolowski: ping
[09:50] <pstolowski> tsdgeos: pong
[09:51] <tsdgeos> pstolowski: the data of a unityPreview never changes?
[09:52] <pstolowski> tsdgeos: yes
[09:52] <tsdgeos> damn yes to a negative question :D
[09:52] <pstolowski> :)
[09:52] <tsdgeos> yes as in "yes, it does change" or "yes, it does not change"?
[09:52] <pstolowski> tsdgeos: it doesn't change
[09:52] <tsdgeos> oki
[09:53] <tsdgeos> pstolowski: i was thinking that you could reuse a single signal then
[09:53] <tsdgeos> instead of one per property
[09:53] <tsdgeos> since you're only going to emit it at setPreview(unityPreview) anyway
[09:53] <tsdgeos> no?
[09:55] <m4n1sh> mhr3: moving everything to libzg2
[09:56] <m4n1sh> to avoid long term maintenance of libzg1
[09:56] <m4n1sh> some fine day they will have to be moved
[09:58] <mzanetti> Saviq: can't install libunity-api from the next ppa. requires libboost 1.49 while we require libboost-1.53
[09:58] <pstolowski> tsdgeos: in therory yes, but doesn't NOTIFY protocol mandate that notification of every property follows <property>Changed naming?
[09:59] <tsdgeos> not that i know
[09:59] <tsdgeos> but i may be wrong
[09:59] <tsdgeos> afaik the qml side of things is all defined by the property name
[09:59] <Saviq> mzanetti, we shouldn't require boost at all, do we still?
[09:59] <tsdgeos> and the rest is just the c++ names of the "bindings"
[10:00] <mzanetti> Saviq: apparently... installing libunty-api-dev and then doing ./build -c removes libunity-api-dev again. because of conflicting boost
[10:00] <mzanetti> Saviq: oh... comes with libunity-core and libnux I guess
[10:00] <Saviq> mzanetti, yeah, probably
[10:01] <Saviq> mzanetti, still, needs fixing in unity-api
[10:01] <Saviq> mzanetti, MP incoming
[10:04]  * Saviq hooked sbuild up to `bzr bd`, feels smug ;)
[10:05] <tsdgeos> pstolowski: i mean http://paste.kde.org/~tsdgeos/787022/ in case i wasn't clear
[10:05] <tsdgeos> Saviq: mzanetti: ↑↑↑ this should work, right?
[10:05] <Saviq> tsdgeos, yeah, should
[10:06] <pstolowski> tsdgeos: yes, that's what I understood
[10:06] <tsdgeos> what you guys think about that?
[10:06] <tsdgeos> am i being silly?
[10:07] <Saviq> tsdgeos, pstolowski question is - do they actually ever change?
[10:07] <Saviq> should they just be constant instead
[10:07] <Saviq> because you create a new Preview every time anyway?
[10:08] <tsdgeos> they never change
[10:09] <tsdgeos> or so said pstolowski a few lines above
[10:09] <tsdgeos> well, they change from empty to something
[10:09] <tsdgeos> and then they never change
[10:09] <pstolowski> Saviq: in theory you could create a preview object with default ctor, and then do setUnityPreview
[10:09] <pstolowski> in which case they would change
[10:09] <tsdgeos> well, it's what you do, no?
[10:09] <Saviq> pstolowski, right
[10:09] <pstolowski> yes, but only in factory method
[10:09] <pstolowski> so it's not exposed to qml before that
[10:10] <tsdgeos> right
[10:10] <Saviq> pstolowski, tsdgeos so it's never possible that only one of those change
[10:10] <Saviq> pstolowski, tsdgeos in which case I'm fine with tsdgeos's thing
[10:10] <pstolowski> Saviq: exactly
[10:13] <Saviq> pstolowski, tsdgeos only thing to make sure is to only emit the signal once
[10:13] <Saviq> pstolowski, so in setUnityPreview
[10:13] <Saviq> after having updated all the members
[10:14] <Saviq> mzanetti, https://code.launchpad.net/~saviq/unity-api/any-boost/+merge/172525
[10:15] <mzanetti> Saviq: cheers
[10:15] <pstolowski> Saviq, tsdgeos: ok
[10:15] <mzanetti> dednick: you have a lot of "\No newline at end of file" in your MP
[10:16] <tsdgeos> pstolowski: will give us a somewhat smaller binary ;-)
[10:16] <dednick> mzanetti: grr. ok, fixing now
[10:17] <pstolowski> lol
[10:17]  * Saviq sees latestsnapshots
[10:17] <didrocks> Saviq: yep, let's wait for it to migrate to the release pocket to do the merges?
[10:18] <Saviq> didrocks, yup
[10:18] <didrocks> Saviq: on the qtubuntu transition, they wanted to wait for the flipped image to be switched on though
[10:18] <didrocks> Saviq: and I think it's not there yet?
[10:18] <Saviq> didrocks, yeah, might be
[10:19] <didrocks> Saviq: so we'll have to postpone the packaging merge until it's in, I'll ask rsalveti and sergiusens once they are around
[10:20] <Saviq> didrocks, yup
[10:34] <mhr3> Saviq, unity on the phone is constantly using 25% cpu with yesterday's image, known?
[10:36] <om26er> I get as high as 46% continuous hog on Nexus 4 for unity8
[10:36] <Saviq> mhr3, om26er is that with the flipped image?
[10:37] <om26er> Saviq, yeah, I have flipped image installed
[10:37] <mhr3> Saviq, i don't
[10:37] <Saviq> hmm I'm not seeing that...
[10:37] <Saviq> on 20130701.2
[10:37] <mhr3> there's also 10% in surfaceflinger, so clearly something's repainting
[10:38] <mhr3> dunno how to give you more info
[10:38] <Saviq> mhr3, we'll try and reproduce
[10:39] <mhr3> this is even with screen off btw
[10:40] <om26er> on another note the NetworkManager was consuming 99% yesterday, had to kill the service. But that's clearly for someone else to figure.
[10:42] <tsdgeos> woa, i'm getting 40% of unity8 in my desktop
[10:42] <tsdgeos> that's bad :D
[10:46] <mhr3> uh oh, i just dist-upgraded and unity just crashes
[10:48] <didrocks> mhr3: apt-cache policy unity?
[10:49] <mhr3>   Installed: 7.81.2
[10:50] <didrocks> ah, unity8
[10:50] <didrocks> as we just published a version to saucy, you frightned me :)
[10:51] <mhr3> didrocks, you're frightening me, you don't care about working system on the phone?! :P
[10:52] <didrocks> mhr3: not that, but as long as we don't run integration tests and if that passed tests, it would mean we have big issues in our infra :)
[10:56] <Saviq> tsdgeos, I can't reproduce, can you try and find out which commit introduced that?
[10:57] <tsdgeos> amy not be our fault
[10:57] <tsdgeos> i did a qml-debug thing on the phone
[10:57] <Saviq> tsdgeos, right
[10:57] <tsdgeos> and it has no repaint
[10:57] <tsdgeos> so may be some other thing
[10:57] <tsdgeos> i was going to run callgrind on it now
[10:57] <Saviq> ok, I'm not seeing it anyway
[10:57] <mlankhorst> modprobe nouveau
[10:58] <mlankhorst> oh figures
[11:01] <Cimi> mzanetti, seems to work but all tests are screwed :D will have to dig but thanks
[11:01] <mzanetti> Cimi: ok, cool
[11:04] <pstolowski> tsdgeos: updated my MP
[11:07] <tsdgeos> oki
[11:07] <tsdgeos> Saviq: gone back to r37 and i still get around 40% cpu usage when i'm at the videos scope
[11:08] <Saviq> tsdgeos, flipped or not?
[11:09] <Saviq> tsdgeos, and is that on your desktop still?
[11:11] <tsdgeos> Saviq: desktop yes
[11:11] <Saviq> tsdgeos, interesting
[11:11] <tsdgeos> callgrind didn't gave me much
[11:11] <tsdgeos> gdb seems to imply there's something drawing all the time
[11:11] <tsdgeos> since everything i ctrl+c there's a renderer thread going on
[11:11] <tsdgeos> but i may be wrong and the thread is just waiting
[11:12] <tsdgeos> anyways, if you guys don't get it let's forget it for the moemnt ;D
[11:13] <Saviq> tsdgeos, well, mhr3 and om26er seem to get it on devices
[11:13] <Saviq> tsdgeos, do you?
[11:14] <tsdgeos> let me see
[11:22] <tsdgeos> Saviq: no, can't repro on the phone
[11:23] <Saviq> tsdgeos, k, I'll have a shout in -touch, too
[11:55] <jibel> didrocks, mhr3 ati is back, but I couldn't collect data I needed. I killed the machine by removing the wrong modules. It's all yours, ping me when it crashes again
[12:38] <davidcalle> didrocks, ping again. Who should I talk to for the Jenkins issue ? I now have both a saucy changelog and cupstream2distro switched to saucy, but the CI pass is still trying to build with raring (and obviously fails).
[12:48] <didrocks> davidcalle: fginther should be your contact
[12:48] <didrocks> jibel: ok, thankx
[12:48] <davidcalle> didrocks, thanks
[13:06] <tsdgeos> pstolowski: why setUnityPreviewBase + setUnityPreview instead a virtual setUnityPreview where children call the parent implementation too?
[13:13] <pstolowski> tsdgeos: because I didn't like to require subclass to call base class method in the overriden method to work correctly, I preferred to ensure this from the outside (the factory method)
[13:15] <tsdgeos> ok
[13:17] <tsdgeos> paulliu: shall i top-approve https://code.launchpad.net/~stolowski/unity8/activation-and-previews/+merge/172102 or you want to have a look too?
[13:18] <paulliu> tsdgeos: I've looked already. No special comments.
[13:18] <tsdgeos> ok
[13:20] <pstolowski> thanks for reviewing!
[13:25] <tsdgeos> mterry: and is that "regression" accepted?
[13:26] <mterry> tsdgeos, it's only a regression if we consider the touch image to be just a demo.  Otherwise it's getting closer to actually working
[13:27] <tsdgeos> sure
[13:27] <tsdgeos> but still it'll look worse :D
[13:27] <mterry> tsdgeos, it'll look the same as when a user gets the device for the first time
[13:27] <tsdgeos> ok
[13:27] <mterry> tsdgeos, which is what's happening when you install
[13:43] <dednick> dandrader: you need a review for panel drag handle branch?
[13:43] <dandrader> dednick, oh yeah
[13:44] <dandrader> dednick, a big diff, unfortunately
[13:44] <dednick> dandrader: indeed. i'll get on it
[13:45] <dandrader> dednick, thanks a lot!
[13:46] <dandrader> dednick, biggest changes are in the tests though
[14:01] <dandrader> greyback, I'm getting this error when running unity8+mir on the flipped saucy http://paste.ubuntu.com/5836289/
[14:01] <dandrader> greyback, how far did you get?
[14:02] <dandrader> greyback, btw, I've updated that wiki page
[14:02] <greyback> dandrader: not even that far :) I get crash
[14:02] <greyback> dandrader: there's no working Ubuntu.Application plugin yet. So you need to use hte fake one
[14:03] <Saviq> mzanetti, can I ask you to please look at https://code.launchpad.net/~nick-dedekind/unity/8.indicators-client/+merge/168022 from autopilot PoV?
[14:03] <dandrader> greyback, ah... it's weird the library is actually installed, so it should at least find and load it
[14:03] <dandrader> greyback, have you gone the ppa:phablet-team/mir way?
[14:04] <greyback> dandrader: no, I'm using the mir staging ppa. To my detriment I believe
[14:04] <greyback> but I need to work on cutting edge
[14:04] <Saviq> dednick, are the autopilot tests actually run in the indicators-client branch?
[14:04] <Saviq> dednick, they're not part of the unity8 autopilot module, are they?
[14:04] <Saviq> mzanetti, should they be ↑?
[14:05] <Saviq> dednick, is there a custom target to run them maybe?
[14:05] <Saviq> dednick, I'm unable to get them to work, I'm afraid
[14:07] <dednick> Saviq: hm. apparently they're not.
[14:08] <dednick> Saviq: should i make them part of the unity8-autopilot package?
[14:08] <dednick> Saviq: or make a indicators-client-autopilot one?
[14:09] <tsdgeos> Saviq: is there an easy way to only load the dashhome?
[14:11] <Saviq> tsdgeos, it's a dconf setting
[14:11] <dandrader> greyback, ok it's working now!
[14:11] <Saviq> dednick, I think part of unity8
[14:11] <greyback> dandrader: excellent!
[14:11] <Saviq> dednick, as that's the only autopilot package we're running in CI
[14:12] <Saviq> mzanetti, any comment on ↑?
[14:12] <dandrader> greyback, but doesn't mean much as it's using fake plugins, just like when you "./run" on the desktop
[14:12] <greyback> dandrader: yes I know. I'm working on a real application manager plugin so we get real behaviour back
[14:13] <Saviq> fginther, hey, is it correct that http://10.97.2.10:8080/job/unity-phablet-qmluitests-saucy/ is bound to ps-saucy-server-amd64-1 ?
[14:13] <Saviq> fginther, we're kinda blocked by mir on that one :/
[14:14] <fginther> Saviq, I think I can help there, just give me a few minute
[14:14] <fginther> s
[14:14] <Saviq> fginther, thanks
[14:26] <Saviq> fginther, btw, would it be possible to have unity-8.0-autolanding and unity8-autolanding to block each other? i.e. so they don't run in parallel?
[14:29] <dandrader> Saviq, cant' we forget about  lp:unity/8.0 ?
[14:29] <Saviq> dandrader, we will, soon
[14:29] <fginther> Saviq, maybe. I don't know of a simply way to do this off the top of my head, but it may be possible. Can we discuss a little later (an hour or so)?
[14:30] <Saviq> fginther, probably not worth it :)
[14:30] <fginther> Saviq, ok
[14:30] <Saviq> dandrader, OTOH, we could just resubmit against lp:unity8 and be done with it...
[14:31] <Saviq> dandrader, I think I was just hoping we'll reduce the queue against lp:unity/8.0 quicker
[14:31] <dandrader> Saviq, exactly
[14:31] <dednick> Saviq: i've added indicator-client to the autopilot target. should now run with make autopilot.
[14:31] <dednick> and added to install.
[14:31] <Saviq> dednick, cheers
[14:33] <Saviq> dandrader, ok, doing
[14:33] <Saviq> dandrader, there's only 4 branches now
[14:34] <Saviq> dandrader, right, but... "lp:~unity-team/unity/unity8-packaging-cleanup is not mergeable into lp:unity8"
[14:34]  * Saviq needs to pull/push
[14:36] <mzanetti> Saviq: sorry... have been eating
[14:36] <Saviq> mzanetti, don't be
[14:39] <Saviq> dandrader, ok, did it, if anything happens, I'll blame you :P
[14:40] <Saviq> didrocks, resubmitted against lp:unity8 https://code.launchpad.net/~unity-team/unity8/packaging-cleanup/+merge/172578
[14:40] <Saviq> dednick, resubmitted against lp:unity8 https://code.launchpad.net/~unity-team/unity8/indicators-client/+merge/172582
[14:40] <didrocks> Saviq: ah great! let's wait from the phone fundation team for the greenlight :)
[14:41] <dednick> Saviq: ta
[14:41] <Saviq> didrocks, yup, with that we'll be able to drop lp:unity/8.0 altogether
[14:41] <didrocks> Saviq: debian/unity8.install merge conflict btw :)
[14:41] <Saviq> didrocks, will merge
[14:41] <didrocks> thx!
[14:42] <dandrader> Saviq, hahaha
[14:46] <tsdgeos> lol, someone using the LVWPH exposed a bug in QLimitProxyModelQML :D
[14:46] <tsdgeos> took me a while to trace
[14:49] <Saviq> tsdgeos, ;)
[14:50] <Saviq> tsdgeos, test, fix, ship it :)
[14:50] <tsdgeos> on it
[14:57] <mzanetti> Saviq: dednick: commented regarding autopilot tests
[14:57] <Saviq> mzanetti, yup, thanks
[14:59] <Saviq> mterry, uh, the meeting got pushed back to tomorrow, can you please ping sforshee to have a chat about the blanking?
[15:03] <dednick> mzanetti: ta. i'd prefer to tackle the further dev of autopilot in a future revision. This one is taking a bit long, and I'd like to get it in so we can link up with the new backends sooner rather than later.
[15:03] <mzanetti> dednick: sure... It wasn't meant to add it here
[15:04] <mzanetti> dednick: but as you guys asked me on the general opinion for the autopilot suite, I wrote it there as a comment
[15:04] <dednick> mzanetti: i'll fix up the targets. I'm sure i tried and the unity8 ap tests were run as well as the indicators_client.
[15:04] <mzanetti> dednick: oh... I didn't do that
[15:04] <mzanetti> dednick: I killed the unity8 one after a while
[15:04] <dednick> mzanetti: sure. the info is appriciated :)
[15:04] <dednick> mzanetti: yeah, it's a bit painfully long
[15:04] <mzanetti> dednick: so no clue if the indicators one would have come after it
[15:05] <mterry> Saviq, sure...  I'm a bit confused why you prefer powerd's interface to Qt's, but I can talk to sforshee, sure
[15:05] <dednick> mzanetti: but yah, think we could benifit from splitting anyway
[15:05] <Saviq> mterry, no no, that's not it
[15:05] <Saviq> mterry, I just want to make sure we're doing the right thing at the right moment
[15:06] <mterry> Saviq, are you saying that in future, we will suspend before we blank the screen?
[15:06] <Saviq> mterry, i.e. backlight == 0 shouldn't necessarily mean that we should lock
[15:06] <Saviq> mterry, and I'm not even saying what you're doing is incorrect
[15:06] <Saviq> mterry, just that I don't have enough info to say that's the case
[15:07] <Saviq> mterry, i.e. backlight == 0 != blanking
[15:07] <mterry> Saviq, ah...  I thought it was by design that when the backlight is turned back on, the greeter shows
[15:07] <Saviq> mterry, it is
[15:07] <tsdgeos> Saviq: quick one https://code.launchpad.net/~aacid/unity8/qlimitproxyfiltersetsamemodeltwice/+merge/172587
[15:07] <mterry> Saviq, wait...  I get backlight == 0 != locking
[15:07] <mterry> Saviq, but I don't get backlight == 0 != blanking
[15:08] <Saviq> mterry, blanking (screen off) isn't necessarily the same as backlight == 0
[15:08] <Saviq> mterry, as you can reach backlight == 0 with brightness control
[15:08] <Saviq> mterry, but that shouldn't result in locking
[15:08] <mterry> Saviq, hrm, fair
[15:09] <mterry> Saviq, OK, then without GNOME tech, I don't think we have the right signals yet...  I can put this off until the meeting tomorrow
[15:09] <Saviq> mterry, and IIUC the Qt API exposes the actual brightness/backlight control
[15:09] <Saviq> mterry, but I'd assume there should be something re: locking / screensaver, too?
[15:10] <mterry> Saviq, yes.  It still had a bug that it never emitted backlightStateChanged, so that was still good to fix, but we don't need to use it for this greeter thing
[15:10] <Saviq> mterry, yup
[15:10] <mterry> Saviq, as for locking/screensaver, I haven't seen it in Qt's API yet, but I'm not an expert
[15:11] <Saviq> mterry, so it's not there in the module you were looking at?
[15:11] <mterry> Saviq, there is QSystemScreenSaver, but it only exposes whether the screensaver is inhibited
[15:11] <Saviq> mterry, is this what you were looking at http://harmattan-dev.nokia.com/docs/cn/qtmobility/qsystemdisplayinfo.html#BacklightState-enum ?
[15:12] <mterry> Saviq, sure, I was going off http://doc.qt.digia.com/qtmobility/qtsysteminfo.html but same API yeah
[15:13] <mterry> though that API is old, since the new API has a backlightStateChanged signal, but this page doesn't show that
[15:14] <Saviq> mterry, so, we definitely should expose those... but whether we should rely on it to lock the screen, /me doesn't know...
[15:14] <Saviq> mterry, we'll know by other means anyway (shell+mir will know that screen is being blanked)
[15:14] <Saviq> mterry, so yeah, let's pick that up tomorrow
[15:15] <mterry> Saviq, yeah, but it's a matter of exposing an API for it.  I hadn't thought we'd want to bother, but if we do want to treat them separately, yeah, we'll have to
[15:21] <mzanetti> Saviq: jenkins still uses the unity-build-next ppa. I guess its ok to switch it over to the "next" ppa
[15:22] <Saviq> mzanetti, I'm not sure we should use it at all, didrocks ↑?
[15:22] <mzanetti> I need the "next" one for libunity-api-dev
[15:22] <didrocks> yeah, you should use the next ppa for unity8 right now
[15:22] <didrocks> (unity8 stacks)
[15:22] <mzanetti> ack, thanks didrocks
[15:22] <didrocks> until it's getting into distro
[15:22] <didrocks> yw!
[15:22] <didrocks> "next" is always safe anyway
[15:33] <didrocks> mterry: hum, is it possible to only restore one folder with deja-dup/duplicity?
[15:39] <mterry> didrocks, yup, right click in nautilus
[15:39] <didrocks> mterry: no… don't tell me we have that level of integration? :-)
[15:40] <mterry> didrocks, unfortunately no one expects it/looks for it
[15:41] <didrocks> mterry: testing, it looks awesome! :-)
[15:41] <mterry> didrocks, you can even click in the empty bit of a nautilus folder and ask to see all missing files and restore them
[15:41] <didrocks> mterry: waow, I'm sold! :)
[15:41] <Saviq> mterry, we need integration with BackupPC ;D
[15:43] <mterry> :)
[16:13] <jbicha> hi, I have two small MPs that have been pending for a few weeks:
[16:13] <jbicha> https://code.launchpad.net/~jbicha/unity-lens-video/build-with-valac/+merge/168199
[16:13] <jbicha> https://code.launchpad.net/~jbicha/unity-scope-home/build-with-valac/+merge/168273
[16:25] <Saviq> mterry, FYI resubmitted as https://code.launchpad.net/~unity-team/unity8/libusermetrics/+merge/172618
[16:25] <mterry> Saviq, oh right, I forgot that was before the switchover
[16:25] <Saviq> mterry, that's ok, we just decided it's time to just move everything over
[16:27] <pstolowski> bschaefer: ping
[16:27] <bschaefer> pstolowski, pong
[16:27] <pstolowski> bschaefer: hey! fyi, I'm working on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1189088 if that's ok?
[16:28] <bschaefer> pstolowski, yup! I just was getting the bug ready to work on :)
[16:28] <pstolowski> bschaefer: in fact I've a fix, but struggling to test it atm
[16:29] <bschaefer> pstolowski, hmm yeah, getting a test for that could be hard...possibly an AP test that goes to the application lens
[16:30] <bschaefer> and you *should* be able to assert that an app start, or assert we are not in the dash and not in preview mode
[16:30] <pstolowski> bschaefer: I mean more fundamental problem - unity doesn't seem to work at all when compiled from src and run in vbox ;)
[16:30] <bschaefer> o well
[16:30] <bschaefer> pstolowski, if you need me to test the branch out, give me a link :)
[16:30] <pstolowski> (runs fine in vbox otherwise)
[16:31] <bschaefer> hm so it crashes for you when compiled from src? Or is it just not running the compiled version?
[16:34] <pstolowski> bschaefer: I think it crashes (empty desktop on login). here is my branch lp:~stolowski/unity/no-click-preview-for-apps
[16:34] <bschaefer> pstolowski, awesome, Ill take a look :)
[16:35] <bschaefer> but thats strange :(
[16:35] <pstolowski> bschaefer: million thanks, let me know if it works; in the meantime I'm recompiling again
[16:35] <bschaefer> pstolowski, cool, and thank you for the quick fix :)
[16:35] <pstolowski> bschaefer: it's not.. I've a very special setup :P where I compile in chroot, and deploy and test in vbox
[16:36] <pstolowski> bschaefer: so perhaps I messed something. this normally works with less complicated stuff, such as backend ;)
[16:36] <bschaefer> pstolowski, geez, that sounds a bit complicated to tests a branch :)
[16:36] <bschaefer> possibly, we shall see, im recompiling :)
[16:36] <mhall119> tedg: does libhud-qt produce any API documentation?
[16:36] <pstolowski> bschaefer: btw, this fix needs to be tested in applications lens and in home scope (apps category)
[16:37] <bschaefer> pstolowski, cool, tested that we can tell the difference in the home lens?
[16:37]  * bschaefer hasn't looked at the diff yet
[16:37] <pstolowski> bschaefer: yeah, since home scope aggregates, so I had to do an extra check
[16:38] <tedg> mhall119, I think it did, but it's deprecated
[16:38] <tedg> mhall119, It'll be replaced by the Unity Actions API that Wellark is working on.
[16:38] <bschaefer> pstolowski, cool, ill test both :
[16:38] <bschaefer> :)
[16:38] <mhall119> tedg: Wellark: do we have a timeframe for when that will be ready?
[16:40] <pstolowski> bschaefer: thanks :)
[16:40] <bschaefer> pstolowski, looks like ill need a the newest versions of libunity?
[16:41] <tedg> mhall119, Soonish, not sure on the exact details.
[16:41] <bschaefer> opps, for some reason libunity-dev was uninstalled?
[16:41] <mhall119> tedg: in time for the SDK beta?
[16:41] <tedg> mhall119, I'm not sure when that is, so I can't comment :-)  My guess would be that Wellark does and would be trying for it.
[16:41] <pstolowski> bschaefer: you should be fine on saucy as long as you're up-to-date
[16:42] <bschaefer> pstolowski, the only thing I seem to be missing: --   package 'indicator3-0.4>=12.10.2' not found
[16:42] <bschaefer> which sounds a bit high number wise...
[16:43] <bschaefer> geez, its not installed ... i've must have messed up my system a bit :)
[16:44] <bschaefer> pstolowski, sorry, doing some mir/1.14 xserver stuff and things just get removed automatically :). Now its building!
[16:49] <pete-woods> mterry: hi, just tried out your libusermetrics branch with the real usermetrics, and it works :)
[16:49] <mterry> pete-woods, nice  :)
[16:49] <pete-woods> mterry: https://pastebin.canonical.com/93700/ it did need this patch to make the infographic animations work nicely, though
[16:50] <pete-woods> mterry: I don't think they have ever been run with just a small amount of data before
[16:50] <pstolowski> bschaefer: yay, got it working; I've applied my patch ontop of src deb from saucy, rather than trunk
[16:50] <pete-woods> mterry: when I say nicely, I mean for the second month data to appear at all
[16:50] <bschaefer> pstolowski, code wise the fix looks good, but it might be nice as somepoint to add this to the scope API, and say if any scopes wants to change left click behaviour it could make it easier...
[16:51] <bschaefer> pstolowski, and awesome!
[16:51] <pstolowski> bschaefer: funny you mentioned it. this is exactly the discussion we had this morning on standup. and we decided to opposite, to prevent that :)
[16:52] <bschaefer> pstolowski, well perfect :)
[16:52] <bschaefer> just thought I should at lease mention that
[16:53] <bschaefer> pstolowski, also would you or mhr3 be able to look at these reviews?
 https://code.launchpad.net/~jbicha/unity-lens-video/build-with-valac/+merge/168199
 https://code.launchpad.net/~jbicha/unity-scope-home/build-with-valac/+merge/168273
[16:53] <bschaefer> they look super simple...
[16:53] <bschaefer> but i wasnt sure if you were wanting to just stick to 0.18 for valac or not
[16:53] <pstolowski> bschaefer: yes, I'll check them tomorrow morning, eod for now if that's ok?
[16:54] <bschaefer> pstolowski, sounds good. Have a good end of your day!
[16:54] <bschaefer> ill email you letting you now how the branch goes haha
[16:54] <bschaefer> (even though yours works)
[16:54] <pstolowski> bschaefer: I think we want to avoid 0.20 for now, but will check with mhr3
[16:54] <bschaefer> pstolowski, cool, thanks and cya :)
[16:55] <jbicha> bschaefer: I believe vala-0.18 will be dropped from Ubuntu before 13.10 is released
[16:55] <mhr3> bschaefer, scopes should be fine with 0.20, we don't want libunity with 0.20... yet
[16:55] <pstolowski> bschaefer: thanks for looking at my branch, mind doing a proper review once I MP? (need to look at AP tests)
[16:55] <bschaefer> pstolowski, yes, I can do that :)
[16:55] <pstolowski> mhr3: ah, ok, good then
[16:55] <pstolowski> bschaefer: thanks
[16:55] <bschaefer> np!
[16:56] <bschaefer> mhr3, which should make those scopes branches fine to merge
[16:56] <bschaefer> mhr3, I just didn't want to merge that in without asking anyone :)
[16:57] <mhr3> bschaefer, indeed, if you have a moment and want to give them a spin when they're built with 0.20, feel free to ;)
[16:57] <bschaefer> mhr3, yeah, I can build it with 0.20 and test it out
[16:57] <bschaefer> jbicha, thanks for the branches :)
[17:36] <Saviq> fginther, btw, all the jobs for lp:unity/8.0 can be dropped
[17:38] <fginther> Saviq, ok, I'll disable it
[17:39] <Saviq> fginther, btw, panda-4 seems flaky https://jenkins.qa.ubuntu.com/job/unity8-saucy-armhf-autolanding/17/console
[17:39] <Saviq> https://jenkins.qa.ubuntu.com/job/unity8-saucy-armhf-autolanding/16/console
[17:42] <fginther> Saviq, thanks, we also just noticed that and took it out of the pool
[17:42] <Saviq> fginther, cheers
[17:51] <mzanetti> Saviq: is libunity-api to be released manually?
[17:54] <dednick> dandrader|lunch: review done for panel draghandle. few fixes needed.
[17:55] <mzanetti> Saviq: ah no... seems daily releasing has started on that one. So should be there tomorrow
[18:23] <Saviq> mzanetti, if you're still here, any idea what changed to cause https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/337/?
[18:23] <Saviq> suddenly we have 7 tests failing regularly in CI :/
[18:24] <mzanetti> Saviq: weird... no clue right now
[18:25] <Saviq> mzanetti, ok, we'll tackle tomorrow
[19:24] <Saviq> fginther, we actually have some failures in qmluitests that started this afternoon
[19:25] <Saviq> fginther, so no point in approving stuff that failed on the panda
[19:25] <Saviq> fginther, as it will fail there anyway, we'll tackle that early tomorrow
[19:25] <fginther> Saviq, ok.
[19:26] <kgunn> mterry: ping
[19:26] <kgunn> mterry: nvmd...i'll catch you in 30
[20:02] <kgunn> veebers: just trying to get off the phone....
[20:02] <veebers> kgunn: ack
[20:02] <kgunn> a minute or 2
[21:08] <mhall119> hey guys, after an apt-get dist-upgrade on Saucy and a reboot, my indicators are out of order
[21:09] <mhall119> http://ubuntuone.com/2P9GfwQekCCN9uZFItClbS
[21:09] <mhall119> is that intentional or a bug?
[21:10] <mhall119> I'm having flash-backs to my Gnome 2.x days
[21:41] <dandrader> mhall119, I have the same issue
[21:57] <fginther> cyphermox, is this ready to approve and deploy? https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/enable_indicator-network/+merge/172643
[21:57] <cyphermox> fginther: yeah
[21:57] <fginther> cyphermox, great! done