[08:22] <Saviq> mzanetti, you looking at the packaging cleanup?
[08:24] <mzanetti> Saviq: yeah.
[08:27] <Saviq> mzanetti, cool, let me know if you need help there
[08:29] <Saviq> mzanetti, it looks like we could not install some of them (like Utils, do we need them installed?)
[08:29] <Saviq> mzanetti, and then they're installed into $LIBDIR/qml/ directly - instead of $LIBDIR/qml/plugins
[08:29] <Saviq> I'm good with leaving mocks under $LIBDIR/qml/mocks
[08:30] <Saviq> as the real implementations will be installed into $LIBDIR/qml/plugins
[08:31] <Saviq> didrocks, question: the ${SHELL_PRIVATE_LIBDIR} - is it ok that other packages would install there (the shell-facing plugins should not be on the system-wide import path)
[08:31] <Saviq> didrocks, and how do we communicate that path to others? cmake module or can we do with a .pc file?
[08:32] <didrocks> Saviq: you mean, like plugins? in qml/ ?
[08:32] <Saviq> didrocks, yes
[08:32] <didrocks> yeah, it's fine
[08:32] <didrocks> Saviq: .pc file if you want more widespread support, I'm fine if you just provide a cmake modules to force the others to use cmake though
[08:32] <Saviq> didrocks, evil :D
[08:33] <didrocks> heh :)
[08:33] <didrocks> Saviq: what about qml/plugins/ ?
[08:33] <didrocks> Saviq: I saw that qml modules for Qt are under qml/
[08:33] <Saviq> didrocks, everything should be under qml/{plugins,imports,modules}
[08:33] <Saviq> didrocks, we'll fix that in the branch
[08:34] <didrocks> Saviq: hum, it's not how it is in /usr/lib/x86_64-linux-gnu/qt5/qml/?
[08:34] <didrocks> everything is under qt5/{qml/plugins,imports,modules}
[08:34] <didrocks> oups
[08:34] <didrocks> everything is under qt5/{qml,plugins,imports,modules}
[08:34] <Saviq> didrocks, I know
[08:34] <Saviq> didrocks, you're right
[08:35] <Saviq> didrocks, we probably only want the separation in code
[08:35] <Saviq> aah wait
[08:35] <didrocks> Saviq: so, following that schema in file system? (I think it's better if we folllow what Qt is doing) :)
[08:35]  * Saviq is lost
[08:36] <didrocks> Saviq: I think your case is more plugins, so you should ship them in /usr/lib/x86_64-linux-gnu/unity8/plugins
[08:36] <didrocks> (not qml/, that's why I tried to tell yesterday :p)
[08:36] <didrocks> apart if those plugins are qml modules
[08:36] <didrocks> and so /usr/lib/x86_64-linux-gnu/unity8/qml
[08:36] <didrocks> does it make sense?
[08:37] <sil2100> bregma: ping :)
[08:37] <Saviq> didrocks, well, qt5/imports only have Qt labs and QtWebKit for qml
[08:37] <Saviq> didrocks, the rest is under qml
[08:37] <didrocks> Saviq: those are modules exposed to qml, right?
[08:38] <Saviq> didrocks, anything that has a "qmldir" file, yes
[08:38] <didrocks> ok :)
[08:38] <didrocks> so /usr/lib/x86_64-linux-gnu/unity8/qml/ I guess for your modules, as it is today?
[08:38] <Saviq> didrocks, yes
[08:38] <Saviq> didrocks, not sure why the separation to imports
[08:38] <didrocks> Saviq: yeah, it's the shadow part for me TBH :)
[08:38] <Saviq> didrocks, after all, you don't want two things installed in parallel in plugins and modules
[08:39] <didrocks> right
[08:39] <Saviq> didrocks, as then you can't foresee the priority order
[08:39] <didrocks> /usr/lib/x86_64-linux-gnu/unity8/plugins/ would be Qt-only plugins, right?
[08:39] <didrocks> (not exposed to qml)
[08:39] <paulliu> pstolowski: hi.. I think I got empty actions list when using previewData.actions.
[08:39] <Saviq> didrocks, yeah
[08:39] <didrocks> Saviq: at least, we agree on our understanding of the current layout, not that bad :p
[08:39] <Saviq> didrocks, :)
[08:40] <didrocks> did you see my email? ok for unity-api and unity8 being in the same stack for the time being?
[08:40] <didrocks> and you will dep on platform-api, so depending on platform stack
[08:40] <pstolowski> paulliu: hi, is your branch the same as yesterday?
[08:41] <paulliu> pstolowski: no.. let me push it..wait
[08:47] <Saviq> didrocks, +1, didn't read through it yet, but what you say makes sense
[08:47] <Saviq> didrocks, did you see http://code.launchpad.net/unity8 btw? ;)
[08:48] <didrocks> Saviq: oh I didn't \o/ awesome :)
[08:48] <Saviq> didrocks, we're going to do a smooth transition, ok? as in we'll wait for most of the MRs against lp:unity/8.0 to land
[08:48] <Saviq> didrocks, but propose new ones against lp:unity8
[08:48] <Saviq> didrocks, and sync across
[08:49] <didrocks> Saviq: hum, I think it's possible to retarget automatically the MP
[08:49] <paulliu> pstolowski: lp:~paulliu/unity/activate1
[08:49] <didrocks> Saviq: have you already diverged?
[08:49] <Saviq> didrocks, no
[08:49] <Saviq> didrocks, no divergence planned
[08:49] <didrocks> Saviq: let me have look then
[08:49] <dednick> Saviq: have we got a coding style doc for unity8?
[08:49] <Saviq> didrocks, let me make sure
[08:50] <Saviq> dednick, not yet, I'm afraid
[08:50] <Saviq> dednick, for C++ we'll probably go for Qt code, as like 99% of what we're doing is Qt
[08:50] <Saviq> s/code/style/
[08:50] <didrocks> Saviq: yeah, your latest commit is in
[08:50] <dednick> Saviq: aiight
[08:51] <Saviq> dednick, for QML we're going for Qt, too (as there isn't anything else)
[08:51] <didrocks> Saviq: so, let me try something *crazy* :)
[08:51] <dednick> Saviq: so basically all just qt style :)
[08:51] <Saviq> dednick, yeah, we're a full-on Qt app, don't see a reason to diverge
[08:52] <Saviq> didrocks, synced
[08:52] <didrocks> Saviq: ok, one sec!
[08:52] <pstolowski> paulliu: ok, looking... afacit it works with your yesterday's code (just checked; after changing that one line to "text: modelData.displayName")
[08:55] <pstolowski> paulliu: I'm getting " ReferenceError: grid is not defined" with your branch
[08:56] <pstolowski> paulliu: and according to your debug, I get [PreviewAction(0x3c24da0)]
[08:57] <didrocks> Saviq: grrr, changing the branch between projects seem to forget all MP :/
[08:57] <didrocks> Saviq: it's working when you rename the branch
[08:57] <didrocks> like ~foo/bar/test1 to ~foo/bar/test2
[08:57] <Saviq> didrocks, :/
[08:57] <didrocks> (it retargets the MP)
[08:57] <Saviq> didrocks, yeah, let's go manual
[08:58] <didrocks> but not from one project to another
[08:58] <didrocks> Saviq: yeah, I have reverted…
[08:58] <Saviq> didrocks, it'll be fine, we'll do dailies from lp:unity8
[08:58] <Saviq> didrocks, and I'll sync everything up from lp:unity/8.0
[08:59] <didrocks> Saviq: hum ok, the changelog generation will be weird though at first
[08:59] <didrocks> Saviq: as we won't list everything (as we merge/resync from another branch)
[08:59] <Saviq> didrocks, won't it always
[08:59] <Saviq> didrocks, that's fine
[08:59] <didrocks> just cosmetic TBH, be te be aware of :)
[08:59] <didrocks> to*
[09:00] <didrocks> Saviq: ok, once my packaging branch is merged with your changes, we can daily release to the next ppa
[09:00] <Saviq> didrocks, yay!
[09:00] <Saviq> mzanetti, no pressure ↑ :D
[09:00] <didrocks> :)
[09:00] <didrocks> ahah
[09:02] <paulliu> pstolowski: hmm.. that's strange. I got empty on my compuiter.. I'll check it.. Thanks.
[09:04] <pstolowski> paulliu: what about my grid error, did you push all your code?
[09:04] <paulliu> pstolowski: yeah.. sorry, that's my mistake.. I'll fix it.
[09:12] <didrocks> Saviq: I see unity-notifications in the mir stack, shouldn't it be in the shell one?
[09:15] <Saviq> didrocks, it sure should
[09:30] <MCR> didrocks, hi. During my cleanup of Expo ( http://bazaar.launchpad.net/~compiz-team/compiz/0.9.10/revision/3740 ) I fixed the "One big wall"  mode, which was ignored for several Ubuntu versions, but was default...
[09:31] <didrocks> MCR: great :)
[09:31] <didrocks> it's a keybinding?
[09:31] <MCR> So I changed the default for Ubuntu back to "One wall per output" now, so nothing will change
[09:31] <MCR> No, it is the default setting
[09:31] <didrocks> MCR: ah, excellent, thanks for taking care of that, did you migrate the data as well?
[09:32] <didrocks> using dh-migration?
[09:32] <didrocks> or maybe we don't need to, as it's gsettings, ignore me :)
[09:32] <MCR> Yes, quilt is my friend -> no, just with quilt
[09:32] <MCR> didrocks, here is the fix: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1074487-expo-xml-fixes/+merge/171484
[09:32] <MCR> It just needs approval (also cleans up and fixes other CCSM Expo stuff)
[09:33] <didrocks> MCR: hum, you remove other settings apparently
[09:33] <MCR> No
[09:33] <didrocks> like shortcuts, and so on?
[09:33] <MCR> No
[09:33] <MCR> All is the same like it was -> that is the purpose
[09:33] <MCR> I do not want to shock any multi-monitor user
[09:34] <MCR> because in 0.9.10 they will otherwise have "One big wall"
[09:34] <MCR> which is the better mode, but not always
[09:34] <MCR> so the user should have to choose it manually
[09:34] <didrocks> MCR: but what about the timing?
[09:34] <didrocks> --    <default>0.10</default>
[09:34] <didrocks> 72-+    <default>0.2</default>
[09:34] <didrocks> did you change that back somewhere else? (not the wall expo, but the other mode?)
[09:34] <MCR> It was the quilt design by Ubuntu
[09:35] <didrocks> ah, it's below, sorry
[09:35] <MCR> Do not worry, I am a quilt Pro now ;)
[09:35] <didrocks> confusing diff, thanks quilt :)
[09:35] <MCR> Well, I also shuffled one setting (moved it where it belongs -> Curve strength)
[09:36] <didrocks> MCR: yeah, I saw that
[09:36] <didrocks> looks fine, and thanks for taking care of that :)
[09:36] <didrocks> MCR: approved
[09:36] <MCR> thx
[09:37] <MCR> didrocks, I am taking care with all the patches to not change anything for Ubuntu unless I talked with design
[09:37] <didrocks> MCR: yeah, thanks for that!
[09:37] <MCR> didrocks, thx 4 your fast responses
[09:37] <MCR> they are highly appreciated
[09:38] <didrocks> thanks for your work ;)
[09:38] <MCR> I am on SSD, so I do not have place for too many MPs
[09:38] <MCR> ;)
[09:38] <MCR> didrocks, unfortunately OpenGL and GLES are still quite hard for me, even with thick books
[09:39] <didrocks> MCR: well, it's coming with time :)
[09:39] <MCR> sure
[09:39] <didrocks> my SSD is quite large
[09:39] <didrocks> like 120G IIRC
[09:39] <mlankhorst> that's large? o.O
[09:40] <didrocks> mlankhorst: that's enough for my hacking needs :)
[09:40] <mlankhorst> I was considering upgrading to a 512G one out of laziness
[09:40] <MCR> I have 256, but 2 partitions and Swap...
[09:40] <MCR> A RAID5 with 20 disks would be nice
[09:41] <MCR> http://www.youtube.com/watch?v=26enkCzkJHQ&fmt=18
[09:42] <MCR> mlankhorst, ^^ -> this is what one needs
[09:42] <MCR> :)
[09:45] <mlankhorst> I need 0 db from spinning components
[09:46] <MCR> mlankhorst, unfortunately I still need those spinning TBs
[09:46] <MCR> but the 0db argument is something I can understand, since I am building low-noise machines since years
[09:46] <mlankhorst> I still have one :-)
[09:47] <mlankhorst> but I put my music on it
[09:47] <MCR> and mechanics should be finally banned from machines ;)
[09:47] <mlankhorst> and I use dynamic spindown so when I'm not listening to music it turns off
[09:48] <MCR> where do you configure this dynamic spindown ?
[09:49] <mlankhorst> 'sudo hdparm -S 10 /dev/sdb' when system boots somewhere
[09:50] <mlankhorst> or maybe just hdparm -S 10 /dev/sdb in /etc/rc.local, it spinsdown the disk after 10 * 5 seconds
[09:50] <MCR> mlankhorst, cool -> noted
[09:51] <mlankhorst> and mount with noatime if you don't need it, else the reads from cache may cause the disk to spin up :/
[09:52] <mzanetti> Saviq: do you have any specific changes in mind for the packaging cleanup? Or should I just make sure everything still works?
[09:53] <Saviq> mzanetti, I thought you wanted to consolidate the mocks?
[09:53] <mzanetti> Saviq: ah, directly into this merge?
[09:53] <Saviq> mzanetti, yes
[09:53] <MCR> mlankhorst: ok, thx a lot -> the 7200rpm from Samsung is the only thing making low noise here...
[09:53] <Saviq> mzanetti, since it deals with those files already
[09:54] <mzanetti> Saviq: is didrocks comment referring to that?
[09:54] <Saviq> mzanetti, that, too, we probably need to update paths.h, too
[09:55] <Saviq> at least
[09:55] <Saviq> mzanetti, and prepend private libdir, append mocks to import path
[09:56] <Saviq> mzanetti, as we want the private libdir to be the place where others install shell-facing plugins
[09:56] <sil2100> didrocks: I found the problem with show_desktop, I think I know what to revert to fix the issues - I'll quickly check if we can fix it differently and if not, I'll try reverting
[09:57] <sil2100> didrocks: Brandon made a fix to show_desktop behavior a few days ago, and it broke the show_desktop mode a bit
[09:57] <didrocks> sil2100: yeah, saw your email, excellent!
[09:57] <sil2100> didrocks: unity thinks it's in show_desktop mode when all windows are minimized
[09:57] <didrocks> sil2100: it's going to be another revert on brandon's credit :p
[09:58] <didrocks> sil2100: on my side, I'm running the mir and unity8 stack (everything but unity8 itself)
[09:58] <didrocks> and releasing that in -next
[09:58] <didrocks> crossing fingers :)
[09:58] <sil2100> Oooh :) \o/
[10:01] <MCR> This is now possible with Expo in 0.9.10: https://bugs.launchpad.net/compiz/+bug/1009592/+attachment/3687163/+files/Expo-2screens-different-resolution-very-usable_scaled_down.png
[10:02] <MCR> 4x 3200x1200 wallpapers :)
[10:06] <didrocks> MCR: heh, nice ;)
[10:13] <Saviq> dednick, there's a small conflict in paths.h.in now that the merge went in
[10:15] <dednick> Saviq: ok, i'll fix it in a minute
[10:15] <Saviq> dednick, cheers
[10:24] <Saviq> greyback, I love your LVWPH test qml... it's alive!
[10:24] <greyback> Saviq: quite hypnotic, yes :)
[10:26] <Saviq> dednick, "MenuContent.qml:182: TypeError: Object IndicatorsDataModel_QMLTYPE_87(0x1d00500) has no method 'get'"
[10:26] <Saviq> dednick, feels like this needs to be addressed with the removal of the get methods
[10:27] <Saviq> dednick, if you want, just bring the get() back for now and we'll replace with data(int, int) later
[10:29] <dednick> Saviq: ah. well that line is easy to fix.
[10:29] <dednick> just missed it
[10:29] <Saviq> dednick, k
[10:46] <MCR> sil2100, didrocks: Why is Saucy still using Compiz 0.9.9 ? Will there not be a daily Compiz version for Saucy, or is it not ready yet ?
[10:46] <MCR> sil2100, hi, btw ;)
[10:47] <mhr3_> sil2100, ping?
[10:48] <sil2100> MCR: hi! We disabled daily releasing for compiz, since it wasn't quite ready for that back in the past - we'll have to check how things are looking right now
[10:48] <sil2100> mhr3_: pong
[10:49] <MCR> sil2100, there are a ton of fixes in 0.9.10 ;)
[10:50] <MCR> and a lot is planned: https://launchpad.net/compiz/+milestone/0.9.10.0
[10:50] <mhr3_> sil2100, i think unity is abi broken in the ppa, we inadvertently broke the ABI of the protocol library, then unity got build with that, and now we fixed it back in the proto lib
[10:50] <mhr3_> sil2100, is that a problem, or will everything get properly rebuild once it'd go to distro?
[10:51] <mhr3_> the fix is simple though - rebuild unity with trunk libunity
[10:54] <MCR> sil2100, the problem is: Compiz 0.9.10-dev  has no testers and no PPA, not on Raring and not on Saucy -> this is really a showstopper
[10:55] <MCR> a lot of bugs are fixed and just need confirmation that they are, but without any testers this is hard to get
[10:59] <MCR> sil2100, may I quote you in a bug report/feature request ?
[11:01] <MCR> bug #1193619
[11:01] <sil2100> mhr3_: hmmm, let me understand the situation better - so, unity needs a rebuild with libunity trunk to work now, yes?
[11:01] <sil2100> MCR: no problem
[11:01] <MCR> thx
[11:01] <mhr3_> sil2100, right
[11:01] <sil2100> MCR: let me bookmark that bug, I'll update it once I know what's up
[11:01] <MCR> quoted
[11:01] <mhr3_> sil2100, unity in the ppa
[11:01] <MCR> sil2100, thanks a lot
[11:02] <MCR> sil2100, I would not press so much if it would not be really important ;)
[11:02] <MCR> I know Unity8 has the focus now, but I still hope for some co-existence :)
[11:03] <sil2100> mhr3: ok, hm hm, so actually we'll have to modify the lp:unity deps on libunity as well for everything to work properly, right?
[11:05] <mhr3> sil2100, well, it was a temporary break, unity in S is ABI compatible with trunk libunity
[11:07] <sil2100> mhr3: hm, ok, but we still need to make sure that all the 'in-between' cases are handled, so it's best if we make sure we depend on the right versions on both sides
[11:08] <mhr3> sil2100, that means bumping debian libunity version and making unity dep on that?
[11:08] <sil2100> mhr3: did we release libunity with that temporary ABI break? When was that made?
[11:08] <mhr3> sil2100, release in S? no
[11:09] <sil2100> mhr3: could you point me to the commit with that?
[11:09] <mhr3> sil2100, 242 broke it, 246 reverted the break
[11:09] <sil2100> Ah, I think I see it
[11:25] <sil2100> mhr3: as for the debian libunity version, yes, that seems to be the safest way of doing that ;/ Since otherwise yes, sooner or later it might stabilize itself and we'll have unity building with the correct libunity, but we should always ensure that any changes to the ABI are version-bumped and properly depped
[11:25] <sil2100> mhr3: we could build-dep on the daily-build-bleble version, but that doesn't look that nice
[11:26] <sil2100> mhr3: so usually I would recommend another (sadly) version bump on the libunity version and changing unity to build-dep on that
[11:26] <sil2100> didrocks: right? ^
[11:27] <didrocks> sil2100: hum, depends, the libunity version with the revert is already in the PPA?
[11:28] <dednick> Saviq: ping
[11:28] <Saviq> dednick, pong
[11:28] <mhr3> didrocks, yes
[11:28] <sil2100> didrocks: not yet, as the revert happened 1 hour ago
[11:28] <dednick> Saviq: what image provider do we use for gicon loaded images?
[11:28] <didrocks> sil2100: we can as well, rebuilding just libunity
[11:28] <Saviq> dednick, GIconProvider
[11:28] <Saviq> dednick, from Ubuntu.Components
[11:28] <didrocks> and then, any new unity coming into the ppa will use this reverted libunity
[11:28] <Saviq> dednick, http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/plugin/giconprovider.cpp
[11:28] <dednick> Saviq: ah. i c.
[11:28] <mhr3> oh right, ppa builds are once a day, so no, it's not there yet
[11:29] <mhr3> or depends which ppa, i guess :P
[11:29] <sil2100> didrocks: ok, so it's allowable?
[11:29] <didrocks> mhr3: daily build as a hint in the machine :p
[11:29] <didrocks> sil2100: yeah, if the revert really reverts to previous published ABI :)
[11:30] <sil2100> didrocks: since whenever there's an ABI break, (even if it's a revert ;p) I tend to think about safty of ABI's in deps ;)
[11:31] <sil2100> mhr3: ok, I guess I'll do as didrocks mentions - I'll push libunity to the PPA, and then force a rebuild of unity (or wait for tomorrow even)
[11:31] <mhr3> sil2100, i think just waiting for tomorrow will fix it
[11:32] <mhr3> there's already a branch proposed for unity and once that is merged things will be compatible again :)
[11:34] <sil2100> Ok, so I'll just rebuild libunity so that unity uses the libunity trunk (since without the deps changed, it might build against the old libunity still)
[11:35] <didrocks> yep :)
[11:55] <Saviq> dednick, another instalment of the indicators review came ;)
[11:59] <dednick> Saviq: thanks :)
[12:17] <dpm> mhr3, ok, I've updated the online docs from the Unity 7 .gir file on d.u.c -> http://developer.ubuntu.com/api/devel/ubuntu-13.10/c/Unity-7.0.html
[12:19] <dpm> mhr3, however, I see no comments at all other than listing of members. I seem to remember there was a bug in valadoc whereby the apidoc comments were not being forwarded to the .gir file. Is this the case, or is it just that there is no documentation at all for the Unity API?
[12:45] <sil2100> didrocks: https://code.launchpad.net/~sil2100/unity/revert_r3380_showdesktop/+merge/171781 <- this revert should help
[12:45] <sil2100> I couldn't check that for sure, since my system still can't build packages properly
[12:45] <sil2100> (unity is always broken then, need to investigate finally)
[12:45] <sil2100> And the testing PPA still didn't build the package ;/
[12:49] <MCR> sil2100, I tuned Compiz' showdesktop plugin -> this works and has much more "FlashBoomBang" :) -> https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1161343-showdesktop-needs-random-movement-direction-option
[12:50] <MCR> sil2100, I'm just joking - I know you do not want to much "FlashBoomBang" ;) -> but it is still worth a try ;)
[12:50] <MCR> *too much
[12:53] <sil2100> hmmm ;)
[12:54] <MCR> I recommend the "Fully random direction" mode, it moves all of the windows out of the way in a really cool way ;)
[12:59] <sil2100> andyrock: https://code.launchpad.net/~sil2100/unity/revert_r3380_showdesktop/+merge/171781 <- could you take a look?
[13:00] <sil2100> MCR: I'll try that out ;) I don't use the showdesktop plugin normally, since I don't use show desktop almost ever ever ;)
[13:00] <sil2100> (that's what happens when you don't use the desktop at all)
[13:00] <andyrock> sil2100, sure
[13:01] <andyrock> sil2100, can you change the bug status from "fix com" to "triaged" once your branch gets merged?
[13:02] <sil2100> andyrock: ACK! I hope this fixes it ;p
[13:02] <sil2100> andyrock: (since as I mentioned to didrocks, I couldn't get my built unity to work properly again) ;)
[13:04] <dpm> hi sil2100, we talked a few days ago about a change to libunity to land in order to be able to publish the scopes tutorial. It seems it's been a few days and that change is not yet in the archive as far as I can tell. Could you help me with some estimation on when this change will be available as a package on the archive? -> http://bazaar.launchpad.net/~unity-team/libunity/trunk/revision/240 - Thanks!
[13:04] <dpm> mhr3, ^
[13:05] <sil2100> dpm: hi! Right! Sorry about that, since we were able to get stuff working but then a regression struck us and we couldn't verify the state of the stack, so we couldn't release
[13:05] <sil2100> dpm: the merge I proposed *should* resolve that, and we would probably be able to release soon
[13:06] <sil2100> dpm: as for an estimate... hmm, we could try releasing today if the merge wents in
[13:06] <sil2100> dpm: let me get back to you after lunch
[13:06] <dpm> sil2100, thanks. Let's sync up later then, it'll help me make a decision on whether I should add a workaround in the tutorial or not
[13:13] <seb128> pete-woods, hey
[13:15] <seb128> pete-woods, just as a fyi, I got accountsservice updated in saucy, including desrt's patches for what you need (if I'm not mixing people and pinging the wrong person ;-)
[13:15] <seb128> pete-woods, https://launchpad.net/ubuntu/+source/accountsservice/0.6.34-0ubuntu1
[13:18] <didrocks> fginther: hey, around?
[13:18] <fginther> didrocks, good morning!
[13:19] <didrocks> fginther: good morning ;) can you have a quick look on the upstream merger configuration for https://code.launchpad.net/~didrocks/cupstream2distro-config/add-mir-unity8/+merge/171749 please?
[13:19] <fginther> didrocks, yes
[13:19] <didrocks> thanks!
[13:22] <dandrader> dednick, updated the dragHandle merg proposal
[13:27] <dandrader> Saviq, so lp:unity8 is ~didrocks/unity8/trunk ?
[13:27] <Saviq> dandrader, no, didrocks, did you break it ^?
[13:27] <Saviq> dandrader, should be ~unity-team
[13:28] <Saviq> didrocks, you! :P
[13:28] <mzanetti> Saviq: took me longer than I hoped, but the mocks/fakes are merged and paths.h adjusted
[13:28] <Saviq> mzanetti, cool
[13:30] <Saviq> dednick, standup?
[13:31] <didrocks> Saviq: hem
[13:31] <didrocks> hem hem hem :p
[13:31] <fginther> didrocks, one comment
[13:31] <didrocks> Saviq: I had to repush the branch after my trial this morning
[13:31] <didrocks> Saviq: and seems then, I autotyped :p
[13:32] <didrocks> Saviq: dandrader: fixed
[13:33] <Saviq> didrocks, thanks
[13:33] <didrocks> I'm so disappointed that changing the trunk didn't work :/
[13:33] <didrocks> I had great hope in launchpad, as you can rename branch…
[13:33] <Saviq> Cimi, you need to be aware of https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/simple_theming
[13:33] <didrocks> fginther: nice catch!
[13:34] <didrocks> fginther: pushed
[13:35] <pete-woods> seb128: cool, thanks!
[13:46] <mzanetti> Saviq: now that you brought it up. I changed the dep to qtubuntu to this: qtubuntu [armhf]
[13:46] <mzanetti> Saviq: so now we can install the package on desktop again and it uses the the fake_qtubuntu from unity8-private
[13:47] <Saviq> mzanetti, yup, cool
[13:47] <mzanetti> Saviq: I think its ready for you to give it another look and then merge. didrocks changes all make sense I think.
[13:48] <mzanetti> maybe we could drop the qml-phone-shell transition packages?
[13:48] <mzanetti> or too early?
[13:48] <mzanetti> didrocks: ^, your opinion?
[13:48] <Saviq> didrocks, what do you think ↑ can we drop the transitional qml-phone-shell packages?
[13:48] <Saviq> mzanetti, I will now
[13:49] <didrocks> Saviq: mzanetti: I'm totally fine for dropping them, I didn't dare, but secretly hoped for this ;)
[13:49] <didrocks> the less clutter, the better :p
[13:49] <mzanetti> +1
[13:49] <Saviq> didrocks, mzanetti DO IT!
[13:49] <didrocks> so all transition packages, breaks/conflicts you can remove ;)
[13:50]  * mzanetti is on it
[13:50] <didrocks> \o/
[13:51] <nic-doffay> Saviq, trying to think of how I can implement the UbuntuShape into the Option-Selector.
[13:51] <nic-doffay> Any ideas.
[13:52] <Saviq> nic-doffay, will have something in a bit
[13:53] <Saviq> nic-doffay, am working on something similar now for the shell
[13:53] <nic-doffay> Saviq, cool.
[13:53] <mzanetti> lol... "/$BINARY\\\\\|qml-phone-shell/d"
[13:54] <mzanetti> moar escaping
[13:54] <Saviq> mzanetti, indeed
[13:54] <Saviq> mzanetti, that was trial'n'error
[13:54] <mzanetti> :D
[13:54] <Saviq> mzanetti, don't ask me what's happening there, but it works
[13:54] <mzanetti> I managed to read it
[13:54] <mzanetti> well, sort of
[13:55] <Saviq> nic-doffay, for now a hack like so http://pastebin.ubuntu.com/5780204/plain/ is needed
[13:57] <dobey> is the dash in lp:unity/8.0 supposed to be completely broken at the moment?
[13:57] <mzanetti> dobey: hmm... not that I know of
[13:58] <mzanetti> works fine here
[13:58] <dobey> when i ./run, and slide from the right edge to open it, it's completely empty, and i can't close it or anything
[13:59] <kgunn> dobey: are you on saucy ?
[14:00] <mzanetti> dobey: works fine here - yeah, as kgunn said, we're working on saucy. might not work on raring any more by now
[14:00] <dobey> kgunn: yes, it's on a saucy vm
[14:00] <dobey> yeah it won't run on raring at all becasue the required things aren't packaged for it apparently, and it's not pulling/building them all from source
[14:01] <mzanetti> just noticed that the video lens actually shows my videos now \o/
[14:02] <nic-doffay> Saviq, we can't really commit that to the SDK though.
[14:03] <Saviq> nic-doffay, we have no other choice, it was recommended to me by the SDK team ;)
[14:03] <Saviq> nic-doffay, just wrap in FIXMEs
[14:03] <Saviq> nic-doffay, and when the new UbuntuShape lands
[14:03] <Saviq> they will fix
[14:04] <didrocks> fginther: thanks!
[14:04] <fginther> didrocks, no problem
[14:06] <nic-doffay> Saviq, so that basically hides the image then?
[14:06] <Saviq> nic-doffay, in that case the image, yes
[14:07] <dobey> mzanetti: http://ubuntuone.com/4VckwwoEdpqP6lBgZWX3qV is what i get
[14:07] <Saviq> nic-doffay, but ShaderEffectSource can get any item
[14:07] <Saviq> nic-doffay, and becomes the source for the Shape
[14:08] <dobey> WARN  2013-06-27 10:00:59 unity.dash.gsettingsscopereader GSettingsScopes.cpp:108 Error fetching protocol metadata for scope: home.scope : Valid key file could not be found in search dirs
[14:08] <dobey> maybe because of that though?
[14:10] <nic-doffay> Saviq, any idea when the new UbuntuShape lands btw?
[14:10] <Saviq> nic-doffay, nope
[14:10] <dobey> i wonder where it's looking for those files at
[14:11] <mzanetti> dobey: maybe try removing the builddir and run ./build again?
[14:12] <kgunn> dobey: not sure...but i recently updated the wiki
[14:12] <kgunn> http://unity.ubuntu.com/getinvolved/development/unity8/
[14:12] <mzanetti> dobey: or did you freshly check out and build this?
[14:12] <kgunn> might blow away your unity dir & re-branch a new one
[14:12] <dobey> i'll try to rm builddir, but it did it when it was a fresh checkout the other day too
[14:13] <kgunn> dobey: ./build -c -s will blow away builddir
[14:13] <kgunn> if you just want to try that first
[14:13] <mzanetti> also make sure your saucy is dist-upgraded recently
[14:13] <kgunn> also....watch the scroll by when you run ./build -c -s
[14:13] <kgunn> just in case something fails
[14:13] <kgunn> to update/install
[14:14] <kgunn> dobey: alternatively you can open the ./build script and just follow it manually....adding ppa's, apt-get update/installs
[14:14] <kgunn> dobey: shouldn't have too...but i find myself doing that to debug
[14:14] <kgunn> my own system!
[14:15] <kgunn> dobey: ....its usually some weird thing on my system :)
[14:15] <dobey> well, ./build -s is broken, because it wants to re-add the PPAs every time, and I really don't need N copies of the Packages.gz for every PPA it adds
[14:15] <dobey> especially not in my vm
[14:16] <dobey> where the heck is that WARN even coming from?
[14:16] <kgunn> dobey: hmmm, not sure how apt-add-repository works if you've already done it...
[14:16] <kgunn> at least i think its actually smart
[14:19] <Saviq> dobey, it doesn't add it multiple times, but indeed it could check whether it already exists and not even ask you
[14:20] <Saviq> Cimi, found a small visual issue in the Carousel, would be good to fix at some point - alternate taps on the first two items - they don't wait for the unzooming item to start zooming - so there's an abrupt switch when their z changes
[14:21] <didrocks> kgunn: ok, so FYI, daily release for the unity8 stack done (minus unity8 itself, Saviq and mzanetti are just finishing the upstream changes for it)
[14:21] <Saviq> didrocks, yup, on it in 5
[14:21] <didrocks> kgunn: Mir stack with lightdm is mostly ready, but we have 2 new issues:
[14:21] <didrocks> - Mir doesn't build on powerpc (tests fails)
[14:21] <kgunn> didrocks: thanks...and tell me
[14:21] <didrocks> - Mir build stuck on tests on armhf
[14:21] <didrocks> I added both bugs to https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy
[14:22] <kgunn> bregma: ^
[14:22] <didrocks> those 2 failures are what are blocking the Mir stack for daily release in a ppa (as we'll use a ppa until all bugs listed here are fixed + integration tests passing)
[14:22] <kgunn> didrocks: for sure armhf is critical to fix
[14:22] <didrocks> So I would say bug #1195260 and bug #1195265 are critical
[14:23] <bregma> powerpc?  sheesh
[14:23] <kgunn> wrt power pc....is there any chance of waiving ? (just in case we get resource crunched)
[14:23] <sil2100> Powerpc? Will we be blocking on that?
[14:23] <sil2100> I would put all manpower on the armhf issue for now
[14:24] <didrocks> sil2100: we need both for various reasons ;)
[14:24] <bregma> that particular fail is that basically Mir does not (yet) support PPC, so perhaps the packaging should take that into account
[14:24] <sil2100> Ok, so tvoss's solution of disabling the test for powerpc sounds ok to me
[14:25] <dobey> mzanetti, kgunn: ok, i've figured out why it broke now. didn't realize it was using the installed scopes on the system now, rather than providing its own fake stuff (or as well as providing fake stuff), and required them to work. re-installed the missing packages and it's working again now
[14:25] <sil2100> dpm: ok, so still trying to get the merge into lp:unity trunk
[14:25] <mzanetti> dobey: if you want to add a pointer to this to the wiki page, that'd be great
[14:25] <sil2100> dpm: once that's in, I'll re-run the unity stack and check if we can release
[14:26] <dpm> sil2100, excellent, thanks for the update, let me know how it goes
[14:27] <dobey> mzanetti: if you mean that page kgunn linked, i don't think i can. i certainly see no way to on the page itself
[14:27] <Saviq> didrocks, btw, isn't http://bazaar.launchpad.net/~unity-api-team/unity-notifications/trunk/view/head:/debian/rules#L13 the preferred way for multiarch?
[14:28] <mzanetti> dobey: interesting... this isn't a wiki indeed
[14:28] <didrocks> Saviq: hum, no, I have better now, what me to propose something?
[14:28] <Saviq> didrocks, sure
[14:29] <kgunn> dobey: i'm open to taking some text from you....i can add
[14:29] <Cimi> Saviq, file a bug and assign :)
[14:29] <Saviq> kgunn, would be good to add to CODING too, while you guys are at updating it
[14:30] <mzanetti> Saviq: pushed the qml-phone-shell-- stuff
[14:30] <Saviq> mzanetti, yup
[14:30] <dobey> kgunn: well, apparently unity-scope-home at least, needs to be installed, to be able to do anything useful with the dash
[14:31] <didrocks> Saviq: we do need to -DCMAKE_BUILD_TYPE='', do you have something I can put in comment?
[14:31] <tsdgeos> mterry: maybe i wasn't clear in https://code.launchpad.net/~mterry/unity/8.libusermetrics/+merge/169905 i don't say you shouldn't have a local class, what i say is that your local class should inherit "the real thing"
[14:32] <dobey> kgunn: also, I see "ppa's" used in several places on that page. it should be "PPAs" instead for pluralization. unless it's actually talking about something the PPA owns, in which case it should be "PPA's"
[14:32] <Saviq> Cimi, https://bugs.launchpad.net/unity8/+bug/1195349
[14:32] <Cimi> thx
[14:32] <mterry> tsdgeos, but inheriting involves linking against the real library, which we don't want to do for the mock
[14:33] <Saviq> dobey, unity-scope-home and unity-lens-applications are Recommends by unity8
[14:33] <dobey> kgunn: alternatively, it might be pertinent to add the scopes packages as Depends in the unity8-build-deps metapackage that gets built/installed
[14:33] <Saviq> dobey, those are only build dep packages, I'm afraid
[14:34] <Saviq> didrocks, not sure what you mean by "a place to comment"?
[14:34] <tsdgeos> mterry: any reason we don't?
[14:34] <dobey> Saviq: things reuqired to test that the thing you're building actually works, are build dependencies, in the scope of debian packaging :)
[14:34] <didrocks> Saviq: I just want to comment why CMAKE_BUILD_TYPE is emptied in debian/rules
[14:34] <Saviq> dobey, it's not required to test
[14:34] <Saviq> dobey, for testing we have mocks, we don't rely on real implementations
[14:35] <Saviq> didrocks, ah
[14:35] <dobey> Saviq: clearly it is, because otherwise i wouldn't have had a totally useless dash when running the unity8 i just built
[14:35] <mterry> tsdgeos, we are trying to mock the same namespace and symbols as that library...
[14:36] <Saviq> dobey, if you uninstalled the scopes, the Unity works just as well, only there's nothing in the dash
[14:36] <Saviq> dobey, and by testing I meant automated testing
[14:36] <tsdgeos> mterry: right, obvious :D
[14:37] <Saviq> dobey, it's the same for unity7, it's just the way it is - it's recommended to have it, but it's not a requirement
[14:38] <Saviq> dobey, but I agree a mention of it in CODING, and the installation of them in ./build -s is needed
[14:38] <didrocks> Saviq: should I try without it, just to see what it gives us? :p
[14:38] <didrocks> (building them in release mode)
[14:38] <Saviq> didrocks, I mean I don't know :D
[14:39] <Saviq> didrocks, Satoris might :)
[14:39] <Saviq> didrocks, it's his line
[14:39] <Saviq> didrocks, I rather meant -DLIBDIR
[14:39] <dobey> that seems horribly broken to me (allowing a unity to have a broken dash); but whatever, i don't want to argue about it. i've had enough trouble with trying to work on this already :-/
[14:39] <didrocks> Saviq: ah, for LIBDIR, it's a copy of an hold version I pushed for multiarch
[14:39] <didrocks> Saviq: ok, let's do that in 2 steps, first the multiarch one
[14:40] <didrocks> then, we'll see for -DCMAKE_BUILD_TYPE=''
[14:40] <tsdgeos> mterry: ok, so what i said is basically impossible to do :D
[14:41] <dobey> how does one simply close the dash in unity8?
[14:42] <Saviq> dobey, one doesn't
[14:42] <Saviq> dobey, there isn't a background behind the dash in unity8
[14:42] <Saviq> dobey, the dash is the background, really (at least for the touch form factors)
[14:43] <dobey> ok. then how do i get back to the lock screen?
[14:45] <Saviq> dobey, there's no way on the desktop atm
[14:45] <dobey> i suppose the answer in terms of "./run" is "reboot (quit, and ./run again)"
[14:46] <Saviq> dobey, unless nothing takes the power key over - that's what it reacts to
[14:46] <Saviq> dobey, but it's easy to add something
[14:46] <mzanetti> nic-doffay: super simple one: https://code.launchpad.net/~mzanetti/unity8/wobblyness--/+merge/171823
[14:46] <Saviq> dobey, Shell.qml:121
[14:46] <nic-doffay> mzanetti, will take a look shortly.
[14:46] <didrocks> Saviq: https://code.launchpad.net/~didrocks/unity-notifications/better-multiarch/+merge/171820
[14:47] <Saviq> didrocks, ah, so we can override CMAKE_INSTALL_LIBDIR anyway
[14:47] <Saviq> didrocks, looks good
[14:48] <didrocks> Saviq: yeah, I've found the GNUInstallDirs quite recently :)
[14:49] <mterry> tsdgeos, I think so.  We can use other tricks to be able to use the system headers still (like symlinks to them), but those are not preferred to just having local versions
[14:49] <tsdgeos> mterry: yeah let's not go there
[14:50] <Saviq> mzanetti, +#include <QDebug> ← no
[14:50] <mzanetti> Saviq: already removed
[14:50] <Saviq> ;)
[14:51] <didrocks> mterry: hey! in case you didn't see my answer: https://code.launchpad.net/~didrocks/platform-api/changelog-cleanup/+merge/171476 ;)
[14:52] <mterry> didrocks, oh, hum, no I didn't.  Thanks!
[14:52] <Saviq> kgunn, dandrader while updating CODING, can you make sure it points to lp:unity8, too?
[14:53] <didrocks> bregma: thanks! :)
[14:53] <didrocks> sil2100: https://code.launchpad.net/~bregma/libgrip/raring-lp-1188693/+merge/171819 if you didn't see it
[14:53] <didrocks> sil2100: would be cool to rerelease oif tomorrow morning :)
[14:54] <dandrader> dednick, ping
[14:54] <Saviq> didrocks, ah, we actually had a release yesterday, can you please merge trunk and bump the changelog version in https://code.launchpad.net/~unity-team/unity/unity8-packaging-cleanup/+merge/171537
[14:54] <dednick> dandrader: plop
[14:54] <Saviq> plop?
[14:54] <Saviq> plonk
[14:54] <Saviq> we doing funny noises now?
[14:54] <didrocks> Saviq: so, this was your latest release? ;)
[14:55] <dandrader> dednick, so, is the merge proposal good to go?
[14:55] <Saviq> didrocks, indeed!
[14:55] <didrocks> waow :)
[14:55] <didrocks> Saviq: remerge against lp:unity8, right?
[14:55] <Saviq> didrocks, yes
[14:56] <sil2100> bregma, didrocks: looks good indeed! Once someone who knows the codebase reviews, I'll be happy to re-run the machinery
[14:56] <dandrader> Saviq, will wait until kgunn shows up so that we don't hit this impasse again
[14:57] <Saviq> dandrader, just merge one of your branches into the other
[14:57] <Saviq> dandrader, no point in having two separate merges in
[14:57] <kgunn> dandrader: i can propose to merge with yours
[14:57]  * kgunn now just has to figure out how
[14:58] <dednick> dandrader: ya. approved
[14:58] <didrocks> Saviq: pushed!
[14:58] <dandrader> kgunn,  so who creates the new merge proposal, you or me?
[14:58] <Saviq> didrocks, thanks!
[14:59] <didrocks> Saviq: tell me once it's in lp:unity8 and I'll enable dailies (without integration test for now, anyway, we are landing to a ppa) :)
[14:59] <dandrader> either way is fine by me
[14:59] <Saviq> didrocks, will do
[14:59] <kgunn> Saviq: dandrader for for unity8 it'll be from scratch right ?
[14:59] <kgunn> i'll do it
[14:59] <didrocks> thanks ;)
[14:59] <kgunn> dandrader can do "real work"
[14:59] <Saviq> kgunn, it's the same history
[14:59] <Saviq> kgunn, just different place
[14:59] <Saviq> kgunn, so the only thing to remember is to --remember when you pull
[15:00] <didrocks> Saviq: why qtubuntu [armhf], ?
[15:00] <didrocks> Saviq: this was changed, but qtubuntu is available on all archs
[15:00] <Saviq> didrocks, is it?
[15:00] <Saviq> didrocks, indeed
[15:00] <Saviq> mzanetti, ↑
[15:01] <mzanetti> hmm... it wasn't available here
[15:01] <mzanetti> hmm... it is now :/
[15:01] <mzanetti> dafuq
[15:01] <mzanetti> I'll remove it again
[15:01] <didrocks> mzanetti: it is for some month*s* :p
[15:01] <didrocks> mzanetti: thanks!
[15:02] <mzanetti> didrocks: I wanted to install it today and it complained
[15:02] <mzanetti> didrocks: I did an apt-cache search and it gave me nothing
[15:02] <dandrader> kgunn, yes, start a new mp from scratch
[15:03] <mzanetti> didrocks: Saviq: fixed
[15:03] <dandrader> kgunn, then manually copy paste parts o my mp and yours
[15:03] <kgunn> dandrader: ack
[15:03] <Saviq> mzanetti, k
[15:04] <dandrader> kgunn, it's not worth the trouble of trying to retain the commit history of those modifications
[15:04] <didrocks> mzanetti: interesting, maybe you just tried during an archive skew? not sure TBH
[15:05] <mzanetti> didrocks: well, it works now. so no prob
[15:05] <dandrader> dednick, thanks!
[15:07] <Saviq> didrocks, byyy the waay, how do we get unity8 into the touch images then? will it build into a common PPA that the images use or?
[15:07] <didrocks> Saviq: yeah, the "ubuntu-unity/next" ppa
[15:08] <Saviq> didrocks, ok
[15:08] <didrocks> sergiusens: did you remove that one or still have it enabled btw? ^
[15:10] <sergiusens> didrocks: pulling from the ppa?
[15:10]  * sergiusens reads more from the backlog
[15:10] <didrocks> sergiusens: yeah, the ubuntu-unity/next ppa will be of use for unity8 stack and Mir for some weeks until we get all issues resolved
[15:11] <Saviq> didrocks, ah, and we need a merger set up for lp:unity8, right?
[15:12] <didrocks> Saviq: yeah, I've already changed the config and merged it into cupstream2distro-config, I think fginther just need to redeploy it if not done already.
[15:12] <sergiusens> didrocks: Saviq ok, we are not using it though... what are the issues?
[15:13] <didrocks> sergiusens: no issue, we'll have unity8 and mir released through that channels for some weeks
[15:13] <sergiusens> Saviq: merger is still on the same system, package deployment is what changes
[15:13] <didrocks> sergiusens: so good if you can add it
[15:13] <sergiusens> didrocks: ok, just though _issues_ meant instabilities :-)
[15:13] <fginther> didrocks, thanks for the deploy reminder
[15:14] <didrocks> sergiusens: not sure it will be instable, we'll have dailies the usual way :)
[15:14] <sergiusens> didrocks: Saviq to clarify, does this unity8 imply Mir in the touch images?
[15:14] <didrocks> fginther: ensure you deploy rev 469 btw :)
[15:15] <fginther> didrocks, ack
[15:16] <didrocks> sergiusens: not yet AFAIK (and from the build-deps)
[15:16] <didrocks> sergiusens: you don't install lightdm, on the image, right?
[15:17] <dandrader> dednick, this is the same, but targeting the new lp:unity8 -> https://code.launchpad.net/~dandrader/unity8/dragHandle/+merge/171840
[15:17] <dandrader> I wasn't able to make the original merge proposal point to the new repo
[15:18] <dandrader> launchpad gave out an error
[15:18] <mterry> tsdgeos, if that removes your objection to the libusermetrics branch, is that an approval?
[15:19] <tsdgeos> mterry: i think so yes, i'll have a look in the next hour, is that ok for you?
[15:19] <Saviq> dandrader, there was no need for that, it's fine to merge to lp:unity/8.0 still
[15:19] <Saviq> dandrader, I'll make sure to keep them in sync
[15:19] <Saviq> dandrader, I only meant that new MRs should go against lp:unity8
[15:19] <dandrader> Saviq, ah ok
[15:19] <mterry> tsdgeos, sure, no rush
[15:20]  * dandrader deletes the new mp
[15:21] <sergiusens> didrocks: negative on lightdm
[15:22] <didrocks> sergiusens: ok, so you're fine Mir-wise
[15:22] <Saviq> didrocks, changed? so we won't have the merger for lp:unity/8.0 anymore?
[15:22] <Saviq> didrocks, I didn't want to resubmit everything against lp:unity8 for now :)
[15:23] <didrocks> Saviq: ah good point, yeah, we had to change it. I think that fginther needs to duplicate the config for the other branch
[15:23] <didrocks> with daily_release: False
[15:23] <didrocks> but I prefer him to do that as I don't know how he will handle local repositories
[15:23] <Saviq> didrocks, k
[15:24] <fginther> didrocks, Saviq, so we need auto-merger on lp:unity8 and lp:unity/8.0?
[15:24] <didrocks> fginther: yep
[15:24] <fginther> ack
[15:25] <didrocks> fginther: but daily release only on lp:unity8, so please set daily_release: False for the other one
[15:25] <Saviq> fginther, thanks
[15:25] <fginther> didrocks, understood
[15:26] <Saviq> mzanetti, Ubuntu.Application isn't installed
[15:27] <mzanetti> Saviq: when, how?
[15:27] <Saviq> mzanetti, we need to install the fake Ubuntu.Application, too/
[15:27] <Saviq> mzanetti, well...
[15:28] <mzanetti> Saviq: I'be built a package and installed it and ran it from there. And I'm pretty sure the fake Ubuntu.Application was there too
[15:28] <mzanetti> Saviq: but let me try again
[15:28] <Saviq> mzanetti, in the fake-env probably?
[15:28] <mzanetti> Saviq: yeah
[15:28] <Saviq> mzanetti, but that's not required by unity8 package
[15:28] <mzanetti> oh... so there's the issue then
[15:28] <Saviq> mzanetti, it should be in -private for now, probably
[15:29] <Saviq> mzanetti, but!
[15:29] <Saviq> mzanetti, qtubuntu installs /usr/lib/x86_64-linux-gnu/qt5/imports/Ubuntu/Application/
[15:29] <mzanetti> Saviq: so?
[15:29] <Saviq> mzanetti, so if we go for fall back to our private ones
[15:29] <Saviq> mzanetti, we will probably have issues
[15:30] <mzanetti> Saviq: I for one would install them with the -fake package and if the fake package is installed, prefer that one (for demos and such)
[15:31] <mzanetti> Saviq: but in that case its true, we must not depend on the -fake from the unity8 package
[15:31] <Saviq> mzanetti, yeah, we can't even recommend it
[15:31] <Saviq> mzanetti, as it will get pulled in onto the image
[15:31] <Saviq> and break it
[15:31] <mzanetti> Saviq: but is that a problem?
[15:31] <mzanetti> Saviq: you install unity8 on the desktop and it won't work, because its not finished
[15:32] <mzanetti> so you install the -fake package and your fine
[15:32] <mzanetti> and at some point the fake pacakge won't be needed any more
[15:32] <Saviq> mzanetti, yeah, probably
[15:32]  * Saviq wonders why import Ubuntu.Application 0.1 doesn't work, then, with qtubuntu installed
[15:32] <mzanetti> yeah... that's another think I really don't get
[15:33] <mzanetti> Saviq: we had that situation in December
[15:33] <mzanetti> Saviq: all the apps stopped working on the desktop and I opened a bug that Ubuntu.Application should just provide some mock for desktop
[15:33] <mzanetti> Saviq: the answer was no. and now all apps have a Loader {} wrapped around the ubuntu.Application to not fail on desktop
[15:33] <mzanetti> which is crazyness imho
[15:34] <Saviq> mzanetti, interesting
[15:34] <Saviq> mzanetti, didn't we do a review of what's there in Ubuntu.Application and what shouldn't be there?
[15:34] <mzanetti> Saviq: yeah... greyback is mostly on that one nowadays
[15:35] <Saviq> mzanetti, do you remember what the apps use of that?
[15:35] <mzanetti> Saviq: all of our apps did that (not sure if they were changed since I'm in the unity team tho)
[15:35] <Saviq> mzanetti, I meant what did they use of that PAI
[15:35] <Saviq> API
[15:36] <Saviq> like the desktop file parser or?
[15:36] <mzanetti> ah... no idea tbh
[15:36] <mhr3> Saviq, eh, new branches now go to ~team/unity8/foo ?
[15:36] <Saviq> mhr3, yes please
[15:36] <mhr3> Saviq, will branch base work fine if it was branches off lp:unity/8.0?
[15:36] <Saviq> mhr3, yes
[15:36] <mhr3> ok
[15:36] <Saviq> mzanetti, then why do we have qtubuntu on the desktop in the first place ?:
[15:37] <mzanetti> Saviq: I don't know...
[15:37] <mzanetti> Saviq: as you have seen in my commit I thought it wouldn't be there
[15:37] <Saviq> mzanetti, soo... fakes are prepended to the import path, so if installed they take precedence?
[15:38] <mzanetti> Saviq: not 100% sure about the plugin loading internas
[15:39] <Saviq> mzanetti, they're not, they're installed to the same path
[15:39] <mzanetti> Saviq: which same path?
[15:40] <Saviq> mzanetti, that all the other plugins
[15:40] <Saviq> mzanetti, we should have priority:
[15:40] <Saviq> fakes > global > mocks
[15:41] <Saviq> mzanetti, something's not right there, we're installing the LightDM plugin twice
[15:41] <Saviq> mzanetti, once in $libdir/qml, once in $libdir/qml/mocks
[15:41] <mzanetti> Saviq: no
[15:42] <mzanetti> Saviq: one is the QML plugin
[15:42] <mzanetti> Saviq: the others are libraries that are loaded by the QML plugin
[15:42] <mzanetti> depending on the demo configuration
[15:42] <Saviq> mzanetti, libMockLightDM-qml.so and libLightDM-qml.so
[15:43] <Saviq> mzanetti, they're both QML plugins
[15:43] <Saviq> mzanetti, one installed to $libdir/qml
[15:43] <mzanetti> right
[15:43] <Saviq> mzanetti, the other to $libdir/mocks
[15:43] <Saviq> mzanetti, what's more, the $libdir/mocks one is from the -fake-env
[15:43] <Saviq> mzanetti, so it should take precedence
[15:43] <mhr3> Saviq, if you have a sec pls take a look at https://code.launchpad.net/~mhr3/unity8/use-dee-filtermodel/+merge/171846 it's still wip, but would be good to know whether i should continue fixing all the tests
[15:44] <Saviq> mzanetti, precedence should be:
[15:44] <Saviq> fake-env > global > private
[15:45] <Saviq> mzanetti, it might even be the case now, but we shouldn't install MockLightDM at all, AFAICS
[15:45] <Saviq> mhr3, will do
[15:45] <mzanetti> mterry: ^^
[15:46] <mzanetti> mterry: do we need to install MockLightDM?
[15:46] <Saviq> mhr3, fancy, and it uses Dee filters?
[15:46] <mterry> mzanetti, you were asking about ofono: https://github.com/c4milo/ofono/blob/master/doc/sim-api.txt
[15:46] <mzanetti> Saviq: I think that's used for different stuff.
[15:46] <mterry> mzanetti, for autopilot tests, yes
[15:46] <mhr3> Saviq, yea, although that's hidden in unity-core's GetResultsForCategory()
[15:47] <mzanetti> mterry: yeah, the ofono api is just like we assumed
[15:48] <mzanetti> mterry: still the question, should this be piped through lightdm or should we have a separate qml plugin for this
[15:48] <mzanetti> Saviq: so... yes, we need the MockLightDM for autopilot
[15:48] <mterry> mzanetti, I'm thinking separate qml plugin, because that code will want to be shared between greeter and shell
[15:49] <mterry> mzanetti, since either may need to present the dialog
[15:49] <mzanetti> mterry: and how would they know who's turn it is?
[15:49] <Saviq> whose
[15:49] <mzanetti> :D
[15:49] <mzanetti> thanks mr spellchecker
[15:49] <sil2100> dpm: so, it seems all the merging and building takes quite a while... I'll try to release it today, but it might be a bit troublesome to do, as the build and testing process might take some time still ;/
[15:50] <Saviq> mzanetti, /me no sure... the fake-env package was prepared for autopilot
[15:50] <mterry> mzanetti, well, this may depend on how design wants to show it.  But I'm thinking the shell will display a notification that goes away when the SIM is unlocked.  So if user unlocks via greeter, the notification will just go away and everything will work as expected
[15:50] <didrocks> sil2100: meanwhile btw, do you think you will have time to clean all the head stack for listing only what we need to install?
[15:50] <mterry> mzanetti, i.e. both can try to handle it
[15:51] <didrocks> sil2100: I think it's just downloading the manifest for the package and removing everything that's on it :)
[15:51]  * Saviq looks at what the previous packages contained
[15:51] <mterry> Saviq, you don't like installing MockLightDM in -fake-env?
[15:51] <Saviq> mterry, I like installing it there
[15:51] <dpm> sil2100, no worries, I appreciate the effort and the follow-up. I think what I'll do is I'll just publish the tutorial with the workaround now, and I'll update it once the fix lands
[15:51] <mterry> Saviq, oh.  Where is it installed now?
[15:51] <Saviq> mterry, there's two
[15:51] <Saviq> mterry, libMockLightDM-qml.so
[15:52] <Saviq> mterry, and libLightDM-qml.so
[15:52] <mterry> Saviq, mock in -fake-env, real in unity8
[15:52] <mterry> right?
[15:52] <Saviq> mterry, Mock == real? :D
[15:52] <mterry> Saviq, once we have split processes, that can be true
[15:52] <Saviq> mterry, no, I mean is libMockLIghtDM-qml.so the real one atm?
[15:53] <Saviq> mterry, no
[15:53] <mterry> Saviq, no.  The real one has demo users statically linked in.  The mock needs an LD_LIBRARY_PATH to point at the shared library to use
[15:53]  * Saviq got lost
[15:53] <mterry> Saviq, that's the only difference right now
[15:55] <Saviq> mzanetti, so... I think we should install Ubuntu.Application in unity8-private, then, not in -fake-env, not until we can rely on the real implementation
[15:55] <mzanetti> Saviq: and what happens on the phone?
[15:55] <mzanetti> Saviq: i.e. where we have a real implementation?
[15:55] <Saviq> mzanetti, global has precedence
[15:55] <mzanetti> ack
[15:55] <mzanetti> is that correct already?
[15:56] <Saviq> mzanetti, /me checks
[15:59] <mhr3> tedg, is my assumption that phone apps won't have access to session bus correct?
[15:59] <Saviq> mhr3, yeah, looks sane
[15:59] <mhr3> Saviq, thx, will fix the qmltests then...
[16:00] <tedg> mhr3, They will have access to the session bus, but that access will be mitigated via AppArmor.
[16:00] <Saviq> mhr3, bear in mind it's 6pm here, so don't rely on me too much
[16:00] <mzanetti> :D
[16:00] <mhr3> Saviq, it's not like 1k diff, just 700 :P
[16:01] <Saviq> mhr3, yeah, and I've been reviewing an 8k one for two weeks already :P
[16:01] <Saviq> mhr3, it's almost all green, too
[16:03] <Saviq> mzanetti, didrocks ok, so qtubuntu on desktop is not importable by default - it's installed to /imports instead of /qml
[16:03] <Saviq> and I don't think it's useful at all without SF
[16:03] <Saviq> not to us
[16:04] <Saviq> not sure what it's doing on the desktop anyway
[16:04] <didrocks> Saviq: IIRC, mterry should konw more about that one :)
[16:04] <didrocks> Saviq: well, the idea was to be able to prepare it being available so that once we switch to more progressive enhancement vision, we already have the components there and not too many "if that arch or if that arch"
[16:05] <mhr3> tedg, so say they request a name, is that allowed? can then other apps talk to them?
[16:05] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/libunity-core_bump/+merge/171852 <- quickie? ;)
[16:05] <mterry> Saviq, why is it installed to imports btw?  I found that odd
[16:05] <tedg> mhr3, They can not request a name.
[16:05] <Saviq> mterry, you tell me :)
[16:05] <tedg> mhr3, They should be able to be talked to, but what they could send in reply might be limited.
[16:05] <Saviq> mterry, but then, why is it installed (able) at all, if it's not really working
[16:05] <tedg> mhr3, So they'd only be able to use allowed interfaces, etc.
[16:05] <Saviq> mterry, as in it doesn't provide the app management interface
[16:06] <mterry> Saviq, I've had https://code.launchpad.net/~mterry/qtubuntu/qmldir/+merge/160977 for a while
[16:06] <mhr3> tedg, before i ask 10 related questions, is there a spec defining all this?
[16:06] <mzanetti> Saviq: I guess because didrocks forced them to make it installable
[16:06] <mterry> 2 months
[16:06] <tedg> mhr3, But, for instance, what could be allowed is definable.  So if you want something there, you should talk to security.
[16:06] <tedg> mhr3, It's in the app confinement spec, but not at the detail you're looking for.
[16:07] <Saviq> mzanetti, ok, whatever, I'm not gonna try and understand it today
[16:07] <mterry> Saviq, we wanted all components to be installable regardless of architecture.  Whether it's suitable for desktop is a different thing.  But architecture ideally shouldn't be a problem
[16:07] <didrocks> mzanetti: we need to have that vision, and I was told that the qtubuntu calls won't segfault anyway, just give (for the camera part) nothing
[16:07] <didrocks> Saviq: ^
[16:07] <didrocks> mterry: yep :)
[16:07] <mhr3> tedg, i'm interested in for example how do you xdg-open something in an app? say a simple mp3 from the dash
[16:07] <Saviq> mterry, well, it's not a question of arch in that case
[16:07] <mzanetti> didrocks: yeah. not an issue per se... it just doesn't make much sense either...
[16:07] <didrocks> mzanetti: well, stop thinking of armhf == touch, other == desktop
[16:07] <Saviq> mterry, but simply the fact that U.A can't work on intel,
[16:08] <mzanetti> didrocks: sure
[16:08] <didrocks> it's not what we have here :)
[16:08] <tedg> mhr3, We're going to have a "URL Dispatcher" over DBus, and will provide access to that DBus interface.
[16:08] <Saviq> 'cause it talks to surfaceflinger...
[16:08] <didrocks> mzanetti: this is what you specify though with [armhf]
[16:08] <tedg> mhr3, It's actually on my TODO to prototype today :-)
[16:08] <mhr3> tedg, good, so picked the right person to ask about it :)
[16:08] <Saviq> didrocks, of course, that's a poor man's condition
[16:08] <mhr3> i picked*
[16:08]  * tedg hides
[16:09] <mterry> Saviq, well, there must be some abstraction layer somewhere for that?  If it's not qtubuntu, then maybe we don't need it on the desktop, but we do need whatever abstraction there is...
[16:09] <Saviq> mterry, sure, there will be
[16:09] <Saviq> mterry, or rather
[16:09] <Saviq> mterry, qtubuntu is that abstraction layetr
[16:09] <Saviq> -t
[16:09] <tedg> mhr3, The problem with xdg/gnome-open is that they read the desktop files, which we don't want apps to be able to do.
[16:09] <Saviq> mterry, but it's not there for arches other than armhf
[16:10] <Saviq> mterry, so forcing a crippled version of the package onto amd64 / i386 is broken, IMO
[16:10] <mhr3> tedg, right, but the dash can do it :)
[16:10] <mhr3> i live in priviledged world :)
[16:10] <Saviq> mterry, since we can't rely on the "it's not there yet, let's fall back to our mock implementation" approach
[16:10] <tedg> mhr3, Yup, certainly.  #unpriviledgedproblems
[16:10] <mterry> Saviq, well, that's just a bug.  :)  That qtubuntu calls don't do the right (abstracted) thing yet.  But it's apparently the right component/API to use, eh?
[16:10] <Saviq> mterry, it's like you put LightDM on QML2_IMPORT_PATH now
[16:11] <Saviq> mterry, even though it can't do anything
[16:11] <mhr3> tedg, but yea, i suppose you'll the the same url dispatcher to allow apps launch things?
[16:11] <Saviq> mterry, and suddenly the fact that we're shipping the mock^Wreal libLightDM-qml.so wouldn't matter
[16:12] <Saviq> mterry, 'cause someone supplied a system-wide one that will be used
[16:12] <Saviq> mterry, even though it's not doing anything
[16:12] <mterry> Saviq, was the original argument that we shouldn't ship qtubuntu on the desktop?
[16:12] <tedg> mhr3, Yeah, we need it for tel://2342343 and application://inkscape most pressingly.
[16:12] <Saviq> mterry, yes
[16:12] <Saviq> mterry, or require it by unity8 on arches other than armhf
[16:13] <mhr3> tedg, you mean application://inkscape.desktop? ;P
[16:13] <mterry> Saviq, but don't lots of touch components use qtubuntu?
[16:14] <Saviq> mterry, if it's not available on the QML import path anyway - no ;)
[16:14] <Saviq> mterry, then there's the fact that Ubuntu.Application shouldn't ever have been used by things other than the shell
[16:14] <Saviq> or, we need to switch to a different name
[16:14] <Saviq> where the shell-only API is exposed
[16:15] <Saviq> and not available to apps
[16:15] <mterry> Saviq, yeah, I don't get why it's not importable.  What's the point of qtubuntu even on arm if we don't import it...
[16:15] <Saviq> mterry, on arm we do
[16:15] <Saviq> mterry, the whole app management goes through that
[16:15]  * Saviq checks the import paths there
[16:16] <tedg> mhr3, Oh, yes, typo ;-)
[16:16] <Saviq> mterry, no idea how, but we do ;)
[16:16] <mterry> Saviq, oh.  I guess I don't understand how to load a plugin from the import/ path
[16:16] <Saviq> mterry, QML2_IMPORT_PATH is exported on the device
[16:16] <Saviq> mterry, hardcoded in /etc/environment <facepalm.
[16:16] <Saviq> >
[16:17] <Saviq> jeez we need to clean that stuff up
[16:17] <Saviq> greyback, you reading? ;)
[16:17] <tsdgeos> mterry: i run the usermetrics thing in the PC and don't get any nice circle on start
[16:17] <mterry> ah...
[16:17] <mterry> tsdgeos, hrm..
[16:18] <greyback> Saviq: nope, but am now.
[16:18] <Saviq> greyback, Ubuntu.Application < MESS
[16:18] <Saviq> greyback, and I mean ←, not less than
[16:18] <mterry> It's a one line change to make it importable like standard modules.  But maybe you don't want that (to discourage use)
[16:19] <Saviq> mterry, yeah, we need to install shell-facing plugin on a shell-private path
[16:19] <Saviq> mterry, so that we can even apparmor it
[16:19] <Saviq> mterry, and that would be /usr/lib/*/unity8/qml/
[16:19] <Saviq> mterry, but then, as you promptly noticed
[16:19] <greyback> Saviq: well it is only for shell. It needs to be made a private plugin somehow
[16:19] <Saviq> mterry, U.A is used by apps, too
[16:19] <Saviq> greyback, it's not only for shell, that's the thing
[16:19] <tsdgeos> mterry: is that intended or a small bug?
[16:20] <Saviq> greyback, gallery app imports it, for example
[16:20] <Saviq> greyback, or the SDK even
[16:20] <greyback> Saviq: then we need to remove the parts that apps are using, and place them into a separate plugin
[16:20] <Saviq> greyback, yes exactly
[16:20] <Saviq> mzanetti, ↑ write that down
[16:20] <greyback> Saviq: I didn't even know apps were using it.
[16:20] <mterry> tsdgeos, not intended, trying to reproduce now, hold on a sec
[16:20] <greyback> that's bad
[16:20] <Saviq> greyback, it is indeed
[16:21] <mzanetti> Saviq: huh?
[16:21] <Saviq> mzanetti, ;)
[16:21] <mterry> tsdgeos, my device is going crazy right now
[16:21] <greyback> Saviq: ok, I'll investigate and work on a proposal to fix it. (still reading up tho)
[16:21] <Saviq> greyback, no need
[16:21] <tsdgeos> mterry: the device works fine, it's the PC that is lacking the infographic
[16:21] <Saviq> greyback, it might not be the case any more, even
[16:21]  * Saviq checks
[16:22] <Saviq> greyback, one reason I think was to launch apps from apps
[16:22] <mterry> Saviq, greyback: reverse-depends qtubuntu is pretty light
[16:22] <Saviq> mterry, that, unfortunately, doesn't mean it's not used :/
[16:22] <Saviq> mterry, but anyway
[16:22] <greyback> Saviq: which is a more general problem we've to fix. Using U.A to do that was a hack
[16:22] <mterry> Saviq, well, fair...
[16:22] <Saviq> mterry, qtubuntu also provides the QPA plugin required to run apps on amrhf
[16:23] <Saviq> s/amrhf/surfaceflinger/
[16:23] <Saviq> greyback, http://bazaar.launchpad.net/~phablet-team/gallery-app/trunk/view/head:/rc/qml/Utility/UbuntuApplicationWrapper.qml
[16:24] <greyback> Saviq: yuk
[16:24] <mzanetti> Saviq: yeah... thats the crazyness I meant before
[16:24] <mterry> tsdgeos, are you running via ./run -f or ./run_on_device?
[16:24] <didrocks> Saviq: can you remind me the difference on a system where I installed qtubuntu + unity8 on !touch and unity8 only?
[16:24] <tsdgeos> mterry: ./run
[16:24] <Saviq> didrocks, none
[16:25] <Saviq> didrocks, but that's just because it's installed on a weird import path
[16:25] <didrocks> Saviq: if we fix the import/ -> qml/
[16:25] <Saviq> didrocks, it won't work
[16:25] <Saviq> didrocks, not on X11
[16:25] <didrocks> won't work, like, unity8 only?
[16:25] <greyback> Saviq: mzanetti: we need a discussion on this. My idea would be to use the platform API to enable Qt.openUrl() for launching apps. But we should discuss it with other peeps too
[16:25] <mterry> tsdgeos, aha!  I see the bug too now
[16:25] <mzanetti> +1
[16:25] <mterry> tsdgeos, let me look
[16:25] <mzanetti> greyback: ^
[16:26] <didrocks> Saviq: or won't work because we import it? (and so, we have an additional side-effect)
[16:26] <mzanetti> greyback: we need to have Qt.openUrl() working
[16:26] <Saviq> didrocks, stuff will break
[16:26] <Saviq> didrocks, although I'm not sure what qtubuntu on X11 really is
[16:26] <mzanetti> greyback: there's now way we can ship a device claiming to be Qt compatible and not implementing basic backends
[16:27] <didrocks> Saviq: ok, when I asked about those, people would just tell that the call would return empty results basically
[16:27] <greyback> mzanetti: yep I think so too. But would like to run it by app armour people and app lifecycle people too, to make sure it fits
[16:27] <mterry> tsdgeos, oh!
[16:27] <mterry> tsdgeos, sorry, that's intentional
[16:27] <didrocks> Saviq: it's not the case? what makes unity behaving differently when having qtubuntu installed?
[16:27] <mterry> tsdgeos, because that is actually using the system libusermetrics
[16:27] <mterry> tsdgeos, so that's the behavior when libusermetrics isn't giving us anything
[16:27] <Saviq> didrocks, we have a mock implementation of the Ubuntu.Application API
[16:27] <Saviq> didrocks, local to unity8
[16:27] <Saviq> didrocks, for use on X11
[16:28] <Saviq> didrocks, that just really moves images around
[16:28] <didrocks> and so, they are disabled when qtubuntu is installed?
[16:28] <sil2100> mhr3, pstolowski: what's unity-scopes-master-default ?
[16:28] <mterry> tsdgeos, which is not likely how design wants it.   But that's sort of a separate bug.  And maybe a bug in libusermetrics instead of unity.  We have to talk to design
[16:28] <Saviq> didrocks, if qtubuntu will be installed on the correct import path
[16:28] <sil2100> mhr3, pstolowski: do you guys know where is it pulled from?
[16:28] <tsdgeos> mterry: ok, feels weird that the infographic is gone in the pc
[16:28] <Saviq> didrocks, it would get precedence
[16:28] <tsdgeos> even if it was fake
[16:28] <mhr3> sil2100, home scope
[16:28] <tsdgeos> i'm sure it's fake in the device too, no?
[16:28] <didrocks> Saviq: yeah, yeah, I'm intending that :) that's better with explanations :p
[16:28] <didrocks> Saviq: shouldn't as well qtubuntu provides those mocks as request results?
[16:28] <mhr3> sil2100, it's all the default .scope files (ie master scopes)
[16:28] <didrocks> until the real implementation is in?
[16:29] <Saviq> didrocks, will it be called qtubuntu-mock?
[16:29] <Saviq> didrocks, it really needs to get split
[16:29] <mhr3> sil2100, or maybe that's the virtual pkg
[16:29] <sil2100> mhr3: ACK
[16:29] <Saviq> didrocks, into the QPA plugin
[16:29] <greyback> +1
[16:29] <Saviq> didrocks, into the app-facing API, if any
[16:29] <Saviq> didrocks, and the shell-facing API
[16:29] <mhr3> sil2100, one that allows overriding of those
[16:29] <mterry> tsdgeos, we're slowly getting closer to what will actually ship.  But I believe design is not finished deciding how "initial infographic" will look like
[16:29] <didrocks> Saviq: why? it should be transparent for the "apps/shell" requesting qtubuntu
[16:29] <mterry> tsdgeos, agreed that it's an ugly regression though
[16:29] <didrocks> if the implementation is real (because of surfaceflinger detected) -> send the real results
[16:29] <tsdgeos> mterry: ok, so can you comment on the MR and say that "this is the intended behaviour" if that is so
[16:29] <didrocks> if not -> send the mock
[16:29] <Saviq> didrocks, apps/shell shouldn't request qtubuntu
[16:30] <didrocks> Saviq: hum, don't you have a dep? :p
[16:30] <mterry> pete-woods, can I ask a favor?  You'll be around tomorrow?
[16:30] <Saviq> didrocks, I do, but I'd rather not
[16:30] <Saviq> didrocks, if qtubuntu without surfaceflinger provided mocks
[16:30] <Saviq> didrocks, that would be fine with me
[16:30] <Saviq> didrocks, but still Ubuntu.Application API needs to be split
[16:30] <didrocks> Saviq: I think that would be the right way to go
[16:30] <nic-doffay> mzanetti, reviewing now
[16:30] <nic-doffay> sorry for the delay
[16:30] <Saviq> didrocks, into app-facing and shell-facing part
[16:31] <mzanetti> nic-doffay: no worries
[16:31] <didrocks> Saviq: yeah yeah, not talking about that part, just about how convergence should be approached :)
[16:31] <nic-doffay> how can I navigate to test mzanetti ?
[16:31] <didrocks> that's why I don't think [armhf] isn't the right approach
[16:31] <Saviq> didrocks, sure, the shell should just depend on *an* implementation of Ubuntu.Application
[16:31] <Saviq> didrocks, same for the apps
[16:31] <didrocks> yep :)
[16:31] <mzanetti> nic-doffay: ./run -p and ./run -k
[16:31] <mzanetti> nic-doffay: same for run_on_device
[16:31] <didrocks> then the implementation knows if it can talk to the backend
[16:31] <Saviq> didrocks, that's what we did with the -impl virtuals
[16:31] <didrocks> and send real data
[16:31] <sil2100> didrocks: another quickie :( https://code.launchpad.net/~sil2100/cupstream2distro-config/add_unity-scopes-master-default/+merge/171858
[16:31] <didrocks> or send mocks otherwise
[16:32] <Saviq> didrocks, that's utopian, and a yes and no, simply because if you're doing mocks
[16:32] <sil2100> mhr3, pstolowski: would it be a big bother if I asked you to poke me an e-mail/IRC message when there's a new binary package added by you guys somewhere in the scopes? :) With cherries on top!
[16:32] <Saviq> didrocks, you can cut corners
[16:33] <Saviq> didrocks, and do them in QML, for example
[16:33] <Saviq> didrocks, so I'd rather do it somewhat differently
[16:33] <sil2100> didrocks: thank you!
[16:33] <didrocks> Saviq: right now, I'm just telling that the armhf -> touch, [!armhf] -> desktop is a transitional thing that we can't add to saucy anymore
[16:33] <didrocks> sil2100: yw :)
[16:33] <Saviq> didrocks, understood
[16:33] <didrocks> Saviq: hud is getting rid of that for instance in a couple of weeks
[16:33] <Saviq> didrocks, i.e. two separate packages providing the implementation of Ubuntu.Application
[16:34] <Saviq> didrocks, one would be the real thing
[16:34] <didrocks> Saviq: yeah, I'm fine with that, and different seeds installing different ones
[16:34] <Saviq> but it needs to depend on something that's only available for touch
[16:34] <didrocks> like the desktop -> install the mock version
[16:34] <didrocks> and touch image -> install the "real implementation using surfaceflingers" for now
[16:34] <didrocks> Saviq: yep :)
[16:34] <mhr3> sil2100, right, sorry thought you talk to didier :)
[16:35] <Saviq> didrocks, so in that sense *we* can provide qtubuntu for desktop
[16:35] <Saviq> that will just spit out mocks
[16:35] <didrocks> Saviq: exactly :)
[16:35] <didrocks> Saviq: want to consolidate that tomorrow? I need to pop out right now, but happy to help you tomorrow with that
[16:35] <Saviq> didrocks, yeah, let's do tomorrow
[16:35] <didrocks> Saviq: just ping me in the morning please :)
[16:36] <Saviq> didrocks, will do
[16:36] <didrocks> thanks!
[16:36] <didrocks> have a nice evening :)
[16:37] <sil2100> mhr3: I do ;p But sadly not about every small thing! At least he didn't give me a sign about that
[16:38] <greyback> Saviq: have we a plan for qml plugins that should be shell specific? A special import path?
[16:38] <Saviq> greyback, yeah /usr/lib/*/unity8/qml
[16:38] <Saviq> greyback, the packaging things were already doing that
[16:38] <greyback> Saviq: good, thanks
[16:38] <greyback> ok, I didn't realise
[16:39] <Saviq> greyback, I mean the to-be-merged packaging things
[16:39] <greyback> Saviq: And we shall separate the QPA plugin from the Ubuntu.Application qmlplugin out into 2 separate packages, no?
[16:40] <Saviq> greyback, IMO we need three
[16:40] <Saviq> greyback, QPA plugin, app-facing Ubuntu.Application, shell-facing Unity.Application or so
[16:40] <Saviq> greyback, and then there's the separate mirserver QPA plugin, right?
[16:40] <greyback> Saviq: well we need to decide if there's a need for app-facing U.A, no?
[16:40] <Saviq> greyback, indeed
[16:41] <Saviq> greyback, you will probably know best
[16:41] <greyback> Saviq: will see.
[16:41] <greyback> yep, separate QPA plugin for server
[16:41] <Saviq> greyback, shell-facing should really be named something else, too
[16:41] <Saviq> wth is Ubuntu.Application anyway
[16:41] <greyback> agreed
[16:42] <greyback> terrible name
[16:42]  * Saviq calms down now
[16:42] <Saviq> eod
[16:42] <greyback> Saviq: good evening!
[16:43] <pete-woods> mterry: sure, what do you need?
[16:44] <Saviq> greyback, ditto
[16:45] <mterry> pete-woods, never mind, I wanted you to bug katie when she appeared tomorrow (I'll be off tomorrow), but I just commented in a MR and subscribed her instead
[16:45] <mterry> pete-woods, thanks anyway!
[16:45] <mterry> pete-woods, it is about the infographic on initial boot
[16:45] <mterry> pete-woods, that hasn't been decided how it will look, has it?
[16:46] <pete-woods> mterry: katie and I had a conversation about it
[16:46] <pete-woods> and we/she decided that basically having the circle visible, no blobs, and a label saying something along the lines of "no data" would be fine
[16:47] <mterry> pete-woods, hmm, OK.  So that could be done on the UI side
[16:47] <mterry> pete-woods, I'll add that to my branch to use libusermetrics
[16:47] <pete-woods> mterry: I actually think it'll happen automatically now
[16:47] <mterry> pete-woods, oh?  Is libusermetrics updated to fake that for us?
[16:48] <pete-woods> mterry: the backend should just not return an empty string for no data, but instead give the "no data" label instead
[16:48] <pete-woods> mterry: the mock backend could be made to do the same, too!
[16:48] <mterry> pete-woods, is this in trunk?
[16:51] <pete-woods> mterry: should be
[17:00] <sil2100> dpm: I'll try to publish unity today, but I would opt for tomorrow most probably :(
[17:00] <sil2100> See you later!
[17:09] <nic-doffay> mzanetti, you get any spam on output with your branch?
[17:09] <nic-doffay> ApplicationsFilterGrid etc
[17:10] <mzanetti> nic-doffay: hmm... I think thats in trunk already.
[17:10] <mzanetti> nic-doffay: and I think there is another branch that fixes it already
[17:10] <nic-doffay> mzanetti, cool.
[17:10] <nic-doffay> testing now...
[17:10] <mzanetti> nic-doffay: anyways, they are not caused by the cange of the animation distance I would assume
[17:11] <nic-doffay> mzanetti, just looked at the diff now! haha yeah
[17:12] <nic-doffay> mzanetti, approved, it looks wicked
[18:22] <Saviq> jeez almighty how I hate bzr ;(
[18:50] <kgunn> Saviq: bzr...what now ?
[19:17] <ritz> smspillaz hi , wrt https://smspillaz.wordpress.com/2012/12/13/experimental-ppa-with-performance-improvements/
[19:17] <ritz> and https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861268
[19:18] <ritz> if I understand , this should help minimize the rendering issue ?
[19:19] <mterry> How come qtsystems from the Qt5 proper PPA never made it to saucy?
[19:23] <mterry> Ah, I see it has a bug: bug 1190896
[19:37] <seb128> mterry, you need it as well? ;-)
[19:38] <seb128> mterry, it's in the ppa if you want to start using it, I'm planing to ping Mirv about it when he's back from holidays next week
[19:38] <seb128> mterry, (I need it for the system settings storage infos)
[19:38] <mterry> seb128, I'm looking at it for backlight information
[19:44] <ritz> upower dbus call ?
[19:44] <ritz> for backlight info ?
[19:45] <seb128> mterry, https://launchpad.net/~ubuntu-sdk-team/+archive/ppa/+packages?field.name_filter=qtsystems&field.status_filter=published&field.series_filter=
[19:45] <seb128> ritz, qml doesn't include "dbus call"
[19:45] <seb128> ritz, dbus is not an api anyway, you usually want a library wrapping dbus
[19:46] <ritz> agreed
[19:46] <mterry> seb128, yeah it's also in qt5-proper PPA
[19:46] <ritz> okay, which project is this ?
[19:47] <seb128> ritz, ubuntu touch
[19:47] <seb128> we have qml UIs on there
[19:47] <ritz> it is a huge project
[19:47] <seb128> but qtsystem is just fine, not sure what you try arguing about
[19:47] <seb128> we just need it in saucy, which will happen once Mirv is back
[20:10] <Saviq> kgunn, it's partly launchpad's fault, because we use the unity project before, it's decided to copy all the tags from there, even though they share no revisions...
[20:11] <Saviq> kgunn, and I don't think there's a way to fix that short of deleting the branch (and the corresponding MRs, as a result) and pushing again
[20:11] <Saviq> kgunn, even though locally I was able to delete the tags, but it says that there's no revisions or updates to push/pull
[20:14] <kgunn> Saviq: ug...so we get to push all that data around every time (so no speed up)
[20:14] <Saviq> kgunn, no no
[20:14] <Saviq> kgunn, it's just tags
[20:14] <Saviq> kgunn, it's a rev : name mapping
[20:14] <Saviq> or rather name : rev mapping
[20:14] <kgunn> Saviq: oh...so not that bad....just annoying
[20:15] <Saviq> kgunn, yeah, `bzr tags` and you see everything lp:unity had from v0.1
[20:15] <Saviq> with ? as the revisions they relate to...
[20:16] <Saviq> hah!
[20:17] <Saviq> bzr tag --delete $tag_name -d lp:unity8
[20:18] <Saviq> I tried `bzr tags -d lp:unity8` and that failed, but deleting them works fine <facepalm>
[20:18] <Saviq> one by one, but there's nothing that bash can't handle
[21:19] <Saviq> fginther, ping
[21:23] <fginther> Saviq, hello
[21:24] <Saviq> fginther, hey, just wanted to check - do we have mergers set up for both lp:unity8 and lp:unity/8.0?
[21:24] <fginther> Saviq, yes
[21:24] <Saviq> fginther, awesome, thanks
[21:24] <fginther> np