[00:04] <mhall119> anybody know if there's a way to run Unity Next on my laptop, but then launch an SDK App inside of it?
[07:22] <mzanetti> good morning
[07:23] <didrocks> hey mzanetti!
[07:23] <mzanetti> hey didier
[07:38] <smspillaz> sil2100: hey, just on the autopilot failures - it was a local problem
[07:38] <smspillaz> sil2100: but probably something you should be aware of
[07:38] <smspillaz> I think gdk is doing the wrong thing in gdk_screen_get_n_monitors ()
[07:38] <smspillaz> it returns the number of monitors currently plugged in, not the number of monitors the desktop actually spans
[07:39] <smspillaz> so there were some non-obvious failures coming from that
[07:39] <smspillaz> (I had a mirrored display FWIW)
[07:39] <smspillaz> but anyways, there were some failures like
[07:39] <sil2100> smspillaz: ah!
[07:39] <smspillaz> it would detect 2 monitors, and then try and get the second launcher
[07:39] <smspillaz> and return None
[07:39] <smspillaz> and then tests would fail
[07:40] <smspillaz> or there would be asserts on the number of panels
[07:40] <smspillaz> etc
[07:40] <smspillaz> sil2100: anyways, I unplugged the other monitor and it works fine now
[07:40] <smspillaz> and added a note in the readme
[07:40] <sil2100> smspillaz: I think I know about that one, but forgot filling out a bug - since indeed I saw those failures on my guest session when using mirrored displays, that's why I always disable that when testing
[07:40] <sil2100> smspillaz: and guest session mirrors the displays by default when I have a monitor attached
[07:40] <smspillaz> sil2100: it might be better to ask unity how many monitors there are
[07:41] <smspillaz> sil2100: because for example, you can configure compiz to pretend to be multi-monitor when in fact there's only one
[07:41] <smspillaz> etc
[07:43] <smspillaz> sil2100: relevant https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1170013/+merge/159422
[08:07] <MCR> didrocks, hi :)
[08:07] <didrocks> hey MCR
[08:08] <MCR> didrocks, I would like to remove the quilt patch from EZoom xml.
[08:08] <didrocks> MCR: is it upstream?
[08:09] <MCR> The ubuntu quilt patch just removes 4 shortcuts from EZoom.
[08:09] <didrocks> MCR: right
[08:09] <MCR> No, it will affect Ubuntu
[08:09] <MCR> but not really
[08:09] <didrocks> MCR: so no, this patch is there for a usability reason
[08:09] <MCR> as EZoom is turned off by default
[08:09] <didrocks> MCR: usability testing showed that people hit that by mistake
[08:09] <didrocks> then, they feel "stuck"
[08:10] <didrocks> and reboot their machine
[08:10] <didrocks> not a nice experience :/
[08:10] <didrocks> hence the patch
[08:10] <MCR> how can someone hit this by mistake ?
[08:10] <didrocks> MCR: it seems it happens a lot
[08:10] <MCR> you have to enable EZoom manually first
[08:10] <didrocks> especially super + scrollwheel
[08:10] <didrocks> MCR: it's enabled by default
[08:10] <MCR> ah
[08:10] <MCR> my fault then
[08:10] <didrocks> no worry :)
[08:11] <MCR> How about changing the upstream shortcuts to something else then ?
[08:11] <didrocks> MCR: I think the shortcut makes default
[08:11] <Mirv> I wonder if anyone could think whether there'd be some ~easy fix to https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/932520 on precise?
[08:11] <didrocks> MCR: what is missing a system settings option to enable them
[08:12] <didrocks> Mirv: discussed at UDS, nobody tackled it
[08:12] <MCR> didrocks, it is completely useless to have an enabled EZoom without any shortcuts...
[08:12] <Mirv> that compiz bug has a history of being marked erronously as fixed etc, but still there
[08:12] <MCR> why is it enabled in the first place ?
[08:12] <didrocks> MCR: the idea is to avoid people enabling/disabling plugin (which is risky)
[08:12] <didrocks> then, having an option to enable the shortcuts
[08:12] <didrocks> MCR: want to tackle that? :)
[08:12] <MCR> didrocks, soon it won't be risky anymore
[08:13] <Mirv> didrocks: oh ok. for me it's a bit unclear how big change in the "famous work branch" was the part that fixed that part. since it seems it could be something relatively easy related to coordinates after all, if one just understood what's going on.
[08:13] <Mirv> sil2100: according to bug comments you also took a hard look at it a year ago :)
[08:13] <didrocks> Mirv: sorry, wrong M[Tab], again :/
[08:14] <didrocks> Mirv: was talking to MCR
[08:14] <smspillaz> Mirv: I think I know what that was hang on
[08:14] <smspillaz> Mirv: is it still happening in precise ?
[08:15] <Mirv> didrocks: :P
[08:15] <Mirv> smspillaz: yes, it's still there with the Shotwell in particular
[08:15] <sil2100> Mirv: ;) The problem was that it wasn't reproducible on my machine, so I was experimenting in the dark
[08:15] <Mirv> I guess this was the commit that fixed it http://bazaar.launchpad.net/~compiz-team/compiz/0.9.8/revision/3110 in the 0.9.8 branch
[08:16] <Mirv> sil2100: it may be you didn't try out shotwell, it seems that's the most trustworthy one (at least I experience it on fglrx machine, radeon machine and I think I had it on intel machine as well)
[08:16] <MCR> didrocks, I want to reduce Ubuntu-distro-patches against Compiz to a minimum... it makes changes to .xml.in files and code to a small horror-trip ;)
[08:16] <smspillaz> MCR: its pretty easy to test those patches
[08:16] <smspillaz> export QUILT_PATCHES=debian/patches; quilt push -fa
[08:17] <smspillaz> (fix failures)
[08:17] <smspillaz> quilt refresh
[08:17] <smspillaz> quilt op -fa
[08:17] <smspillaz> *pop
[08:17] <didrocks> MCR: take them upstream is another solution ;)
[08:17] <MCR> smspillaz, it is not so easy if I change the whole .xml.in file upstream...
[08:17] <smspillaz> MCR: trust me, it used to be a massive PITA before we had inline packaging
[08:17] <MCR> smspillaz, I trust you, but
[08:18] <MCR> IT IS A HORROR TRIP
[08:18] <sil2100> Mirv: not sure now
[08:18] <smspillaz> quilt apply and refresh them where appriate
[08:18] <smspillaz> *erm, just apply
[08:18] <smspillaz> it takes like
[08:18] <smspillaz> 2 minutes
[08:18] <sil2100> didrocks: I jump out now for some errands again, buying insurance and such for the trip - be back soon
[08:18] <didrocks> sil2100: ok
[08:18] <smspillaz> Mirv: hmm, did that revision ever go into precise ?
[08:18] <Mirv> interestingly that patch (http://bazaar.launchpad.net/~compiz-team/compiz/0.9.8/diff/3110) applies just fine on top of 0.9.7, but it's a huge patch of course
[08:18] <smspillaz> (r3110)?
[08:19] <smspillaz> guess not
[08:19] <Mirv> smspillaz: no, that's the thing, it was the work branch that became 0.9.8
[08:19] <smspillaz> Mirv: you might also want a few other things too
[08:19] <MCR> smspillaz, could you do it then once successfully and print me the commands you used ?
[08:19] <Mirv> smspillaz: yeah, I was fearing you might say that ;) there's that problem of SRUability
[08:20] <MCR> smspillaz, here it would be perfect: https://code.launchpad.net/~mc-return/compiz/compiz.merge-ezoom-cleanup/+merge/159991
[08:22] <smspillaz> MCR: I already said how to do it?
[08:22] <smspillaz> cd into the root project directory
[08:22] <smspillaz> export QUILT_PATCHES=debian/patches
[08:22] <smspillaz> quilt push -fa
[08:22] <MCR> smspillaz, yes -> but it will not work correctly that way...
[08:22] <smspillaz> *find the .rej files, fix the original files as though the distro patches were applied*
[08:22] <smspillaz> ^^^ important step!
[08:22] <smspillaz> quilt refresh
[08:23] <smspillaz> quilt push -fa
[08:23] <smspillaz> quilt pop -fa
[08:23] <MCR> probably it was that step that was missing
[08:23] <MCR> *urgh*
[08:24] <Mirv> I updated the bug report. I don't think the route of trying to apply both that and some other commits from 0.9.8 to 0.9.7 is going to work. it simply becomes too big. there would be a need of a simpler patch to 0.9.7 that only addresses that drawing problem and is more verifiably not causing regressions.
[08:25] <smspillaz> Mirv: I'll grab the bits you need hang on
[08:25] <smspillaz> its a small part of like 2 commits
[08:27] <Mirv> smspillaz: ok, thank you, can you update those to the report? do you think all of that 3110 is needed to address #932520, or could some smaller subset of it address that bug alone (and not #862430, #892012, #923683)?
[08:27] <smspillaz> Mirv: I'd recommend taking all of 3110 if possible
[08:28] <smspillaz> there were just two other potential regressions I fixed later
[08:28] <Mirv> smspillaz: yeah, if that's the only possibility then that's the only choice to evaluate. it might be too much.
[08:28] <smspillaz> I'm just trying to find the subcommits for them
[08:28] <smspillaz> Mirv: I'd say its worth putting out for testing at least
[08:28] <Mirv> smspillaz: true, via a PPA
[08:29] <smspillaz> if only we could backport the testsuite :p
[08:29] <Mirv> :)
[08:29] <smspillaz> (Wouldn't suggest it, its like 15000 lines)
[08:38] <smspillaz> ah man, this is why I don't like trunk reverts
[08:38]  * smspillaz had been looking at the wrong rev the whole time
[08:45] <MCR> smspillaz, I want to update showmouse and firepaint to use GL_TRIANGLE_FAN instead of GL_TRIANGLES -> it will then just need 4 vertices instead of 6 to make a quad, am I correct ?
[08:46] <smspillaz> MCR: prefer GL_TRIANGLE_STRIP if possible
[08:46] <smspillaz> GL_TRIANGLE_FAN is really only there for rendering spheres
[08:46] <smspillaz> GL_TRIANGLE_STRIP works like this:
[08:46] <smspillaz> 1----2
[08:46] <smspillaz>     /
[08:46] <smspillaz>    /
[08:47] <smspillaz> /
[08:47] <smspillaz> 3
[08:47] <smspillaz> -----4
[08:47] <smspillaz> yeah okay, expressing ascii art over irc doesn't work very well
[08:47] <MCR> hehe
[08:47] <smspillaz> in any case, you need to be careful with both TRIANGLE_FAN and TRIANGLE_STRIP . They are both continuous primitives
[08:48] <smspillaz> so they only open at one and and close at another
[08:48] <smspillaz> as opposed to triangles which are always closed on each primitive
[08:49] <MCR> well -> you mentioned once (when the GLES port was made) that STRIP would be better and it would really be more efficient...
[08:50] <MCR> but FAN would imho be quite ideal for a quad also
[08:50] <MCR> well -> I will simply test it extensively
[08:51] <smspillaz> well, at least for four vertices TRIANGLE_STRIP and TRIANGLE_FAN work the same way
[08:51] <MCR> ah -> yes
[08:51] <smspillaz> the winding is just different that's all
[08:51] <MCR> okidoki
[08:51] <smspillaz> if you went tl, tr, bl, br it would go something like
[08:51] <smspillaz> 1,3,2,4 for STRIP
[08:52] <smspillaz> and 1,2,3,4 for FAN
[08:52] <smspillaz> its just easier if you emulate quads by doing STRIP as it makes more sense concentually
[08:52] <smspillaz> *conceptually
[08:52] <MCR> that GL stuff is quite mighty, but fun
[08:52] <smspillaz> OpenGL is like the worlds worst API
[08:52] <MCR> ok -> I take STRIP then
[08:53] <MCR> hehe
[08:53] <smspillaz> Mirv: yeah, now that I've looked into it pulling in any more revs looks complicated
[08:53] <MCR> smspillaz, I thought it is the world's most advanced 3d API ;)
[08:53] <smspillaz> Mirv: feel free to test 3110 . I don't think there wer e many regresisons from it
[08:53] <MCR> we must take what we get ;)
[08:54] <smspillaz> MCR: the whole implicit thread context is just the most annoying thing to work with
[08:54] <smspillaz> there's this whole idea that the pipeline is stateful but then that state is completely hidden from you
[08:54] <smspillaz> but then you shouldn't query that state as there's no guaruntee that the driver won't stall the pipeline or whatever
[08:54] <smspillaz> its *stupid*
[08:55] <smspillaz> anyways, time for me to get off IRC and do some study related things
[08:56] <MCR> c ya
[08:57] <Mirv> smspillaz: ok, so those depend on some more new stuff et cetera. so "3110 only or nothing"?
[08:57] <Mirv> I can make a test PPA out of that
[08:58] <smspillaz> Mirv: I could probably pull the relevant bits out - I'd just have to do it manually really
[08:58] <smspillaz> ( in terms of fixing "in theory" bugs in the ConfigureWindow handling bits )
[09:03] <Mirv> smspillaz: ok.. let's see with this. I need to modify the 3110 a bit anyway since it doesn't apply on top of the other patches, but probably nothing too big there
[09:03] <smspillaz> coolio
[09:11] <om26er> its the release day
[09:12] <mzanetti> om26er: \o/
[09:13] <mzanetti> om26er: how is it going?
[09:13] <mzanetti> did you completely recover from being sick?
[09:14] <om26er> mzanetti, yeah, my stomach hurts other than that i am pretty much alive
[09:14] <om26er> mzanetti, ;)
[09:15] <om26er> mzanetti, overall i am pretty good now
[09:15] <mzanetti> ok. good
[09:48] <Cimi> how do I know if an item is completed/loaded?
[09:48] <Cimi> I'm trying to access x/width properties of delegates of a listview
[09:49] <Cimi> but it complains on loading the app, because I think they are not completed yet
[09:49] <Cimi> so I did listview.currentItem ? listview.currentItem.x for example
[09:49] <Cimi> but it still doesn't work
[09:50] <Cimi> mzanetti, tsdgeos ^ :)
[09:50] <mzanetti> Cimi: Loader.progress == 1.0
[09:50] <Cimi> mzanetti, it's not a Loader
[09:50] <Cimi> mzanetti, is a listview
[09:51] <Cimi> mzanetti, I want to see if the delegate exist
[09:51] <mzanetti> Cimi: hmm... its a bit tricky but I usually do this:
[09:51] <mzanetti> Cimi: tryCompare(listView.count, model.count) // Wait for listView to read the model
[09:51] <mzanetti> Cimi: wailt(0) spin event loop to let the listview create delegates
[09:52] <Cimi> mzanetti, it's not in a test :P
[09:52] <mzanetti> Cimi: don't access the delage then
[09:52] <Cimi> I'll do differently then, but I don't like it
[09:52] <Cimi> onCurrentItemChanged: { }
[09:53] <mzanetti> Cimi: accessing delegates will crash sooner or later unless you really know whats happening inside the ListView
[09:53] <Cimi> and set there, from the listview, the properties of the item I need
[09:54] <mzanetti> Cimi: ok... only to read x of currentItem should be ok...
[09:54] <Cimi> mzanetti, indeed
[09:55] <Cimi> I'm doing from the listview
[09:55] <Cimi>                 onCurrentItemChanged: {   highlightLine.width = currentItem.width
[09:55] <Cimi>                     highlightLine.x = x + currentItem.x   }
[09:55] <mzanetti> Cimi: listview.currentItem !== null ? listview.currentItem
[09:55] <Cimi> mzanetti, did that
[09:55] <mzanetti> Cimi: your example didn't check for !== null
[09:55] <mzanetti> Cimi: err... might be !== undefined
[09:55] <Cimi> mzanetti, isn't the same thing?
[09:56] <Cimi> well, undefined is different
[11:24] <Marlinc> How would my app integrate with the sync menu?
[11:50] <sil2100> didrocks: can we re-run the unity tests, or are they already re-running themselves ;) ?
[12:39] <mzanetti> tsdgeos: ping
[12:41] <didrocks> sil2100: you mean, rebuild unity and rerunning, right?
[12:55] <tsdgeos> mzanetti: yes?
[12:55] <mzanetti> tsdgeos: hey... seems we are blocked by the hud migration now
[12:55] <mzanetti> tsdgeos: I've updated the jenkins job to include the new ppa
[12:55] <tsdgeos> hmmm
[12:55] <mzanetti> tsdgeos: sergiusens pointed me to your branch with the updates after I pinged you
[12:56] <tsdgeos> is that new ppa landing on the devices?
[12:56] <mzanetti> tsdgeos: I've ran it through the updated job. still fails:
[12:56] <mzanetti> tsdgeos: http://s-jenkins:8080/job/unity-phablet-qmluitests/630/console
[12:56] <mzanetti> tsdgeos: I don't know... didrocks maybe know.
[12:57] <mzanetti> didrocks: mind spreading some information on the ppa you set up?
[12:57] <tsdgeos> if it doesn't land into the devices we can't put it in our code
[12:57] <tsdgeos> otherwise we'll have unusable devices
[12:58] <mzanetti> sergiusens: ^
[12:58] <didrocks> tsdgeos: yeah, from what I know it's this ppa + the phablet one
[12:58] <didrocks> phablet one for things that we can't land yet in distro
[12:58] <didrocks> mzanetti: ^
[12:58] <tsdgeos> ok
[12:58] <didrocks> tsdgeos: so you will have the new HUD from the ppa on the device
[12:59] <tsdgeos> good
[12:59] <didrocks> tsdgeos: be careful, the HUD has a double build
[12:59] <tsdgeos> ?
[12:59] <didrocks> tsdgeos: i386 and amd64 is the "desktop with bamf"
[12:59] <didrocks> amrhf is the phone with platform-api
[12:59] <tsdgeos> sure
[12:59] <didrocks> tsdgeos: this is temporarly, until ted can fix the issue :)
[12:59] <tsdgeos> that doesn't matter to us
[12:59] <Marlinc> How would my app integrate with the sync menu? It is made in Java. Can I use D-Bus?
[12:59] <didrocks> tsdgeos: just that if you test on i386/amd64, don't be surprised :)
[12:59] <tsdgeos> the api that goes to our side is the same
[13:00] <didrocks> mzanetti: this as well might interest you in case you are not aware of it ^
[13:00] <tsdgeos> didrocks: it's been that way all the time
[13:00] <didrocks> tsdgeos: ok, not sure about HUD on i386, how you tested it :)
[13:01] <tsdgeos> mzanetti: what failed was my branch or my branch + merge to trunk?
[13:01] <sergiusens> mzanetti: I see libhud-client2-dev in https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+packages
[13:01] <mzanetti> tsdgeos: +merge to trunk
[13:01] <tsdgeos> why is it not finding libhudclient2-dev?
[13:02] <tsdgeos> what does a virtual package mean?¿
[13:02] <mzanetti> tsdgeos: sergiusens: the job uses those ppas: D08add_ppa-ubuntu-unity-daily-build D08add_ppa-qt5-proper D09add_ppa-phablet-team-ppa D09add_ppa-ubuntu-sdk-team-ppa
[13:02] <luv> hell, the page Bug reporting etiquette after clicking "report a bug" is sooooo anoying
[13:02] <sergiusens> tsdgeos: my explanation may be crude, but it means it's refed somewhere but can't be found
[13:03] <tsdgeos> sergiusens: i see
[13:03] <mzanetti> :D
[13:03] <tsdgeos> mzanetti: daily-build vs daily-build-next ?
[13:03] <mzanetti> tsdgeos: ?
[13:03] <sergiusens> mzanetti: yeah, that's the issue
[13:03] <didrocks> mzanetti: sholdn't it be D08add_ppa-ubuntu-unity-daily-build-next?
[13:03] <didrocks> sohuldn't*
[13:03] <tsdgeos> in those ppas
[13:03] <sergiusens> mzanetti: use the dynamic add ppa we have
[13:03] <luv> omfg, do i really need to use "ubuntu-bug" to make a report??
[13:04] <mzanetti> sergiusens: what is that?
[13:05] <luv> given  my ubuntu computer at work is not connected to the internet
[13:05] <didrocks> mzanetti: I think he means that the wrong ppa is added
[13:05] <didrocks> daily-build, not daily-build-next
[13:05] <mzanetti> didrocks: yeah... we don't have a hook for next as it seems
[13:06] <sergiusens> mzanetti: didrocks yeah, but I'm searching for the syntax ;-)
[13:06] <kgunn> mzanetti: ping
[13:06] <mzanetti> kgunn: hey
[13:06]  * mzanetti waits in the hangout
[13:06] <sergiusens> mzanetti: D09add_ppa~ubuntu-unity~daily-build-next
[13:07] <rsalveti> morning
[13:07] <didrocks> hey rsalveti
[13:08] <ChrisTownsend> luv: Using ubuntu-bug is good in that it will attach many logs that could help in diagnosing the issue you have.  However, if you can just put in a bug and provide enough info that developers can use to fix the bug, then it's not an absolute necessity.
[13:09] <luv> ChrisTownsend: cool, how can i file a bug from a web browser then? Because when I click "report a bug" im redirecting to wiki
[13:10] <ChrisTownsend> luv: Hmm, that doesn't sound right.  Give me a sec and I'll post a link.
[13:10] <rsalveti> sergiusens: if you replace the dependency to what is described at https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603 it kind of works
[13:10] <ChrisTownsend> luv: Are you wanting to file a bug against Unity?
[13:10] <rsalveti> sergiusens: well, hud will show up, but it'll be useless
[13:11] <rsalveti> but that might be a different issue
[13:11] <luv> ChrisTownsend: for example https://bugs.launchpad.net/ubuntu and click "Report a bug". Nah, it's signond
[13:12] <sergiusens> rsalveti: that MR is going to land soonish ;-)
[13:12] <Marlinc> https://answers.launchpad.net/ubuntu/+source/indicator-sync/+question/227438
[13:12] <rsalveti> sergiusens: great, then we need another MR to release it
[13:13] <rsalveti> sergiusens: since qml-phone-shell is still maintained by our ci at phablet-ppa
[13:14] <ChrisTownsend> luv: We should probably move this conversation to #ubuntu since that is the support channel.  But that link and Report a bug works for me.
[13:15] <luv> ChrisTownsend: heh, that's very strange then, it behaves differently for you
[13:28] <Cimi> tsdgeos, mzanetti how do I check if a model has finished loading?
[13:29] <tsdgeos> what do you mean a model has finished loading?
[13:31] <Cimi> tsdgeos, fully loaded
[13:31] <Cimi> tsdgeos, Lenses have finished loading
[13:31] <Cimi> populated
[13:32] <Cimi> lenses.loaded ?
[13:32] <tsdgeos> Cimi: but that's because it's a dee model, no?
[13:32] <Marlinc> Where do I need to ask questions related to he sync menu?
[13:32] <Marlinc> the*
[13:36] <tvoss> Saviq, ping
[13:38] <tsdgeos> tvoss: he's holidaying
[13:38] <tvoss> tsdgeos, ah, thanks
[13:54] <tsdgeos> tvoss: anything the rest of the shell team can help with?
[13:54] <tvoss> tsdgeos, nope, but thanks for asking :)
[14:04] <rsalveti> sergiusens: anything blocking https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603 still?
[14:05] <sergiusens> rsalveti: nah... I think mzanetti has it covered
[14:06] <rsalveti> mzanetti: ^^ :-)
[14:06] <nic-doffay> mzanetti, branch: https://code.launchpad.net/~nicolas-doffay/unity/infographics_transitions
[14:06] <sergiusens> rsalveti: we were talking in a different channel... be patient :-)
[14:06] <rsalveti> sergiusens: lol, ok
[14:12] <Cimi> mzanetti, how can I use a tryCompare for a condition?
[14:13] <Cimi> unless I do while (condition is false) (wait(0))
[14:14] <nic-doffay> mzanetti, can you pm me your email?
[14:15] <nic-doffay> Sending the vid over now.
[14:15] <Cimi> yep, works
[14:20] <tsdgeos> Cimi: we have a tryCompareFunction or something like that
[14:20] <tsdgeos> that is a bit better than while-ing
[14:20] <Cimi> ah
[14:20] <tsdgeos> well, it's the same
[14:20] <tsdgeos> but looks less lame when reading the test :D
[14:20] <Cimi> tsdgeos, where is it?
[14:21] <tsdgeos> Cimi: ./tests/utils/modules/Unity/Test/UnityTestCase.qml
[14:21] <tsdgeos> if you grep for it it's used in a few places
[14:21] <tsdgeos> Cimi: sorry i didn't followup with the model thing, did you get what you wanted?
[14:21] <tsdgeos> mzanetti: do you need anything from me in the hud thing
[14:21] <tsdgeos> ?
[14:22] <Cimi> tsdgeos, yes I did
[14:22] <tsdgeos> cool
[14:24] <Cimi> tsdgeos, js question
[14:24] <Cimi> tsdgeos, how to embed a function as argument?
[14:24] <Cimi> tsdgeos, I want tryCompareFunction (width > 0, true)
[14:24] <Cimi> tsdgeos, syntax wise, replacing width > 0 with?
[14:25] <tsdgeos> Cimi: afaik there's no lambdas, so just create a function
[14:25] <Cimi> ok
[14:26] <tsdgeos> actually it seems you can write the function code in there
[14:26] <tsdgeos> but it's a bit weird :D
[14:26] <tsdgeos> i.e. you could so something like tryCompareFunction (function(){return width > 0;}, true);
[14:27] <tsdgeos> not really helping readability imho
[14:30] <Cimi> mzanetti, could you help me?
[14:31] <mzanetti> ok... now... was in a meeting
[14:31] <mzanetti> Cimi: yes, let me just read all the scrollbacks in all channels first
[14:31] <Cimi> mzanetti, not on that
[14:31] <Cimi> mzanetti, a different thing
[14:31] <Cimi> I'd like to move to the Launcher rewrite using Panel
[14:31] <Cimi> but there is something wrong in the last test for the dashBar
[14:32] <mzanetti> sergiusens: rsalveti: tsdgeos: on it... I think the jenkins runs still failed... let me check
[14:32] <Cimi> you need
[14:32] <Cimi> lp:~tpeeters/ubuntu-ui-toolkit/panel
[14:32] <Cimi> and
[14:32] <Cimi> lp:~unity-team/unity/phablet.dashbar_panel
[14:32] <mzanetti> sergiusens: http://s-jenkins:8080/job/unity-phablet-qmluitests/633/console
[14:35] <sergiusens> mzanetti: arg...
[14:40] <mzanetti> Cimi: now... sorry
[14:40] <mzanetti> I was in a meeting for 1.5 hours and got pinged in all possible channels
[14:41] <mzanetti> Cimi: Launcher rewrite?
[14:42] <tsdgeos> lol
[14:42] <tsdgeos> grow (size=-39299359) at /home/tsdgeos/qt5/qtbase/src/corelib/tools/qlist.cpp:67
[14:42] <tsdgeos> grow!
[14:42] <tsdgeos> not!
[14:45] <mzanetti> tsdgeos: you allright?
[14:45] <tsdgeos> would like to know why qt wants to grow that list in -39299359
[14:46] <tsdgeos> other than that
[14:46] <tsdgeos> not that bad
[14:46] <mzanetti> :D
[14:48] <mzanetti> Cimi: still here?
[14:53] <Cimi> mzanetti, yep
[14:53] <Cimi> mzanetti, was out for a walk with vesa
[14:53] <mzanetti> Cimi: ok. np
[14:53] <mzanetti> Cimi: you said something about Launcher rewrite?
[14:53] <Cimi> mzanetti, I am rewriting the launcher to support the Panel SDK component
[14:53] <mzanetti> btw. hi vesar :) Long time no see
[14:54] <mzanetti> Cimi: oh... hm..
[14:54] <mzanetti> Cimi: because I started working on the launcher and seems to me it needs to be changed A LOT
[14:54] <Cimi> mzanetti, you can do it then :)
[14:54] <Cimi> just use lp:~tpeeters/ubuntu-ui-toolkit/panel
[14:55] <mzanetti> Cimi: yours is only about the dragging in/out, right?
[14:55] <Cimi> mzanetti, you can see how it works with lp:~unity-team/unity/phablet.dashbar_panel
[14:55] <vesar> mzanetti, hi man.  how's it going.
[14:55] <mzanetti> vesar: very busy. but fine :)
[14:55] <Cimi> mzanetti, the idea is to remove this part of the logic
[14:55] <mzanetti> vesar: thanks
[14:55] <Cimi> mzanetti, and leave it to the panel
[14:55] <mzanetti> Cimi: thats the right information at the right time :) thanks!
[14:56] <mzanetti> Cimi: so we can get rid of all that timing stuff?
[14:56] <vesar> Cimi, mzanetti: So you guys are rewriting launcher component. Great!
[14:59] <Cimi> mzanetti, mostly
[14:59] <Cimi> mzanetti, watch out from the tooltips etc
[15:00] <mzanetti> Cimi: ok. thanks
[15:01] <mzanetti> vesar: yeah. well. I'm trying to reuse most of the existing stuff. but basic architecture will change.
[15:03] <vesar> mzanetti, ok. Just thinking that the whole launcher is quite of a mess at the moment. Just wonder if it would be better to start it pretty much from the scratch?
[15:03] <vesar> mzanetti, Cimi : though need to check that cimi's branch.
[15:03] <mzanetti> vesar: in terms of code... yes... its a mess... and I started from scratch. still hope to be able to reuse the delegates and tooltips and such stuff
[15:03] <Cimi> vesar, this is for the dashBar
[15:04] <vesar> Cimi, oh ok then..
[15:04] <vesar> mzanetti, ok good. that makes sense.
[15:04] <mzanetti> vesar: I'll implement the model in C++ and get rid of those 5 QML ListModels aggregated in some weird way
[15:06] <vesar> mzanetti, yes that was the most terrible part of it. They were created in the first place to enable the accordion pattern which is disabled anyway.
[15:06] <vesar> mzanetti, and sure it wouldn't need all those models to get it done anyway.
[15:07] <mzanetti> vesar: cool. so you know the internals if it... that might lead to me bugging you more often with questions
[15:08] <vesar> mzanetti, yes feel free to bug me. I can take responsibility of all weirdos in that code. unfortunately:)
[15:08] <mzanetti> vesar: haha :)
[15:09] <vesar> mzanetti, are you aware that we have here in design team one motion graphic contractor at the moment looking after e.g. launcher behaviours? Animations and that sort of stuff.
[15:09] <mzanetti> vesar: after a first look I thought: hmm... that all seems totally unrelated... must have been just copied over from Unity 2D and integrated somehow
[15:09] <mzanetti> vesar: no, I'm not
[15:10] <mzanetti> vesar: does he do changes in the code? or mostly writing specs and create videos?
[15:10] <vesar> mzanetti, the launcher is currently just a mix of multiple different prototypes and that's why it is as it is at the moment.
[15:11] <vesar> mzanetti, no he doesn't. He's using mostly after effects and flash for creating animation videos.
[15:12] <mzanetti> vesar: hmm... I guess that will impact the behavior when dragging the launcher in/out
[15:12] <vesar> mzanetti, basically proposals for possible launcher animations and behaviours. Like for example highlight, stacking/scrolling/accordiong etc. Might be worth of having a meeting together at some point.
[15:14] <mzanetti> vesar: I'm just thinking if it makes sense to use the Toolbar as Cimi suggested. because in that case we probably won't be able to finetune the launchers behavior but have to go with what all the other toolbars go
[15:14] <mzanetti> vesar: can you clarify that for me?
[15:17] <vesar> mzanetti, sure I can check the cimi's implementation and check how it would fit in launcher's place. And what would be missing from intended launcher behaviour. I'll check also with Martin (motion graphics guy) when we can expect something from him.
[15:18] <Cimi> the launcher reveal is fine with the Panel component
[15:18] <Cimi> only difficulty is chaining mouse events
[15:18] <Cimi> the Panel has its own MouseArea (dragginarea)
[15:19] <mzanetti> Cimi: I'm not entirely sure there... because if you look at the desktop panel with autohide in current unity it has some mechanism that you have to push the mouse harder to the edge to trigger the panel revealing
[15:19] <mzanetti> Cimi: I don't think the Panel component can do that
[15:19] <mzanetti> Cimi: question is if it will at some point
[15:20] <Cimi> mzanetti, if we need things, we simply ask timp
[15:20] <Cimi> mzanetti, we're doing the component now, so we need everything we need
[15:21] <mzanetti> Cimi: I'll better ask before switching :)
[15:21] <Cimi> mzanetti, please come up with a list of requirements
[15:21] <cyphermox> dandrader: looking at geoclue2... is that ready to ship / shipping, or whatever that I can put in daily release?
[15:22] <mzanetti> Cimi: well, that would be the list of designer requirements. with so far is: "Make it exactly like the Panel in current Unity"
[15:22] <Cimi> mzanetti, nope
[15:22] <Cimi> mzanetti, it's a different reveal
[15:22] <dandrader> cyphermox, no, not at all
[15:22] <Cimi> should be consistent with the toolbars
[15:22] <mzanetti> on a touch interface yes. but on a mouse interface, no. it should be the same
[15:23] <cyphermox> dandrader: is there an ETA?
[15:23] <mzanetti> Cimi: I for one would love to reuse the Panel... I just fear that in the end some designer says we're lacking features that the other panels won't have
[15:23] <dandrader> cyphermox, it barely started and work on it stopped shortly after last UDS
[15:24] <cyphermox> dandrader: well, I mean we agreed to something at that UDS
[15:24] <Cimi> mzanetti, we created the Panel to port the Launcher to use it :)
[15:24] <cyphermox> dandrader: I'm trying to make sense of whether than something got done and needs daily release love :)
[15:24] <Cimi> mzanetti, so if it is missing things, we need to mark the MR for Panel to Needs Fixing
[15:24] <mzanetti> Cimi: and did you talk with a designer about it?
[15:25] <Cimi> mzanetti, they want the same behaviour
[15:25] <Cimi> of the toolbar
[15:25] <Cimi> afaics
[15:25] <dandrader> cyphermox, sure. Since then I've moved on to work on Unity Next and, AFAIK, no one else move in to work on it
[15:25] <Cimi> the day we will require a sort of edge resistance, we will work on it
[15:26] <Cimi> Build-Depends dependency for qml-phone-shell cannot be satisfied because the package libhud-client1-dev cannot be found
[15:26] <mzanetti> Cimi: ok... I'll take your word for granted then... Don't make me change the Panel implementation in September then :)
[15:26] <Cimi> how can I ran on the phone?
[15:26] <cyphermox> dandrader: ok! thanks for the sitrep :)
[15:26] <Cimi> tsdgeos, apt-get build-dep qml-phone-shell on the phone
[15:26] <Cimi> Build-Depends dependency for qml-phone-shell cannot be satisfied because the package libhud-client1-dev cannot be found
[15:26] <mzanetti> Cimi: you need a new ppa
[15:27] <mzanetti> Cimi: one sec...
[15:27] <cyphermox> Cimi: yeah,
[15:27] <Cimi> let's add it in the build scripts
[15:27] <cyphermox> ppa:ubuntu-unity/daily-release-next
[15:27] <mzanetti> Cimi: ppa:ubuntu-unity/daily-build-next
[15:27] <mzanetti> Cimi:  I think if you flash your device now this ppa will already be there
[15:27] <mzanetti> Cimi: or at least will be in next images
[15:30] <tsdgeos> Cimi: the world is dying :D
[15:30] <tsdgeos> mzanetti: that new ppa doesn't have libhud-client1-dev either
[15:30] <tsdgeos> no?
[15:30] <tsdgeos> it has the 2
[15:30]  * mzanetti gives up on that hud ppa things
[15:31] <tsdgeos> ?
[15:31] <mzanetti> tsdgeos: I don't know
[15:31] <tsdgeos> what's the problem?
[15:31] <mzanetti> tsdgeos: that everything is broken
[15:32] <cyphermox> mzanetti: tsdgeos: give me a second, I'll clear that up for you
[15:32] <cyphermox> I built it all with libhud in that ppa a few days ago
[15:33] <cyphermox> right, it's libhud-client2-dev
[15:33] <cyphermox> mzanetti: what are you trying to build?
[15:33] <cyphermox> or was it Cimi?
[15:33] <Cimi> I was
[15:33] <Cimi> unity
[15:33] <mzanetti> cyphermox: it was Cimi. but its the shell
[15:33] <mzanetti> unity-phablet
[15:33] <cyphermox> ok
[15:34] <cyphermox> yeah, so just change the depends to look for hud-client-2 IIRC
[15:34] <cyphermox> I'll try it now just to be sure
[15:34] <mzanetti> cyphermox: wasn't it hud 1.0?
[15:34] <cyphermox> yes, but I think it's still hud-client-2
[15:35] <tsdgeos> mzanetti: so we need my MR
[15:35] <mzanetti> anyways... have to run for a bit... will be back later to see if jenkins needs some love
[15:35] <tsdgeos> thing is why it's failing in jenkins
[15:35] <mzanetti> tsdgeos: I guess so
[15:35] <cyphermox> grabbing the packages now, and I'll send  a MR to fix this
[15:35] <mzanetti> tsdgeos: it also fails because that ppa is missing
[15:35] <tsdgeos> cyphermox: i have a MR to use libhud2
[15:35] <cyphermox> ok
[15:36] <tsdgeos> mzanetti: and can't we add it?
[15:36] <tsdgeos> mzanetti: anyway, run :)
[15:36] <mzanetti> tsdgeos: and for some reason adding that ppa requires us to change all the VM's (adding LP oauth creds)
[15:36] <cyphermox> tsdgeos: link? I'll test everything here
[15:36] <tsdgeos> cyphermox: https://code.launchpad.net/~aacid/unity/new_hud_client
[15:37] <tsdgeos> it's not up to date
[15:37] <tsdgeos> but merges cleanly
[15:37] <cyphermox> ok
[15:37] <cyphermox> needs review?
[15:37] <sergiusens> cyphermox: tsdgeos fginther was working on the credential adds to the VMs
[15:37] <cyphermox> ack
[15:37] <tsdgeos> cool
[15:38] <sergiusens> problem should be solved soon
[15:41] <tsdgeos> let's make mzanetti happy :-)
[15:49] <cyphermox> tsdgeos: hud-client2 is already landed in the ppa for daily-release where lp:unity/phablet will land
[15:49] <cyphermox> so I guess it's just -ci that needs fixing?
[15:50] <sergiusens> cyphermox: lp:unity/phablet is not currently landing there :-(
[15:50] <cyphermox> err
[15:51] <cyphermox> interesting..
[15:51] <sergiusens> cyphermox: I asked that yesterday
[15:51] <cyphermox> is there a reason why not except "not done yet" ? :)
[15:51] <sergiusens> cyphermox: was told that only trunk trunk lands there...
[15:51] <cyphermox> OH
[15:51] <cyphermox> right
[15:51] <cyphermox> the projects sharing names make things complicated
[15:52] <tsdgeos> :D
[15:52] <sergiusens> cyphermox: well qml-phone-shell doesn't share anything...
[15:52] <cyphermox> didrocks: ^ I'd be all for renaming the unity/phablet stuff to something like qml-phone-shell
[15:52] <sergiusens> cyphermox: and it's unfair, because there's a Qt landed in there ;-)
[15:52] <cyphermox> sergiusens: yeah, in the packaging it's not conflicting, but the bzr branch is still named unity
[15:53] <sergiusens> cyphermox: yeah, problem is, it's called unity ng in the outerwebs
[15:53] <didrocks> sergiusens: cyphermox: it's not because of only trunk lands
[15:53] <sergiusens> cyphermox: which will be a constant problem anyways since you want both to be there
[15:53] <cyphermox> assuming the binary and source packages are renamed already (and I think they are) we could probably unblock that by just pushing lp:unity/phablet to lp:unity-ng, or lp:qml-phone-shell, depending on what the name should be
[15:54] <sergiusens> +1 on unity-ng
[15:54] <didrocks> cyphermox: transitionning to the shell and having it easy installable side by side is planned for mid/end may
[15:54] <didrocks> sergiusens: we decided for unity-next as a name
[15:54] <cyphermox> pushing to lp:unity-ng means another renaming of source+binary packages though and other config changes
[15:54] <sergiusens> +1 on that too
[15:54] <cyphermox> oh, cool
[15:54] <didrocks> cyphermox: but unity-next -> unity at some point
[15:54] <didrocks> later on
[15:54] <cyphermox> didrocks: any of that I can help unblock
[15:54] <cyphermox> ugh
[15:55] <didrocks> cyphermox: what is blocking? exactly?
[15:55] <cyphermox> I don't know
[15:55] <cyphermox> anything I can help to make that faster? :D
[15:55] <didrocks> cyphermox: upstream needs to port on MIR first for landing to the desktop
[15:55] <sergiusens> didrocks: cyphermox only thing I can think of is libunity changes... Saviq you around?
[15:55] <didrocks> so it's not blocked on the integration at all
[15:55] <didrocks> cyphermox: removing their nux old version
[15:55] <didrocks> cyphermox: and other cleanswapping :)
[15:55] <Cimi> mzanetti, when you finished your findings, comment on the panel MR
[15:56] <cyphermox> didrocks: well, yeah
[15:56] <sergiusens> didrocks: cyphermox the new unity does not depend on nux
[15:56] <cyphermox> didrocks: but in the meantime we could still start shipping things in the PPA to make things work on the phone as it currently is
[15:56] <sergiusens> didrocks: cyphermox only notify-osd, but that doesn't matter for daily releases
[15:57] <cyphermox> didrocks: what I mean by that is that I can currently build and run unity/phablet on my nexus 4, so theoretically it could ship now in a PPA
[15:57] <didrocks> cyphermox: they are using the phablet ppa for that
[15:57] <cyphermox> ok
[15:57] <cyphermox> but phablet ppa doesn't have the new hud? :P
[15:57] <cyphermox> (I didn't check)
[15:57] <didrocks> cyphermox: they are building on both our ppa + the phablet one
[15:58] <cyphermox> indeed
[15:59] <cyphermox> so it would be grabbing the new hud
[15:59] <sergiusens> didrocks: cyphermox we want to stop using ppa:phablet-team...
[15:59] <sergiusens> cyphermox: didrocks people are getting confused about what is daily released and what isn't
[15:59] <cyphermox> :'( this is all so complicated
[16:00] <sergiusens> cyphermox: yes it is
[16:00] <didrocks> sergiusens: right, but we need to stage changes, bottom to top, otherwise we'll get 10 breakages
[16:00] <cyphermox> sergiusens: understandably, when we are :)
[16:00] <cyphermox> didrocks: we're already somewhat broken on hud already though
[16:00] <cyphermox> for the apps?
[16:01] <didrocks> cyphermox: ? it's getting fixed
[16:01] <cyphermox> right
[16:01] <didrocks> cyphermox: you didn't track the HUD changes? apps are all merged
[16:01] <Marlinc> Where do I need to ask questions related to the sync menu?
[16:01] <cyphermox> didrocks: I'm doing all I can to track the changes but hey, I can't remember everything :)
[16:01] <didrocks> cyphermox: if you have some time, please do unity, but it's clearly not ready for the next ppa
[16:01] <sergiusens> cyphermox: tsdgeos build is progressing btw /unity-phablet-qmluitests/637/console
[16:02] <cyphermox> didrocks: unity/phablet already builds fine with hud-client2.
[16:02] <sergiusens> didrocks: why isn't it ready? With details people can fix
[16:02] <cyphermox> sergiusens: AIUI, porting to Mir
[16:02] <didrocks> sergiusens: involved people in unity next are in that discussion for a month
[16:03] <didrocks> sergiusens: and the plan is 1. MIR
[16:03] <didrocks> 2. Unity next
[16:03] <cyphermox> *that* would be a second stage though, and shouldn't be blocking putting that in daily-release-next?
[16:03] <tsdgeos> sergiusens: cool, that's with my MR, no?
[16:03] <didrocks> sergiusens: otherwise, there is no way to test before to the next ppa, there is no jenkins job I can hook in to install, provision an image and tests from the ppa
[16:04] <didrocks> cyphermox: ^
[16:04] <sergiusens> didrocks: what if we dput instead of you? We have all that infrastructure
[16:05] <didrocks> sergiusens: how would that change the original issue you pointed first?
[16:05] <didrocks> like people not knowing if we are daily releasing or not
[16:05] <didrocks> (and those people know for unity next that we are not)
[16:05] <cyphermox> if there are no tests ready/ported, then that's a good reason
[16:06] <sergiusens> didrocks: well, the big issues is that hud is in daily release and qml-phone-shell isn't
[16:06] <sergiusens> cyphermox: there are tests... that's what the failing job was doing...
[16:06] <cyphermox> sergiusens: sorry, I mean autopilot tests
[16:06] <didrocks> tests that we can run to validate a stack
[16:07] <didrocks> otherwise, you will get breakage
[16:07] <cyphermox> regression testing, basically
[16:07] <sergiusens> didrocks: that did not prevent breaking qtubuntu-media
[16:07] <didrocks> sergiusens: but qml-phone-shell is not an isolated case, is it?
[16:07] <didrocks> sergiusens: because we don't have autopilot tests running for those?
[16:07] <didrocks> that's the next PPA?
[16:07] <didrocks> sergiusens: and that's where we should focus, having those jobs running AP?
[16:07] <didrocks> sergiusens: I don't really like this tone btw, *again*
[16:08] <sergiusens> didrocks: autopilot or not, playing and having a black screen wouldn't be detected by autopilot
[16:08] <didrocks> sergiusens: we decided one week ago to have 2 ppas
[16:08] <didrocks> stuff that are already daily releasing
[16:08] <didrocks> and the rest
[16:08] <didrocks> you have your ubuntu-session
[16:08] <didrocks> and tons of other components
[16:08] <didrocks> what changed since then?
[16:08] <sergiusens> didrocks: yes, and that is good
[16:08] <sergiusens> didrocks: really
[16:08] <didrocks> sergiusens: so why not for the qml-phone*?
[16:08] <cyphermox> sergiusens: what's causing a black screen broken right now, and how can I test/reproduce that?
[16:08] <sergiusens> cyphermox: being fixed now
[16:09] <sergiusens> didrocks: qml-phone-shell depends on the new hud... and that new hud is not in the prev ppa
[16:09] <sergiusens> didrocks: that's why
[16:09] <didrocks> sergiusens: you can have build-dep between ppas
[16:09] <didrocks> if it's what's missing
[16:09] <cyphermox> it's already set that way, actually
[16:09] <sergiusens> didrocks: but there's a new qt in that ppa and duplicate packages
[16:10] <cyphermox> phablet-team/ppa depends on daily-release-next
[16:10] <didrocks> sergiusens: in which ppa?
[16:10] <sergiusens> didrocks: daily-build-next
[16:10] <cyphermox> and what duplicate packages?
[16:10] <didrocks> for the new qt?
[16:10] <didrocks> sergiusens: so building the phone in daily-build-next will take that "duplicated qt"
[16:10] <didrocks> what's the difference?
[16:13] <sergiusens> cyphermox: that ppa dep was added yesterday... but I see your point
[16:14] <sergiusens> didrocks: only big difference I see is that people on desktop could add the daily-build-next ppa and not break there desktops
[16:14] <didrocks> sergiusens: those people already have the phablet ppa, right?
[16:15] <sergiusens> didrocks: phablet ppa breaks unity because it has that nux, osd, frame and grail mod
[16:15] <sergiusens> et.al.
[16:15] <didrocks> sergiusens: again, what is making pushing the phone-shell-qml in the daily-build-next ppa fixes magically osd, nux?
[16:16] <sergiusens> didrocks: again, qml-phone-shell does NOT depend on nux or osd
[16:16] <didrocks> sergiusens: so, why nux and osd from the daily-build-next is breaking their dekstop?
[16:16] <cyphermox> old stuff left around, my guess
[16:16] <didrocks> you are not giving all info
[16:16] <sergiusens> didrocks: the other way around
[16:16] <rsalveti> because they contain *huge* hacks
[16:17] <sergiusens> didrocks: if you add ppa:phablet-team tou your desktop, it will break
[16:17] <rsalveti> the qml-phone-shell can be part of the daily ppa afaik
[16:17] <rsalveti> I kind of expected that yesterday
[16:17] <rsalveti> was surprised it was not yet part of the new ci thing
[16:17] <didrocks> rsalveti: the discuss with the unity-next team meant by mid-may…
[16:17] <didrocks> rsalveti: would be great that you guys are aligned :)
[16:18] <didrocks> sergiusens: ah, I start to get you
[16:18] <didrocks> sergiusens: you can remove nux I guess?
[16:18] <didrocks> sergiusens: but yeah for notify-osd
[16:18] <rsalveti> from what I understand the mid-may thing is related with a new notify-osd and such
[16:19] <didrocks> rsalveti: not really, it's more with MIR
[16:19] <rsalveti> I'm just saying that I was expecting it to be tracked by the daily-next ci ppa as well
[16:19] <rsalveti> right, but is that blocking us?
[16:19] <cyphermox> rsalveti: didrocks: sergiusens: well, this doesn't need to be fixed today does it?
[16:19] <didrocks> rsalveti: at vUDS, WI was set and unity-next was dismissed remember? :)
[16:20] <cyphermox> we can discuss qml-phone-shell with the unity-next team next week and figure it out
[16:20] <rsalveti> as I remember one of the goals we had in mind was having a ppa people could use with x86, and I thought this daily-next would be it
[16:20] <rsalveti> that's why we don't have hacks there
[16:20] <didrocks> rsalveti: it should be the ubuntu-unity/next
[16:20] <didrocks> rsalveti: but for that, you need to have AP tests passing from ubuntu-unity/daily-build-next
[16:20] <rsalveti> cyphermox: no, all we need is https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603 to land
[16:20] <didrocks> which is the current issue
[16:21] <rsalveti> so the only thing that is blocking the qml-phone-shell is the test cases?
[16:21] <didrocks> rsalveti: the double AP thingy
[16:21] <cyphermox> rsalveti: that's completely unrelated to ubuntu-unity/daily-build-next containing lp:unity/phablet though; it only needs to take the PPA for building with hud-client2
[16:21] <didrocks> rsalveti: like for the apps
[16:21] <didrocks> rsalveti: this is what should make everything pass in the next ppa then
[16:21] <didrocks> rsalveti: which is the safe one
[16:21] <cyphermox> rsalveti: in other words, it's a CI configuration issue we can fix quickly
[16:22] <rsalveti> cyphermox: no, that's not what I wanted either, I'm just saying I was expecting qml-phone-shell to be landing at the daily-build-next ppa
[16:22] <rsalveti> which is not yet the case
[16:22] <cyphermox> rsalveti: full ack, I expected it as well
[16:22] <cyphermox> but I understand why it's not
[16:22] <didrocks> rsalveti: where did you read that qml-phone-shell would land?
[16:22] <didrocks> vUDS and other discussions with upstream shows that it wasn't supposed to be
[16:22] <cyphermox> didrocks: just logic since a lot of other stuff does
[16:22] <didrocks> yeah, but yesterday, we talked about communication
[16:23] <didrocks> this was communicated and part of the list ;)
[16:23] <rsalveti> and that we wanted a ppa with qml-phone-shell that people could install in their desktops
[16:23] <didrocks> anyway…
[16:23] <didrocks> rsalveti: ok, so if I follow you
[16:23] <rsalveti> the shell itself?
[16:23] <didrocks> you can remove nux from the phablet-team ppa
[16:23] <didrocks> isn't it?
[16:23] <didrocks> as it's not needed
[16:23] <rsalveti> we can't
[16:23] <didrocks> why?
[16:23] <rsalveti> it's needed for armhf
[16:23] <sergiusens> didrocks: it's needed on the device
[16:23] <rsalveti> and touch
[16:23] <didrocks> but without that nux
[16:23] <rsalveti> phablet-ppa will still contain a bunch of hacks for a while
[16:23] <didrocks> AP tests will never pass?
[16:24] <cyphermox> sergiusens: what is nux used for on the device?
[16:24] <rsalveti> didrocks: don't think so, as people are testing it in their own desktop
[16:24] <sergiusens> didrocks: nux and qml-phone-shell don't depend on eache other
[16:24] <sergiusens> cyphermox: didrocks nux and notify-osd do
[16:24] <didrocks> sergiusens: ahhhhhhhh
[16:24] <sergiusens> nux has a binding to the platform-api
[16:24] <cyphermox> ah
[16:24] <didrocks> phew, starting to make sense
[16:24] <cyphermox> so required for building platform-api
[16:24] <cyphermox> ?
[16:25] <didrocks> cyphermox: no, I think the other way around
[16:25] <rsalveti> so qml-phone-shell doesn't need to land *only* at phablet-ppa until we fix *everything*
[16:25] <didrocks> ok so
[16:25] <cyphermox> didrocks: well, that wouldn't make it a reason to have nux in the ppa though :)
[16:25] <rsalveti> it can land somewhere else, it just that we need the hackish stuff from phablet-ppa to have a working device
[16:25] <didrocks> I think "not breaking dekstop computers" is a good reason enough
[16:26] <didrocks> cyphermox: we'll need the double ppa anyway as long as this is not fixed
[16:26] <rsalveti> yup, that's fine
[16:26] <cyphermox> yeah
[16:26] <sergiusens> nux, frame, grail and notify-osd that live in ppa:phablet-team should stay there and live only there and NEVER be added to a desktop
[16:26] <cyphermox> ok
[16:26] <didrocks> so we can add it as it. I would just hope we can fix the AP issue which is what prevents us to have the safe "next" ppa
[16:26] <didrocks> sergiusens: but none of them are a dep of the qml phone shell?
[16:26] <didrocks> right?
[16:26] <sergiusens> didrocks: exactly
[16:26] <didrocks> and tests will happily pass without that?
[16:27] <cyphermox> well, currently daily-release-next works on desktop *and* on touch, correct? you just need to rebuild the shell on tablet?
[16:27] <rsalveti> didrocks: yup, and that's why you're able to have the shell in your desktop if you want
[16:27] <didrocks> ok, you are assuming we know the stack when we grasp some info there and there :)
[16:27] <didrocks> ok
[16:27] <didrocks> rsalveti: sergiusens: does the shell is parallely installable with unity?
[16:27] <didrocks> (like unity compiz)
[16:27] <rsalveti> probably, it's just one package
[16:27] <cyphermox> didrocks: yes, separate source and binary packages, unless there are file conflicts
[16:27] <rsalveti> Saviq might know more
[16:28] <cyphermox> I can test for file conflicts now, if it helps
[16:28] <didrocks> cyphermox: that would be awesome
[16:28] <sergiusens> didrocks: http://bazaar.launchpad.net/~unity-team/unity/phablet/view/head:/debian/control
[16:28] <rsalveti> didrocks: that's why I was kind of surprised to not see qml-phone-shell as part of daily-next, because in theory there's nothing blocking it
[16:28] <sergiusens> no nux or friends in there
[16:28] <rsalveti> didrocks: and as it needs the new hud now, it'd make sense for it to be there
[16:29] <didrocks> sergiusens: can be a runtime thing, we have more and more :)
[16:29] <didrocks> sergiusens: demo-assets?
[16:29] <didrocks> rsalveti: yeah, that's not what was communicated to me :)
[16:29] <didrocks> I'm pretty sure to have heard the libunity-core and nux thing
[16:29] <rsalveti> didrocks: I just thought it'd be part of the huge CI effort
[16:30] <sergiusens> didrocks: I'll tell you what... I'll get this tested on desktop
[16:30] <rsalveti> as people started taking care of a bunch of packages
[16:30] <rsalveti> and we didn't have a list of what would go in and what not
[16:30] <rsalveti> at least I didn't see that
[16:30] <rsalveti> so that's why I expected it to be as well
[16:30] <didrocks> sergiusens: I don't know about the demo-assets, maybe yet-another-component?
[16:30] <rsalveti> as this is kind of the most important package we have :-)
[16:30] <didrocks> rsalveti: the WI
[16:30] <didrocks> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-delivering-touch-apps-to-raring
[16:30] <sergiusens> didrocks: that should be removed from the deps most likely for a prod package...
[16:31] <didrocks> sergiusens: so, if the assets are not necessary, (for the tests maybe?), yeah would be good
[16:31] <rsalveti> didrocks: " The phone shell isn't scoped as well for now." - do you know why?
[16:31] <didrocks> sergiusens: last thing is libunity-core-6.0-dev
[16:31] <rsalveti> sorry didn't participate at this session
[16:31] <didrocks> sergiusens: I remember Saviq telling they forked it
[16:31] <cyphermox> I wish we got rid of installing the demo assets asap
[16:31] <sergiusens> didrocks: it's to fill in the lens with stuff for people doing the demos
[16:31] <didrocks> rsalveti: that was at the vUDS session, it was because of this discussion of forked nux, libunity-core and planning for mid-may
[16:32] <rsalveti> oh, but none of that were blockers =\
[16:32] <didrocks> rsalveti: hum, it is to be able to build it :) if libunity-core is still not compatible for instance
[16:32] <didrocks> basically they took libunity-core from quantal
[16:32] <didrocks> patched it
[16:32] <rsalveti> didrocks: well, as I said, people were testing that stuff in their own desktop
[16:33] <sergiusens> didrocks: unity core would be the only one... but they were working on that... I'll test on desktop and come back to you
[16:33] <rsalveti> yeah
[16:33] <didrocks> rsalveti: sergiusens: yeah, seems it's the best thing to do
[16:33] <didrocks> sergiusens: rsalveti: the deps should maybe be set as recommends?
[16:33] <sergiusens> didrocks: last month Saviq told me they already had the split package thing going
[16:33] <didrocks> all the indicator-* we don't have
[16:34] <rsalveti> cool
[16:34] <rsalveti> so it *might* be possible to migrate it to daily-next
[16:35] <didrocks> rsalveti: yeah, this libunity-core is the last thing we need to have confirmed
[16:35] <rsalveti> let's make sure it lands today at phablet-team/ppa and we can work this migration tomorrow/next week
[16:35] <didrocks> and then, we can remove demo-assets and downgrade some deps to recommends
[16:35] <rsalveti> cool
[16:35] <didrocks> + change any to list everything but powerpc
[16:35] <sergiusens> ack
[16:36] <didrocks> rsalveti: sergiusens: ok, keep me posted with this libunity-core, then, we are going to propose the other changes and have it landing
[16:36] <didrocks> rsalveti: sergiusens: I just want to discuss with Saviq first about it :)
[16:36] <rsalveti> didrocks: sure
[16:37] <sergiusens> didrocks: sure... I don't plan on doing anything without Saviq's blessing
[16:37] <didrocks> sergiusens: rsalveti: I wonder if we shouldn't have a 15 minutes daily meeting until everything is in after the sprint, it seems there are so many things that are not fully communicated
[16:37] <rsalveti> sergiusens: sorry asking you again, but what is blocking https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603 to land?
[16:37] <rsalveti> didrocks: could be
[16:37] <sergiusens> rsalveti: nothing now
[16:38] <sergiusens> rsalveti: the Work in progress needs to change...
[16:38] <rsalveti> sergiusens: alright
[16:38] <sergiusens> rsalveti: changed it to needs review
[16:38] <rsalveti> guess will just approve it
[16:38] <rsalveti> Saviq seems to be off
[16:39] <rsalveti> tested here and could get the shell installed and up at least
[16:40] <rsalveti> happroved, will see what happens
[16:40] <sergiusens> rsalveti: hmmmm
[16:40] <rsalveti> sergiusens: any issue?
[16:41] <rsalveti> just want to unblock the image first
[16:42] <sergiusens> rsalveti: ok... just read the comments in the MR ;-)
[16:42] <rsalveti> sergiusens: the issue is temporary ;-)
[16:42] <rsalveti> we fixed it, and I trust you that you fixed jenkins as well :P
[17:09] <cyphermox> rsalveti: sergiusens: so lp:unity/phablet can't land at all; it necessarily breaks desktop to do so since I'd need to build/ship lp:unity/phablet-mods, which lp:unity/phablet depends on for UnityCore/PeoplePreview.h
[17:10] <rsalveti> cyphermox: how people test that on desktops then?
[17:10] <cyphermox> test what?
[17:10] <rsalveti> qml-phone-shell
[17:10] <cyphermox> beats me
[17:10] <cyphermox> they totally break unity in the process
[17:10] <rsalveti> urgh
[17:10] <cyphermox> or maybe by pure luck unity still works :)
[17:10] <sergiusens> cyphermox: good, but bad as well... let me circle back on this one
[17:11] <rsalveti> yeah
[17:11] <didrocks> so that was what I heard on the -core one…
[17:11] <cyphermox> basically, that unity-core is based on quantal's
[17:12] <cyphermox> didrocks: should I bother seeing if I can convince it to build against the current libunity-core?
[17:13] <didrocks> cyphermox: Saviq told me it was hard, so it seems nothing really changed there
[17:14] <cyphermox> didrocks: well it's just the people preview stuff, surely it can be ripped out :)
[17:19] <didrocks> :)
[17:20] <cyphermox> Saviq: did you look at porting qml-phone-shell to use the libunity-core we have in raring (7.0 basically) before?
[18:00] <renato> sil2100, any news about the new hud package? I am having problems to test the media-player app
[18:00] <renato> I can not find the package
[18:26] <sil2100> renato: hi!
[18:26] <sil2100> renato: hm, what PPA and what media-player version are you using? And what's the problem?
[18:27] <renato> sil2100, I am using the media-player from source
[18:27] <renato> sil2100, its depends on qtdeclarative5-hud1.0, which I can not find
[18:27] <sil2100> renato: do you have the https://launchpad.net/~ubuntu-unity/+archive/daily-build-next PPA enabled?
[18:28] <sil2100> You can find that package there, it's being built per-daily
[18:29] <renato> sil2100, ok I check this,
[18:31] <sil2100> renato: tell me later if there's still a problem
[22:15] <davidcalle> mhr3, so where are you these days, London?
[22:16] <mhr3> davidcalle, the lack of comments is scary
[22:17] <mhr3> all those re.sub are #magic here
[22:17] <davidcalle> mhr3, well, they are :P
[22:17] <davidcalle> Faire enough *adding comments*
[22:17] <davidcalle> fair*
[22:17] <mhr3> davidcalle, and yea, i'm in london
[22:18] <mhr3> cause you know i live here now :)
[22:23] <davidcalle> mhr3, I wasn't sure you were there full time :) (mp updated)